Just use a variable-time update method, then updates/sec don’t affect physics, etc. (for reasonable framerates, ofc)
And there is still no sane reason for wanting 1000 fps rendering.
It should also be pretty trivial to lock to any specific framerate using non-continuous rendering mode coupled to a custom gameloop using either your own timing or the LWJGL backend’s Display.sync()
Graphics card can force it as well, check your settings, either that or your hardware is dated, sound like it because when I refresh or clean all my projects (which I have about 20) it’s pretty much instantaneous.
Set LwjglApplicationConfiguration foregroundFPS to zero and vSyncEnabled to false. RTFM before complaining. :-*
Everybody should be allowed to express their opinion and criticize even libgdx without people jumping down your throat.
however disappointingly your complains weren’t professional and all seemed to stem from ignorance rather than actual technical suggestions.
[quote]Always capped at 60 fps
[/quote]
You never want to draw faster than your monitors refresh rate… right ? that would be stupid. so what the deal ?
Even if you have 120hz monitor im sure you can sync to 120 via vsync if thats at all desirable.
[quote]Sprite class doesn’t have anti bleeding built in
[/quote]
Wow hm. I guess you dont really understand how bleeding happens - which is ok its not immediately obvious since its low level; Point is: its not the sprite classes fault.
This is a good write about texture bleeding and how to deal with it, it is due to the image scaling interpolation algorithm used, particularly a linear algo. This is again not related to libGDX. Use the TexturePacker to make your atlases and your shouldn’t have problems.