0 Members and 1 Guest are viewing this topic.
Bump,So my demo made it on Pouet ! https://www.pouet.net/prod.php?which=62454And ticalc too ! http://www.ticalc.org/archives/files/fileinfo/458/45819.htmlLet's spam the staff with mails saying to feature it Final gif :
My turn!I was convinced this effect could be made faster, and after a lot of careful thought and crazy tricks, I managed to bump up the FPS: from 14.3 to 18.5, an improvement of about 30%! Again, it is running at 15MHz. It may look slightly different, as I had to rotate the texture up and right by one pixel per frame (rather than down and right) due to complications of the immensely aggressive optimization. I'll attach the source to this post, but be warned that there's a still a bug that I haven't had the time to hunt down which crashes the calculator with fair frequency upon exiting. But here's a gif, proving that it does indeed work:Spoiler For Oh, and did I mention...: ... that that's just the pure Axe version? As is always the case for assembly, and is especially the case for really specific, concise algorithms, if you know what you're doing you can get big performance gains over a compiled language. Re-coding only the rendering core in just as (if not more) aggressively optimized assembly, I registered a huge boost in FPS: 18.5 to 44, an improvement of about 140% on my pure Axe version and 200% on the existing assembly core version! The source for this will be attached as well, and luckily this one is 100% stable, so play with it all you want! Here's a gif again, showing it off, although keep in mind that it's actually rendering about twice as many frames as the gif captured:Spoiler For Wait a second...: ... why does that gif say 6MHz and load effects so slowly? Because it is 6MHz! The true 15MHz FPS for the version with the assembly core is a stupidly high 107! This is with no pre-rendering of frames or any such cheating, every frame is rendered pixel-by-pixel as always. So the total performance markup on the original 14.3 FPS comes to about 650%. You can try it for yourself by simply un-commenting the Full in the setup part of the assembly version source. And although it doesn't even capture a quarter of the frames rendered and the original effects are all but impossible to discern, here's a gif:Beat that.
Okay what the actual fuck. So you're getting 18.5, then 44, then 107 FPS ? You overclocked your calc or what.EDIT : tested and yes. I see you actually wrote your own code, only taking my deformation functions. I can't understand shit to what you wrote, so yeah.I find it actually a bit desperating, how whatever code we come with you can make it 600% faster.
Disp: ld (spSave),sp ld c,$20 ld a,$80 out ($10),a ld sp,(LUT)ColLoop: ld de,64*256+%11111110 ld hl,ColLoop ld a,c inc c ld b,7 djnz $ out ($10),a ;152cc into, 153cc loop cp $2C ld a,e ret c ld sp,(spSave);Pixel: add a,a ;or adc, a a ret c out ($11),a ;147cc into, 148cc loop ld a,e scf dec d ret nz jp (hl)
My turn!I was convinced this effect could be made faster, and after a lot of careful thought and crazy tricks, I managed to bump up the FPS: from 14.3 to 18.5, an improvement of about 30%! Again, it is running at 15MHz. It may look slightly different, as I had to rotate the texture up and right by one pixel per frame (rather than down and right) due to complications of the immensely aggressive optimization. I'll attach the source to this post, and here's a gif proving that it does indeed work:Spoiler For Oh, and did I mention...: ... that that's just the pure Axe version? As is always the case for assembly, and is especially the case for really specific, concise algorithms, if you know what you're doing you can get big performance gains over a compiled language. Re-coding only the rendering core in just as (if not more) aggressively optimized assembly, I registered a huge boost in FPS: 18.5 to 44, an improvement of about 140% on my pure Axe version and 200% on the existing assembly core version! The source for this will be attached as well, and luckily this one is 100% stable, so play with it all you want! Here's a gif again, showing it off, although keep in mind that it's actually rendering about twice as many frames as the gif captured:Spoiler For Wait a second...: ... why does that gif say 6MHz and load effects so slowly? Because it is 6MHz! The true 15MHz FPS for the version with the assembly core is a stupidly high 107! This is with no pre-rendering of frames or any such cheating, every frame is rendered pixel-by-pixel as always. So the total performance markup on the original 14.3 FPS comes to about 650%. You can try it for yourself by simply un-commenting the Full in the setup part of the assembly version source. And although it doesn't even capture a quarter of the frames rendered and the original effects are all but impossible to discern, here's a gif:Beat that. EDIT: Apparently, at 15MHz, the assembly version is too fast for the LCD driver on my calculator and glitches out a bit. Whoops. I should probably fix that...