| |
anix
Account closed
Registered: Feb 2004
Posts: 35 |
gonna show you guys how it's done !
well that's what i thought a few days ago !
this, my second go at c64 coding. much more serious this time. about a year ago i gave it a shot and got tangled up in stable rasters and such... i remember chatting with graham on irc trying to learn more about them, but mostly hearing about how i should support c128 2mhz in my routines :)
so this time, i decided to try and duplicate (without monitoring!) one of my favorite routines - xbow's sideborder rasters from demus interruptus endpart.
had it all figured out !
(i thought, you'll quickly see what i missed)
open the borders,
fld to get rid of the badlines,
all 8 sprites stretched across,
y-stretch all 8 sprites so the screen is filled with the same row of the sprite (128 rows anyway)
now on each line, plot the new bar into the sprite.
i even had some (i thought) great ideas - like, all 8 sprites use the same buffer, and i toggled the stretching on each, before the effect, so that each would be using the next sprite-line during the effect... so i have a 24-byte 'linear' area to plot new bars on.
of course, i'd have to unroll the loop to get it to fit in 63 cycles.
and it has to be modified each frame, to plot the right bytes directly where they should go.
so the calculation for each frame takes a long time since it has to modify the unrolled irq.
so i had to unroll that also.
and it still takes too long... so i decided to do some more FLD to free up some time from badlines and use that to clear the sprite buffer before the next frame.
oh my
after all this work, and thinking things were not so tough - stretched multicolor sprites are ugly ! but demus's rasters are thin... so after all my efforts, i have a half-screenwidth of bars, which can be put in the sideborder, and not a whole screen.
depressing, cuz now i don't understand it.
can FLI/FLD be used to repeat the same bitmap row all the way down the screen?
i had a few mistakes that seemed to do this, except the byte that i had on the screen appeared to come from $3fff.
then of course the problem of getting the sprites on there, in the sideborders, with badlines (i guess).
now it appears impossible (haha)
nevermind the other demus bars which are in all borders - where is the time to calculate the movement ??
well anyway,
much respect to all you guys because this stuff is very challenging. fun though
|
|
... 13 posts hidden. Click here to view all posts....
|
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
@Stryyker:
changing the chars and not the contents of the chars will have no effect due to no badlines.
@crossbow, hcl and all the others:
i wonder why everyone is so exited about the kefrens bars in sideborder being impossible etc. it has been done in 1992 already in emotional breakdown by offence. |
| |
anix
Account closed
Registered: Feb 2004
Posts: 35 |
@graham: it's just a pretty routine that looks like one to learn alot while trying to copy. for myself anyway...
@oswald: the sprite-only one that i already did - all of the movement is calculated before each frame is drawn. i calculate the two bytes i will draw, and their addresses, and those bytes are put into the unrolled loop for the effect.
...
ldx #xx <- load precalculated left bar byte
lda #xx <- load precalculated right bar byte
...
sta $80xx <- store right bar byte into sprite
...
stx $80xx <- store left bar byte into sprite
...
now during the calculation, i just modify those four bytes. so to adapt it to use chars and a few sprites will be mostly changes to the calculation.
that made for a slow calculation loop also - so i had to unroll -it- and precalc it's destination addresses in the unrolled raster loop (!)...
i don't see how there is time to do lda/and/ora/sta for both bytes in the raster loop ... with sprites on the screen as well
thanks for all your input guys :)
|
| |
Stryyker
Registered: Dec 2001
Posts: 468 |
Your sprite version works ok? Why not move gfx so the sprites are stored in zero page?
Graham: I was thinking of stretching first char line forgetting about sprites :( |
| |
anix
Account closed
Registered: Feb 2004
Posts: 35 |
stryyker: yeah it works... i was wondering if sprite from zero page would work or not, i have not done much with the zero page yet except store a few things in $fb/fc/fd. it would win many cycles since so much read/write is done to the sprite - but i did get 127 bars in one frame without it. now if i continue, the next challenge is to get the char portion of the screen going. zero page sprite might buy me some more cycles since i'll be adding another half-width-screen of bytes that have to be cleared twice... and the new ones can't be zeropage.
i havn't done much with turning off the basic/kernel. i flipped a few bits in $01 to try using a sprite at $0300 and everything crashed up - so i'll have to learn some more about how to safely use that zp next
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
you dont have to "switch off" the basic or the kernal to use mem at $0300, the machine only crashed on you, since you fucked up the irq vectors at $0314-$0315, simply use a sei to avoid that, or turn off the kernal and basic rom by lda #$35 sta $01, and use fffe/ffff for irq vectors. |
| |
CyberBrain
Administrator
Posts: 392 |
All this kefrensbars-talk, made me wonder if it could be done in 256b. So a lame 256b version has been made. |
| |
anix
Account closed
Registered: Feb 2004
Posts: 35 |
@CyberBrain: it's good ! i like the sinus low 2-bits seperate from the upper part. probably an old idea but i didn't think of that...
i'm trying to make more complex movement now, trying to sum two different sin-tables when recalculating, and it's not going well.
6502 has no arithmetic shift right ?!? how can i >>1 a signed byte... in a reasonable time
|
| |
WVL
Registered: Mar 2002
Posts: 902 |
anix :
do a cmp #$80, then ror.
if the accu was negative, cmp #$80 will set the carry, and a ror will shift the carry into bit 7, so the result is still negative..
this is a common trick.
|
| |
anix
Account closed
Registered: Feb 2004
Posts: 35 |
WVL: thanks for the tip, it works fine.
now i took two offset sin() and summed them together, so i can have some neat movement like hcl & xbow... but of course now my calculation is even slower.
it really sucks that all of the opcodes are so slow - you have to get some big gains from a table before they are worth it, since a big table will take your 4/5 cycles to hit... the only way i see to get back to a single frame now, is to put my spritedata in zero page.
anyone ever use S for an extra place to hold a val during IRQ instead of zero page? seems like nothing should be wrong with that... store S into zero page and restore it after the loop is done
|
| |
WVL
Registered: Mar 2002
Posts: 902 |
anix : maybe you should try to use some illegal opcodes.
see this page for a complete list :
http://oxyron.net/graham/opcodes02.html
anyway, while you're at it, please think about using 3 bytes for storing the bars, instead of 2. This will increase the width of the bars from 5 multicolor pixels to 9 multicolor pixels (almost double!), and it's rather cheap in cycles (only lda #$xx sta sprite).
You only need to store the middle byte directly, there's no need for 'and' and 'or'..
|
| Previous - 1 | 2 | 3 - Next |
