Jump to content
  • 0
Fenner Machine

Sprites, H&V-Scale, layers, other

Question

I have several technical questions.

 

1). Sprites

 

I understand a 128 sprite limit per screen:

No more than 128 sprites per screen.

Also limits per scan line depending on work load.

What I don’t understand is how many frames of animation can be stored in memory.

 

a). Is sprite data limited to 128 entries total?

Example:

b). If each object has 8 animations, 128/8 means you can only have 16 unique objects?

Or can you store 40 unique object x 8 animations for 320 animations?

Then display all 40 objects cycling through 8 animations?

c). Can multiple sprites use the same data?

Such as a tree in several places?

 

2). H-Scale and V-Scale

 

a). Can H-Scale and V-Scale be independently set?

b). How is performance affected by different settings? Is there a formula, such as simply how many pixels drawn? Fewer pixels = more performance, more pixels = less performance?

Example resolutions: 320x200, 320x240, 360x200, 480x270

c). At what resolution does 256 colour become impossible/impractical?

 

I think the answers to 1c and 2a are yes, but would like confirmation.

 

3). Graphics layers

 

a). Is it possible to start a layer part way down the screen, and if so would this save processing power for either the CPU or VERA?

b). At 640x480 resolution, is it possible to set a layer to 32 tiles by 8 pixels so just 256 pixels high?

 

4). For fun, speculation

 

I’ve seen videos comparing Commander X16 to various 16 bit systems.

The X16 seems their equal in a few areas, better in some, inferior in others.

Would it be possible to make a game for the X16 that would be superior to what the Genesis or SNES could do?

What genre would be the best candidate?

Edited by Fenner Machine

Share this post


Link to post
Share on other sites

8 answers to this question

Recommended Posts

  • 0

I'll try to answer your questions to the best of my ability, everyone is free to correct me on any point 😀.

1. There are 128 sprite definitions, and there is a hard 128 sprites per raster line limit, but there's no 128 sprites per screen limit. Sprite definitions can be changed during the frame, so you can reuse sprites in the same frame, further down the screen.
     a) Yes, but as stated above, that data can change during the frame
     b) No, the number of sprite animation frames is limited only by the available video memory (128K total). Each sprite definition points to a location in video memory containing the sprite pixel data, so you can just change that pointer in each frame (or even more often)
     c) Yes, absolutely

2. a) Yes
     b) There is no performance penalty besides the sprite limit per scanline (which also depends on the sprite size and the sprite no#)
     c) 256 colors is possible in 320×240 max for bitmap layers without resorting to raster interrupt tricks; for tiled layers it depends on the amount of memory needed for the tile data (e.g. 1024 16px×16px tile definitions takes 256K of memory, so that's out of the question, but if you don't need many different tiles you can use really big maps)

3. a) Yes, but it requires using raster line interrupts
    b) Sure, but it would start repeating the layer after 256 lines. But you can also use 64 tiles vertically and just use an empty tile (tile with all pixels using palette index 0) for all the tiles in the bottom half

4. I'm not very familiar with Genesis or SNES so... maybe. But i believe Mode 7 would be pretty hard to emulate.

 

 

  • Like 1

Share this post


Link to post
Share on other sites
  • 0
6 hours ago, Guybrush said:

I'll try to answer your questions to the best of my ability, everyone is free to correct me on any point 😀.

1. There are 128 sprite definitions, and there is a hard 128 sprites per raster line limit, but there's no 128 sprites per screen limit. Sprite definitions can be changed during the frame, so you can reuse sprites in the same frame, further down the screen.
     a) Yes, but as stated above, that data can change during the frame
     b) No, the number of sprite animation frames is limited only by the available video memory (128K total). Each sprite definition points to a location in video memory containing the sprite pixel data, so you can just change that pointer in each frame (or even more often)
     c) Yes, absolutely

2. a) Yes
     b) There is no performance penalty besides the sprite limit per scanline (which also depends on the sprite size and the sprite no#)
     c) 256 colors is possible in 320×240 max for bitmap layers without resorting to raster interrupt tricks; for tiled layers it depends on the amount of memory needed for the tile data (e.g. 1024 16px×16px tile definitions takes 256K of memory, so that's out of the question, but if you don't need many different tiles you can use really big maps)

3. a) Yes, but it requires using raster line interrupts
    b) Sure, but it would start repeating the layer after 256 lines. But you can also use 64 tiles vertically and just use an empty tile (tile with all pixels using palette index 0) for all the tiles in the bottom half

4. I'm not very familiar with Genesis or SNES so... maybe. But i believe Mode 7 would be pretty hard to emulate.

I'll supplement some of these answers.

2.b: Performance is not impacted at all by hscale and vscale.

