www.retrosoftware.co.uk
http://www.retrosoftware.co.uk/forum/

C64 Sprites to BBC convertion
http://www.retrosoftware.co.uk/forum/viewtopic.php?f=73&t=343		 Page 3 of 6
Author:  MartinB [ Wed Oct 07, 2009 10:30 pm ]
Post subject:  Re: C64 Sprites to BBC convertion
Hi Colin.

Been following with interest :D

Is the second one actually faster? Running them both in BeebEm at 0.1 speed shows demo 2 is moving the sprite in much bigger XY steps and hence it appears faster. If you changed the first demo to move at these intervals would it not be equally fast?

(I'm just a novice btw ;) )

EDIT : I guess what I'm asking is related to an earlier question I asked here in that you could perhaps keep your first method but increase the steps since at 50Hz the screen can't paint all the interval steps at faster speeds.

Martin
Author:  ColinD [ Wed Oct 07, 2009 11:09 pm ]
Post subject:  Re: C64 Sprites to BBC convertion
All this stuff may seem trivial... BUT.... my testing / research may prove usefull to NON-C64 guys.... as I've almost kind of unlocked a method of storing graphics in a more memory efficient way.... (very much a trade off speed wise though !!!) - Like I say I'm coming in from a different angle, and find the bbc native graphics storage format a little klunky... lol .....
Author:  ColinD [ Wed Oct 07, 2009 11:11 pm ]
Post subject:  Re: C64 Sprites to BBC convertion
MartinB wrote:
Hi Colin.

Been following with interest :D

Is the second one actually faster? Running them both in BeebEm at 0.1 speed shows demo 2 is moving the sprite in much bigger XY steps and hence it appears faster. If you changed the first demo to move at these intervals would it not be equally fast?

(I'm just a novice btw ;) )

EDIT : I guess what I'm asking is related to an earlier question I asked here in that you could perhaps keep your first method but increase the steps since at 50Hz the screen can't paint all the interval steps at faster speeds.

Martin


Hey.. Hold on... I'm the BBC novice here !! (Trust me !!)

Yes.. the 2nd one is much much faster.....its actually increasing in the same steps. (look at the pixels/artefacts)... Its just a LOT LOT LOT faster, so it just looks like its plotting in bigger steps (its done the convertion code once at the start, instead of every display loop)..... So..its plotting faster..... hope that makes sense... I'm on my 6th can of Strong Bow before bedtime, lol !!!

Ps.. I'm not locking to the screen refresh... I'm running as fast as I can... (screen refresh sync is a little over my head for now)
Author:  MartinB [ Wed Oct 07, 2009 11:38 pm ]
Post subject:  Re: C64 Sprites to BBC convertion
Ok - two novices then ;)

No, what I'm saying (badly) is that there's no point in updating/plotting a sprite any faster than every 20ms. Thus, you can just work out where it will be in 20ms time, which for a fast sprite might be tens of pixels (bytes) away, and the interim time saved is then free to do other things.

(Hmm.. someone else will be able to explain this much better tomorrow :lol:)

Martin
Author:  ColinD [ Wed Oct 07, 2009 11:45 pm ]
Post subject:  Re: C64 Sprites to BBC convertion
MartinB wrote:
Ok - two novices then ;)

No, what I'm saying (badly) is that there's no point in updating/plotting a sprite any faster than every 20ms. Thus, you can just work out where it will be in 20ms time, which for a fast sprite might be tens of pixels (bytes) away, and the interim time saved is then free to do other things.

(Hmm.. someone else will be able explain this better tomorrow :lol:)

Martin


Yes... you are right.... But I'm 'speed testing' at the moment....

If you look at the fast code.... It takes say about a second (well maybe just under) to do 2 loops round the screen.... one loop is 256 sprite plots, so its plotting at least 500 sprites per second or say 10 per 20ms or frame update (hence the big steps) .... Make sense ?? - Now a game may plot a few sprites, not just one.... so If I went for the slower code, I may only get say 2 per frame instead.... so If I were plotting mutiple sprites, things would slow down a lot... It all depends on how fluid/fast you want the graphics to update.... I'm looking at no slower than about 15 frames per second or so... for what I want to do...eventually.....

