nametable & double buffering

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


Enlighted (6550)

ARTRAG's picture

21-05-2012, 07:42

I think I can improve a lot sprite flickering using the fact that half of the frames the screen is in normal mode...

Hap thanks for testing

By PingPong

Prophet (3767)

PingPong's picture

21-05-2012, 08:47

hit9918 wrote:

Lets talk 32 chars onscreen. I always mean 32 chars x all scroll positions.
32 chars onscreen, for 16 new chars to enter the scene, 16 chars got to be FREE.
Free means: they are not in the nametable, they are not visible.
Reloading them cannot need doublebuffering.

16 chars not displayed on screen is a limiting factor.
If needed, I need to use all the tiles on screen without reserving anything 'free'.
So i need double buffering.


Enlighted (6550)

ARTRAG's picture

22-05-2012, 00:21

new small update in demo8 at :
The flickering now has improved but it is still visible. Using the fact that in normal mode all sprites appears correctly, and that the screen is in normal mode half of the frames, I limited the blank frames to 1 out of 4 (for sprites beyond the 8th in the lower 3rd of the screen). Of course, if sprites are 8 or less in the lower 3rd of the screen,there is no flickering.
I fixed also the transitions between middle and lower bank
Now lower bank management starts for y>128-16

By anonymous

incognito ergo sum (116)

anonymous's picture

22-05-2012, 11:38

Should level compression and tile allocation be done offline by a script processing the level?
In this way the z80 would just retreive the pnt for column 33 and data for tiles that have changed

By hit9918

Prophet (2905)

hit9918's picture

22-05-2012, 17:09

I got no worries about the size of the list, it can be precalculated ROM. I imagine the diff list contains just

vram tile number, level tile number.

Telling what to load where. So the tool also includes the allocation in vram.
The header contains the amount of such entries, and the X/8 position in the level.

Animation, I wonder how the Moai shall open its mouth.
With dynamic alloc, on the left side of the level I place all sorts of invisible example gfx,
so the tiles are known to the compressor, at the same time I get a nametable sample to draw that stuff.

You could do it with dynamic alloc.
Dynamic alloc generates a list of tiles.
If a comparison to the list of the recent frame is identic, then need no charloading.

Whenever a new thing enters the scene, you need to reload all tiles and may get a hiccup frame.
But you run in 4 frames. Reloading all 12k needs 6 NTSC frames. 2 screen regions is max 8k that could ever be reloaded.

On a sidenote. The NTSC machine is a speed pain.
Having had just some happy PAL demo, the NTSC machine does slowdown, oh no.
Solution: the scroll speed for NTSC machine is "take one more frame".

Example, 2 frames PAL = 25fps, 3 frames NTSC = 20fps.

So, this time the NTSC version is the slower scroller.
But I would make sprite speed and music speed same on both machines!

For sprite moves, have a "basespeed" 16bit fixpoint value around 0.25 pixel per frame, the NTSC version value is lower by 6/5.
Faster speeds are derived by some "add hl,hl" from base speed.
This calculation should be outside enemy move, in enemy creation or in global variables.
Also, sinus cosinus tables be derived from this base speed.

PAL vs NTSC again could be in VDP setup, e.g. for detection failing on TurboR with Turbo enabled.
This switch is not about changing the VDP mode, it is "engine assumes: PAL/NTSC".

And then I thought about a "music speed" switch PAL/NTSC Big smile
The deal is: no matter what you select, result will be same BPM on all machines.
Means NTSC users can also have the calm version and PAL users can also have the tekkno version Big smile


Enlighted (6550)

ARTRAG's picture

22-05-2012, 23:43

new demo8.rar (and dsk) v.3

I improved a bit the sprite flickering by changing the pattern of switching between hybrid and normal modes.
I had also to increase the scroll speed to have faster page (& mode) swap and a better looking flickering
You can also fire bullets (one at time) and control the main ship, just to see how flickering goes under different conditions.

If for sprites this seems all what we can get (IMHO at least), I'll start coding some matlab experiments for the tool you envisaged.
NB: I have to manage 4 "phases" of the scroll, corresponding to 4 tilesets of 128 tiles each.
Everything has to be extended to the management of 4 parallel tilesets

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