Why are PCE games that use >= 320 horizontal res so rare?

[alasyon]

From the perspective of programming an 8-bit CPU in assembly, it’s a real pain having to deal with horizontal positions above 255 because you need two bytes rather than one. Doesn’t sound like a big deal but that means more instructions when moving every single sprite, and is a fair bit more complicated when comparing sprite positions (which happens a lot). This makes code more complicated and slower, maybe not by much but we’re dealing with relatively underpowered hardware. So that might explain it, not sure, just a thought.

[turboxray]

Dec 28, 2023 8:06:09 GMT alasyon said:

From the perspective of programming an 8-bit CPU in assembly, it’s a real pain having to deal with horizontal positions above 255 because you need two bytes rather than one. Doesn’t sound like a big deal but that means more instructions when moving every single sprite, and is a fair bit more complicated when comparing sprite positions (which happens a lot). This makes code more complicated and slower, maybe not by much but we’re dealing with relatively underpowered hardware. So that might explain it, not sure, just a thought.

What? That's manifest nonsense. A "real pain" to do 16bit operations.. maybe if you've never coded on an 8bit cpu and consider typing out instructions as a "pain". It's actually pretty easy and totally a non-issue. We're talking about an extended 65x architecture running at 7.16mhz. Where's the issue? More instructions? Sure. But that's how the 65x rolls.. simple but fast instructions.. paired with a pretty high clock speed makes it more than capable. Even as an 8bit processor, it's still faster than the SNES at 16bit math (yes, even faster than SNES running in fastrom mode). It sits pretty close to the Megadrive in overall capable performance (even exceeds in it some areas).

 Btw, even low-res mode needs more than an 8bit range for horizontal screen coords (the PCE is not the NES, and sprites are wider than 8px). Sprites needs to transition on both right and left sides of the screen (so they can partially show off screen). A simple 8bit value will not do that. It's gonna a 16bit coord value whether it's 256px res or 320px and higher. Also, things like "fixed point" systems existed in games of that era. That's a 24bit coord system (16bit whole, and 8bit fractional).

 If you don't believe me, check out my Bonk Adventure demo for PCE. It has a foreground made completely out of sprites. Up to 50 at a time. Performance wise, it's uses relatively little processing for the frame (it's rebuilt from scratch every frame - no buffering or caching). They all use 16bit coords too. And that's with an additional 16bit translation operation to each sprite on screen (even some off screen that get culled in the final step).

 Let me put that into context: if you have all 64 sprites on screen.. and you used 8bit values.. what does that performance cost look like? If an average 8bit add takes 17 cycles (load,clc, add, store), and you have X/Y coords, that's 2176 cycles total for all 64 sprites positions. An average 16bit add would be an additional 15 cycles (lets assume the delta is a full signed 16bit value and not an optimized 8bit value. I.e. this is not an 8bit + 16bit ->16bit optimized add). 8bit version is 2176 cycles for all 64 sprites for a total 1.8% cpu resource impact for a given frame. 16bit version is 4096 total cycles for 64 sprites for a total 3.4% cpu resource impact on the frame. That's a pretty miniscule difference between the two.. 1.6% more to use 16bit coords over 8bit coords.

[gilbot]

The 8-bit coordinates thing is definitely not an issue.

As shown from the discussions starting from page 1, NEC advised against using the "320" mid-res unless some restrictive rules were followed (maximum 14 sprites per scanline before drop-out instead of 16), so a number of developers just didn't want to mess with it and chose to use only the low resolution. This is also the main reason something was changed for the western version and the later complete CD version R-Type.

There were still some games that slipped through this restriction though, even 1st party games (by 1st party I mean games from Hudson Soft, not those from NEC HE/AV/Interchannel), probably NEC wasn't that strict in checking so they missed those games, or they lifted that restriction in latter half of the console's life.

[alasyon]

Fair call, was just a thought.

[wf]

Mar 18, 2020 15:25:29 GMT turboxray said:

There's a trick called "infinite sprites" (I can't remember the exact name but there's even a PCE rom floating around showing it off.. with a Bonk sprite). It's an old school trick. It totally could be modified for this boss, and remove almost all flicker. It'd have to be modified though.. with an erase function and real sprites to cap either ends of the worm. Chris Covell might know what I'm talking about.

Edit:

The name is right in the video you linked. "Infinite (or Unlimited) bobs", as in plotted Bitmap OBjects instead of true sprites. I've never seen one with an erase function, and while theoretically possible, I think it would be way too expensive in both CPU and memory to implement. You'd have to update an offscreen coverage mask for each virtual bob every time you rendered a new one, unless there's some other trick of which I'm unaware.

And regarding 8-bit values for horizontal sprite coords, a lot of Commodore 64 games (320x200, 6502) would left-shift an 8-bit memory value into the 9-bit sprite coords, but that 2-pixel stepping matched the 2-pixel-wide multicolor format anyway. An interesting strategy to keep the coordinates simpler under the constraints of a ~1MHz processor.