# nametable & double buffering

Page 8/10
1 | 2 | 3 | 4 | 5 | 6 | 7 | | 9 | 10

Haha, the demo features the fat cousin of the Ghost n Goblins flower
And prerotated charsets means animation

hit9918 wrote:

@PingPong,

A solution which got scroll bits asks for tiles reloaded with new gfx as the old gfx just left the screen.
In that case, you need no doublebuffering. So 32 chars go in 1 pixel scroll.
I think it can be said that if you got scroll bits, need no doublebuffer bit.

@hit9918:
The previus explanation was incomplete. (for simplicity)
If i remember correctly:
- there is a convertor, that take a bitmap of the full level. The convertor generate all the needed tiles starting at x=0 for 32x16 charaters. It does compute a unique set of tiles. Then do the same with X=8 (a tile right). Again new tiles are generated on a window of 32x16 charaters. the tiles generated are compared with previous generation, discovering what tiles are not used, what are the same, what are new. The process run until you reach the end of the bitmap. Contextually the tool do the same even with shifted tiles by 2px, so you have:
X=0, X=8, X=16, X=....... ' scroll offset 0
X=2, X=10, x=18, X=...... ' scroll offset 2
X=4, X=12, x=20, X=...... ' scroll offset 4
X=6, X=14, x=22, X=..... ' scroll offset 6
- The display and scrolling does this (current bank=0):
(A):
- X=0. Copy the entire tileset on nametable with scroll offset = 0, does prepare the next tileset on bank1 (X=8, for scroll offset = 0)
- X=2. Copy the entire tileset on nametable with scroll offset = 2, does prepare the next tileset on bank1 (X=8+2, for scroll offset = 2)
- X=4. Copy the entire tileset on nametable with scroll offset = 4, does prepare the next tileset on bank1 (X=8+4, for scroll offset = 4)
- X=6. Copy the entire tileset on nametable with scroll offset = 6, does prepare the next tileset on bank1 (X=8+6, for scroll offset = 6)
- swap the bank0 with the bank 1 then goto (A)....

Previously i've told that the cpu does prepare all the tileset on non visible bank. It's not true. the cpu does only prepare the new tiles incoming from right to left. Because the screen area is 16 charaters tall, the maximum n. of new tiles is 16 resulting in 256 bytes needed to be written at every nametable scroll.

even with the code showed, the cpu is fast enough to be not catched up by the raster beam if almost 32 bytes of nametable are already written when active area begins. This situation is true for me.

However, let's point some things:
- The routine is slow. I can accept a partially unrolled version with inc l instead of inc hl
- i'm not a fan of stack abuse (pop xx thingy). I do not like it, as i do not like, for example self modifying code.

I think that double buffering with hybrid mode offer more possibilities than expected... Without updating a single tile, just PNTs, I succeeded to have x2 scrolling of the plant level of nemesis III...
Try demo7.dsk (or rar) at:
To get this result, all 4 "phases" are constrained to fit in 128 tiles, where phase 0 has to host also a bit of tiles for score bar.
After all the two pages offer 512 tiles pre-loaded in VRAM...
I think that finding a good workaround for sprite cloning (and/or for managing objects of tiles) could unleash a new set of opportunities for horizontal scrollers on msx1

Now demo7 (v.2) has scorebar too (I had to reduce scorebar to 64 tiles).
No changes in the x2 smooth scroll.

in v.3 of demo7 there is also free static background
WIP on sprites, that seems the most crucial HW issue to solve

But it always refuses to scroll slow
Now as you ended up with halve a charset, this could be done with my scroller 1 pixel fullscreen fullsprites.

The only thing I envy is the low cpu load. I think you actually made a Mario engine. The top charset gets one cloud, then it is fullscreen.

And it is highly interesting to first time see the wobbleborder to a parallax scroller!
Depending on the tile, it is not bad.
Could you make the back layer scroll, too.

It is not a 2 pixel scroll One of the four scroll steps is missing, making a jumpy mess.
Look in slowmotion on emu.

It has to be a bug in my matlab script processing the data
thanks to spot it! going to see

Found! The problem was a missing "break" in a case. Now demo7 v.4 is correct and all the 4 phases are displayed. I've also slowed the scrolling speed, so all phases are visible (and the noise from floyd steinberg dithering too).
Thanks!

PS
I was thinking to the fire level of Nemesis: with this solution we can have animated flames for free, in the scrolling.
All I need is to compute the tiles of each scroll step from the level where flames ave moved one step in their animation cycle.
All the fire can be animated in 4 frames while scrolling, and everything costs to the CPU only a PNT update ;-)

@PingPong,
your first description of your engine was 256 bytes per frame, i.e. no difference to simply reloading 32 chars every frame. Now you are bringing in the diff tools. I would describe it like this:

There are max 32 tiles onscreen.
As some gfx left the screen, these vram tiles can come in with new gfx.