261 replies to this topic

[Heaven/TQA]

;puts one char on screen(x,y) 
;in x,y
;in a = char tile no
draw_char:  
			sta draw_char1+1
			lda linetab3l,y
			clc
			adc collumtabl,x
			sta v1
			lda linetab3h,y
			adc collumtabh,x
			sta v1+1
draw_char1	ldy #$ff
			lda chartabl,y
			sta v0
			lda chartabh,y
			sta v0+1
			ldy #7
draw_char0	lda (v0),y
			sta (v1),y
			dey
			bpl draw_char0
			rts

is my "put background tile on screen".

and here is my not optimised to death "sprite" routine just to give you an idea how much code needed to "mimic" 1 sprite on c64... where there you have 2 POKES for positioning (or 2 LDA/STAs for x and ypos (in 256 mode))

; 1000 PROC DRAW_SIMPLE
; 1010   AD=SPR+NO*63
; 1020   FOR J=0 TO $14
; 1030     FOR I=0 TO 2
; 1040       POKE F+J+I*24+Y,PEEK(AD)
; 1045       AD=AD+1
; 1050     NEXT I
; 1060   NEXT J
; 1100 ENDPROC 			
;each 4 shifted sprites are in 1 page (64 bytes each)
draw_simple: lda #3*8 ;vertical only 3 sprites
			sta got_abs2+1
			lda xpos
			tax
			ldy tempfacing
			cpy #8
			bcc draw_simple00
			lda ypos
draw_simple00 
			and #3 ;0-3
			ora tempfacing
			tay ;shifted
			lda spritetabl,y
			sta simple0+1
			clc
			adc #21 ;y size per stripe
			sta simple1+1
			adc #21
			sta simple2+1
			lda spritetabh,y
			sta simple0+2
			sta simple1+2
			sta simple2+2
			txa
			lsr
			lsr
			tax
			ldy ypos
			clc
			lda linetabl,y
			adc collumtabl,x
			sta v1
			lda linetabh,y
			adc collumtabh,x
			sta v1+1
			lda v1
			clc
			adc #24
			sta v2
			lda v1+1
			adc #0
			sta v2+1
			lda v1
			clc
			adc #48
			sta v3
			lda v1+1
			adc #0
			sta v3+1
clear_simple:	lda yptab,y
			tay
;now copy 63 bytes = 3 * 21 bytes 			
			ldx #0
simple0:		lda $ffff,x
			eor (v1),y
			sta (v1),y
simple1:		lda $ffff,x
			eor (v2),y
			sta (v2),y
simple2:		lda $ffff,x
			eor (v3),y
			sta (v3),y
			iny
			inx
			cpx #21
			bcc simple0
			rts

; PROC DRAW_SPLIT
; 2010   EF=F+1024
; 2020   H1=24-PEEK($7F00+YP)
; 2030   H2=21-H1
; 2040   AD=SPR+NO*63
; 2050   FOR J=0 TO H1-1
; 2060     FOR I=0 TO 2
; 2070       POKE F+J+I*24+Y,PEEK(AD)
; 2080       AD=AD+1
; 2090     NEXT I
; 2100   NEXT J
; 2110   FOR J=0 TO H2-1
; 2120     FOR I=0 TO 2
; 2130       POKE EF+J+I*24,PEEK(AD)
; 2140       AD=AD+1
; 2150     NEXT I
; 2160   NEXT J
;2199 ENDPROC 
draw_split: lda #4*8
			sta got_abs2+1
			ldy ypos
			lda h1tab,y
			sta h1+1
			
			lda xpos
			tax
			ldy tempfacing
			cpy #8
			bcc draw_split00
			lda ypos
draw_split00 and #3
			ora tempfacing
			tay ;shifted
			lda spritetabl,y
			sta split0+1
			sta split00+1
			clc
			adc #21 ;y size per stripe
			sta split1+1
			sta split11+1
			adc #21
			sta split2+1
			sta split22+1
			lda spritetabh,y
			sta split0+2
			sta split1+2
			sta split2+2
			sta split00+2
			sta split11+2
			sta split22+2
			txa
			lsr ;div 2
			lsr ;div 2
			tax
			ldy ypos
			lda linetabl,y
			clc
			adc collumtabl,x
			sta v1
			lda linetabh,y
			adc collumtabh,x
			sta v1+1
			lda v1
			clc
			adc #24
			sta v2
			lda v1+1
			adc #0
			sta v2+1
			lda v1
			clc
			adc #48
			sta v3
			lda v1+1
			adc #0
			sta v3+1
