@HiSaturnV I saw that you pushed a new release to Github today. I noticed though that the HW builds you uploaded do not appear to reflect the changes you noted. The SW builds appear to do so.
Gotcha, I think I might've messed up the files. I've recompiled the HW build and edited the release, let me know if the changes are present.
I'm back, and i can confirm that the third .cia posted before the official 1.30v (is it the same?) seems to work perfectly. No crashes after a good 45/60 minutes of gameplay, 3D still works perfectly, and i was able to exit the game normally (which was solved in the previous version).
I didn't get to play a special stage, i assume those still look strange. But if you can overlook that tiny issue, this port is just perfect
Also, i'm testing on O3DS so yes, this runs fullspeed even while using 3D, so go ahead and install it!
edit: the menus on the time attack part of the game look weird! i just found out. Not a dealbreaker, still playable. But there's that
Yea, Time Attack is weird, mainly because the HW backend doesn't fully take palettes into account as of yet.
The Retro Engine is kinda built like an old game console in that graphics loaded need to take into account a limited set (or palette) of 256 colors. Older game consoles had support for paletted textures (which would make implementing something like this trivial), but unfortunately, the 3DS doesn't appear to, at least, in 3DS mode. This is why palette-based effects don't work correctly in the current HW build. If I remember correctly, this is also why some 3DS emulators don't work well with games that use specific palette-based effects. The SW backend, while inefficient, allows these effects to be rendered correctly, by virtue of manually placing each pixel on the screen, checking graphics against the current color palette.
Thing is, the Retro Engine stores 8 palettes internally, and from what I've seen, these palettes appear to be static. I think caching the graphics against all 8 palettes and creating a reference to the current palette texture index should be enough to implement palette cycling, as well as fix most palette-related issues.
That said, graphics need to be rearranged (tiled/swizzled) to play nice with the 3DS's graphics chip (PICA200), and the current way the HW build does this is kinda inefficient, in that it rearranges graphics in real time. This is part of the reason why load times suck on O3DS. Considering the game's tilesets should all be the same size, I think introducing a lookup table and caching graphics against that should speed things up considerably, as well as make it easier to cache versions of the tileset using all 8 palettes.