Xenon 2 Megablast Port

[Napomex]

Hello everyone, 
I'm not a programmer, and apart from industrial controllers like Siemens S7 or a bit of Arduino, I can't code. 
Multiple attempts with Gamebuino and MakeCode Arcade didn't get me the success I was hoping for either, porting my favorite shoot 'em up since childhood. 

Nine months ago I made my first attempt at getting the whole thing running on the NGPC via GPT, which wasn't really successful. 
Now with Claude things look different, and I've made pretty good progress. Unfortunately, as great as AI is, it still doesn't replace people with actual understanding, right now I have three problems, one of which I'll probably manage to solve on my own.

Problem number one: the status bar at the bottom for score and lives currently consists of nine tiles that cycle through to create the effect of a static bar. 
The downside is that this needs too many tiles, and the approach someone suggested to me on Reddit works fine in the emulator but not on real hardware.

Problem number two: even though I haven't maxed out the sprite limit of 64, sprites keep disappearing. I'm trying to solve that today together with my friend Claude, though I'm not sure it'll work out.

Problem number three: with too many enemies on screen, the framerate drops. 
In emulation it runs reasonably smoothly, my guess is it's related to the collision detection, which gets killed once an enemy is dead or off screen. I'm out of ideas, and Claude seems to be out of a plan too.

I hope someone here can help me figure these problems out, because as a noob I'm honestly a bit lost.

https://www.reddit.com/r/ngpc/comments/1..._the_ngpc/

[Ahchay]

Hi, that was me on reddit, so I'm glad you found your way here.

Some actual code examples of the bits that are causing you grief will help, it's difficult to debug via trying to guide you to ask Claude the right questions. I guarantee you'll get better answers here, and we're a lot cheaper

[sodthor]

ADIH source code available here: https://github.com/sodthor/ngpcdev/tree/main/pdroms3
and other sources https://github.com/sodthor/ngpcdev

[Ahchay]

I wondered where that was hiding

[Napomex]

Problem 1 the status bar (SOLVED )
This was the big one. The old bar faked a "static" HUD by cycling through a bunch of pre-shifted tile variants it ate a lot of tiles and, as several of you predicted, the raster trick that worked in the emulator did not hold up on real hardware.

We finally got it working properly with a MicroDMA raster split: instead of a CPU interrupt rewriting the scroll registers every scanline (which flickered on hardware because the interrupt timing jitters during heavy scrolling), a MicroDMA channel triggered by Timer0/HBlank rewrites the scroll register per line with zero CPU cost and no jitter. The bar is now rock-solid on real hardware, and it freed up ~126 tiles.

Huge thanks to Tixu (NgpCraft / kuroi_dokutsu) studying that engine and its docs is what pointed us to the MicroDMA approach. The CPU-interrupt version taught us a lot, but MicroDMA was the real fix.

Problem 2 disappearing sprites (root cause found )
It wasn't a sprite-count problem. The bug: enemy spawn coordinates were stored as unsigned 8-bit but read back as signed, so any coordinate ≥ 128 was interpreted as negative and the sprite got culled as "off-screen" after a short time.
Switching those to signed 16-bit fixed it all enemies stay on screen now, confirmed on hardware. Also worth noting for anyone hitting this: the NGPC has no per-scanline sprite limit, only the 64 total so if sprites vanish, it's almost certainly a logic/coordinate bug, not a hardware limit.

Problem 3 framerate drops (understood, not a mystery anymore )
The scary part random ~3-second drops to single-digit fps turned out to be a measurement bug, not a real slowdown: the fps counter used an 8-bit VBlank counter that wraps every ~4.3 s, and the maths broke at the wrap. Tixu independently confirmed the same diagnosis.
On top of that we made real optimizations (only scanning spawn triggers when the scroll row actually changes, dropping a redundant per-sprite write). Heavy scenes (8–10 enemies + bullets) are genuinely close to the hardware's per-object budget, so we locked the game to a rock-solid 30 fps and rescaled all movement speeds to feel right much better than a fluctuating framerate.

Current status: now integrating a bigger level/enemy set the tiles freed by the new bar approach are exactly what makes it fit. Sorting out some sprite-numbering after the map update, but the hard structural problems are behind me.

Honestly couldn't have gotten here without this sub and Tixu's work being open. Thank you all