| |
oziphantom
Registered: Oct 2014
Posts: 490 |
Cycle Excact Timings and moving sprites
What fancy techniques to people have for handling the need for cycle exact timing for effects and then having sprites move over it?
I'm thinking of having side borders partially open in places which then may or may not have a number of sprites over. My current thinking is to have sets of 4 clock burners per sprite with a d015 sprite value per line when then looks up a num sprites per line value table per line that then indexes into a Branch offset table. so
lda SpritesValue,x
tay
lda ValueToNumBitsSetLUT,y
tay
lda BranchOffsetTable,y
sta BranchOffset
BranchOffset = *+1
bne $00
lda $00,x
lda $00,x
lda $00,x
lda $00,x ; I think 4 sprites will be enough
38 col
40 col
check num lines and loop
BranchOffsetTable 01,03,05,07,09 ; can't remember at the moment it if needs to be 1 or 0
but I might be over complicating it... |
|
... 13 posts hidden. Click here to view all posts....
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
making the table for that by hand is a zen like experience for all "intuitive" coders =P |
| |
Radiant
Registered: Sep 2004
Posts: 639 |
Quote: I did something similar for the sprite multiplexer on top of 4x4 timing in The Wild Bunch. But there each ball consist of 2x3 sprites so there will only be 16 different timing combinations, instead of 256. I couldn't use a timer since the $d011 FLI-write has to come directly after the sprite fetches, so no time to stabalize using a timer.
Were there any glitches? ;-P |
| |
lft
Registered: Jul 2007
Posts: 369 |
Quoting JackAsserI couldn't use a timer since the $d011 FLI-write has to come directly after the sprite fetches, so no time to stabalize using a timer.
Another idea: FLI is self-stabilising, so one solution would be to narrow the 4x4 area from the left by the expected amount of jitter due to sprite fetches.
Clarifying example: To place 2 moving sprites over a 4x4 routine, you'll get a variable delay due to sprite DMA in the range of 0..7 cycles. Start counting from cycle 55 as if there is no sprite DMA, and put the FLI at cycle 14 as usual. If there are sprites, the FLI will move to cycle 21. So make sure to have 10 black characters at the left edge of the screen, to cover that and the FLI bug. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
You just DONT reduce effect size due to lazyness. ;) |
| |
Radiant
Registered: Sep 2004
Posts: 639 |
Quote: You just DONT reduce effect size due to lazyness. ;)
Wouldn't dream of it. *whistles* |
| |
Pex Mahoney Tufvesson
Registered: Sep 2003
Posts: 52 |
A lazy solution is to only use 19 pixels high sprites. Keep the uppermost line of the sprite blank, and stretch it using D017 to the desired y-position. Then, start stretching again 19 lines further down. Then, you'll have a constant number of CPU cycles on every line.
That's what I did 2003 in BitLive4-demo
/ Pex
---
Have a noise night!
http://mahoney.c64.org |
| |
HCL
Registered: Feb 2003
Posts: 728 |
@LFT: Self-stabilising 4x4-FLI is just sooo 1994, and reminds of the death of the scene.. World of Code 3.. Don't give us that again ;).
@Mahoney: When i entered the scene in 1990 or so.. the only reason to do a d017-stretcher would be lameness, not being able to do a DYSP! Probably things were different in 2003 then ;). |
| |
Pex Mahoney Tufvesson
Registered: Sep 2003
Posts: 52 |
@HCL: Yes, d017 in 1990 was probably lame (what do I know, I was into Amiga stuff then). But at least I thought I was cool when I did d017-stretching in 1988 in Skruv ... long before you were born, kiddo. :P ;)
---
Have a noise night!
http://mahoney.c64.org |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
finally some decent arguments! =D |
| |
HCL
Registered: Feb 2003
Posts: 728 |
Damnit.. <word> :P |
| Previous - 1 | 2 | 3 - Next |
