JetZone

[Freespirit]

Back by popular demand. The return of Arnie. Arnie thought he should be doing more than flying through gaps with a galaxy full of aliens. He wants a laser gun and he wasn't happy about not being able to see behind him.

I've added bi-directional movement to start.

[dfzx]

I've added bi-directional movement to start.

Classic Spectrum game illusion: there isn't actually bi-directional movement there, the sprite is stationary. The only thing that's moving is the stars. It's so simple, and yet works so well.

[Freespirit]

My first attempt at a laser. Looks a bit weird when he shoots and then moves. I'll have to see how jetpac/defender do it.

[Freespirit]

Shooting left AND right now.





If i wanted to scroll the planet at the bottom 1 character at a time left and right. What is the quickest way? I just copy the data straight to the screen at the moment.

[Freespirit]

Added my first sound effect to the laser and added an alien with basic movement that heads towards Arnie. The alien is changing colour so i assume he is between two colour attributes. I've only coloured one square at the moment. I might try to add a radar (defender style) at some point so it feels more like you are travelling somewhere.

[R-Tape]

Neat.

If i wanted to scroll the planet at the bottom 1 character at a time left and right. What is the quickest way? I just copy the data straight to the screen at the moment.

It depends how you're drawing it in the first place, and how fancy you want the landscape to be. In this case I'd print the landscape as you would any text string.

For a really simple scroll effect, you could just toggle between printing "ABABABABABABABABABABABABABABABAB" and "BABABABABABABABABABABABABABABABA" (with A + B being UDGS of course) when moving.

For something fancier, you could have a landscape as a very long string of lots of different graphics "ABCDEFGHIJK....etc and every time you print 32 of them from a given position. When you move left, the print position moves back one place, and right, one forward. You store the position ready for next time.

[AndyC]

If the planet is rotating in place, then reading then I'd be inclined to just do the copy in place using a block of LDIs. Taking care to move the end bytes. Probably quicker than figuring out what to draw.

[R-Tape]

Or you could have an easy smooth effect using RLC. You can't have a varied landscape of course.

Code: Select all

org 32768 ;quick and rough demo
	ld hl,18432
	ld b,32
lp	ld (hl),254
	inc l
	djnz lp
main:	halt
	ld hl,18432
	ld b,32
rlp:	rlc (hl)
	inc l
	djnz rlp
	jr main

[Freespirit]

Neat.

If i wanted to scroll the planet at the bottom 1 character at a time left and right. What is the quickest way? I just copy the data straight to the screen at the moment.

It depends how you're drawing it in the first place, and how fancy you want the landscape to be. In this case I'd print the landscape as you would any text string.

For a really simple scroll effect, you could just toggle between printing "ABABABABABABABABABABABABABABABAB" and "BABABABABABABABABABABABABABABABA" (with A + B being UDGS of course) when moving.

For something fancier, you could have a landscape as a very long string of lots of different graphics "ABCDEFGHIJK....etc and every time you print 32 of them from a given position. When you move left, the print position moves back one place, and right, one forward. You store the position ready for next time.

Thanks. That sounds like an good option

[Freespirit]

If the planet is rotating in place, then reading then I'd be inclined to just do the copy in place using a block of LDIs. Taking care to move the end bytes. Probably quicker than figuring out what to draw.

What are LDI’s? Not seen that yet.

[Freespirit]

Or you could have an easy smooth effect using RLC. You can't have a varied landscape of course.

Code: Select all

org 32768 ;quick and rough demo
	ld hl,18432
	ld b,32
lp	ld (hl),254
	inc l
	djnz lp
main:	halt
	ld hl,18432
	ld b,32
rlp:	rlc (hl)
	inc l
	djnz rlp
	jr main

Yes, I don’t have a varied landscape just 2 character lines. I might try this option first, it should be quick to try.

[Nienn Heskil]

Or you could have an easy smooth effect using RLC. You can't have a varied landscape of course.

Or use RL and RR to just scroll what is onscreen in a looped manner. You'd need to take care of the last pixel at the edge toward which it is moving (put it at the opposing edge). Rough example:

Code: Select all

	;set HL to left edge
	ld a,(hl)	
	rlca			;set the carry flag to the value of the last pixel at the left
	;set HL to right edge
.loop
	rl (hl)			;scrolls in the last bit, then everything else in the line towards the left edge
	dec l
	djnz .loop

If RL/RR is too slow visually, there's RLD/RRD (scrolls by 4px). It is similar, although more tricky.

[Freespirit]

Or you could have an easy smooth effect using RLC. You can't have a varied landscape of course.

