Open Apaczer opened 1 year ago
I suspect this is a timing issue - similar graphical glitches to Sims 2: The Pets, possibly trying to load some graphics tiles before they exist in VRAM or something like that. Timing in gpsp is/has always been rather screwy. Good to have this issue tracked though, give another game that experiences the same/similar issue.
Yes, the same issue on "The Sims 2: Pets", which is no suprise as it was designed by the same person.
Video with gameplay: https://www.reddit.com/r/Bittboy/comments/i3tcxn/i_need_help_i_want_to_play_sim_2_pets_gba_in/
Tks Andy ๐
On Sun, Aug 27, 2023, 22:39 andymcca @.***> wrote:
I suspect this is a timing issue - similar graphical glitches to Sims 2: The Pets, possibly trying to load some graphics tiles before they exist in VRAM or something like that. Timing in gpsp is/has always been rather screwy. Good to have this issue tracked though, give another game that experiences the same/similar issue.
โ Reply to this email directly, view it on GitHub https://github.com/libretro/gpsp/issues/224#issuecomment-1694757242, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWUIZIGFOFOW5RNVWFGDYZDXXOWBLANCNFSM6AAAAAA4AQRFOY . You are receiving this because you authored the thread.Message ID: @.***>
"Monster House" same Game Developer, same issue (maybe less evident).
I don't think there are others.
On Mon, Aug 28, 2023, 10:22 Apaczer GH @.***> wrote:
Yes, the same issue on "The Sims 2: Pets", which is no suprise as it was designed by the same person.
Video with gameplay:
https://www.reddit.com/r/Bittboy/comments/i3tcxn/i_need_help_i_want_to_play_sim_2_pets_gba_in/
Tks Andy ๐
On Sun, Aug 27, 2023, 22:39 andymcca @.***> wrote:
I suspect this is a timing issue - similar graphical glitches to Sims 2: The Pets, possibly trying to load some graphics tiles before they exist in VRAM or something like that. Timing in gpsp is/has always been rather screwy. Good to have this issue tracked though, give another game that experiences the same/similar issue.
โ Reply to this email directly, view it on GitHub https://github.com/libretro/gpsp/issues/224#issuecomment-1694757242, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWUIZIGFOFOW5RNVWFGDYZDXXOWBLANCNFSM6AAAAAA4AQRFOY . You are receiving this because you authored the thread.Message ID: @.***>
Thank you @Apaczer - I asked a user on GBATemp to check for the existence of this bug on TempGBA. He said -
_**TempGBA 20160527
-Sims 2:The Pets PAL
Intro was fine. Graphics looks fine to me. Fullspeed
-Tiny Toon Adventures - Buster's Bad Dream PAL
Intro was fine and I couldn't spot any graphical issues. Games had some slowdowns with many enemies at ones but emulator was still showing (60/60) so it's probably just how the game behaves**_
So this is interesting - TempGBA doesn't seem to have this bug. I have seen this situation before, so I will try and troubleshoot by comparing the code.
OK, so speaking with David he tells me this is a timing issue.
gpsp is focused on speed rather than accuracy, so whilst there is some cycle counting going on to make sure things work well enough, it's a balancing act.
Doing some crude testing with the code (setting a penalty on ARM/Thumb default instruction cycles), sure enough, I can reduce the visual glitching on Sims 2 but at the expense of introducing glitches to the audio and slowing down video rendering. I haven't found a combination that yields acceptable performance with this method, nor would I really expect to - it requires more thought and coding to address properly. So I think these games are just particularly susceptible to some aspect of timing
TempGBA-Mod seems to take a different approach to timing and is targeted at the PS2/PSP CPU only. I'd be interested to know how Sims 2 works in something like ReGBA (derived from TempGBA) on an Opendingux device.
I appreciate the whole effort and explanation!
For ReGBA testing I would use QEMU for mips handheld e.g.: https://steward-fu.github.io/website/handheld/a320/opendingux/build_qemu.htm. Preferably it would be the best to try compile PC build of that emu (could look into it after 2 weeks cuz I'm abroad now ๐)
BTW we have also QEMU for Miyoo AMR32 (see our main page) but they're not the most accurate source AFAIK
Regards!
On Sat, Sep 2, 2023, 13:25 andymcca @.***> wrote:
OK, so speaking with David he tells me this is a timing issue.
gpsp is focused on speed rather than accuracy, so whilst there is some cycle counting going on to make sure things work well enough, it's a balancing act.
Doing some crude testing with the code (setting a penalty on ARM/Thumb default instruction cycles), sure enough, I can reduce the visual glitching on Sims 2 but at the expense of introducing glitches to the audio and slowing down video rendering. I haven't found a combination that yields acceptable performance with this method, nor would I really expect to - it requires more thought and coding to address properly. So I think these games are just particularly susceptible to some aspect of timing
TempGBA-Mod seems to take a different approach to timing and is targeted at the PS2/PSP CPU only. I'd be interested to know how Sims 2 works in something like ReGBA (derived from TempGBA) on an Opendingux device.
โ Reply to this email directly, view it on GitHub https://github.com/libretro/gpsp/issues/224#issuecomment-1703791242, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWUIZIGC6JRMZC6MPY7RIYLXYMCRVANCNFSM6AAAAAA4AQRFOY . You are receiving this because you were mentioned.Message ID: @.***>
Thank you @Apaczer !
I actually made a bit of progress on this issue -
https://github.com/libretro/gpsp/blob/188887e6c8a5e5d6b3282e2b07804d0cf3db5314/main.c#L114
If we change the baseline value in this line from -64 to a positive value (say, 4), then this clears up all visual issues in Sims 2 and Teen Titans. The downside is it breaks all other games ๐
I have reported this to David but I'm not sure why this works and whether it is something that we can even utilise. Still, if you wish to build with that change then you can play these two games and maybe Monster House only ๐
Teen Titans seems to have a separate issue where you get to the 'this icon means the game is saving' screen on the intro, in that it stays on this screen for a few seconds and then either reboots to the Gameboy logo or freezes the emulator (this happens regardless of the change above)
Monster House also hangs on the 'Create Game' screen.
Probably worth checking the other games from this developer / release year(s) to see if the same problems occur - https://en.wikipedia.org/wiki/Behaviour_Interactive#Titles
I tried to bisect it and I got similar crash on "Monster House" and "The Sims". However these were very random and usually had happend after loadstate (no log), to be sure I would have to reproduce it on another platform.
@andymcca I was following David Richard dev work, where he was lead designer.
Yes I've noticed that once changing the line mentioned above, you also need to have .srm or .sav files in place beforehand (depending if save type is set to libretro or gpsp respectively) in order for the games to work. Otherwise you'll be met with a blank screen on load. Even then, if you attempt to save in-game it will crash as described above! Probably causes a race condition or similar
Anyway, all shooting in the dark a bit - needs proper investigating and solving by someone more knowledgeable than me! ๐
@Apaczer I'm looking at this again ๐ as of the current commit, for Sims 2 The Pets you need to change the MAX of remaining_cycles to either be -256 to see the 'Warning' splash screen at the start, or to 4096 or higher to remove in-game graphics glitches.
The issue seems to be connected to entering the loop in the update_gba function in main.c when the CPU is in an active state. It needs to go into the loop once to check Timers/IRQs/DMAs, but this seems to mess up the graphics so my gut feeling is that graphics transfer DMAs are being interrupted/aborted early somehow. When setting remaining_cycles to 4096, this greatly limits the number of times video_count goes below 0, which stops the above.
@davidgfnet - any thoughts? I'm still investigating/playing with it.
I did a PR for this based on commenting out the below line -
https://github.com/libretro/gpsp/blob/4caf7a167d159866479ea94d6b2d13c26ceb3e72/main.c#L265
It makes the games work but stops the sync between execute_cycles and video_count, so execute_cycles never gets updated and it makes some other games run very slowly.
A better change which seems to work well for all games including those in this issue is -
execute_cycles = MIN(video_count, 96);
EDIT: having run some more tests I think the above works by allowing timers/irqs/dma transfers to be initiated in a more timely manner in relation to the scanlines being rendered. Unedited, the current code enters the update_gba function between 600-800 times a frame. With this change, it enters the function around 3000 times, whilst still maintaining 456 entries into the video_count if statement and approx 280896 cycles run per frame as normal.
The instances where update_gba is entered where video_count > 0 are greatly increased, meaning that timers are checked and irqs flagged earlier.
These games generate a huge number of interrupts per frame compared to other games, hence the timing appears to be far more sensitive. The change above seems to work well on all games I've tried so far, including these, with no speed or other penalty that I can see. If anyone else can build and test, it would be appreciated!
Big ๐ @andymcca, I tried with this change:
diff --git a/main.c b/main.c
index 55401d7..df14d3b 100644
--- a/main.c
+++ b/main.c
@@ -265,7 +265,7 @@ u32 function_cc update_gba(int remaining_cycles)
execute_cycles = MAX(video_count, 0);
{
u32 cc = serial_next_event();
- execute_cycles = MIN(execute_cycles, cc);
+ execute_cycles = MIN(execute_cycles, 96);
}
// If we are paused due to a DMA, cap the number of cyles to that amount.
this change indeed fix the issue on "Teen Titans (USA)" and "The Sims 2: Pets" and as you said there is performance penalty (tried with unrelated game "Castelvania AoS" to be sure). Moreover it seems "Monster House" still suffers (not as much as before!), for e.g. you can see glitching on round sprites' shadows.
@Apaczer good to hear!! Slight error in your change though, from your diff it looks like you changed the wrong line. In the most current commit the change should be changing line 265 in main.c from -
execute_cycles = MAX(video_count, 0);
to -
execute_cycles = MIN(video_count, 96);
You should find this works without a performance hit. Also, you can limit the character shadow problems in Monster House by turning on Interframe Blending
ah, yes sry for mistep! Tried now with:
diff --git a/main.c b/main.c
index 55401d7..71b3bcb 100644
--- a/main.c
+++ b/main.c
@@ -262,7 +262,7 @@ u32 function_cc update_gba(int remaining_cycles)
// Figure out when we need to stop CPU execution. The next event is
// a video event or a timer event, whatever happens first.
- execute_cycles = MAX(video_count, 0);
+ execute_cycles = MIN(video_count, 96);
{
u32 cc = serial_next_event();
execute_cycles = MIN(execute_cycles, cc);
much better now, I would say it is 5รท3fps drawback (propably could be overcome with platform specific optimization) - tested on armv5.
BTW: The Interframe Blending
opt helps a lot! ๐
@Apaczer Excellent! Yes you will definitely feel it more on armv5 platforms, as they usually seem to be single core/lower cache/software fpu.
Yeah Interframe Blending really helps when the games try and do that 'flicker' effect that the GBA has, other games that do it that I know about are Phantasy Star 1 and Steel Empire.
By the way - could you help test my Draft Pull Request which fixes the sprites in areas in Golden Sun 1/2 and Zelda Minish Cap? It's all described in issue #227 and the Pull Request is the only one open at the moment. I know it works as-is but I'm not sure of what the performance hit is. Testing on an Armv5 would be useful (my old Armv5-based console has bitten the dust unfortunately!)
sure, will try with those changes (saw the PR gratz!), glad to be of any help and see progress.
sure, will try with those changes (saw the PR gratz!), glad to be of any help and see progress.
Hey @Apaczer , I created my own fork of lr-gpsp just to incorporate all my PRs and experiments!!! I've put it here -
https://github.com/andymcca/lr-gpsp-amcc
Could you please build it when you have time and try it out? It should work a bit nicer on older/less powerful devices like ARMv5te, though I'm not too sure what the compatibility will be like!
@andymcca, sent a DM via mail, didnt want to go offtopic here ๐
Issue: Blank screen during startup animation and many graphical glitches in gameplay.
INFO: I tested it with older revision of libretro and the newest one, also present in old standalone port. First noticed in https://github.com/TriForceX/MiyooCFW/discussions/482#discussioncomment-5319121
Commit: https://github.com/libretro/gpsp/commit/188887e6c8a5e5d6b3282e2b07804d0cf3db5314 Engine: Interpreter/Dynarec Platform: Win x86_64, Miyoo ARM32