nametable & double buffering

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

By ARTRAG

Enlighted (6515)

ARTRAG's picture

19-05-2012, 07:21

This allocator looks faster,but the on fly combiner and tile updater seems quite cpu intensive
I would spend this same cpu time for some tile based enemies

By PingPong

Prophet (3754)

PingPong's picture

19-05-2012, 09:25

Time ago, i've approached the problem in this way:

Let's say: max 128 different tiles on screen. tiles 0-127 were bank0, tiles 128-255 were bank1
Basically at every pixel scroll by tile is represented as follow:

nametable bit
7 bank selector
6-2 tile n.
1-0 scroll offset (doing 2px scroll)

with this layout i can have 32 different tiles in 4 different scrolling offset.
at every pixel scroll i write to nametable different configurations of bits 1-0.
while doing this, i re-write tile patterns.
I assume one can redefine the full pattern set because the cpu must write 2K in 8 consecutive frames, 256bytes each frame into the back buffer
The limit of this solution is that, while there is no theoretical limit on the number of tiles / level, there is a limit on the number of tiles on screen in a given frame. the limit is 128 that one need to cut off by a factor 4 because of 'scrolling'

I've abandoned this solution because i cannot do fast nametable write. My nametable write looked like

ld a,(HL)
or d
out (0x98),a
inc hl
djnz ....

slower than a outi

By ARTRAG

Enlighted (6515)

ARTRAG's picture

19-05-2012, 10:13

hap wrote:

I ran it on MSX1, and it's the same as meisei: middle block is always stable, lower block always flickers. And there's a small glitch at the topmost scanline when scrolling.

btw, don't forget that a sprite can also be on the middle and lower block at the same time (eg. y=120 -> sprite is on 120-136)

humm... maybe to avoid strange problems (eg. cloned sprites on the top of the scorebar) I should avoid that planes 8-31 go with y>127-16 = 111

thanks for testing, some more experiments on my side are needed

By hit9918

Prophet (2904)

hit9918's picture

19-05-2012, 13:33

@ARTRAG, the allocator works with everything, on thy fly combine and precalculated tiles.

By hit9918

Prophet (2904)

hit9918's picture

19-05-2012, 14:58

@PingPong,
I wouldn't abadon it because of nametable write.
Rather is missing an idea of how would you make dynamic use of the 32 tiles.

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.

By hit9918

Prophet (2904)

hit9918's picture

19-05-2012, 15:13

By the way, to add something to the nametable bytes:

8 ld a,(HL)
5 or d
12 out (0x98),a
7 inc hl
--
32

Again POP makes the show:

11 pop hl
5 ld a,l
5 add d
12 out 0x98
5 ld a,h
5 add d
12 out 0x98
--
55 / 2 = 27.5

By hit9918

Prophet (2904)

hit9918's picture

19-05-2012, 15:20

No wait... pop and add hl,de make the show:

11 pop hl
12 add hl,de
14 out (c),l
14 out (c),h
--
51 / 2 = 25.5

Typical for z80. Sketch many versions. This time a 16bit version makes it.

By hit9918

Prophet (2904)

hit9918's picture

19-05-2012, 15:26

p.s. the 25.5 cycles version will get you into visible area and then wreck vram write.
After 16 lines, i.e. 16*32 chars dump, switch to this version:

11 pop hl
5 ld a,l
5 add d
14 out 0x98
5 ld a,h
5 add d
14 out 0x98
--
59 / 2 = 29.5

Ask bluemsx debugger for violations.

By ARTRAG

Enlighted (6515)

ARTRAG's picture

19-05-2012, 15:46

look for demo6 at
https://sites.google.com/site/testmsx/Home/double-buffer-in-...
nothing new except a small animation (requested by my older son)

By hit9918

Prophet (2904)

hit9918's picture

19-05-2012, 16:47

Real machine update: The analog horrors.

At current VDP temp Wink with full pattern masking but no color masking, I get
sprite Y = 0 matches on line 0,64,128
sprite Y = 64 matches on line 64
sprite Y = 128 matches on line 128

in increased effect with also color masked
sprite Y = 0 matches on line 0,64,128
sprite Y = 64 matches on line 64
but sprite Y = 128 does not match on line 128

UH, QUICK! with color mask not enabled, pattern mask fully enabled. enable means 0 bits.

sprite Y = 0. matches on line 0,64,128, but clone on line 64 goes sparcles! It goes disappearing as VDP gets hotter!
sprite Y = 64 matches on line 64
sprite Y = 128 matches on line 128

The sparcles are "rnd" per scanline. Per scanline counter comparison.
After some minutes, still there as a ghost with 1 or two scanlines matching per frame (in random noise).

But no changes to the report with all mask bits enabled.
And with only one of the two mask bits enabled, things again may be different.

When doing a game, one got to assume the worst case, all effects happening.
Maybe an emu could somehow make the worst case. Clones in sparcles.

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