[Z80-asm] Advise about tilemapping

driesguldolf · Post by **driesguldolf** » Sat 29 Sep, 2007 6:23 pm

I made a proper tilemapper (took me about 2 weekends

), with proper tilemapping I mean with shifting the screen and only update a line.
But I'm wondering how to use it correctly:
-> The tilemap needs to be stored somewhere untouched because anything drawn on it will not be erased (just shifted as the rest)
-> You could use xor logic and erase everything before shifting the map but that's way too limited
-> The only option I see is to have a seperate buffer for the tilemap and copy everything every time you want to update the screen

The problem is that in the last case there's a huge overhead plus this doesn't allow for masked tilemaps (or multiple layers, depends how you look at it)
Any way to get around it? Or do I just have to live with it and be happy because completely redraw the tilemap is still waaaay slower?

for the curious I'll post my code soon^^

Btw Notepad has serious issues with word wrap...

Jim e · Post by **Jim e** » Sat 29 Sep, 2007 6:32 pm

driesguldolf wrote:The only option I see is to have a seperate buffer for the tilemap and copy everything every time you want to update the screen

Yup!

The problem is that in the last case there's a huge overhead plus this doesn't allow for masked tilemaps (or multiple layers, depends how you look at it)

Ha! LINK

driesguldolf wrote:Any way to get around it? Or do I just have to live with it and be happy because completely redraw the tilemap is still waaaay slower?

No redraw is the only way around. Depending on what your doing infusing your mapper with a fastcopy routine would be just as fast, saving it in a buffer.

driesguldolf wrote:Btw Notepad has serious issues with word wrap...

I've had the same problem.

You should really drop by revsoft.

driesguldolf · Post by **driesguldolf** » Sat 29 Sep, 2007 9:33 pm

Thanks Jim e

Jim e wrote:You should really drop by revsoft.

Done^^

Jim e wrote:Ha! LINK

You inspired me to make mine even better

Jim e wrote:Mean 1 map has 1 layer, and the 2nd map has 2 layers.

Hmmm rendering one map (without anything on it) is sooooo sweeeeet

, thankfully the biggest issue stays the lcd so rendering 3 maps at the same time should be doable (though you can't really ldir the buffers together

)

Side note: on a 15Mhz calc, should you use fastcopy but temporarily set speed to 8Mhz or just wait for the lcd?

Liazon · Post by **Liazon** » Sat 29 Sep, 2007 9:49 pm

i think jim's map simply has more wait time. i duno if he checks the calc model and then changes the number of nops, but I'm pretty sure he doesn't touch the speed once it's been set.

driesguldolf · Post by **driesguldolf** » Sun 30 Sep, 2007 8:36 pm

LINK
Don't you think Z80 code looks beautiful if watched from a distance? (I don't really like commented code for this reason

)

More:

Assemble with Brass, I know the example is WAAAY to small. It was for testing purposes only
If you're going to use this code, I would appreciate it if you give me credit
More info will be given if asked

Anyway:

driesguldolf wrote:; * Diagnostics *
;size: 555 bytes
;
; * The math (vertical scrolling) *
;movedown: 13,139-13,213 + _drawscanline (2nd value if shifting to new ypos)
;moveup: 13,040-13,115 + _drawscanline (2nd value if shifting to new ypos)
;_drawscanline: 1,461~3,430 (depends on xshift) (mean=2,446)
;
; * Conclusion (worst case scenario) *
;can shift a tilemap vertical
;~362 times per second (without updating lcd)
;~78 times per second with fastcopy per frame (~60,000 tstates)
;~906 times per second on 15Mhz calc (without updating lcd)
;
; * The math (horizontal scrolling) *
;moveleft: 20,358~22,197 (depends on xshift) (mean=21,278)
;moveright: 20,656~22,377 (depends on xshift/yshift) (mean=21,517)
;
; * Conclusion (worst case scenarios) *
;can shift a tilemap horizontal
;~269 times per second (without updating lcd)
;~73 times per second with fastcopy (~60,000 tstates)
;~673 times per second on 15Mhz calc (without updating lcd)

Now that's one big fat smile on my face

spencer's 40fps makes sense now ^^

Now if I just had a map editor... Isn't earlymorning some sort of map/tile-editor?

Liazon · Post by **Liazon** » Sun 30 Sep, 2007 9:01 pm

jeez, that's another reminder how the LCD driver/fastcopy part is the major bottleneck of any mapper, as Jim e would say.

why don't you upload as text?

and i believe that's what early morning was supposed to do.

driesguldolf · Post by **driesguldolf** » Mon 01 Oct, 2007 4:17 pm

Liazon wrote:why don't you upload as text?

I thought that it would be 'inconvienient' (however you write that) because it's quite a lot of text, and I'm not finished adding some explanation.

This is still the very basics, now on to the more advanced stuff

Liazon wrote:jeez, that's another reminder how the LCD driver/fastcopy part is the major bottleneck of any mapper, as Jim e would say.

Jim e would definately say that

.
I first made a calculation error: it said that the horizontal scroller takes 133000tstates but luckily it isn't, still I think 75 pixels per second is better then nothing (though 300 would be soooo sweeeet)

