comment by dodke on 23 September 2008
it's more like an unexpanded a1200 demo that also kinda works on a500.
comment by corial on 23 September 2008
I like this quite a lot. Well, I don't understand the use of the 3d-flare effect. However, the rest of the effects look really good. Especially that Sonik Clique-inspired thing. Looking forward to see more from you Dodke!
comment by z5 on 23 September 2008
Considering the fact that you released your first production at BP this year, i'm amazed at how fast you're progressing in coding, dodke. Not only that, but you do great graphics aswell which is a good combination.
I liked the demo a lot. Cool graphics, the colors worked well, the logo looks awesome, the effects are enjoyable. The music isn't really my taste but still enjoyable. The most impressive effect for me was screenshot 15. The lightning was neat and gave it an underwater look.
The fading to blue/purple wasn't as effective and i would have loved to see a bit more work in transitions between effects. But an impressive effort once again.
comment by tjahzi on 23 September 2008
Hard Core Stuff (5/5)!!!
comment by Frog on 23 September 2008
Really impressive for an A500 stuff !! Thanks a lot !
comment by extralife on 26 September 2008
Then why is ocs speaking dodke ;)
A damn fine demo anyways, it runs just as fast on my 500 as it does when switching of aksel on my 1200, from what I could see. But I most certainly prefer to run this with aksel onboard to eliminate the screen tearing though.
I like this demo and big thumbs up for having me run over to test it on my ocs machine m8.
If this is only the second amiga demo from u m8, then the old farts better watch out, coz a new star is certainly on the rise here.
comment by dodke on 26 September 2008
a bit more optimised and double buffered final version was uploded to scene.org last night. hopefully it'll be available soon :)
comment by dodke on 26 September 2008
hmmh... and it ran just fine on a1200 without the turbo when i tried it. maybe not 50hz but quite nicely. or what does "switching of aksel" mean?
comment by extralife on 26 September 2008
No 060, is what it means here ;) and yes it ran fine on my 1200 and 500 aswell, apart from tearing as I said, but doesn't change the fact that I like it :)
Going to grab the optimized version now, for comparison
comment by klipper on 27 September 2008
ah, guys. that was nice! :) great track.
comment by extralife on 27 September 2008
Now my ocs is speaking too :D Huzzah for a nice final there dodke, all tearing is gone and i'm happy to see a fine, fine prod. for the oldtimer a500 here in 2k8. Good job and thx for feeding my a500 :)
comment by sp on 24 November 2008
Your table-effects can be done faster with self modified code:
Your routine (4 pixels):
move.w (a0)+,d2 ;8
move.w (a3,d2.l),4(a1) ;4+10+4
move.w (a0)+,d2 ;8
move.w (a3,d2.l),4(a2) ;4+10+4
move.w (a0)+,d2 ;8
move.w (a3,d2.l),8(a1) ;4+10+4
move.w (a0)+,d2 ;8
move.w (a3,d2.l),8(a2) ;4+10+4
....
104 cycles
optimized:
move.w 0000(a3),4(a1) ;4+8+4
move.w 0000(a3),4(a2) ;4+8+4
move.w 0000(a3),8(a1) ;4+8+4
move.w 0000(a3),8(a2) ;4+8+4
....
64 cycles
comment by sp on 24 November 2008
An error in the cycle calculation above. Correct should be:
Your routine (4 pixels):
move.w (a0)+,d2 ;8
move.w (a3,d2.l),4(a1) ;22
move.w (a0)+,d2 ;8
move.w (a3,d2.l),4(a2) ;22
move.w (a0)+,d2 ;8
move.w (a3,d2.l),8(a1) ;22
move.w (a0)+,d2 ;8
move.w (a3,d2.l),8(a2) ;22
....
120 cycles / 4 pixels = 30 cycles pr pixel
optimized:
move.w 0000(a3),4(a1) ;20
move.w 0000(a3),4(a2) ;20
move.w 0000(a3),8(a1) ;20
move.w 0000(a3),8(a2) ;20
....
80 cycles / 4 pixels = 20 cycles pr pixel
......
Optimized more:
Fill $180(?) in the highword of all dataregisters.
move.w 0000(a3),d0 ;8
move.w 0000(a3),d4 ;8
move.w 0000(a3),d1 ;8
move.w 0000(a3),d5 ;8
move.w 0000(a3),d2 ;8
move.w 0000(a3),d6 ;8
move.w 0000(a3),d3 ;8
move.w 0000(a3),d7 ;8
movem.l d0-d3,-(a1) ;40
movem.l d4-d7,-(a2) ;40
144cycles / 8 pixels = 18 cycles pr pixel.
comment by sp on 24 November 2008
12 color registers ($180 - $194) are used.
The final optimized loop above won't work without some modifications.
hehe, I am spamming this thread now. maybe we should continue in the code section of the forum.
comment by dodke on 25 November 2008
I've no experience on using smc yet so pardon me if i'm totally clueless. I'm guessing the whole screen should be generated which would be trivial if the table wasn't scrolling (and the bitplanes would be changed to use the same amount of colors as there are data registers). With a scrolling table i'm guessing there should be jumps added in the code at the end of each line in a frame (while saving the replaced code elsewhere temporarily) to skip the table that's outside of the screen. But then also because every other pixel is on a different scanline (and therefore in a different location in the copperlist) I'm guessing there should be two versions of the whole thing to achieve 1 pixel horizontal scrolling. This should still be possible but the amount of memory needed would be WAY too much for the demo in its current state which once again brings up the need for a trackloader.
Or maybe i'm just not getting something. (?;)
The routine could also be optimized without smc by using movem to fill the data registers from the table (as britelite pointed out to me after I released the final and it was still slow ;)
Please log in to add a comment!
User Votes: Average: 4 points (13 votes) |
Please log in to vote on this production!
|