Cheers, Col
Author:  MartinB [ Wed Oct 07, 2009 11:51 pm ]
Post subject:  Re: C64 Sprites to BBC convertion
Ok Colin - understood.

See, this forum works in a similar way - the guys that know what they're talking about come on at frame rate but I sneak in during flyback to ask dumb questions and learn a bit more about sprites n stuff :lol:

Martin
Author:  ColinD [ Thu Oct 08, 2009 12:12 am ]
Post subject:  Re: C64 Sprites to BBC convertion
25 Frames per second would be cool.. with lots of graphics flying around...Its all a trade off..... Don't think I'll make that though, lol !!!
Author:  ColinD [ Thu Oct 08, 2009 9:41 pm ]
Post subject:  Re: C64 Sprites to BBC convertion
Modified to convert the sprite, then plot 16 of them..... You can see its slowing down now.... No masks or clearing the old sprite.... Throwing a LOT of bytes round the screen memory !!

I've done 16 sprites 'moving around' on the c64 just like this at 50fps (even though the c64 can only display 8 - In theory ;) - you just needed some clever code to coaxe more out of the hardware and 'recycle' them while chasing the raster line !!! - You can only really do 8 on the same line though, then do another 8 lower down, and repeat as required - you can do loads more - but code overhead vs speed again - basically 'fast sort' routines to sort the y co-ordinates out and then some code to intercept them just after they had finished displaying on the screen, so that the new ones could be displayed lower down the screen) - Right... time to put the beeb hat on again, lol....

Disk image enclosed... just hacked this together while watching 'micromen' on BBC4 repeated later....

What next... I think a 'quick' old sprite erase subroutine may be in order ? (so no artefacts)

Cheers, Colin

Attachments:
colin16.zip [2.36 KiB]
Downloaded 9 times
Author:  ColinD [ Fri Oct 09, 2009 1:08 am ]
Post subject:  Re: C64 Sprites to BBC convertion
Thought I'd make it 32 sprites with some animations (all the sprite frames only use 64 bytes each !!!) - I'm also slowly'ish cycling the colour pallets around...

Lots of work to do.... but I think its neat... what do ya reckon ?

Cheers, Col

Attachments:
col32anim.zip [2.4 KiB]
Downloaded 19 times
Author:  SteveO [ Fri Oct 09, 2009 10:00 am ]
Post subject:  Re: C64 Sprites to BBC convertion
Hey , great, almost hypnotic to watch ! Main character animation is cool, love the explosions too :) nince job. Are you still running with no screen sync ? I guess so as you're not bothering with erase or masks yet ?
Author:  DaveM [ Fri Oct 09, 2009 10:14 am ]
Post subject:  Re: C64 Sprites to BBC convertion
Wow, that's completely mental - I love it! Especially like the explosions, too!!
Author:  ColinD [ Fri Oct 09, 2009 3:24 pm ]
Post subject:  Re: C64 Sprites to BBC convertion
Thanks Chaps.... Its very much a kludge at the moment !!

One of my mates did the graphics for me back in about 88.

Is there a 'Quick start How to Sync' Guide somewhere ? (and how to turn all the other interupts off !!)

Cheers, Colin
Author:  TomW [ Fri Oct 09, 2009 3:35 pm ]
Post subject:  Re: C64 Sprites to BBC convertion
Here's a quick framework I came up with a while ago. It's not totally optimal (you want to have an interrupt some lines before vsync ideally, as vsync is some time after display over) but it works!

Code:
        sei

        lda #$7f  ;Disable all interrupts
        sta $fe4e
        sta $fe6e
        lda #$82  ;Enable vsync interrupt
        sta $fe4e

        lda #<ourirq ;Set up our IRQ handler
        sta $202     ;Store to IRQ1V
        lda #>ourirq
        sta $203

        lda #$40 ;RTI
        sta $D00

        lda #$7F  ;Set up System VIA for keyboard
        sta $fe43
        lda #$0f  ;allow write to addressable latch
        sta $fe42
        lda #$03
        sta $fe40 ;set bit 3 to 0

        cli


    ;insert game here!



