[quote author=darkmoon2321 link=topic
I didn't know this. I'll have to take a look and see if I can find out what's happening. I must have missed something.
Edit: I'm not convinced this is from me. I just ran both versions up to this boss using an invincibility cheat to test, and both showed some pretty glitchy graphics. I think there are just too many overlapping sprites trying to be displayed at once. The way the boss curls around on itself makes it particularly prone to glitchy sprites. However, I did find a potential bug. At $80/9166, it should be changed to:
In other words, extended OAM data needs to be saved prior to checking whether there are too many sprites on-screen. Otherwise the extended OAM data (size toggle, X MSB) might not be saved for the last few sprite tiles in the event that there are too many sprites on-screen at once.
There actually was glitchy graphics in the fire stage while fighting the boss but the 4 lines of code you posted fixed it.
@darkmoon2321 and Aaendi
The optimizations that you two have done so far are great! Not sure if you two can optimize anymore of the code but there are still significant slowdowns on the 2nd level with all the big bubbles. The slowdown looks like it’s coming from the function before the sprites function at 00:878E.
I played around a little bit with the assembly and I was able to optimize some of the code but it’s not better than the optimizations that have already been done. I’ll probably look into optimizations at a later time if there are still slowdowns. Right now I’m currently rewriting all of the assembly for gradius 3. Gradius 3 uses a lot of long jumps (JSL’s) instead of using JSR’s and the assembly has a lot of rep 10, rep 20 when it should be rep 30. I’m also finding a lot of spots where they are using too many reps and seps by not organizing the code inside of the functions. So yea I’m doing a complete rewrite. It’s probably going to take several weeks to complete.
Wish me luck
Hopefully this will give a minor speed up. I’m not really expecting much of a speed up if any but it is possible to get some speed up. After the assembly rewrite is completed, I’ll complete the fastrom hack, and then I’ll rip out all of the compression and expand the rom. I’ll probably start getting some of the sram features implemented after all of that.