Myself086 / Project-Nested

MIT License
493 stars 17 forks source link

Kirby’s adventure keeps crashing at certain points despite finishing it while keep adding sram to it #59

Closed johneymute closed 2 years ago

johneymute commented 2 years ago

While i was able to beat the game on snes9x while adding new generated save files to it after each world,

1 the game still keeps randomly hickong up when performing those same movements,may ask why that is? because i was even replaying the game after finishing it to keep pregenerating sram to patch it with the game just to make sure it get’s enough routine calls later on,but nope because after all that replaying it still does show spikes at times and it still does run slow once there’re a few enemy’s on screen, and once i played it on the powerpak it still does eventually crash by saying ram is full(note: that i attempted several times to get kirby’s adventure to run on the snes everdrive after trunscating the rom but all i just get is a black screen, 2, the game does sometimes crash and the boss of world 3 by saying that “this form of emulation is not yet fully supported by nested” 3,In world 4 i got at 2 places an error massage saying “unknown exception this exception has no tag or was generated by the jit compilor with a pc value of 0x00FF1B, I used nested 1.5 so you will know that.

Myself086 commented 2 years ago
  1. Show me video evidence of "hickong up". Otherwise yeah this game is slow for multiple reasons. This game has a high call source count (SRM saves call destination) which slows down emulating return from sub-routine when using non-native return address. This game also does a lot of PRG bank switching which has an overhead of about 100 cycles each on MMC3.
  2. Read the error name, I'm guessing it's "Interpreter fail". Kirby has self-modifying code for its IRQ handler. I added a few more opcodes in the interpreter just to get this game running but I didn't bother writing every opcode. It's possible that a new IRQ handler was written and didn't support an opcode in it. The address for the interpreter should be in page 0 if that's the case.
  3. That's very interesting, 0x00FF1B is a mirrored CPU Derailed. The correct address is 0x80FF1B but it somehow found its way into it! 0x00FF1B can be reached if either: NMI at vblank is enabled, native return address is enabled, stack overflow or maybe something else I'm forgetting. Stack overflow can sometimes be fixed by disabling "Stack page 01".
johneymute commented 2 years ago

Wow thanks for mentioning this,now am gonna see what am gonna do when i will take the time for it, if i can indeed also upload video’s to this sote,then i will definitely do that as well,but it’s no surprise that this game is a huge technical demanding game.

johneymute commented 2 years ago

IMG_2680 heres an error massage i got during gameplay,however it's a different error massage then before but it's similar to the error massage wich does say that the ram is full,also note that i hardly tryed to get that unknown exception error massage at those same places but i couldn't get those massages again,otherwise i would,ve certainly snapped a picture of them,now do you have an emailadress sothat i can send you the video because as expected i can't send video's to github,i may as well update this commant too to rectifie things.

Myself086 commented 2 years ago

You can send it on my discord, link on the first tab of the spreadsheet.

https://discord.gg/dJRTc3yEEt

johneymute commented 2 years ago

https://youtu.be/zA8oZABKLsU

Hi i have sended you a link to my video on youtube where it does still show some spikes during gameplay despite i already went trough the entire game,it still do randomly show some spikes while doing the same moves like spitting or jumping etc,,, Let me know if you watched it so can can delete that video as soon as possible. Thanks alot.

Myself086 commented 2 years ago

If you're talking about the black bar appearing at the top of the screen when performing moves, that's because PPU emulation takes too much time. The game changes CHR bank for Kirby's sprites but also changes some BG CHR over time.

Performing moves always takes more CPU time than idling, especially if additional sprites are being rendered such as: wind, ice, fire, bigger Kirby, etc.

Level transition is slow because updating BG tiles adds about 100 cycles of overhead per tile, this is not very noticeable during screen scroll. However, the music pauses because NMI at vblank is disabled.

I watched the video and there's no sign of slowdown associated with the JIT recompiler.

johneymute commented 2 years ago

Oke thanks for mentioning this but still trough i do keep running out of memory saying ram is full or memory trim failure,but the more and more i keep updating the srm file,the lesser the chance this should happen,i got over 2000 calls of in srm BUT just imagine if kirby’s adventure will require over 10.000 calls of srm before running without hickups,then this whole srm ram updating process could take forever,but hey will will see what comes next.