Crash Bandicoot: Episode 1 and 2 - can't go in-game anymore #75
Comments
|
Love when additional accuracy breaks stuff.
Normally, reopen the issue. Not sure how the permissions are set up on this repo, but anyone should be able to reopen issues. |
|
I don't have permissions to re-open issues. Maybe it's something someone could talk to Feos about. |
This is approaching a point of no longer having benefits, so might as well remove it from the code. Only leaving the notification as a debug print. Fixes Rainbow Six Urban Chaos and allows Crash Bandicoot 1 back into game (if limited to 15, which is what the game kinda runs at). Related to #37 and #75.
|
Okay so Rainbow Six Urban Chaos decided it now had an issue with the recursive repaints workaround/hack that has been around ever since the early freej2me-plus days (came from zb3's fork), and Crash Bandicoot 1 and 2 should now be playable once locked to 15fps (at least they are here). I feel like this is the new frame limiter logic's doing... No matter since it is more accurate and is just exposing inaccuracies elsewhere. |
|
Sadly it doesn't seem like Crash Bandicoot always goes in-game at 15 fps, even with this setting there's a chance it will lock up with the aforementioned error. I also had the game destroy itself once even. But it's better than not working at all, and it's very good to see Rail Rider, Rainbow Six Urban Crisis and Rayman Bowling working again. |
|
LCDUI shenanigans, fairly sure it's the same for Crash as well even if it looks like it doesn't rely too much on it. Still tons of legacy code in there that might need some retaking... gonna queue that up alongside Textfield + Textarea input handling. |
It still maintains the improvements done since it was the default, just the "processInputs()" method and the related polling mode were removed in favor of the more direct command issuing. I can already see this causing regressions on the SDL frontend, but given how little i'm focusing on it at the moment, i don't see it as much of a loss, where this will very likely reintroduce the issue of no inputs being read when the game or app doesn't draw new frames until a new input is registered (which basically means a softlock). But other than that... this commit alongside the one immediately prior to it should fix a BUNCH of recently discovered regressions, like #75, # 71, #73 and to some extent (although untested), #66 at the same time maintaining compatibility with games that were fixed by the newer code, for example, Racing Fever 1 & 2.
It still maintains the improvements done since it was the default, just the "processInputs()" method and the related polling mode were removed in favor of the more direct command issuing. I can already see this causing regressions on the SDL frontend, but given how little i'm focusing on it at the moment, i don't see it as much of a loss, where this will very likely reintroduce the issue of no inputs being read when the game or app doesn't draw new frames until a new input is registered (which basically means a softlock). But other than that... this commit alongside the one immediately prior to it should fix a BUNCH of recently discovered regressions, like #75, #71, #73 and to some extent (although untested), #66 at the same time maintaining compatibility with games that were fixed by the newer code, for example, Racing Fever 1 & 2.
|
Indeed, this issue appears to be fixed now, thank you. |
Selecting "Jouer" freezes the game on the menu and spams
[WARNING] javax.microedition.lcdui.Canvas: Exception hit when painting graphics: Cannot read the array length because "CrashBandicoot.f.bz" is nullinto the console.This is as good of a time as ever to ask: what is the proper thing to do when the game breaks, the issue is created, the game is fixed, the issue is closed, then the game breaks again?
The text was updated successfully, but these errors were encountered: