| |
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....
|
| |
Stryyker
Registered: Dec 2001
Posts: 468 |
Demus Interruptus doesn't have many colours so chars are fine. Stretching a char line isn't too hard. Stretching the bitmap is exactly the same. Stretch it properly and you don't get the 3 char bug. And yes the code looks alot like FLI.
Clever calculations are clever tables. Clever character or sprite organisation. You started with a smart idea for the sprites, 1 sprite just different Y offsets before stretch. Now look at any calclations you are doing. Maybe tidy up tables to reduce any overflow detection if you have any. If you use chars with sprites then you don't need as many sprites. |
| |
anix
Account closed
Registered: Feb 2004
Posts: 35 |
cruzer: yea i admit i have not touched any bitmap or char stuff yet.. hell i should just try and code a scroller or something :) but if i set onto a complex task then i can learn alot of things on the way, which i have.
stryyker: thanks :) i also wondered if my multicolor 'put-bar' was very good or not. xbow's bars are at least 5 pixels wide... so i made a routine that can do up to 8 pixels wide, always writing two bytes.
i made four masks to and with, and four copies of the bar-pattern to ora.
the low 2 bits of the x position are index into the mask & pattern...
so it looks like
lda sprite,x
and masktable,y
ora patterntable,y
sta sprite,x
but that's a lot of cycles, i'd like a faster way but i don't see it yet. i thought of making a table of precalculated results for all 4-pixel-offsets against any possible existing pixels.
also i need to work on some better sin/cos animation cuz mine is really lacking, so i think i'll write up a generator tonight and see what better movement i can get out of it.
|
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
> hell i should just try and code a scroller or something :)
Maybe not a bad idea to try something a bit simpler. Not to take anything away from your enthusiasm, but sideborder-kefrensbars are probably quite a hard routine to code. After all, it was done by the #1 coder Crossbow, after the #3 coder HCL had said, he thought it was impossible. :) |
| |
Turtle
Account closed
Registered: Jan 2002
Posts: 70 |
@Cruzer: Just in case I missed something: Who's #2 to your oppinion? And what did he (she) thought of the possibility to code such fx? I already have a guess... |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
you can stretch down 1 rasterline of bitmap or characterscreen, the code is as fli, but u have 63 cycles each line... play a bit with a 63 cycle fli routine, and you will find the way. Even with border removal you must have enough cycles to do the thing...
lda #xx ;2
sta $d011 ;4=6
ldx sine ;4
ldy offset,x ;4 (tricky table, either points to
and mask,x ;4 bitmap or the right sprite
ora bar,x ;4 location)
sta spriteorbitmap,y ;4=20
ldx sine
ldy offset,x
and mask,x
ora bar,x
sta spriteorbitmap,y ; =20
ldx #xx ;2
ldy #xx ;2
stx $d016 ;4
sty $d016 ;4=12
this makes 58 cycles... well this is probably too slow, as 4 sprites need more then 5 cycles I guess ;) (you can save 4 cycles if u selfmod the irq speedcode, so you do ldx #sinevalue instead of ldx sine, but thats prolly still not enough) I guess thats why xbow made it only every 2nd line.. but with 2 lines you earn a lot of cycles to do things.
This routine just came from the top of my head, so dont judge it too hard :)
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
ok, I forgot the lda spriteorbitmap,y... now its slower than 63 cycles.. :) and it prolly needs 2 buffered lines of bitmap and sprite, that makes an extra $d018 write.. |
| |
Stryyker
Registered: Dec 2001
Posts: 468 |
NAturally self modifying code is used :) Try to reduce the writes as much as possible.
ldx #$xx
lda $mem,x
and #$aa
ora #$aa
sta $mem,x
This shifts come of the code from the timing critical limited to to the little more time in after the effect is done.
This could maybe be change too.
I never tried it but maybe just change the char on screen, not the contents of the char. Some will say that is cheating though.
Never realised Crossbow did it every 2nd line. Makes me think I have a chance of doing it :) |
| |
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 :( |
| Previous - 1 | 2 | 3 - Next |