Hscale and vscale do not actually change the output resolution of the Vera, the Vera will always, always, always output 640x480. Hscale and vscale only changes the decision of which pixels are drawn at any given screen position, in order to emulate other resolutions. Resolutions that are not a clean power of 2 from 640x480 will have scaling artifacts as a result.

But also, performance of the Vera doesn't matter. Even if you attempt to max out its graphical capabilities, it will always draw the 640x480 display at 60Hz. This isn't a modern video card that you can overburden with work.

2.c: You can (and should!) do the math yourself to determine what can fit in the Vera's memory.

If you intend to press the limits of the Vera, you will need to do the math yourself. That's part of the fun of working on a resource-constrained machine.

The Vera has 128KB of memory, minus the PSG registers and sprite attributes. 640x480 is 307,200 pixels, so obviously an 8-bit color bitmap (307,200 bytes) is out of the question. So is a 4-bit color bitmap. A 2-bit color bitmap is possible, but you will not have enough room for a "back-buffer", meaning folks will see your drawing processes unless they are exceedingly fast. A 1-bit, black-and-white bitmap allows for a backbuffer, so you can draw to the backbuffer and then flip which section of memory is presented during vblank.

Tilemaps are more complicated.

  • If you are using 8x8 tiles with 8-bit color, you need at least a 128x64 tilemap to cover an unscaled 640x480 display, and this costs 16,384 bytes. From there you have room for 1,750 tiles. If you need all 1024 tiles, obviously this is ample and it leaves room for sprite data in memory, as well.
  • If you are using 16x16 tiles with 8-bit color, that 640x480 display only needs a 64x32 tilemap to be completely covered, which is 4,096 bytes. However, you only have room for about 450 tiles. If you don't need that many tiles, great. You can put whatever memory is left into sprites.
  • If you are using 4-bit color, your memory requires are cut in half, and again if using 2-bit color, and again if using 1-bit color, so there are boatloads of combinations here based on what you need.

3.a: It is possible to start a layer partway down the screen, but saves no work on the Vera.

Instead, consider this: If you change parameters about layers partway through a screen draw, you could have a portion of the screen dedicated to UI elements (score bar, life counter, HP, inventory and/or power-ups, etc), followed by a gameplay area. And the gameplay area can scroll. And you could scroll layers at different rates, and choose which layer data is used and when, to create a variety of parallax effects. And you can pull other tricks and shenanigans.

4: Define what makes a game "superior".

But in any event, it's unlikely. The X16 was envisioned as a modern take on a Commodore 64, and was designed in a similar fashion. The audio and video options are very beefy for an 8-bit machine, however, and when combined with the outrageously fast 8MHz clock speed (compared to era-similar 1-2MHz clock speeds) this may allow it to flex a little into the realm of 16-bit platforms. I've mentioned in my thread promoting the Coding Secrets youtube channel that the X16 is likely capable of many Genesis-era effects. If you consider the Genesis your "par" for superiority, it's possible you could make a clone of at least some Genesis games which are identical in every way to the originals, but that take advantage of the X16's sound solution, which is likely to be a bit better than the Genesis. But those are going to be relatively few cases.

Really, instead of thinking of the X16 as a 16-bit platform like the SNES or the Genesis, you should think of it more like the PC Engine/TurboGrafx-16, in that it's still basically an 8-bit platform, plus some beef.

  • Like 1

Share this post


Link to post
Share on other sites
  • 0

Thanks Guybrush and StephenHorn.

Your answers have cleared up a few things.

I now better understand the various trade-offs between tilemap size, number of tiles and layers, colour depth and the affect of scaling.

Also how graphics data can be used and optimized.

Planning shall now commence for my first game.

Share this post


Link to post
Share on other sites
  • 0

I have covered most of the topics you are asking about in the series of tutorials on my blog:

https://www.8bitcoding.com/p/commander-x16.html

I go pretty deep into explanations on how VERA works, different video modes, sprites, sprite animations, scrolling, layers and even some simple libraries to add music to your programs. Examples are written mostly in BASIC and some in Assembly but of course all the hardware related subjects are applicable to all programming languages.

  • Like 1
  • Thanks 3

Share this post


Link to post
Share on other sites
  • 0

Thanks DusanStrakl.

I’ve read and reread several of your tutorials.

They are excellent.

A few things I was not quite sure of, but with the X16 docs, answers to specific questions and your guides I think I might be able to make a game.

  • Like 1

Share this post


Link to post
Share on other sites
  • 0
3 minutes ago, Fenner Machine said:

Thanks DusanStrakl.

I’ve read and reread several of your tutorials.

They are excellent.

A few things I was not quite sure of, but with the X16 docs, answers to specific questions and your guides I think I might be able to make a game.

Thanks. I hope you can make it. Just share your progress and there is plenty of help out there. I myself do not come over here often enough but will try to follow this forum a bit closer in the future.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

Please review our Terms of Use