clear_split: lda yptab,y
			tay
			ldx #0
split0:		lda $ffff,x
			eor (v1),y
			sta (v1),y
split1:		lda $ffff,x
			eor (v2),y
			sta (v2),y
split2:		lda $ffff,x
			eor (v3),y
			sta (v3),y
			iny
			inx
h1:			cpx #21
			bne split0
			clc
			lda v1+1
			adc #4
			sta v1+1
			lda v2+1
			adc #4
			sta v2+1
			lda v3+1
			adc #4
			sta v3+1

			ldy #0
split00:	lda $ffff,x
			eor (v1),y
			sta (v1),y
split11:	lda $ffff,x
			eor (v2),y
			sta (v2),y
split22:	lda $ffff,x
			eor (v3),y
			sta (v3),y
			iny
			inx
			cpx #21
			bne split00
			rts

clear:		ldy ypos
			lda #21
			clc
			adc yptab,y
			cmp #25
			bcc clear0
			jmp clear_split
clear0		jmp clear_simple

the Turbo Basic routines there make the code easier to understand. important to understand is the mentioned layout of the screen.

[Heaven/TQA]

the "draw split" is necessary for crossing the "2 fonts" edge...

[José Pereira]

Heaven thanks for all the Time you've spent with me.
You've been a very good Teacher.

Now things are more clearly to me, very, very clear.


But my thoughts always going on, and on,...

I thought I read that this way, acting as if we were in a Bitmap Mode is very difficult to do on Scrolling Games?

Why?

And only on Horizontal Scrollers or in Vertical and Horizontal?


Could we somehow get that:
0,3,6,...
1,4,7,...
2,5,8,...
2

[Heaven/TQA]

ok. scrolling...

question... for Rick Dangerous? or Shooter?

if shooter then difficult in this mode (at least horizontal). if general bitmap? possible just have a look at Zybex or Droll.

did you had a look on the Menace demo done by Jetboot Jack? this uses charmode and softsprites with your "dedicated chars for sprite" method.

[José Pereira]

Heaven/TQA, on Thu Sep 16, 2010 1:37 PM, said:

ok. scrolling...

question... for Rick Dangerous? or Shooter?

if shooter then difficult in this mode (at least horizontal). if general bitmap? possible just have a look at Zybex or Droll.

did you had a look on the Menace demo done by Jetboot Jack? this uses charmode and softsprites with your "dedicated chars for sprite" method.

Yes, I was thinking this Mode, to use the:
ADG...
BEH...
CFI...

in an Horizontal Shoot, a Platform or any other possible to get the 5thcolour.
Yes, in a 4Colour AnticE&F like Zybex I know.
But what'sthe explanation for that?

Why can't you go placing your Gfxs. in the Screen Chars nºs.
A Horizontal Scrolling, for example in 32 Narrow Mode, the A8 consider 40Chars that is 1Charset by 3Lines (40&48 consider 48) for the Fine Scrolling.
Why not having like:
000,003,006,...,117
001,004,007,...,118
002,005,008,...,119

It is not possible go and place the Players in this Chars using:
ADG
BEH
CFI

__________________________________________________________________________________________

And if I use this method but have real Soft Sprites. Reserve the necessary Chars for the Shape+Shifting for each Sprite, even if I, for example, have to reduce in the Narrow mode, for example from 1Charset by 3Lines to 1Charset by 2Lines (and have now 48Chars free for Soft Sprites)?

__________________________________________________________________________________________






And in Vertical Scrollers is it possible?








Thanks.
Greetings.
José Pereira.

[José Pereira]

Near, very near to a good IMHO, I think:


José Pereira.

[Heaven/TQA]

