Scrolling Engine

[John Barrus]

Ok. Right now, getting a smooth-scrolling engine coded is probably the highest focus on our priority list. The engine has to be able to scroll all four directions with out too much trouble. Now I have a couple of ideas on how to do this, (after wading through the source to Mario, and a couple others), but we need to take into account other factors that this engine will affect (collision detection comes to mind).

Now, as I said to James in the irc room, scrolling up and down will be relatively easy: we just shift the whole plotsscreen buffer up or down 12 bytes and copy in the unoccupied line with new data from the level-map.

Shifting to the left and right is another story: There is no way to shift it in the plotsscreen ram 'left' or 'right'. I looked at the source for Mario and found this:

[james]

Hey john,i wasnt able to look at the source,and i wont be able to look at it until i get back from work,around 1 and ill sign on at 1:30eastern..sry..good ideas with the engine

[John Barrus]

That's alright. The source was very hard to look through, so expect a little challange finding anything that might relate. I won't be back til 10:30 pm eastern, so you can research what you can. Good luck understanding it

[John Barrus]

You might also want to try looking at Alien Breed's source. They use the same basic method of scrolling horizontally as Mario does. I guess it must be the standard way. (It certainly seems the easiest and most logical.)

Well, hopefully we can get a working engine by sometime next week. (I won't have much time between now and Saturday)

[james]

What u need to look at is sqarz.its a ti83+ ion game,u can get it at ticalc,weeeellll documented,and its a platform just like mario,but better!i think it uses marios engine

[John Barrus]

Ok, I will try looking at that, too.
Making it scroll horizontally isn't really the hard part, it's just copying the next bytes into the buffer that might provide a challenge.

[james]

Take a look at this

ScrollLeft:
ld b,a
ld a,(XBlock)
add a,12
ld hl,LevelSize
cp (hl) ; Check if end of level reached
; ld a, b
ret nc ; If so, return without scrolling

ld hl, backcnt
ld a, (hl)
dec a ; Allow to scroll back one more pixel
jr z, SL_back0 ; don't dec backcnt if it's already 1
ld (hl), a
SL_back0:
ld a, b
di ; Disable interrupts so IY can be used
ld hl,SqrxzBG+1
dec (hl) ; Update Sqrxz screen X coordinate
push af
push iy
ld hl,PlotScreen+$2E7 ; HL -> end of video_mem-2 rows
ld c,62 ; 62 rows to scroll ( leave 2 for the status bars )
RepScrollR1:
ld b,3 ; 3x4 bytes to scroll each row
or a ; Clear CF : a '0' will be put, so no res 0,(ix) will be used !
RepScrollR2: ; The actual scroll loop
rl (hl)
dec hl
rl (hl) ; It's faster to use 3x4 rotates instead of
dec hl ; 12x1 since the djnz is called much less frequently
rl (hl)
dec hl ; Every bit of speed is needed!
rl (hl)
dec hl
djnz RepScrollR2 ; Repeat the first scroll loop
dec c
jr nz,RepScrollR1 ; And scroll the next row
ld hl,(XScr)
inc hl
ld (XScr),hl ; Increase the scroll X coordinate
ld a,l
ld hl,XBlock
and $07 ; Check if the leftmost block has changed
jr z,Even
scf ; If not, there are 13 tiles left<->right
jr FindRightBlock
Even:
inc (hl) ; If so, increase XBlock
FindRightBlock:
ld a,(hl) ; A = x block tile to left
adc a,11 ; Add with 11 (or 12) to get the x block tile to right
ld h,0
ld l,a
add hl,hl
add hl,hl
add hl,hl
ld de,LevelPtr
add hl,de ; HL -> level data of the blocks to be put to the right
push hl
pop iy
ld a,(XScr)
and $07
ld hl,ExpTable
ld d,0
ld e,a
add hl,de
ld d,(hl) ; D = bit value to mask out of tile sprite data
ld c,8 ; 8 tiles to put
ld ix,PlotScreen+$0B
RepFillRight:
push de
ld a,(iy) ; A = tile to put
inc iy
bit 7,a ; Check if an enemy
jr z,SL_Tile
push bc ; Prepare to add an enemy to the enemy table
push hl
push af
ld a,8
sub c
add a,a
add a,a
add a,a
ld c,a ; C = y coordinate of enemy
ld a,(XBlock)
add a,12
ld h,0
ld l,a
add hl,hl
add hl,hl
add hl,hl ; HL = x coordinate of enemy
pop af
and $7F
call NewEnemy ; Add enemy to table
cp 5 ; Check if it was a fish
ld a,109 ; If so, then the tile should be replace with water
jr z,FillWater
xor a ; Else an empty tile
FillWater:
ld (iy-1),a ; Store the new tile
pop hl
pop bc
SL_Tile:
ld h,0
ld l,a
add hl,hl
add hl,hl
add hl,hl
ld de,Sprites
add hl,de ; HL -> tile to put
pop de
ld b,8 ; 8 rows in the sprite : puts 64 pixels, but not a pb
SR_Fill:
ld a,(hl)
inc hl
and d ; This masks out the only bit that will be put
jr z,SR_NextY ; If bit cleared, remove the last pixel
set 0,(ix) ; Else set it
SR_NextY:
push de
ld de,12
add ix,de ; IX -> next row in video mem
pop de
djnz SR_Fill ; Proceed with next row in tile
dec c
jr nz,RepFillRight ; And proceed with next tile
SR_Done:
pop iy
pop af
ei
ret

ScrollRight:
ld b,a
ld hl, backcnt
ld a, (hl)
cp 25
ret nc ; Don't scroll if maximum is reached
inc (hl)

ld a,b
di ; Disable interrupts so IY can be used
ld hl,SqrxzBG+1
inc (hl) ; Update Sqrxz screen X coordinate
push af
push iy
ld hl,PlotScreen ; HL -> start of video mem
ld c,62 ; 62 rows to scroll ( leave 2 for the status bars )
RepScrollL1:
ld b,3 ; 3x4 bytes to scroll each row
or a ; Clear CF : a '0' will be put, so no res 0,(ix) will be used !
RepScrollL2: ; The actual scroll loop
rr (hl)
inc hl
rr (hl) ; It's faster to use 3x4 rotates instead of
inc hl ; 12x1 since the djnz is called much less frequently
rr (hl)
inc hl ; Every bit of speed is needed!
rr (hl)
inc hl
djnz RepScrollL2 ; Repeat the first scroll loop
dec c
jr nz,RepScrollL1 ; And scroll the next row

ld hl,(XScr)
dec hl
ld (XScr),hl ; decrease the scroll X coordinate
ld a,l
ld hl,XBlock
and $07 ; Check if the leftmost block has changed
xor 7
jr nz, FindLeftBlock
dec (hl) ; If so, decrease XBlock
FindLeftBlock:
ld l,(hl) ; A = x block tile to left
ld h,0
add hl,hl
add hl,hl
add hl,hl
ld de,LevelPtr
add hl,de ; HL -> level data of the blocks to be put to the right
push hl
pop iy
ld a,(XScr)
and $07
ld hl,ExpTable+1
ld d,0
ld e,a
add hl,de
ld d,(hl) ; D = bit value to mask out of tile sprite data
ld c,8 ; 8 tiles to put
ld ix,PlotScreen
RepFillLeft:
push de
ld l,(iy) ; l = tile to put
inc iy
ld h,0 ; No ennemy check as this part as already be shown
add hl,hl
add hl,hl
add hl,hl
ld de,Sprites
add hl,de ; HL -> tile to put
pop de
ld b,8 ; 8 rows in the sprite : puts 64 pixels, but not a pb
SL_Fill:
ld a,(hl)
inc hl
and d ; This masks out the only bit that will be put
jr z,SL_NextY ; If bit cleared, remove the last pixel
set 7,(ix) ; Else set it
SL_NextY:
push de
ld de,12
add ix,de ; IX -> next row in video mem
pop de
djnz SL_Fill ; Proceed with next row in tile
dec c
jr nz,RepFillLeft ; And proceed with next tile
SL_Done:
pop iy
pop af
ei
ret

[james]

JOHN- do u want to go ahead and work on the engine,while i do some graphics,cyan said he hasnt even started,we are going to need a backround for the routine,so im going to have to start making the graphics,if cyan can make them better he said that he would fix them later,he wont be able to start for a week on them....is that ok with u,i would have to leave the actual engine up to u
i will like make a map(tile map) with the sprites and then u can just combine your routine with mine,ok
it would be faster that way,

[John Barrus]

Hey, sure that'd be great. But if I need help, I'll ask. I can probably get a working engine by thursday next week. Email me the sprite codes once you can. (maybe I'll even work on a few of my own. --It would be kinda nice to restrict this project to actual UTI members, so if you can handle the graphics on your own, it'd be great!)

[james]

Ok,i will start working on some graphics
do u want them .db 01010101 or compiled using istudio?
i will try to have some done by tommorow,and i will email them to ya,ok
thx

[John Barrus]

I'd prefer having them in binary .db statements if it's not too much trouble.

[Adm.Wiggin]

i think istudio is easier, but thats just me... u could use istudio, then go and change all the hex to binary, long but easier in the long run (unless u know the exact format of a grayscale sprite!)...

[John Barrus]

Are you guys sure you want grayscale? I downloaded duck's routine and it said all programs would probably only run at 10% their normal speed. And this is most likely gonna be a CPU-intensive game anyway. There's no way that we could get a fast game out of that. I wonder if it is worth that much...

[Adm.Wiggin]

did u try the demo games? one of them goes so fast, i cant even play it!

[james]

Greyscale is definaltly out of the question,until the final boss where sonic goes super sonic,other than that there is no way we can get the speed necassry to make sonic go as fast as he should.john use black nd white for now,at least.

[John Barrus]

Just a little update: I've got the scrolling part done for all four directions, now I just need to work on filling in the lines that are left empty by the scrolling. I'm also having a little trouble with the tile map routine, I think we'll probably have to write a completely different one before we release anything. (I got the routine from Maxcoderz, it isn't exactly suiting our purposes)

[Tyler]

For a scrolling engine, couldn't you guys just inc or de x,y coords and clip sprites?

[John Barrus]

That is the base of how the engine works:

We shift the whole screen right/left using op codes rr and rl, tehn to fill in the empty columns, we read from the map data and mask the needed bit and place it on the screen.

[Tyler]

The only problem with that is collisions would be extremely hard to detect, you'd have to have the location of some items on the screens or something!

[Adm.Wiggin]

no, u just check the array that is the tile map for collisions, not the screen, and the problem is solved!