ballls.jar at 640x480 windowed gives about 1200 objects @ 50 fps.
i didnt know about that FPS capping...? does the swing timer run at a diferent speed on the win 98 system?
anyway, that's simple... dl from same location as the new one in the other post (i ripped off someone elses gfx this time. you probably recognise them)
using many diferent gfx seems to slow it down a bit. 1000 objects at 45 fps... (sorry, mine doesnt have a framerate target feature in it.)http://members.austarmetro.com.au/~juddman/java/MultiGFXBuffer.jar
60 fps = 580 objects...
320 objects at 98 fps. framerate is only capped by the maximum speed of the swing timer.** see edit.
well, if anyone has a timer class that works really well and particularly if it is self containing and just invokes a method of a class passed to in on construction, that'd be useful.
if you have some great timer code and dont mind me converting it to something like the above, that'd be good too. post a link or the code if you can be bothered.
just wondering... is it good to have the timer running on a separate thread to the main class? i get the impression that it's not and it locks out all the operations that swing uses to maintain the GUI. no problem for fullscreen but in a movable window...
Edit: i modified it to bypass the swing timer alltogether and put the main rendering code into a while(true) loop.
it doesnt have any impact at all on the GUI. in fact the gui seems to be much more responsive now than before. bad sideeffect though is that it does a slight hang at intervals of exactly one second (perhaps a couple of frames during FPS calculation)
edit: it does run faster on the whole though. 800 fps (yeah right) at 1 object,
20: 740 fps
40: 750 fps(?)
100: 400 fps
200: 229 fps
400: 115 fps
600: 80 fps
1000: 50 fps (but the 'crunches' are very noticable)
1500: 33 fps
4000: 12 (GUI still responsive. before it was slow. sprite movements very jerky)