Or use RL and RR to just scroll what is onscreen in a looped manner. You'd need to take care of the last pixel at the edge toward which it is moving (put it at the opposing edge). Rough example:

Code: Select all

	;set HL to left edge
	ld a,(hl)	
	rlca			;set the carry flag to the value of the last pixel at the left
	;set HL to right edge
.loop
	rl (hl)			;scrolls in the last bit, then everything else in the line towards the left edge
	dec l
	djnz .loop

If RL/RR is too slow visually, there's RLD/RRD (scrolls by 4px). It is similar, although more tricky.

oh, of course, you need to get the last pixel, thanks. I'll try it now. Not seen RLD before. Something else to consider.

[ketmar]

What are LDI’s? Not seen that yet.

one step of LDIR command. does rougly this:

Code: Select all

dec bc
ld a,(hl)
inc hl
ld (de),a
inc de

it is not repeated (LDIR repeats until BC is zero). alot of LDI commands is the common way to copy blocks of data, due to their speed.
LDI: 16 tstates
LDIR: 21 tstates
code above: 6+7+6+7+6 == 32 tstates (or 26 without "dec bc", which isn't needed, and was included only to emulate LDI).

as you can see, sequenced LDI commands is the fastest way (of those three) to copy a data block.

there is even faster method using the stack, but it is slighly more complex. yet with it you can do things like Destiny Mission (the game itself is a crap, but the scrolling is very nice ;-).

p.s.: you prolly don't need this heavy artillery yet, there should be alot of free time in your drawing code. ;-)

[Freespirit]

Or you could have an easy smooth effect using RLC. You can't have a varied landscape of course.

Or use RL and RR to just scroll what is onscreen in a looped manner. You'd need to take care of the last pixel at the edge toward which it is moving (put it at the opposing edge). Rough example:

Code: Select all

	;set HL to left edge
	ld a,(hl)	
	rlca			;set the carry flag to the value of the last pixel at the left
	;set HL to right edge
.loop
	rl (hl)			;scrolls in the last bit, then everything else in the line towards the left edge
	dec l
	djnz .loop

If RL/RR is too slow visually, there's RLD/RRD (scrolls by 4px). It is similar, although more tricky.

thanks, the RL worked perfectly but as you say looked a bit slow. I'll look at the other options as well

[Freespirit]

What are LDI’s? Not seen that yet.

one step of LDIR command. does rougly this:

Code: Select all

dec bc
ld a,(hl)
inc hl
ld (de),a
inc de

it is not repeated (LDIR repeats until BC is zero). alot of LDI commands is the common way to copy blocks of data, due to their speed.
LDI: 16 tstates
LDIR: 21 tstates
code above: 6+7+6+7+6 == 32 tstates (or 26 without "dec bc", which isn't needed, and was included only to emulate LDI).

as you can see, sequenced LDI commands is the fastest way (of those three) to copy a data block.

there is even faster method using the stack, but it is slighly more complex. yet with it you can do things like Destiny Mission (the game itself is a crap, but the scrolling is very nice .

p.s.: you prolly don't need this heavy artillery yet, there should be alot of free time in your drawing code.

Thanks for the info. So i will need an LDI for every byte i move. So 16x32? is that right?

[Freespirit]

Neat.

If i wanted to scroll the planet at the bottom 1 character at a time left and right. What is the quickest way? I just copy the data straight to the screen at the moment.

It depends how you're drawing it in the first place, and how fancy you want the landscape to be. In this case I'd print the landscape as you would any text string.

For a really simple scroll effect, you could just toggle between printing "ABABABABABABABABABABABABABABABAB" and "BABABABABABABABABABABABABABABABA" (with A + B being UDGS of course) when moving.

For something fancier, you could have a landscape as a very long string of lots of different graphics "ABCDEFGHIJK....etc and every time you print 32 of them from a given position. When you move left, the print position moves back one place, and right, one forward. You store the position ready for next time.

I'm just looking at this, i didn't realise there is only 21 UDG's and i need 64 for my 2 lines. So i used the character set redefine.

Code: Select all

ld a,2
call 5633

the above code i use to print a character only seems to print above where my planet surface is. How do i get to the bottom 2 lines?

[AndyC]

one step of LDIR command. does rougly this:

Code: Select all

dec bc
ld a,(hl)
inc hl
ld (de),a
inc de

it is not repeated (LDIR repeats until BC is zero). alot of LDI commands is the common way to copy blocks of data, due to their speed.
LDI: 16 tstates
LDIR: 21 tstates
code above: 6+7+6+7+6 == 32 tstates (or 26 without "dec bc", which isn't needed, and was included only to emulate LDI).

as you can see, sequenced LDI commands is the fastest way (of those three) to copy a data block.

there is even faster method using the stack, but it is slighly more complex. yet with it you can do things like Destiny Mission (the game itself is a crap, but the scrolling is very nice .

p.s.: you prolly don't need this heavy artillery yet, there should be alot of free time in your drawing code.

Thanks for the info. So i will need an LDI for every byte i move. So 16x32? is that right?

It depends on how much you unroll the loop(s).

A single line would use 31 LDI instructions plus a little extra code to handle moving the first byte to the end. You could repeat that 16 times or just put it in a loop.

[ketmar]

Thanks for the info. So i will need an LDI for every byte i move. So 16x32? is that right?

basically what [mention]AndyC[/mention] wrote. but you don't need it yet, i just explained it so you can refer to that post later. ;-) right now you don't have alot of things happening in the frame, and you have plenty of free tstates, so you can simply print the graphics char by char. just don't use ROM routine for that (it is very slow), roll your own simple one instead.

basically, it is a simplified sprite printing: calculate char address from (x,y) (not pixel, but char), calculate tile gfx address from tile code, and copy 8 bytes, incrementing by 256. like this (warning! the code is not tested, i just directly typed it here ;-):

Code: Select all

; in: A -- tile index
; D: y
; E: x
; out: AF,DE,BC,HL: dead
; calculate tile address
ld l,a
ld h,0
add hl,hl
add hl,hl
add hl,hl
ld bc,tilegfx
add hl,bc
; calculate char address
ld a,d
ld b,a
and #18
or #40
ld d,a
ld a,b
rrca
rrca
rrca
and #e0
or e
ld e,a
; copy 8 bytes
ld b,8
cbloop:
ld a,(hl)
ld (de),a
inc hl
inc d
djnz cbloop
ret

it doesn't set attribute (you can add that code if you need it). now just call that in a loop, printing your bottom tiles as you need. it is much faster than ROM code, and you can use all 24 lines. ;-)

[Freespirit]

Thanks for the info. So i will need an LDI for every byte i move. So 16x32? is that right?

basically what @AndyC wrote. but you don't need it yet, i just explained it so you can refer to that post later. right now you don't have alot of things happening in the frame, and you have plenty of free tstates, so you can simply print the graphics char by char. just don't use ROM routine for that (it is very slow), roll your own simple one instead.

basically, it is a simplified sprite printing: calculate char address from (x,y) (not pixel, but char), calculate tile gfx address from tile code, and copy 8 bytes, incrementing by 256. like this (warning! the code is not tested, i just directly typed it here :

Code: Select all

; in: A -- tile index
; D: y
; E: x
; out: AF,DE,BC,HL: dead
; calculate tile address
ld l,a
ld h,0
add hl,hl
add hl,hl
add hl,hl
ld bc,tilegfx
add hl,bc
; calculate char address
ld a,d
ld b,a
and #18
or #40
ld d,a
ld a,b
rrca
rrca
rrca
and #e0
or e
ld e,a
; copy 8 bytes
ld b,8
cbloop:
ld a,(hl)
ld (de),a
inc hl
inc d
djnz cbloop
ret

it doesn't set attribute (you can add that code if you need it). now just call that in a loop, printing your bottom tiles as you need. it is much faster than ROM code, and you can use all 24 lines.

Many thanks for the code and explanation, much appreciated.

[R-Tape]

I'm just looking at this, i didn't realise there is only 21 UDG's and i need 64 for my 2 lines. So i used the character set redefine.

Code: Select all

ld a,2
call 5633

the above code i use to print a character only seems to print above where my planet surface is. How do i get to the bottom 2 lines?

LD A,1 is the bottom two lines, LD A,2 is the everything above.

[Freespirit]

I'm just looking at this, i didn't realise there is only 21 UDG's and i need 64 for my 2 lines. So i used the character set redefine.

Code: Select all

ld a,2
call 5633

the above code i use to print a character only seems to print above where my planet surface is. How do i get to the bottom 2 lines?

LD A,1 is the bottom two lines, LD A,2 is the everything above.

Thanks R-Tape

[Freespirit]

Added planet scrolling. Thanks to R-Tape, Nienn Heskil and Ketmar for the help.

[R-Tape]

Great. Please turn this into a game.

The gif doesn't show it, but have you got laser collision with the green alien yet?

I'm a bit jealous. It involves a lot of toil, but nothing beats the white heat of your first z80 coding project (yes—NOTHING!).

[Juan F. Ramirez]

Looks cool, [mention]Freespirit[/mention] ! Keep coding!