LOL that made me laughSpencer wrote:I forget how Zelda's works, but its superior to jim's.
[Z80-asm] Advise about tilemapping
Moderator: MaxCoderz Staff
- driesguldolf
- Extreme Poster
- Posts: 395
- Joined: Thu 17 May, 2007 4:49 pm
- Location: $4080
- Contact:
-
- Regular Member
- Posts: 83
- Joined: Tue 18 Apr, 2006 5:33 am
- Location: Washington->UC Berkeley '15
Haha..lol...I can't code very well.. My code for horiz scrolling: (LOL)
Plus.. the actual screen horizantal thingy (didn't make):
Optimized much?
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
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
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.
#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.
You know your hexadecimal output routine is broken when it displays the character 'G'.
- Jim e
- Calc King
- Posts: 2457
- Joined: Sun 26 Dec, 2004 5:27 am
- Location: SXIOPO = Infinite lives for both players
- Contact:
He's lying.driesguldolf wrote:Ah now I get it... it's that spencer vs jim e thingjimmothy wrote:LOL that made me laughSpencer wrote:I forget how Zelda's works, but its superior to jim's.
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.
- tr1p1ea
- Maxcoderz Staff
- Posts: 4141
- Joined: Thu 16 Dec, 2004 10:06 pm
- Location: I cant seem to get out of this cryogenic chamber!
- Contact:
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? .
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? .
- tr1p1ea
- Maxcoderz Staff
- Posts: 4141
- Joined: Thu 16 Dec, 2004 10:06 pm
- Location: I cant seem to get out of this cryogenic chamber!
- Contact:
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.
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
- Extreme Poster
- Posts: 395
- Joined: Thu 17 May, 2007 4:49 pm
- Location: $4080
- Contact:
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)
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)