Heaven/TQA Posted September 16, 2010 Share Posted September 16, 2010 ;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. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted September 16, 2010 Share Posted September 16, 2010 the "draw split" is necessary for crossing the "2 fonts" edge... Quote Link to comment Share on other sites More sharing options...
José Pereira Posted September 16, 2010 Author Share Posted September 16, 2010 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 Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted September 16, 2010 Share Posted September 16, 2010 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. Quote Link to comment Share on other sites More sharing options...
José Pereira Posted September 17, 2010 Author Share Posted September 17, 2010 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. Quote Link to comment Share on other sites More sharing options...
José Pereira Posted September 17, 2010 Author Share Posted September 17, 2010 Near, very near to a good IMHO, I think: José Pereira. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted September 17, 2010 Share Posted September 17, 2010 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). Quote Link to comment Share on other sites More sharing options...
José Pereira Posted September 17, 2010 Author Share Posted September 17, 2010 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 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. Quote Link to comment Share on other sites More sharing options...
popmilo Posted October 1, 2010 Share Posted October 1, 2010 ... 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... Quote Link to comment Share on other sites More sharing options...
+Stephen Posted October 2, 2010 Share Posted October 2, 2010 ... 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? Quote Link to comment Share on other sites More sharing options...
Rybags Posted October 2, 2010 Share Posted October 2, 2010 (edited) 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 October 2, 2010 by Rybags 2 Quote Link to comment Share on other sites More sharing options...
popmilo Posted October 3, 2010 Share Posted October 3, 2010 ...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... Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.