OpenBOR Test Build 6392
- Thread starter Kratus
- Start date
Plombo
Man, it's a honor to have you here, your controller rework is fantastic! I compiled a build using your branch yesterday and did some tests, the automatic detection and configuration work like a charm.
I totally agree with you about moving on even if we lose some old console ports, because the engine will make a huge progress in the controller department. In my opinion, I'm ok having only Windows/Android builds for now.
Don't worry about my fixes, you can move on, it's the best way to the OpenBOR community. My changes are only small adjustments focused on v3.0 structure (builds 6391 and older) to fix long time problems. I'm doing this to help most modders (like me) that are using these builds and would lose too much time remaking and testing your projects in the new 4.0 alpha.
EDIT: I only have one thing to ask. Would be good if you allow the buttons to be customized, like in previous builds
Man, it's a honor to have you here, your controller rework is fantastic! I compiled a build using your branch yesterday and did some tests, the automatic detection and configuration work like a charm.
I totally agree with you about moving on even if we lose some old console ports, because the engine will make a huge progress in the controller department. In my opinion, I'm ok having only Windows/Android builds for now.
Don't worry about my fixes, you can move on, it's the best way to the OpenBOR community. My changes are only small adjustments focused on v3.0 structure (builds 6391 and older) to fix long time problems. I'm doing this to help most modders (like me) that are using these builds and would lose too much time remaking and testing your projects in the new 4.0 alpha.
EDIT: I only have one thing to ask. Would be good if you allow the buttons to be customized, like in previous builds
Kratus,
I think I see one big issue with your outlook on 4.0. That alpha build was a test, just like yours is now, and nothing more. At the time, it was based on one of my working branches. It was never mainline, and it's literally years behind now. You need to compile your own builds of the current source to get a better idea of where it is.
Incidentally, many of my changes aren't even in place since I tend to work for extended periods on branches and then push them in bulk.
Plombo,
It is really good to see you here. Meant everything I said. You don't need to feel obligated, but it would be incredible to have you back as a regular contributor.
On dropping ports? I'm not sure about dropping Wii, just from observation it seems we still have a sizable user base on it. Talk me into it - wouldn't be that hard, lol. Totally agree on PSP. AFAIK the PSP scene is dead, it can't run newer modules anyway, and it's not like the old stuff suddenly stops working if we drop support.
DC
I think I see one big issue with your outlook on 4.0. That alpha build was a test, just like yours is now, and nothing more. At the time, it was based on one of my working branches. It was never mainline, and it's literally years behind now. You need to compile your own builds of the current source to get a better idea of where it is.
Incidentally, many of my changes aren't even in place since I tend to work for extended periods on branches and then push them in bulk.
Plombo,
It is really good to see you here. Meant everything I said. You don't need to feel obligated, but it would be incredible to have you back as a regular contributor.
On dropping ports? I'm not sure about dropping Wii, just from observation it seems we still have a sizable user base on it. Talk me into it - wouldn't be that hard, lol. Totally agree on PSP. AFAIK the PSP scene is dead, it can't run newer modules anyway, and it's not like the old stuff suddenly stops working if we drop support.
DC
Damon Caskey said:
Damon Caskey
Yeah, I confess that sometimes I get a bit confused with the builds sequence. For example, the GitHub labeled the 6391 as the latest, but we have the 6412, 6510, 4.0 alpha and the master-branch... But if I understand correctly, the 4.0 alpha is an old test build, as you explained.
The only thing I can confirm is, any other after the 6391 has too many changes and unfortunately doesn't work well for SOR2X. But for new projects, I will try the master-branch directly.
dropping psp at this point is time is fine, openbor versions for smaller mods exist for psp so thats ok IMO, it has only 16MB of ram, so quite bad for most new mods.
I think leaving and maintaning ports with hardware that has 512mb of RAM and above is fine but lower amount of ram is just a gimmick , ideally linux,win,android and macos versions would be enough and maybe retroarch core even if i dont have good experiences with it on pc it can work fine on some consoles but im not sure if openbor allows running paks from commandline.Its on quite a bit of platforms.
I think leaving and maintaning ports with hardware that has 512mb of RAM and above is fine but lower amount of ram is just a gimmick , ideally linux,win,android and macos versions would be enough and maybe retroarch core even if i dont have good experiences with it on pc it can work fine on some consoles but im not sure if openbor allows running paks from commandline.Its on quite a bit of platforms.
NickyP
Active member
The PSP scene is pretty much done, but I'd say the Wii scene is still kicking. Apparently there's a lot of overlap with the Wii U and NES/SNES classics, so emulators and such for those platforms are regularly updated.
I do think a Retroarch core would be great, though. Especially if it offers the same auto configure feature for controllers as the other Libretro cores.
I do think a Retroarch core would be great, though. Especially if it offers the same auto configure feature for controllers as the other Libretro cores.
nsw25 said:
Yeah, although it has not happened to me yet, I saw that it was reported by other people in other builds. O Ilusionista reported it in 2019 and 2020, if I'm not wrong it is an issue related to global variables.
http://www.chronocrash.com/forum/index.php?topic=703.msg72766#msg72766
https://github.com/DCurrent/openbor/issues/111
About the 6392, there's a new test build. Here's the changes:
- Removed the "backtotitle" function and mixed with the "gotomainmenu" function, can be activated by using the new flag "9". I made this change to avoid engine crashes if a module has the new function but the user is playing in an previous engine build. Now the engine will only change the effect (gotomainmenu flag 6) instead of close due to the non existence of the "backtotitle" function in older builds
- Added the "disconnect" message in the controller configuration menu when a previous configured joystick is turned "off". Simply turn your controller "on" to get the configuration back, but only will work if the current joystick ID is the same as when it was configured previously.
- Changed the behaviour of the "default" function in the controller configuration, now it will clear all button configuration instead of apply a predefined scheme. Both Windows/Android systems will continue using your default devices even if it is not configured in the controller menu (for Windows is the keyboard and for Android is the touch), but this change will avoid "invalid" configurations that sometimes can activate wrong commands, like the gyroscope.
- Disabled the gyroscope in Android. I don't know if some modders are using this device, but I saw that other devs totally disabled the gyro, and I followed the same idea. However, if any modder thinks that it can be useful, I can test a way to enable the gyro in the menu.
After a lot of tests, I made some discoveries that I consider important things to share.
In the previous versions, the joystick IDs were changed anytime a device is turned on or off, causing a lot of trouble when the players are using wireless devices and the battery ends. Now in the test build, the IDs will be changed only during open/close operations, avoiding ID changes during gameplay.
It means that their IDs can change depending on the order you turn on your controllers. For example, in Android if you are using a bluetooth ps4 controller, everytime you turn it on when the engine is already open, the OpenBOR will map as P2 BUTTONS. But if you first turn on the controller and then open the engine, OpenBOR will map as P1 BUTTONS.
If I understand correctly, OpenBOR has a device scan order and the controller is always the first. If no controller is found, the engine will give the first IDs to other devices (for the Android, I think that the touch is counted as a joystick too).
Another thing I need to say is about the ID order. Everytime you open/close the engine, it will check if all previously configured joysticks are turned on. In case the player 1 joystick is turned off for example, all other IDs will be moved to a lower number:
- P2 joystick will be P1
- P3 joystick will be P2
- P4 joystick will be P3
So, if you turn your P1 joystick on when the engine is already open, it will not work because the P1 config was overwritten by another device. After that, you have two options:
1) close the engine, maintain all joysticks turned on, open the engine again and all devices will be automatically recognized. Once you has 4 devices, the engine will define a new ID to every one
2) clear the P4 config and configure the last "turned on" device as P4, because once all IDs were moved, the last ID will be available to use (in this case, the player 4 ID is empty).
The last thing is about the Android API level (security). Some people reported that the controller configuration could not be saved in my previous test build and now I discovered why.
In my first test build, I was using a higher API level and once you install the OpenBOR by the first time, it don't gives the enough time to grant a permission to access/change files. So, it means that the user needs to close and re-open the engine to grant the correct permission, otherwise all OpenBOR configuration changes in your first gameplay will not be saved.
Due to this I decreased the API level and now the permission will be granted once you agree to install the OpenBOR. Now the user can safety configure everything in the first gameplay and it will be saved correctly, at least until the test build is fully tested.
I recorded a video showing a controller test in SOR2X. I know that some people reported problems in the test build, but unfortunately I can't reproduce the same issue for every different controller type.
All my tests were made on the most commonly used devices, like PS4/XBOX joysticks.
https://www.youtube.com/watch?v=8UsA0LHxiL0
Before I forget, some people reported a antivirus warning, but it is due to some "false positives" in the the Cyber Capture feature. Here's a quick explanation:
https://www.geeks3d.com/20200123/how-to-disable-avast-cybercapture-for-developers/
And finally, here's the file. Please, report in case you have any problem related to the changes in this test build:
https://1drv.ms/u/s!AnTXKPMHlONnhNgcD47dtwLZ3H31xw?e=ZoCzdp
O Ilusionista
Captain 100K
msmalik681
I liked the idea of a shutdown/restart option.
O Ilusionista
Don't worry buddy, it's a temporary change until the build is fully tested, like I said in the previous post. I did this to show that it's not a bug in the test build, the official 6391 does the same thing.msmalik681 said:
I liked the idea of a shutdown/restart option.
O Ilusionista
Good! I will wait for your feedback, buddy
O Ilusionista
Captain 100K
Kratus I've test your version on Mac (using Wine) and Android.
So far, everything works great for me. Since Wine has some issues with joysticks, I can't test it yet. But I will test on a windows machine soon.
There is only one minor thing I've noted: the buttons got cut at the left side
This never happened before. My phone is has a 18:9 - 1080x2160 resolution.
About the load bug nsw25 mentioned, it doesn't happens anymore on this version. I've tried my game in both platforms and the load game is working fine.
(I was about to remove the load function from my game because it wasn't working at all).
As I mentioned before, msmalik681 made a custom version where this were fixed but I can't remember the build name. Looks like the fix was included on the branch you are using.
The funny thing is: i've tested the 6391 version and the bug was there. So I don't know why its working, lol.
Nice job, buddy. I will do further tests
So far, everything works great for me. Since Wine has some issues with joysticks, I can't test it yet. But I will test on a windows machine soon.
There is only one minor thing I've noted: the buttons got cut at the left side
This never happened before. My phone is has a 18:9 - 1080x2160 resolution.
About the load bug nsw25 mentioned, it doesn't happens anymore on this version. I've tried my game in both platforms and the load game is working fine.
(I was about to remove the load function from my game because it wasn't working at all).
As I mentioned before, msmalik681 made a custom version where this were fixed but I can't remember the build name. Looks like the fix was included on the branch you are using.
The funny thing is: i've tested the 6391 version and the bug was there. So I don't know why its working, lol.
Nice job, buddy. I will do further tests
O Ilusionista
Thanks for the feedback, buddy
Tested your game on my phone using the Android 8.0, maybe the problem could be related to some differences between Android versions.
I took a look at GitHub and it seems that the malik's fix is based on the build 6412. You mentioned something about a "logo.gif" problem, I will check at the GitHub to see what was changed in the code.
bWWd
In addition, in the next test build I will include the "maximum paks" limit fix. You mentioned it in another post and I think it needs to be fixed to avoid the engine closing when the user has multiple paks.
msmalik681
Thanks for the feedback, buddy
It's good to know. What Android version are you using? It never happened to me before, but I can take a look in the source code to understand better.
Tested your game on my phone using the Android 8.0, maybe the problem could be related to some differences between Android versions.
Great! It's good to know that the bug didn't happen in the test build.
I took a look at GitHub and it seems that the malik's fix is based on the build 6412. You mentioned something about a "logo.gif" problem, I will check at the GitHub to see what was changed in the code.
bWWd
Very good! Thanks for the feedback.
In addition, in the next test build I will include the "maximum paks" limit fix. You mentioned it in another post and I think it needs to be fixed to avoid the engine closing when the user has multiple paks.
msmalik681
Great! And would be good if the engine freezes until the permission is granted by the user.
oldyz
Well-known member
Kratus
I ran into the player 3 controls player 2 issue...
i had 3 360 wireless controllers & one wired 360 controller & since i had plugged in the wired controller last it was controller 4
then after mapping all the buttons, we started the game but player 2 & 3 would simultanously move & act with one controller.
the solution was to end the game, reconnect the wired 360 first, then the wireless ones
then i deleted all files in the saves folder, re-started the game, remapped everything, & everything worked fine.
Another issue that i have run across, is that characters keep moving in the last direction they where going from one level to the other, but in this case i dont know if it was the controller itself....
I ran into the player 3 controls player 2 issue...
i had 3 360 wireless controllers & one wired 360 controller & since i had plugged in the wired controller last it was controller 4
then after mapping all the buttons, we started the game but player 2 & 3 would simultanously move & act with one controller.
the solution was to end the game, reconnect the wired 360 first, then the wireless ones
then i deleted all files in the saves folder, re-started the game, remapped everything, & everything worked fine.
Another issue that i have run across, is that characters keep moving in the last direction they where going from one level to the other, but in this case i dont know if it was the controller itself....
O Ilusionista
Captain 100K
Wired controllers takes precedence over wireless ones - and this isn't related to OpenBOR, but with Windows itself.
Plus, as bWWd said, you always have to delete the save folder before testing a new build - the results can be pretty weird if you don't.
Kratus My phone is Android 9.
Is still early to say, but it looks like the buttons on Android build are "missing" the press more than before. For example, on my game, you can use the CHARGE command with Thor (hold SPECIAL them press JUMP). The SPECIAL button looks to stop register the press if you move your finger slightly to any side while pressing. Same with the UP arrow.
I remember I had tested the 6391 for just few times and I quit from it thanks to a bind() issue (which doesn't happens in 6392) but I don't remember having this issue.
Again I still need to test it more to see I am not rusty, but since I play my game almost everyday on android, its very rare to me to miss an input like DOWN UP A, but I've noticed on this version the move fails a bit.
I will keep you informed.
EDIT: Saddly, the load bug is still present
O Ilusionista I took down the release after 6391 as it had a terrible bind bug. What is this load bug you mentioned?