Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user eightbitswide ! (Registered 2024-12-24) You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > gonna show you guys how it's done !
2004-02-24 15:57
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

 
... 20 posts hidden. Click here to view all posts....
 
2004-02-29 15:02
anix
Account closed

Registered: Feb 2004
Posts: 35
WVL: i've looked through the illegals, but they don't seem to do much for me. lax #imm could be fun but it says it's unstable. i saved a number of bytes last night be cutting my recalc loop in two... part1 creates a table of the new sinus (sin,x+sin,y) then part2 reads it and sets up the irq loop. this way, i didn't have to store my counters in zero page.

also copied my 4-byte ora/and tables (yours were exactly like mine, so i'm happy i figured that out :) into 256 byte tables, so that the pixel position doesn't have to be and #3 to get the right one.

next step is to dump my sin+sin table, and write those values directly into the second loop as ldx #$xx, but that won't really gain much.

wider bars will need more cycles in my irq loop that i don't have...
2004-02-29 16:52
WVL

Registered: Mar 2002
Posts: 902
if the sprites are in zeropage, maybe you could use the illegals with &H -> when storing to zeropage, H=$ff so the &H does nothing. (If I'm not mistaking, don't kill me if I'm wrong ;)))

so you could do Store A and X to zeropage for almost free..

well, you figure it out if you want to show us how it's done ;D
2004-03-01 05:26
CyberBrain
Administrator

Posts: 392
Quote: @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


anix: yeah, well, i only think that trick is clever when you don't use double sinus - it was just something i made up. I made a better 256byte version with double sinuses today, and i don't use that trick anymore.
Previous - 1 | 2 | 3 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
fenz/SCC
Case/Padua
MaD ][/Starship
Conjuror
iAN CooG/HVSC
Bieno/Commodore Plus
Alakran_64
Guests online: 105
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 The Demo Coder  (9.6)
6 Edge of Disgrace  (9.6)
7 What Is The Matrix 2  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 Layers  (9.6)
2 Cubic Dream  (9.6)
3 Party Elk 2  (9.6)
4 Copper Booze  (9.6)
5 X-Mas Demo 2024  (9.5)
6 Dawnfall V1.1  (9.5)
7 Rainbow Connection  (9.5)
8 Onscreen 5k  (9.5)
9 Morph  (9.5)
10 Libertongo  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Censor Design  (9.3)
5 Triad  (9.3)
Top Original Suppliers
1 Derbyshire Ram  (9.7)
2 Fungus  (9.3)
3 Black Beard  (9.2)
4 Baracuda  (9.2)
5 hedning  (9.1)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.029 sec.