ourirq: txa           ;Save all registers
        pha
        tya
        pha

        jsr doupdate  ;Insert IRQ code here!

        pla          ;Restore all registers
        tay
        pla
        tax
        lda $fc
        rti
Author:  ColinD [ Fri Oct 09, 2009 3:50 pm ]
Post subject:  Re: C64 Sprites to BBC convertion
Thanks for that, Interesting.... Is there a way of indicating on screen where its sitting ? (We used to change the border colours on the c64 to show it was 'in an interupt') - Maybe changing colour 0 ??

Now I need to downsize my sprite collection - Hey I've just had another idea !! - The code that converts the sprite data to a 'paint by numbers' prio to colouring it, could probably be adapted to flip the sprites too (So I'd grab some graphics back)... or even Mirror them (so they could be smaller)... Definately thinking cap on tonight !!

Cheers, Col
Author:  RichTW [ Fri Oct 09, 2009 4:05 pm ]
Post subject:  Re: C64 Sprites to BBC convertion
ColinD wrote:
Thanks for that, Interesting.... Is there a way of indicating on screen where its sitting ? (We used to change the border colours on the c64 to show it was 'in an interupt') - Maybe changing colour 0 ??

Yep, I do this all the time to see which line is being rasterised.
Code:
    LDA #3
    STA $FE21   ; change background to blue
        ....
        ....
    LDA #7
    STA $FE21   ; change back to black
Author:  ColinD [ Fri Oct 09, 2009 6:42 pm ]
Post subject:  Re: C64 Sprites to BBC convertion
Thanks Rich....

Right.. I just coded the horzontal flip code... its a copy of the convertion code, with the desination bytes reversed... but that doesnt flip the two pixels in each byte.... so... I've took care of this in the pallet/colour code... the flip/colour code is exaclty the same size, as the non flip code, and takes the same time to run !!

I'm also thinking to speed things up, I either can use half of zero page to store the work sprite, or maybe even hide it in the stack (that might be actually slower, not sure yet?) - Obviously the OS probably wont like it... but who needs an OS... lol !!! - Any thoughts on this ?

TomW commented above that processing the sprites on the fly would cripple it.... He's right of course, but if I do things carefully, it might not be TOO bad... (As I say... coming in at a differnt angle here, its paying off in some ways too)

Doing some speed tests... Sprite conversion is quite quick... But the Pallet thing is a lot slower then I expected....

Heres the code..... Can it be optimised much for speed ?

Converted sprite data (paint by numbers) is at $2f00, coloured sprite desination is $2f80)

The sprite raw data paint by numbers byte format is 0000 yy zz - yy is left pixel colour, zz is right pixel colour (0-3)

ldx #$00
shuffle:
lda $2f00,x ; get 2 pixels of each
lsr
lsr
tay
lda paltable,y
tay
lda coltable,y ; get colour for left pixel
asl ; shift left 1 bit
sta coltemp
lda $2f00,x ; get 2 pixels of each
and #$03 ; get colour for right pixel
tay
lda paltable,y
tay
lda coltable,y
ora coltemp ; combine the 2 pixels together
sta $2f80,x ; store higher up to preserve old
inx
cpx #$7e
bne shuffle
rts

coltable:
.byte %00000000
.byte %00000001
.byte %00000100
.byte %00000101
.byte %00010000
.byte %00010001
.byte %00010100
.byte %00010101
.byte %01000000
.byte %01000001
.byte %01000100
.byte %01000101
.byte %01010000
.byte %01010001
.byte %01010100
.byte %01010101
coltemp:
.byte 0
paltable:
.byte 0,1,2,3 ; changed by game engine to select the 4 plot colours...(0 to 15)
Cheers, Colin

PS... only using the 1st 8 bytes of the table (put all 16 combos in) - I could have a copy of the table shifted left, to save the asl (shift left 1 bit) that would save 128 asl's for starters.... or maybe have the tables in zeropage ?

Might be able to optimise the pre-converstion code to put the pallets in... saving the double load too....?? Not sure yet..... Or combine both lots of code into one loop ??? -- This is the first time I've looked at any speed optimisation at all....
Author:  MartinB [ Fri Oct 09, 2009 8:05 pm ]
Post subject:  Re: C64 Sprites to BBC convertion
Looking good Col Image

