KanedaFr Posted February 29 Share Posted February 29 (edited) I have to draw about 100 sprites on screen so, of course, framerate drops. I'm on progress to optimize it but apart looking if sprites anim are smooth or not, I don't know how to measure the improvment. So, is there a way to measure the framerate ? I found this post but I'm not sure how to use clock() with tgi_busy().... Edited February 29 by KanedaFr Quote Link to comment Share on other sites More sharing options...
42bs Posted February 29 Share Posted February 29 (edited) In the VBL increment a counter. After switching buffer, load and clear it. Then you have your frame rate. Edited February 29 by 42bs 1 Quote Link to comment Share on other sites More sharing options...
42bs Posted February 29 Share Posted February 29 BTW, a good method to see if you can run with full FPS, "dec $FDA0" after switching buffer and "stz $fda0" after rendering. 1 Quote Link to comment Share on other sites More sharing options...
LordKraken Posted February 29 Share Posted February 29 tweaking the green palette? whats the expected effect? (yes i know I could try myself but at work now ) Quote Link to comment Share on other sites More sharing options...
42bs Posted February 29 Share Posted February 29 Most games have 0 as background, so setting color 0 to $FF and later to 0 you can see (if you have visible background) the amount to "time" (scan lines) your loop takes. It if flickers, then you need more than one frame. Quote Link to comment Share on other sites More sharing options...
LordKraken Posted February 29 Share Posted February 29 (edited) thanks, my games run at half the frequency, so around 30ish fps, except ody has a few slow down at 20 (using a "real" timer) but I should try this trick, thx! Edited February 29 by LordKraken Quote Link to comment Share on other sites More sharing options...
42bs Posted February 29 Share Posted February 29 Do you use collision buffer? I noticed clearing it is also a performance killer. I mean, the poor SUZY has to write 16Kb to clear screen and coll-buffer Quote Link to comment Share on other sites More sharing options...
LordKraken Posted March 1 Share Posted March 1 no i dont use the collision buffer, and checking collision is def. a performance killer. On the other hand i wouldnt have enough ram with the collision buffer activated Quote Link to comment Share on other sites More sharing options...
KanedaFr Posted March 6 Author Share Posted March 6 I use a full screen 1bit full size scaled sprite for the background My point is not to see if it slows down (I know it does) but to 'profile' my actual rendering method and to measure if my future optimizations let me gain some cycles or not Quote Link to comment Share on other sites More sharing options...
42bs Posted March 6 Share Posted March 6 1 hour ago, KanedaFr said: I use a full screen 1bit full size scaled sprite for the background My point is not to see if it slows down (I know it does) but to 'profile' my actual rendering method and to measure if my future optimizations let me gain some cycles or not That's what setting FDA0 for, I usualy have a scotch tape besides the screen where I make marks. But if you are already < 60FPS, you may enable HBL interrupt for fine grained time or VBL for a coarse measurement. Quote Link to comment Share on other sites More sharing options...
KanedaFr Posted March 6 Author Share Posted March 6 where is the need for a profiler when you have scotch tape !? GREAT idea! I'll try it tomorrow! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.