driesguldolf · Post by **driesguldolf** » Tue 02 Oct, 2007 1:21 pm

...WTH? lol...
Is it normal that pindurti 'crashes' and flashdebugger does not? Very weird... even more weird bugs have shown up... not... fun...

More specific: pti crashes when 'movedown' is executed as flashdebug does not...

EDIT: Errors fixed, I'll post new code when I have a better map to show off with

because I know how much you all like screenies:

Don't worry about the mess at the start, I'm not initializing gbuf

hmmmm, Jim e's is faster... *starts staring at code in an attempt to optimize it*

Liazon · Post by **Liazon** » Tue 02 Oct, 2007 10:59 pm

still really nice. is it suppose to be gray?

i haven't looked at the code btw

Halifax · Post by **Halifax** » Wed 03 Oct, 2007 11:31 pm

I don't think so. From the looks of the screenshot it looks like a dithered black box, and that it is just ghosting to create the grayscale. Plus PindurTI isn't the best emulator to take pics in, nor any other emulators for that matter.

driesguldolf · Post by **driesguldolf** » Tue 09 Oct, 2007 9:20 pm

Pic made with PTI, it blurs to make gs programs look pretty (and BW ugly ^^)

Anyway Jim, could you explain how you do the fast scrolling?

My main loop for horiz scrolling is like this:

Code: Select all

; DE, points at sprite data
; HL, points in buffer
; B, number of rows of gbuf to draw
; C, number of rows of the tile that are left to draw
; IX, points at the map
; HL', used to get the next sprite of the tile
; DE', base address of the sprites
; BC', get to next row in map data
-
 ; Get next byte of the tile
	ld a, (de)
	inc de
 ; Shift it the correct amount
	rrca
_smc1		= $+1
	jr $
	rrca
	rrca
	rrca
	rrca
	rrca
	rrca
	rrca
 ; Rotate a scanline, input bit comes from the tile
	rr (hl)\ inc hl
	rr (hl)\ inc hl
	rr (hl)\ inc hl
	rr (hl)\ inc hl
	rr (hl)\ inc hl
	rr (hl)\ inc hl
	rr (hl)\ inc hl
	rr (hl)\ inc hl
	rr (hl)\ inc hl
	rr (hl)\ inc hl
	rr (hl)\ inc hl
	rr (hl)\ inc hl
 ; Check if all rows of the tile are drawn
	dec c
	jr nz, {+}
 ; Gets skipped most of the time
 ; Get new pointer to tile sprite
	exx
	add ix, bc
	ld a, (ix)
	ld h, 0
	ld l, a
	add hl, hl
	add hl, hl
	add hl, hl
	add hl, de
	push hl
	exx
	pop de
 ; All tiles are 8px high
	ld c, 8
 ; End skipping
+
	djnz {-}

kalan_vod · Post by **kalan_vod** » Tue 09 Oct, 2007 9:56 pm

driesguldolf wrote:Pic made with PTI, it blurs to make gs programs look pretty (and BW ugly ^^)

Unless you change the settings >.>, via debug window

Jim e · Post by **Jim e** » Tue 09 Oct, 2007 9:58 pm

Neat idea, rotating sprite data straight into the buffer would be fast for single pixel scrolling.

Mine was made for multi-pixel scrolling. It makes it possible to set the pixel coordinates arbitrarily and the mapper would try to to use as much of the original buffer as possible.

When I want to scroll my code calls certain functions like this depending on the number of pixels to move

1: Scroll_Left_1
2: Scroll_Left_1,Scroll_Left_1
3: Scroll_Left_4,Scroll_Right_1
4: Scroll_Left_4,
5: Scroll_Left_4,Scroll_Left_1
6: Scroll_Left_4,Scroll_Left_1,Scroll_Left_1
7: Shift_Bytes_Left,Scroll_Right_1

Any value greater than 8, I simply shift the bytes. Scrolling 4 bytes I make use of the RRD and RLD opcodes.

The data in the blank areas is then filled with an optimized tile drawer.

Spencer · Post by **Spencer** » Wed 10 Oct, 2007 12:03 am

I forget how Zelda's works, but its superior to jim's.

driesguldolf · Post by **driesguldolf** » Wed 10 Oct, 2007 8:22 am

kalan_vod wrote:
driesguldolf wrote:Pic made with PTI, it blurs to make gs programs look pretty (and BW ugly ^^)
Unless you change the settings >.>, via debug window

I knew that!

Jim e, you cheater! I thought those screenies (see link) gbuf was scrolled one pixel at the time

But still say that the whole screen are animated tiles, you still end up redrawing the whole screen? Even if you optimised the tile drawer...

One little question: Isn't it faster to make 16x16 tiles with a combination of 4 8x8 tiles? The map size would quadriple but there will be a lot more opportunities for RLE...

Spencer wrote:I forget how Zelda's works, but its superior to jim's.

you forgot?

I don't believe there is a faster technique, but it may be better optimized
Maybe a combination of row and column major order in the gbuf?

MaxCoderz

[Z80-asm] Advise about tilemapping

[Z80-asm] Advise about tilemapping

Re: [Z80-asm] Advise about tilemapping