[Z80-asm] Advise about tilemapping

[jimmothy]

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

LOL that made me laugh

[driesguldolf]

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

LOL that made me laugh

Ah now I get it... it's that spencer vs jim e thing

[cjgone]

Haha..lol...I can't code very well.. My code for horiz scrolling: (LOL)

Code: Select all

Right_Scroll:
        push hl
        ld hl,Matrx
        ld a,(R_Location)
        ld d,0
        ld e,a
        add hl,de
		ld a,(U_Location) ; offset from top
		cp 0
		jr z, AddNo
		ld b,a
		ld de,43
Down_Increment:
		add hl,de
		djnz Down_Increment
		
AddNo:		
		ld a,(U_Location+1) ; pixel offset
		dec a
		ld b,a
		ld a,8
		sub b ; a = counter, b = image offset
		ld c,b ; image increment
		ld b,a
      ex de,hl
        pop hl   ;     Argument of screen buffer location
Loopedr:
        ld a,(de)
        push de
        Call PicR  ;  
        ld a,c
		push hl
		ex de,hl
		ld e,a
		ld d,0
		add hl,de
		ex de,hl
		pop hl
Draw_Loopxx:
        ld a,(R_Location+1)   ; bit offset rotations
        push bc 
        ld b,a
        ld a,(de)  ; image data
        ld c,a
        xor a  ; sets a to 0
Rotatexx:
        sla c
        djnz Rotatexx   ; finds the bit offset
        rl a
        or (hl)
        ld (hl),a     ; loads it into screen buffer

        pop bc
        inc de
        push de
        ld de,12
        add hl,de
        pop de 

        djnz Draw_Loopxx		
		pop de
		push hl
        ex de,hl      ; hl = Matrx  de = Screen Location
        ld de,43      
        add hl,de
        ex de,hl
        pop hl
		
		
		
		
		
		
        ld b,6
Looped:
        ld a,(de)
        push de
		cp 4
		jr z,Check_Blank
        Call PicR  ;         
        push bc
        ld b,8   ; Draws 8x8 tiles
		

Draw_Loop:
        ld a,(R_Location+1)   ; bit offset rotations
        push bc 
        ld b,a
        ld a,(de)  ; image data
        ld c,a
        xor a  ; sets a to 0
Rotate:
        sla c
        djnz Rotate   ; finds the bit offset
        rl a
        or (hl)
        ld (hl),a     ; loads it into screen buffer

        pop bc
        inc de
        push de
        ld de,12
        add hl,de
        pop de 

        djnz Draw_Loop

end_now:
        pop bc
        pop de
        push hl
        ex de,hl      ; hl = Matrx  de = Screen Location
        ld de,43      
        add hl,de
        ex de,hl
        pop hl
        djnz Looped
		;-------- Draw bottom if UNALLIGNED
		
	ld a,(D_Location+1)
	cp 8
	jp z, Do_NotDraw_Bottom
		
			
	ld b,a
	push bc
	ld a,(de) 
	Call PicR ;{ picture fetch :P}
			
		
		
	pop bc
		
Draw_Loopxxw:
        ld a,(R_Location+1)   ; bit offset rotations
        push bc 
        ld b,a
        ld a,(de)  ; image data
        ld c,a
        xor a  ; sets a to 0
Rotatexxw:
        sla c
        djnz Rotatexxw   ; finds the bit offset
        rl a
        or (hl)
        ld (hl),a     ; loads it into screen buffer

        pop bc
        inc de
        push de
        ld de,12
        add hl,de
        pop de 

        djnz Draw_Loopxxw
		
Do_NotDraw_Bottom:                       
        ret                     
	
Check_Blank:
	push bc
	ld de,96
	add hl,de
	jr end_now

Plus.. the actual screen horizantal thingy (didn't make):

Code: Select all

Shift_Left:
	ld hl,$9340+671
 	ld c,56
loop2:
   	ld b,12
  	or a
smalloop2:
  	rl (hl)
 	dec hl
 	djnz smalloop2
 	dec c
  	jr nz,loop2
        ret

Optimized much?

[Dwedit]

We got two approaches to tilemapping:
#1: The "Crashman-style" routine to graph buffer copy and redraw the map. From there, you draw on your sprites using a modified sprite routine. Then copy/draw again.
#2: The Sqrxz method. Draw a tilemap to start out.
Draw Sprites while saving erase information, Graph buffer copy, erase sprites, bitshift the graph screen, add in the missing tilemap column, repeat...

#1 is much faster.

[Jim e]

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

LOL that made me laugh

Ah now I get it... it's that spencer vs jim e thing

He's lying.

My mapper requires the user to add an extra row to the map buffer, his requires adding an extra column. Because of that mine is extremely fast with vertical scrolling, because it simply stays aligned by the tile row so it only returns a different draw from address to the user. His adds an extra column so he doesn't have to deal with clipping, but requires him to shift an extra column.

Mine handles animated tiles better. His uses the object system to animate tiles, meaning its limited to the number of objects it can render at any time. Mine can animate a full screen with out stealing object mem.

Mine supports 8x8 and 16x16 tiles. His only 16x16.
Mine supports variable map sizes. His only 16x16.
Mine supports 16bit and 8bit data entries. His only 8bit.
Mine can handle more tiles than memory permits. His only 128.
Both of ours can mask off bits that are used as flags, such as marking a tile walkable.

Mine can also move any numbers of pixels, even a completely new map. His only short distances.

In other words, mine is better.

[Liazon]

in other words, both guys designed each to fit different needs

[tr1p1ea]

Nothing better than a good tilemapper debate, especially when Jim and Spencer are involved .

There are many different ways to write a smoothscrolling mapper. Its great that driesguldolf and cjgone are jumping into it, can you guys think of any other methods? Will you be using your respective mappers for any projects? .

[Liazon]

i've been trying to use Jim's in a good project for awhile, but my artwork is not worthy of his tilemapper

on a side note, I think i'm improving at art in general

[Batman]

you know if any one catches this... i have a question about mapping, kinda. i don't get the 768 bytes on screen thing... i mean when i do the plotscreencopy b_call, or whatever it always wraps unless i put two extra bytes in the end of the first row of bytes... why is that???

[benryves]

I'm not entirely sure what you mean by that. Do you have some example code that doesn't do what you think it should?

[tr1p1ea]

PlotsScreen is a continuous 768 byte block of memory used as a screen buffer. Its 8 pixels per byte(1pix per bit) which is 12 bytes per row (12*8=96, how wide the screen is in pixels/bits). Since there are 64 rows (screen is 96x64), its 12*64=768.

However, since i mentioned that it is one big continuous block, that means that each row is stored one after the other in memory. If you want to get to the second row, you would have to advance 12 bytes into the buffer - which is why you might have seen people doing Y*12+X in sprite/tilemap routines.

Sorry if that was a little rushed.

[driesguldolf]

Aaah, I think I get it.
He's talking about the wrap effect (like when you draw a sprite without clipping near the edge of the screen).

It's like tr1p1ea said, all the rows (of 12 bytes each) are stored sequentially in memory. When you have a pointer pointing to the last 8 pixels of a row and you increment that pointer, you point at the first 8 pixels of the next row.

Adding 2 bytes merely 'hides' this effect. It just draws into the pixels that aren't visible anyway. (I assume 1 byte before and after a row)

[Batman]

alright thanx guys, that explained more than enough! thanx a million!!!