VERA 128K

[ZeroByte]

Or use 2bpp assets where possible, such as explosions/bullets/power up icons, your HUD font, etc.

Even the mighty SNES used 2bpp on most of its layer modes. Your scrolling demo has 64x64 tiles. They look awesome but that’s an expensive route to take vs a versatile 16x16 tile set that you have to draw your bg’s with.

[Fenner Machine]

I too wanted more video RAM to make things easier. It was a no. You can find the reasons somewhere in this forum.

So I made a spreadsheet to do some calculations and comparisons between some different combinations of screen modes, layer sizes and bit depths to see what the X16 could do and what I have to work with.

One example:

Resolution: 320x240

Layer 1: 128x32

Layer 2: 64x32

Colour depth: 8bpp

If my calculations are correct there is enough memory to have over 1700 8x8 or equivalent images, for either tiles or sprite animations.

Using the 4 orientations (normal, H-flip, V-flip, H+V-flip) that’s a lot of images to build a screen and for animations.

Using 4bpp with a custom palette and palette offsets could massively increase that number.

[StephenHorn]

As much as I want to support ambitious projects that aim to push the limits of the hardware, it's only with the understanding that the hardware is what it is, and living on the edge means always being a half-step away from teetering over it entirely.

It might be worth planning out what you want to do in your shooter, and figure out whether you have the VRAM to do so at 640x480... or else to drop to 320x240, or make cuts somewhere in order to fit your game into VRAM.

[x16tial]

15 hours ago, svenvandevelde said:

What I don't like is the lack of sufficient VRAM in the VERA. Even in 4bpp, memory runs out fast. Especially if you want to embed spritee animations. With the hardware capabilities of the VERA, memory is underscaled when using the high resolution 640x480 in tiled mode.



An example ... 12 sprites of 32x32 pixels in 4bpp requires $1800 bytes. But in high resolution 32x32 px is very little. 64x64 px quadruples the memory requirement... then you talk about $6000 bytes. And that is for just one "healthy" sprite animation ... beside that, you need explosions, damaged states, shadows, overlays like glowing effects, bullet types. So per enemy type you can easily consume $8000 to $A000 bytes (when in 64x64). And note that all this is in 4bpp. When using 8bpp that requires a multiple by 2. So 12 sprites in 8bpp 32x32 consumes about $3000 bytes. In 64x64 mode that would be $C000. That's 1/3 of the VERA VRAM, for one healthy enemy.



An interactive arcade game would easily have 6 to 8 different enemy types on the screen requiring animations, damage states, bullets, shields, glowing etc.



Noting that the VERA has 128 different sprites that can be shown simultaneously I really am afraid that memory upscaling is a requirement to use the full potential of the machine.

Are you using all 255 banks of RAM?  Data can be copied into and out of VERA memory.

[ZeroByte]

16 hours ago, x16tial said:

Are you using all 255 banks of RAM?  Data can be copied into and out of VERA memory.

It still takes resources to copy this data. SHMUPs by nature often have lots of objects to tend to on the screen at any given time, and CPU time can be precious if you want to keep the frame rate nailed up at 60fps.

Although, one other thing about SHMUPs can be taken advantage of here - the fact that you know what's coming up. OP mentions a dynamic VRAM management system being in place. If so, he could potentially make a dynamic loading process which operates in the background over multiple frames, only performing loads as time permits.. say during the busy loop at the end of a frame's game logic. The logic could look ahead and know that it's about to need to load resources for a new enemy type and start loading that in advance, and possibly keeping track of least recently used data as a place to put it - so if some enemy type is no longer on screen, its resources could be overwritten by an upcoming enemy.