Hi, I'm new to uzebox and currently doing some artwork for an upcoming game. What I haven't found out from the documentation is how many different tiles are possible in video mode 3 simultaneously. 256? Or 256 for background plus RAMtiles for sprites? Or another number + RAMtiles for sprites? How does the indexing work in mode 3?
Janka
Mode 3 maximum tile count
Re: Mode 3 maximum tile count
You start with 256 indices max, then for every ram tile you lose one. So if you have 40 ram tiles it's 256-40 = 216 normal tiles you can use. Forget about sprites they have nothing to do with number of indices. Welcome aboard 
Re: Mode 3 maximum tile count
Sorry, my confusion hasn't ended. What I currently think mode 3 works is as follows, please correct me where I'm wrong:
* Screen RAM is 32x32 (30x28 viewport), with 8-Bit indices to tiles.
* There is some configureable border in tile index where ROM tile indices end and RAM tile indices start.
* Video kernel reads tile index, reads 8 pixels per scanline and tile from ROM or RAM depending on tile index and bitbangs pixels to video output.
---
* Sprite rendering is done in screen shoulder, doing an overlay of sprite shapes and background tiles from ROM into reserved RAM tiles.
* That means, for any 16x16 pixel sprite displayed on the screen I need to reserve up to 9 tile indices (6 if vertical and horizontal fine movement is not simultaneous).
* Sprite shapes are tiles, too, but they are from a different pool so their indices aren't colliding with screen tile indices.
Correct?
Janka
* Screen RAM is 32x32 (30x28 viewport), with 8-Bit indices to tiles.
* There is some configureable border in tile index where ROM tile indices end and RAM tile indices start.
* Video kernel reads tile index, reads 8 pixels per scanline and tile from ROM or RAM depending on tile index and bitbangs pixels to video output.
---
* Sprite rendering is done in screen shoulder, doing an overlay of sprite shapes and background tiles from ROM into reserved RAM tiles.
* That means, for any 16x16 pixel sprite displayed on the screen I need to reserve up to 9 tile indices (6 if vertical and horizontal fine movement is not simultaneous).
* Sprite shapes are tiles, too, but they are from a different pool so their indices aren't colliding with screen tile indices.
Correct?
Janka
Re: Mode 3 maximum tile count
Hi Janka, welcome to the Uzebox community!
-Viewport is 30x28 if you do not use scrolling and 28x28 if scrolling is used. Scrolling requires more code in the hblank and unfortunately reduce the horizontal resolution available. The number of vertical scan line actually rendered can be reduced using FRAME_LINES. Less line to render means more cpu left for the main program. This can be handy for some games.
Ramtiles are a way of allowing some of the rendering tasks to be done during vertical blanking rather than while actually outputting scanlines. It works by finding where sprites are on the screen, looking at what tiles would be under those sprites, then compositing the sprite onto the tiles and storing the result in RAM. That way when it's time to output pixels on a scanline, it can just fetch the pre-rendered images from RAM rather than having to do the sprite compositing on the fly. This saves enough cycles to allow for better resolution, and as a side effect we get nifty things like overlapping sprites and sprite flipping. The tradeoff is that games have less RAM to work with, as well as fewer CPU cycles for running game logic.
So ramtiles are like tiny 8x8 pixels frame buffers. More you have of them and more you can place sprites pixels arbitrarely on the screen. However since they take 64bytes each and we have only 4K of RAM globally, you must limit the quantity allocated with the RAM_TILES_COUNT parameter. This parameter is the "configureable border in tile index" I think you are referring to. The kernel puts the ramtiles indexes first and the number you have allocated will impact the number of regular flash tiles than can be indexed and displayed at once. I.e. if RAM_TILES_COUNT=32 the "index space" would look like this: [indices 0-31: ramtiles][indices 32-255: flash tiles]. So for all practical means, in this case you will only have access to indices 32-255, hence 224 background tiles max are available at once.
Hope that helps!
-Screen RAM (VRAM) is 32x32 8-bit indices, thought less lines can be allocated to save RAM. This is controlled using the VRAM_TILES_V compile time parameter.Sorry, my confusion hasn't ended. What I currently think mode 3 works is as follows, please correct me where I'm wrong:
* Screen RAM is 32x32 (30x28 viewport), with 8-Bit indices to tiles.
-Viewport is 30x28 if you do not use scrolling and 28x28 if scrolling is used. Scrolling requires more code in the hblank and unfortunately reduce the horizontal resolution available. The number of vertical scan line actually rendered can be reduced using FRAME_LINES. Less line to render means more cpu left for the main program. This can be handy for some games.
8-bit tiles indexes normally allows for up to 256 unique tiles to be displayed at once. However mode 3 way of doing things requires ramtiles(from the video mode 3 implementation details):* There is some configureable border in tile index where ROM tile indices end and RAM tile indices start.
Ramtiles are a way of allowing some of the rendering tasks to be done during vertical blanking rather than while actually outputting scanlines. It works by finding where sprites are on the screen, looking at what tiles would be under those sprites, then compositing the sprite onto the tiles and storing the result in RAM. That way when it's time to output pixels on a scanline, it can just fetch the pre-rendered images from RAM rather than having to do the sprite compositing on the fly. This saves enough cycles to allow for better resolution, and as a side effect we get nifty things like overlapping sprites and sprite flipping. The tradeoff is that games have less RAM to work with, as well as fewer CPU cycles for running game logic.
So ramtiles are like tiny 8x8 pixels frame buffers. More you have of them and more you can place sprites pixels arbitrarely on the screen. However since they take 64bytes each and we have only 4K of RAM globally, you must limit the quantity allocated with the RAM_TILES_COUNT parameter. This parameter is the "configureable border in tile index" I think you are referring to. The kernel puts the ramtiles indexes first and the number you have allocated will impact the number of regular flash tiles than can be indexed and displayed at once. I.e. if RAM_TILES_COUNT=32 the "index space" would look like this: [indices 0-31: ramtiles][indices 32-255: flash tiles]. So for all practical means, in this case you will only have access to indices 32-255, hence 224 background tiles max are available at once.
exact* Video kernel reads tile index, reads 8 pixels per scanline and tile from ROM or RAM depending on tile index and bitbangs pixels to video output.
exact, sprite rendering is pre-computed into ramtiles during the vertical sync period.* Sprite rendering is done in screen shoulder, doing an overlay of sprite shapes and background tiles from ROM into reserved RAM tiles.
exact. Constraining the axis of fine movement reduces ram tiles requirements.* That means, for any 16x16 pixel sprite displayed on the screen I need to reserve up to 9 tile indices (6 if vertical and horizontal fine movement is not simultaneous).
exact. Each sprite can even have it's own tile bank (pool).* Sprite shapes are tiles, too, but they are from a different pool so their indices aren't colliding with screen tile indices.
Hope that helps!