you can use this mode... and $d404 to scroll but as it is a virtual bitmap mode... how would you handle the coarse scrolling? you would need to build the whole screen incl. background tiles at screen position-1. so you would need to redraw all chars! without moving sprites etc.

you could use double buffer method like Gameboy and Nintendo DS are using but I doubt it will be fast enough as you would need at least to draw 25 chars (a complete vertical line of chars).

[José Pereira]

Thanks, I understand now.

I'll try not to ask more today...
Have to turn into other things.

Here they are, the Level1 Chars.

It haves all Screens Gfxs, 1Tile for Rick, 1Tile for Enemy1, other for Enemy2 and last other for Enemy3 (Maxim. Enemys at Screen on Level1 is 3), Moving Rocks, Pick-up Objects,...

I think all are here.
Some are already in 2:1, others to turn into 2:1 and others just awnfull in 2:1.

But you can see something:
 Level1_Chars&Tiles.zip   24.68K   25 downloads



If anybody is interested in re-make to 2:1, here is all the Game's Sprites from amiga version:




I think I'll go into something different, no more Rick for Today.


Thanks.
Greetings.
José Pereira.

[popmilo]

Heaven/TQA, on Thu Sep 16, 2010 10:18 AM, said:

... So you need RAM for your sprite shapes. 4x more than on c64 due to the shifting. one reason why conversion need at least 128k or more RAM on XE or using the Corina Cart...

I use 3 shift tables for that (3x512 bytes):
If x and 3 = 0 then sprite is on char boundary and no shift needed.
If x and 3 = 1,2 or 3 then you need to take one byte from one of three tables for 'left-hi' shifted bytes, and one from 'right-low' table of shifted values.

1.5k and you can have as much sprites as you need...

Not as fast as preshifted data but good enough for few sprites...

[Stephen]

popmilo, on Fri Oct 1, 2010 5:09 PM, said:

Heaven/TQA, on Thu Sep 16, 2010 10:18 AM, said:

... So you need RAM for your sprite shapes. 4x more than on c64 due to the shifting. one reason why conversion need at least 128k or more RAM on XE or using the Corina Cart...

I use 3 shift tables for that (3x512 bytes):
If x and 3 = 0 then sprite is on char boundary and no shift needed.
If x and 3 = 1,2 or 3 then you need to take one byte from one of three tables for 'left-hi' shifted bytes, and one from 'right-low' table of shifted values.

1.5k and you can have as much sprites as you need...

Not as fast as preshifted data but good enough for few sprites...

Sorry for the dumb question. Do these 512 byte tables contain pre-shifted sprite data and the combination of them allow for all possible variants of the sprites to be reconstructed?

[Rybags]

512 bytes = 2 tables for the shift combinations of each 256 possible values. They're not actual sprite data, just representations of what values 0-255 would be after shifting e.g. 2, 4, 6 bits for multicolour modes.

e.g. a sprite shifting 2 pixels right with initial value binary "1001 0110"

First table entry would be "0010 0101" - that's the left part of the sprite.
Second table entry would be "1000 0000" - that's the right part. You then OR that with the subsequent entry to the right for the next part of the sprite, e.g. you'd do it however many times needed depending on how wide the sprite is.

Another method can be to just use a 256 byte table, with a "No Carry" rotate of the data.

Then you just AND out the appropriate bits to give you the left or right part of the byte - halves the memory requirement but slightly more CPU time.

ed - removed % binary and enclosed in quotes, for some reason it scraps the leading zeroes.

Edited by Rybags, Sat Oct 2, 2010 8:49 AM.

[popmilo]

Rybags, on Sat Oct 2, 2010 8:46 AM, said:

...First table entry would be "0010 0101" - that's the left part of the sprite.
Second table entry would be "1000 0000" - that's the right part. You then OR that with the subsequent entry to the right for the next part of the sprite, e.g. you'd do it however many times needed depending on how wide the sprite is.
...

Thanks for explaining that instead of me

It is slower then preshifted sprite definitions, but a lot of memory is saved this way...
Maybe now with cartridge based games we could focus on something bigger and better... Maybe even hard coded sprites for even more speed...