Gotta go now - I feel sick :lol:

Martin
Author:  MartinB [ Fri Oct 09, 2009 8:20 pm ]
Post subject:  Re: C64 Sprites to BBC convertion
Tom W wrote :
Code:
        lda #<ourirq ;Set up our IRQ handler
        sta $202     ;Store to IRQ1V
        lda #>ourirq
        sta $203

I meant to ask you about that Tom - is that vector address correct for basic vsync operation? It didn't seem to work for me so I used $204/$205 and that does work. Were you specifying $202/$203 because you actually use a pre-vsync timer?

Also, when I did use $204/$205 the code seem to be stuck in a permanent interrupted state so I had to clear the vsync interrupt after servicing as below. Does this sound correct?

Code:
intend    LDA       #$7F                \clear IRQs from the IFR
          STA       $FE4D

Martin
Author:  ColinD [ Fri Oct 09, 2009 8:45 pm ]
Post subject:  Re: C64 Sprites to BBC convertion
Hi Guys... the sync is not working for me either... I've Pm'd Tom for claification....

Right.... Still running unoptimised sprite conversion code (well doubled the size of the table and saved the shift, but its not saved much).

However, I've now modified the plotter engine.....

What you do is give it a sprite number 0-15 (16 should be enough)...

Prior to plotting, It saves the Hi/Lo screen location into a table, index by the sprite number..... Just before that, it gets the old screen location for that particular sprite, and uses that to blank the old sprite out.... It then displays the sprite.... (and we have its location, so we can blank next time)

I've also slowed the anination and the colour table updates down, so that they dont happen every display loop.... and also flip the sprite left/right from time to time....

Disk image below.....Looking better eh ? (Still no masking or sync)

Cheers, Colin

Attachments:
colinnewplot.zip [2.59 KiB]
Downloaded 11 times
Author:  RichTW [ Sat Oct 10, 2009 10:10 am ]
Post subject:  Re: C64 Sprites to BBC convertion
Yeah, there's some problems with Tom's code - the IRQ vector is at $204/$205, and, yes, it's necessary to mark the IRQ as 'serviced'.
Code:
        sei

        lda #$7f  ;Disable all interrupts
        sta $fe4e
        sta $fe6e
        lda #$82  ;Enable vsync interrupt
        sta $fe4e

        lda #<ourirq ;Set up our IRQ handler
        sta $204     ;Store to IRQ1V
        lda #>ourirq
        sta $205

        lda #$40 ;RTI
        sta $D00

        lda #$7F  ;Set up System VIA for keyboard
        sta $fe43
        lda #$0f  ;allow write to addressable latch
        sta $fe42
        lda #$03
        sta $fe40 ;set bit 3 to 0

        cli

mainloop:
        lda #2
        sta vsyncflag      ; so that game loops every 2/50ths of a second

        ;insert game here!

waitforvsync:
        lda vsyncflag
        bne waitforvsync
        jmp mainloop


ourirq:
; Don't bother to save registers if we don't corrupt them!
;        txa           ;Save all registers
;        pha
;        tya
;        pha

; if we only have vsync enabled, then this is the only interrupt
; that can come here, so we just acknowledge it with:
        lda #2
        sta $fe4d

; decrement vsync flag here
        lda vsyncflag
        beq alreadyflagged
        dec vsyncflag
alreadyflagged:

        ; do other vsync handling here, corrupting only A if possible

; if we had to preserve registers, get them back here
;        pla          ;Restore all registers
;        tay
;        pla
;        tax
        lda $fc        ; Restore A
        rti


The idea of 'vsyncflag' is that it's a zero page location which you set to a non-zero value at the top of your main loop, and each vsync it's decremented until it reaches zero, at which point you can reloop. This allows you to create a fixed frame-rate.

Ideally, you would actually use two interrupts - the VSync IRQ and one of the timers (which is set to interrupt a fixed time after the vsync). If you set the timer interrupt for the moment that the screen has rasterised its last line of the playing area, you win a considerable number of scanlines back during which you can try and do all your rendering.

If you like, I can post code to do this, or perhaps you'd prefer to have a go at implementing it yourself first? :)
Page 3 of 6 All times are UTC [ DST ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/