| |
Rudi
Account closed
Registered: May 2010
Posts: 125 |
Speedcode
Let's say my loop has to iterate 16K times.
unrolling the loop would not be ideal, because then it would be 16K*the amount of bytes inside the loop.
What does speedcode actually do? Unroll loops?
I saw lecture by Ninja at a conference about just LDA's and STA's to specific address locations. But what do these address locations store? tables or opcode+data?
First I thought about actually loading and storing the opcode and data, but afterwards I thought this wouldn't be right! The LDA's and STA's take each x-amount of cycles that I really dont need, and the opcodes and data themselves are the only thing I need :D
I got an idea now about using only one opcode for doing a same operation, but loading and storing the data in 1 or 2 byte format. Perhaps the LDA and STA needs to jump back and forth (as a consequence, i dont know).
Still its a subject that I recently am looking into since i would guess (as an approximation that) my routine will only run in 7 fps as it is now. Ideas or ramblings are welcome about this issue and topic!
(I forgot to ask. Do you make your own tools/or generators for speedcode generation?) |
|
... 15 posts hidden. Click here to view all posts....
|
| |
Rudi
Account closed
Registered: May 2010
Posts: 125 |
yes. some interesting solutions here. its wicked to actually optimize it, and then not see that it can be optimized more.. but right now i do see it clearly lol. strange that i didnt see that before. i tend to be locked into some code and not see around it. but thanks again! i think ill do the 1-dimensional pointer before i actually do anything more. since maybe perhaps the shift luts have to be indexed differently.
bitbreaker: i can start of with integrating shllut into shllut2 but not the other way around. shllut2 is a 16-bit shift table while shllut is 8-bit. i just wondering in your example code are you generating lut-table in the loop? isnt it better to have static tables? or was that just example code. yes, i generate my tables in C not in asm. just because i am lazy :P |
| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
Oh, i should have looked right, it is p(i) being used as index for the first demension of the array. So you can't set up a fixed i beforehand, but you can place p into one of the Index-Registers for fast access then.
However you can easy do a two-dimensional arraylookup via either lda (y,x) or lda (x),y so one dimension is choosen by the index register and the other one by one/two sta's to the zeropage. Illegal opcodes could speed up things here as you can use lax in both cases if you need the value in A and X.
In any case, take care that your data is aligned nicely so that the lookup stays easy. |
| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
p[i] = (r>>z)&1 ? p[i]|s : p[i]&(s^255);
this can also be done with a r>>(z+1) to move the bit to be tested into carry. This saves the and #$01 + cmp and you can directly branch with a bcc/bcs to either do the |s / &(s^255).
Also if you store p(i) in X and s in A you can make use of the SBX command to do the X = A & X. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
I'm too tired and cant properly read C, but that looks a hell of lot of stuff to do 2048 times. RAND pops out to me if you cant get away with some timer/raster register mixups, it will be expensive. j<7 seems pointless when j=w&7 (0..7) anyway if its a special case for j=7 then I'd shuffle it until the branch would work with j=0 you can save a cmp then as Z bit sets itself usually. best would be ofcourse to get rid of the branch and make the LUT have a special case for j=7.
not sure what's the table doing, but using a lookup for bit shifting seems expensive, asl rol / lsr ror is less expensive than setting up a table lookup. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
"RAND pops out to me if you cant get away with some timer/raster register mixups, it will be expensive."
unless you really need "proper" random values (which you almost never do for demo effects), then RAND can be done very cheap:
updaterand: <- call once per frame
jsr rand <- your favourite PRNG
cnt:
sta rtab
inc cnt+1
rts
getrand: <- use instead of the PRNG
cnt:
lda rtab
inc cnt+1
rts
that said, dont listen to whoever tells you to use timers or raster or something like that for "random". it gives horrible results, even a static table will work better (and is faster).
|
| |
Rudi
Account closed
Registered: May 2010
Posts: 125 |
Groepaz: i used this in my noize-generator several months ago:
rol
adc $d012
and experiment by exchanging adc with eor/sbc. in some cases that worked out better. also the $a2 timer could work. anyway, this wasnt about random number generation. the prng will be an experiment when the effect works. which will take months or perhaps years.
i've decided that regular mode cannot be done. so i'll have to rewrite the whole algorithm and use multicolor or some kind of stretched sprites to do this effect. but i learned alot in this thread. ill be re-reading some of it later because there are some things that are usefull to know.
|
| |
enthusi
Registered: May 2004
Posts: 677 |
For Assembloids I generate a proper sbox ;-) |
| |
johncl
Registered: Aug 2007
Posts: 37 |
A fun RND routine is one that uses 256 bytes filled with the simple rnd routine that is on codebase here:
http://codebase64.org/doku.php?id=base:fast_8bit_ranged_random_..
Every frame you add some new numbers, and just wrap around that 256 byte buffer. So whenever you need a random number in your other code its likely a new one there or something you had 256 bytes back in time. In many cases this is more than enough for many uses.
Generally whenever you can use a lookup table for stuff, then use that to speed up code. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
look what i posted above =) |
| |
Danzig
Registered: Jun 2002
Posts: 440 |
Quote:that said, dont listen to whoever tells you to use timers or raster or something like that for "random". it gives horrible results, even a static table will work better (and is faster).
please follow the quoted advice.
raster and timer are sequentially increasing so randomness depends on the time between the demand of a value.
even stuff like eoring rasterline with timer deserves to be called "predictable" in the widest meaning. using actual rasterline as the seed is ok. |
| Previous - 1 | 2 | 3 - Next |
