I never touched the gyroscope code White Dragon was the last one to edit it but as i said it may have changed when i updated the sdl code
OpenBOR Test Build 6392
- Thread starter Kratus
- Start date
Why was it changed ? old one wasnt fine ? Can you revert to previous one ? Theres no need to be on latest version if previous one still works fine.
Im on android 8 tho so was it cause of problems with new android versions ?Not that im aware of any problems on android besides this one with gyro interfering.
Im on android 8 tho so was it cause of problems with new android versions ?Not that im aware of any problems on android besides this one with gyro interfering.
msmalik681 said:
Don't worry buddy, I checked at GitHub and didn't find any difference in the file "SDL_sensor.h", the one that has the gyroscope code.
I'm analyzing to understand how it works and after that will try to develop a solution. If you have any lights, please share here with us.
oldyz
Well-known member
Kratus
bglayer data/bgs/lift2/backb 0 0.7 0 0 0 0 -99999999 -999999999 1 0 0 0 0 0 1.1
bglayer data/bgs/lift2/backc 0 0.5 0 0 0 0 -99999999 -999999999 1 0 0 0 0 0 1.1
bglayer data/bgs/lift2/backd 0 0.6 0 0 0 0 -99999999 -999999999 1 0 0 0 0 0 1.1
#bglayer data/bgs/lift2/c1 0 0.4 0 300 0 0 90000000 900000000 1
#bglayer data/bgs/lift2/c2 0 0.2 0 300 0 0 90000000 900000000 1
fglayer data/bgs/lift2/f1 4 0 0 0 300 0 0 1 1 1 2 0 0 0 2 2 2 2 2
panel data/chars/misc/empty
order a
direction up
DIrection up is not happening , Bglayers scroll as if the lift where going down
Gyro: you could add an option to disable all axises, then after players configure all buttons on their pads, they can re-nable them to map the axises last (an alien 3 the gun type game controlled using the gyros of cellphones/wiimotes would be cool)
Continue bug - i was hoping the player "port" confusion was messing with the countdown level skip bugs, alas it is something else then....
bglayer data/bgs/lift2/backb 0 0.7 0 0 0 0 -99999999 -999999999 1 0 0 0 0 0 1.1
bglayer data/bgs/lift2/backc 0 0.5 0 0 0 0 -99999999 -999999999 1 0 0 0 0 0 1.1
bglayer data/bgs/lift2/backd 0 0.6 0 0 0 0 -99999999 -999999999 1 0 0 0 0 0 1.1
#bglayer data/bgs/lift2/c1 0 0.4 0 300 0 0 90000000 900000000 1
#bglayer data/bgs/lift2/c2 0 0.2 0 300 0 0 90000000 900000000 1
fglayer data/bgs/lift2/f1 4 0 0 0 300 0 0 1 1 1 2 0 0 0 2 2 2 2 2
panel data/chars/misc/empty
order a
direction up
DIrection up is not happening , Bglayers scroll as if the lift where going down
Gyro: you could add an option to disable all axises, then after players configure all buttons on their pads, they can re-nable them to map the axises last (an alien 3 the gun type game controlled using the gyros of cellphones/wiimotes would be cool)
Continue bug - i was hoping the player "port" confusion was messing with the countdown level skip bugs, alas it is something else then....
nsw25
Every new change need to be tested by launching a test build and if no problems are found, the code can be added to the master build. After that, a new engine version can be launched.
oldyz
Now I understand better. About the "direction up/down", I've read the manual and it seems that these directions never were good to use as "left/right". After the other problems are solved, I can take a look.
I don't know how your elevator level is working, but if you plan to make it the same as the Streets of Rage series, I suggest trying moving a panel entity in the "Z" axis to simulate a "fake" elevator movement.
You can check it in the SOR2X game, here's the link:
https://drive.google.com/drive/u/1/folders/1YhRvW0lV-CNU68BPboJEB-R3VMEQMByF
About the gyro I'm also looking for a solution, and for the "Continue bug" I need more information to help you. First we need to confirm if it's really a bug.
Everything is the same as the original 6391, except for the fixes I made in the controllers (Windows build) and the multihit issue (all builds).
As a new member contributing to the engine development, the first step is to gradually develop small fixes and a few improvements/additions to solve simple problems.
Every new change need to be tested by launching a test build and if no problems are found, the code can be added to the master build. After that, a new engine version can be launched.
Yeah, we have the same goal buddy. I will continue analyzing the engine to develop more solutions, but as a new contributor I have to go slowly and carefully to avoid mistakes.
oldyz
Now I understand better. About the "direction up/down", I've read the manual and it seems that these directions never were good to use as "left/right". After the other problems are solved, I can take a look.
I don't know how your elevator level is working, but if you plan to make it the same as the Streets of Rage series, I suggest trying moving a panel entity in the "Z" axis to simulate a "fake" elevator movement.
You can check it in the SOR2X game, here's the link:
https://drive.google.com/drive/u/1/folders/1YhRvW0lV-CNU68BPboJEB-R3VMEQMByF
About the gyro I'm also looking for a solution, and for the "Continue bug" I need more information to help you. First we need to confirm if it's really a bug.
oldyz
Well-known member
Kratus said:
Well, that is the main reason why the NS module features an older Openbor, (OpenBOv3.0 4153 April 22 2015 ) the "UP" "down" commands actually work.
it maybe a naive thought, but "copy/pasting" the code for this function from that version to your new version might fix it...
Kratus said:
The elevator BGlayers depend on the "up" command for their scrolling, & the elements that make it up are split to give it a parallax effect, never thoughabout using the z axis tho, ill check that out, it might enable other things as well...
Kratus said:
continue bug seems to be happening because of the 4 players. Basically if a player dies & the countdown is over, the level either crashes or it skips to the next level, in the levels.txt file.
might have some minor relation to the "no same" command not working when 4 players are enabled ( player 1 & 2 cannot choose the same player , but player 3 & 4 can)
a turtles example - you might end up with Leonardo p1, Michaelangelo p2, Leonardo P3, Leonardo p4
so it seems that enabling 4 players causes functions to break - there might be more, but those 2 are the most critical.
Another thing i did notice on your Openbor, enemies have the tendency to block more.
O Ilusionista
Captain 100K
Guys, we need some organization here.
Please, when reporting to Kratus , keep this in mind:
- Test your game on his 6392 to see if it works
- If not (or if you wanna compare), then test your game on the latest public build 6391 - https://github.com/DCurrent/openbor/releases/tag/v6391- UNDER THE SAME PORT (windows, Android)
- please only report bugs/give feedback about things related to this version, like if something was working on 6391 and its not working anymore (like the gyroscope) and/or some previous bug (like controls) are now working.
- Old bugs that are still happening should not be posted there. Post them at Github
- Old versions are not supported. So versions like "OpenBOv3.0 4153 April 22 2015" are pre-historical and should not be reported here.
- Please, DOUBLE CHECK your game before labeling something as a bug. I've lost the count of times when an user made a mistake and blamed the engine.
and, the most important:
Kratus is now starting to help us, willingly. So do not overload him with questions that are not important or with reports that have nothing to do with the version he is developing. Help him to help us.
Thanks.
Please, when reporting to Kratus , keep this in mind:
- Test your game on his 6392 to see if it works
- If not (or if you wanna compare), then test your game on the latest public build 6391 - https://github.com/DCurrent/openbor/releases/tag/v6391- UNDER THE SAME PORT (windows, Android)
- please only report bugs/give feedback about things related to this version, like if something was working on 6391 and its not working anymore (like the gyroscope) and/or some previous bug (like controls) are now working.
- Old bugs that are still happening should not be posted there. Post them at Github
- Old versions are not supported. So versions like "OpenBOv3.0 4153 April 22 2015" are pre-historical and should not be reported here.
- Please, DOUBLE CHECK your game before labeling something as a bug. I've lost the count of times when an user made a mistake and blamed the engine.
and, the most important:
Kratus is now starting to help us, willingly. So do not overload him with questions that are not important or with reports that have nothing to do with the version he is developing. Help him to help us.
Thanks.
oldyz
Well-known member
Kratus
I figured out what is going on with the elevator level, "direction up" is working, but i don't know if the following is a bug or that values now mean something different in newer builds...
turns out that in build 6392, using the any value below 1 makes the Fglayers/bglayers scroll at the right speed (compared to the older build) but opposite direction -
to fix it, values have to be more than 1
turns out that now {xratio} {zratio} 0.5 (a scrolling layer half the speed of background) value is now 1.5-ish
I am trying to figure out what this "equivalencies" are, because some aestetics may be broken in the newer build -
in order to fix the elevator level the following lines are like this now:
i sort of fixed it but is not an 100% exact match to what it looks like in the old build...
so what i am trying to figure out is a formula to find out the following:
IF 0.82 equals 1.182 & 0.6 equals 1.3999 then....
I figured out what is going on with the elevator level, "direction up" is working, but i don't know if the following is a bug or that values now mean something different in newer builds...
turns out that in build 6392, using the any value below 1 makes the Fglayers/bglayers scroll at the right speed (compared to the older build) but opposite direction -
to fix it, values have to be more than 1
turns out that now {xratio} {zratio} 0.5 (a scrolling layer half the speed of background) value is now 1.5-ish
I am trying to figure out what this "equivalencies" are, because some aestetics may be broken in the newer build -
in order to fix the elevator level the following lines are like this now:
Code:
#skull deco# BOR3.0 build 6392
bglayer data/bgs/lift2/backe 0 1.182 0 0 0 0 -99999999 -999999999 1 0 0 0 0 0 1.1
#skull deco# OpenBOv3.0 4153 April 22 2015
#bglayer data/bgs/lift2/backe 0 0.82 0 0 0 0 -99999999 -999999999 1 0 0 0 0 0 1.1
#
#chain walls FG# BOR3.0 build 6392
bglayer data/bgs/lift2/back 0 1.57 0 0 0 0 -99999999 -999999999 1 0 0 0 0 0 0.7
#chain walls FG# OpenBOv3.0 4153 April 22 2015
#bglayer data/bgs/lift2/back 0 0.43 0 0 0 0 -99999999 -999999999 1 0 0 0 0 0 0.7
#
#chains# BOR3.0 build 6392
bglayer data/bgs/lift2/backa 0 1.8 0 0 0 0 -99999999 -999999999 1 0 0 0 0 0 1.1
#chains# OpenBOv3.0 4153 April 22 2015
#bglayer data/bgs/lift2/backa 0 0.2 0 0 0 0 -99999999 -999999999 1 0 0 0 0 0 1.1
#
#walls# BOR3.0 build 6392
bglayer data/bgs/lift2/backb 0 1.304 0 0 0 0 -99999999 -999999999 1 0 0 0 0 0 1.1
#walls# OpenBOv3.0 4153 April 22 2015
#bglayer data/bgs/lift2/backb 0 0.7 0 0 0 0 -99999999 -999999999 1 0 0 0 0 0 1.1
#
#lift shaft# BOR3.0 build 6392
bglayer data/bgs/lift2/backc 0 1.5 0 0 0 0 -99999999 -999999999 1 0 0 0 0 0 1.1
#lift shaft# OpenBOv3.0 4153 April 22 2015
#bglayer data/bgs/lift2/backc 0 0.5 0 0 0 0 -99999999 -999999999 1 0 0 0 0 0 1.1
#
#lift mech# BOR3.0 build 6392
bglayer data/bgs/lift2/backd 0 1.399 0 0 0 0 -99999999 -999999999 1 0 0 0 0 0 1.1
#lift mech# OpenBOv3.0 4153 April 22 2015
#bglayer data/bgs/lift2/backd 0 0.6 0 0 0 0 -99999999 -999999999 1 0 0 0 0 0 1.1i sort of fixed it but is not an 100% exact match to what it looks like in the old build...
so what i am trying to figure out is a formula to find out the following:
IF 0.82 equals 1.182 & 0.6 equals 1.3999 then....
nsw25 said:i finally tested with 2 controllers.
1 controller is fine, but as soon as you open a game with 2 controllers it will no longer work.
this is an old issue and seems your version hasnt fixed it
What controllers are you using? And what happens really?
I tested with 1, 2, 3 and 4 controllers in different combinations (wired/wireless/PS4/XBOX 360/Keyboard/Touch) and worked fine.
Maybe the problem is related to some conflict between the controller type and the OpenBOR, I haven't tested other than official Sony or Microsoft for example.
oldyz
Well-known member
try remappingnsw25 said:
n64 usb & sabrent -
tho i was testing earlier with the sabrent, i had to remap it because it became controller 2 once i plugged in the n64 controller - OpenBOR does not seem to respect window's "preferred" device registry & gives controllers their own "ID" on this machine
I have this program called joyID that can allow you to re-do the order of controllers & openBor is the only program that ignores it
One thing i did notice is that NS's playable characters can't block anymore, but i have to check the newest build to see if it does the same thing
Guys, I'm trying to reproduce the same problem you are having in the test build 6392, but unfortunately it hasn't happened to me yet. Until now, all tested controllers are working fine with no ID/button changes.
In fact the new button detection code is more persistent and will memorize the current configuration to avoid ID changes, like oldyz said. However I will continue trying to reproduce it.
At the moment I'm doing some progresss on Android. After analyzing the Plombo controller code, now I can disable the gyroscope.
I will post a second test build soon
In fact the new button detection code is more persistent and will memorize the current configuration to avoid ID changes, like oldyz said. However I will continue trying to reproduce it.
At the moment I'm doing some progresss on Android. After analyzing the Plombo controller code, now I can disable the gyroscope.
I will post a second test build soon
Kratus I have been holding off doing too much work on the source code as there are some big changes in version 4.0 to come. And I am sure Damon Caskey did not want any other releases until 4.0 is complete.
Don't get me wrong I love having more developers working on the source code just saying it might be best to wait until 4.0 to see what issues need addressing after that release but there is no release date yet.
Don't get me wrong I love having more developers working on the source code just saying it might be best to wait until 4.0 to see what issues need addressing after that release but there is no release date yet.
O Ilusionista
Captain 100K
msmalik681 hum I have to disagree.
if Kratus build will fix some serious bugs (like the controls), I think it worth a new release for sure.
Because version 4.0 changes so much things that it would be a deal breaker for some - personally, I don't like some behaviours of that version and I will hold back using it for a while.
I would love to have a newer version which is not the 4.0, because something things were changed to a point that it had broken the backward compatibility - like the way DOT is handled by script.
if Kratus build will fix some serious bugs (like the controls), I think it worth a new release for sure.
Because version 4.0 changes so much things that it would be a deal breaker for some - personally, I don't like some behaviours of that version and I will hold back using it for a while.
I would love to have a newer version which is not the 4.0, because something things were changed to a point that it had broken the backward compatibility - like the way DOT is handled by script.
Actually, no, I am not OK with making this offshoot official. I gave Kratus permission to post a test build to try out some fixes - but I didn't realize it was going to be based on an older version of the code (and that's on me, looking back Kratus did tell me, I just misunderstood).
Why? Because it's effectively creating and supporting an alternate OpenBOR. As you can see form this thread - there's already a debate over which one to use. We have enough incompatibility and version confusion already, I'm not going to support literally doubling both. There is one OpenBOR, and that's it. These fixes are fantastic (awesome work Kratus), but ultimately they must be rolled into the main source - not the other way around.
That said, the one thing I was trying to hold off on (controller issues), I no longer have a problem inserting fixes. So far as I can tell Plombo has moved on to coding different game projects, and after this long I think we can say he's unofficially retired from OpenBOR. I mean that with absolutely NO disrespect - he's forgotten more than I'll ever know about low level coding, and IMO is second only to SX in terms of importance to the engine. And even if that wasn't true he has NO obligations here. It's just that I can't keep turning down control fixes in hopes his will get finished.
IOW, Kratus, as soon as you feel satisfied with your control fixes, send me a pull request and I will bring them into the mainline source.
Also, O Ilusionista, like we talked about I believe I know a way to get you backward compatibility with DOT.
DC
Why? Because it's effectively creating and supporting an alternate OpenBOR. As you can see form this thread - there's already a debate over which one to use. We have enough incompatibility and version confusion already, I'm not going to support literally doubling both. There is one OpenBOR, and that's it. These fixes are fantastic (awesome work Kratus), but ultimately they must be rolled into the main source - not the other way around.
That said, the one thing I was trying to hold off on (controller issues), I no longer have a problem inserting fixes. So far as I can tell Plombo has moved on to coding different game projects, and after this long I think we can say he's unofficially retired from OpenBOR. I mean that with absolutely NO disrespect - he's forgotten more than I'll ever know about low level coding, and IMO is second only to SX in terms of importance to the engine. And even if that wasn't true he has NO obligations here. It's just that I can't keep turning down control fixes in hopes his will get finished.
IOW, Kratus, as soon as you feel satisfied with your control fixes, send me a pull request and I will bring them into the mainline source.
Also, O Ilusionista, like we talked about I believe I know a way to get you backward compatibility with DOT.
DC
msmalik681
Man, I understand your point, but my thoughts are the same as the O Ilusionista. During years all my games used the v6330 as base and the v4.0 has too many changes. I will lose years of tests in the SOR2X for example, will need to re-test everything
However, an idea came to my mind. If I understand correctly, all builds from v6391 and below are using the v3.0 structure, and the alpha is using the v4.0 structure. So, maybe we can "extend" the lifetime of the v3.0 structure a little more, without changing the v4.0 structure unless the devs accept some changes and copy it to the master branch, at least until I can fix some problems like the controller and other small things.
It will give more time to some current projects to be finished in the v3.0 structure, and for new projects we can start in the v4.0 alpha directly.
Damon Caskey
I took a look in the Plombo's code and compiled a test build, it's really fantastic. However, your code is unfinished and will break compatibility with most consoles in its current state. Only the Windows/Android are working, and you can't customize the buttons yet.
Would be very good if he can finish it someday, but their updates are based on the v4.0 alpha and unfortunately it will bring us to the same problems I mentioned above.
In short, Plombos's code is a full rework, not a small fix like mine. We can't bring your code to the 6391 because he made changes in the entire engine, creating new menus and options. So, we need another solution that matches with the v3.0 structure.
I took a look in some custom branches and I found a simple way to disable the gyroscope feature in Android. Also I changed how the engine will deal with the controllers, now the "default" function will totally clear the previous configuration, instead of giving a predefined scheme.
In addition, now when a previously configured controller is not found, the engine will not show "bugged" schemes, now will show the "disconnected" message instead. It avoids the gyroscope to be wrongly configured in Android activating some buttons randomly, like the bWWd reported.
A correctly configured controller
What the engine shows when a configured controller is not detected in previous versions
What the engine shows when a configured controller is not detected in the new test build
What the engine shows when the "default" function is applied
Man, I understand your point, but my thoughts are the same as the O Ilusionista. During years all my games used the v6330 as base and the v4.0 has too many changes. I will lose years of tests in the SOR2X for example, will need to re-test everything
However, an idea came to my mind. If I understand correctly, all builds from v6391 and below are using the v3.0 structure, and the alpha is using the v4.0 structure. So, maybe we can "extend" the lifetime of the v3.0 structure a little more, without changing the v4.0 structure unless the devs accept some changes and copy it to the master branch, at least until I can fix some problems like the controller and other small things.
It will give more time to some current projects to be finished in the v3.0 structure, and for new projects we can start in the v4.0 alpha directly.
Damon Caskey
I took a look in the Plombo's code and compiled a test build, it's really fantastic. However, your code is unfinished and will break compatibility with most consoles in its current state. Only the Windows/Android are working, and you can't customize the buttons yet.
Would be very good if he can finish it someday, but their updates are based on the v4.0 alpha and unfortunately it will bring us to the same problems I mentioned above.
In short, Plombos's code is a full rework, not a small fix like mine. We can't bring your code to the 6391 because he made changes in the entire engine, creating new menus and options. So, we need another solution that matches with the v3.0 structure.
I took a look in some custom branches and I found a simple way to disable the gyroscope feature in Android. Also I changed how the engine will deal with the controllers, now the "default" function will totally clear the previous configuration, instead of giving a predefined scheme.
In addition, now when a previously configured controller is not found, the engine will not show "bugged" schemes, now will show the "disconnected" message instead. It avoids the gyroscope to be wrongly configured in Android activating some buttons randomly, like the bWWd reported.
A correctly configured controller
What the engine shows when a configured controller is not detected in previous versions
What the engine shows when a configured controller is not detected in the new test build
What the engine shows when the "default" function is applied
O Ilusionista
Captain 100K
Damon Caskey to not derail the topic, I will contact you by inbox then, because I am waiting for a solution for this issue since long time.
Damon Caskey said:
I hate to complicate things further, but I really do still want to merge the input rework into master. That's still something I think about on a daily basis, even if I'm not around here much anymore. Because, well, the input rework was and is finished except for platform support for Wii and other consoles. The biggest hold-up has just been me not wanting to work any further on the Wii control code for whatever reason. Recently, I've been thinking it might not be too bad to just rebase the work I had, merge it, and let someone else improve the Wii control code if they're interested. It's not even completely broken on the Wii; it's just a bit buggy.
That said, I haven't looked at these new control fixes, but unless they're a competing total overhaul of the input subsystem, I don't see any reason why they couldn't be merged if the work has already been done. Maybe it would be a bit of a shame to have Kratus's work disappear from the engine after only a short time, but that would also be true of not merging it at all.
O Ilusionista
Captain 100K
Plombo if its the WII port that is holding us to go on, I honestly to drop the Wii port and move on. The Wii port can't run the most up to date and/or good games anyway. I don't see a good reason to keep the WII port, if you ask me.
If this is too much radical, I would suggest you to merge the code and tell the players about the Wii controls have some issues. If someone really care about the Wii port, they would pop-up and fix it eventually. If not, drop that port.