| Teen Dreams by Noice [web] | ||||||||
|---|---|---|---|---|---|---|---|---|
|
|
|||||||
|
popularity : 59% |
|||||||
alltime top: #7689 |
|
|||||||
|
||||||||
added on the 2011-03-06 18:35:02 by Sdw  |
||||||||
popularity helper
comments
Nice, especially the "Big Fun" cover in the second part.
rulez added on the 2011-03-06 21:38:15 by Gmitts 
I enjoyed this. I don't mind if it's oldschool as long as the screens and motion look good. And they show.
Little short, but what's shown is the usual noice quality. Thumb up.
We share the same dreams ;-)
Cool!
Kind of cute
very nice! the old times, again! yes!
world record!
nice!
breaking a world record!
Video please. :)
:D
cool one!
I like it but it's way overrated...
a very nice "oldschool-press-space-demo", indeed
Sdw: In your comments for Batman Forever, you said:
Quote:
Sorry, I don't know much about 8bits machines but do you actually erase the 1123 dots individually ? If so I guess it is not possible to clear 8px spans or 8x8px blocks at once in this graphic mode. :\ ouch! Tricky tricky.@Optimus: I don't know what you mean by symmetric, but there is no mirroring or other tricks. I draw 1123 dots in Teen Dreams, and erase 1123 dots each frame.
You're correct that it runs in only a 128x128 pixel area though.
@p01: Actually the clearing of a dot is done by clearing a 8x1 block (1 byte, so a single STA instruction). But I still have to do that for each individual dot.
Plotting a dot is more expensive, since you have to LDA/ORA/STA it in a byte as another dot might already be in another bit.
Plotting a dot is more expensive, since you have to LDA/ORA/STA it in a byte as another dot might already be in another bit.
Ouch! You have to compute the position of each individual dot to clear it :-\
I was wondering 'coz on Atari ST you can display so many dots that it is faster to clear the screen ( well one bitplane ) as a whole rather than clearing the dots one by one.
I was wondering 'coz on Atari ST you can display so many dots that it is faster to clear the screen ( well one bitplane ) as a whole rather than clearing the dots one by one.
Quite cool, nice oldschool vibes.
I can imagine having so many dots in a relatively confined space also helps :) Allows for really simple (read: fast) clearing code...
..probably really simplifies the x/y->screen mem address conversion aswell :) Thinking out loud..
Indeed a 128 x 128 area is quite small and gives at most: 128 / 8 * 128 = 2048 bytes to clear in a brute force clearing code.
Again I don't know 6502 assembler but it seems that in this case, a brute force clearing would be faster than clearing the dots one by one ( which means "computing" their position ).
Again I don't know 6502 assembler but it seems that in this case, a brute force clearing would be faster than clearing the dots one by one ( which means "computing" their position ).
Quote:
Indeed a 128 x 128 area is quite small and gives at most: 128 / 8 * 128 = 2048 bytes to clear in a brute force clearing code.
That's what I thought at first too.
A series of STA $address 4 cycles. 2048 * 4 = 8192 cycles.
8192 / 1123 = 7.29. This would be similar to spend around 7 cycles per dot erase. I think a fast routine would be something like a series of STA $address, X per dot which is 5 cycles. I am not entirely sure, I was thinking of this kind of dot rendering (stationary on X, oscillating on Y).
Big mistake.
Should not be STA $address,X but most probably STA (zero page),Y where in the zero page some_C64_Y_address(SIN(t)) is stored and Y moves you on x coord. You may only have to scroll these addresses inside the zero page after each frame but that's just 254 bytes. There gotta be other ways with this, gotta try to test before thinking in theory. But in any case it's less than 7 cycles.
I have noticed the pattern that made me original think the dots were symmetric. They are not but you see a similarity in four quadrants, maybe because the sine is small to fit in zero page if this is how I think it's done here.
Should not be STA $address,X but most probably STA (zero page),Y where in the zero page some_C64_Y_address(SIN(t)) is stored and Y moves you on x coord. You may only have to scroll these addresses inside the zero page after each frame but that's just 254 bytes. There gotta be other ways with this, gotta try to test before thinking in theory. But in any case it's less than 7 cycles.
I have noticed the pattern that made me original think the dots were symmetric. They are not but you see a similarity in four quadrants, maybe because the sine is small to fit in zero page if this is how I think it's done here.
Actually the code looks like this:
Plotting (x increases each frame):
ldy sinetab,x
lda screenpos_with_precalced_sinepos1,y
ora #constant
sta screenpos_with_precalced_sinepos1,y
lda screenpos_with_precalced_sinepos2,y
ora #constant
sta screenpos_with_precalced_sinepos2,y
.. repeat for a number of points that share same Y-sine (y-sine-period is much smaller than 1123, so it can be reused for quite a few dots)
ldy sinetab+1,x
lda ..
etc.
Clear:
lda #$00
ldy sinetab,x
sta screenpos_with_precalced_sinepos1,y
sta screenpos_with_precalced_sinepos2,y
...
ldy sinetab+1,x
So to plot it takes 4+2+4 = 12 cycles per dot + some additional fraction for loading new sine values.
So to plot it takes 4 cycles per dot + some additional fraction for loading new sine values.
So unless I plot like well over 1500 dots, it's still cheaper to clear the dots instead of clearing the whole 2048 byte area.
Plotting (x increases each frame):
ldy sinetab,x
lda screenpos_with_precalced_sinepos1,y
ora #constant
sta screenpos_with_precalced_sinepos1,y
lda screenpos_with_precalced_sinepos2,y
ora #constant
sta screenpos_with_precalced_sinepos2,y
.. repeat for a number of points that share same Y-sine (y-sine-period is much smaller than 1123, so it can be reused for quite a few dots)
ldy sinetab+1,x
lda ..
etc.
Clear:
lda #$00
ldy sinetab,x
sta screenpos_with_precalced_sinepos1,y
sta screenpos_with_precalced_sinepos2,y
...
ldy sinetab+1,x
So to plot it takes 4+2+4 = 12 cycles per dot + some additional fraction for loading new sine values.
So to plot it takes 4 cycles per dot + some additional fraction for loading new sine values.
So unless I plot like well over 1500 dots, it's still cheaper to clear the dots instead of clearing the whole 2048 byte area.
interesting :) thanks for sharing!
Götta!
Woops, noticed a typo in the explanation. It should read:
So to plot it takes 4+2+4 = 12 cycles per dot + some additional fraction for loading new sine values.
And to clear it takes 4 cycles per dot + some additional fraction for loading new sine values.
So to plot it takes 4+2+4 = 12 cycles per dot + some additional fraction for loading new sine values.
And to clear it takes 4 cycles per dot + some additional fraction for loading new sine values.
Rulez!
nice
submit changes
if this prod is a fake, some info is false or the download link is broken,
do not post about it in the comments, it will get lost.
instead, click here !