gfx speed issues
Closed this issue · 7 comments
I am not sure if you remember but v0.8 tbftss was fairly playable on a RPi2 in the game, although there was speed issues with the main menu. At the time I believe you had just added a bunch of stuff to the background: scrolling background, scrolling star field, ships, and maybe also the ship trails.
If I remember rightly there were only ship trails in the game itself, no background or stars.
I have patched some switches in the build to turn them off in levels and it makes a huge difference. For example having only ships on the title screen changes wait & fps from ~-3500 & 2 to ~15 & ~119.
There are 2 things happening, the speed (or slowness) of both prepareScene() & presentScene(), and the amount of work a app.delegate.draw() does.
To put that in perspective wait goes from ~-1000 to >-2000 when you are on the RESUME menu in game.
Is there not some way to cache the rectangles once they have been drawn, like you do with text. And or only drawing / undrawing the buttons, at least for the menus.
I just does not seem right that one (normal from master branch) screen pass should take ~7000 SDL_Ticks() (with wait ~-3500) on the main menu.
With the patches I put in place it appears the game speed is directly linked to the FPS. IE turning the ship to point to ship changes per render, not per uSec/mSec. That would explain the lack of proper speedup my patches achieved.
What about palming the render and draw off to separate threads. The RPi2 and RPi3 has 4 cores even tho they are normally clocked at 900Mhz that should be more than enough horsepower for tbftss.
BTW the most of the app.delegate.logic() happens with wait at 10 to 15 (not negative).
well since the above post I change the build patches and I started getting responses that are more usable, especially from the mouse and keyboard click.
So what I did (beside dropping all the nice bg's etc) was allow the game engine to run longer before rendering, and evenly splice blank, draw, and render.
Although a bit slower at standard 1280x720, the 640x360 is almost usable. I got good reponse from a 48th frame render, which draws on the 24th and flips the FPS to 0 on the 64th. However the player control ingame is strange, cant seem to align to the mouse direction, like its spinning between renders or something like that.
The best ingame controls, slightly better visuals render ever 128th frame, draw on mod 128/4 -1 (to miss the render frame) and reset FPS to 0 on frame 192. The controls are 100% accurate, the fire and trust is responsive, you still have to wait a it to see things, but there is (almost) no delay is action.
This is something that will take sometime to fix. I have a plan to implement a sprite batching system like I did for 3Guys, which should reduce the number of draw calls significantly and therefore speed up the game. However, I don't have an ETA for this just yet.
A custom build for the Pi with effects, etc. toned down might be the best thing in the short term.
yeah. There was a nice side effect to the 128th mod frame render tho, that mad the level chooser screen "a bit nicer". there is not one "red arrow" in the top left, but 2 scissoring back and forth, and the green rings, there are more of them and they are grouped in 3's, overall it looks really nice (having played a previous standard draw)
(all timings are SDL_Ticks after then compare, they are (usually) negative wait values)
the real problem (speed hits) is the combined back to back render then "prepare". combined they take huge amount of time (~3500) compared to the draw which varies depending, but ~250 without menus and ~650+ with a small (resume) menu.
The build patches I have, allowed me to get the overall render/prepare cycle down to ~1200 and ~2500 with a menu
This all sounds a bit suspicious. Is SDL2 working correctly on your setup? i.e., is it using OpenGL and not falling back to software rendering. The game shouldn't be having as many performance problems as this.
The laptop I've developed on has 8GB of RAM, an Intel i5, and an integrated GPU. It's hardly a powerhouse and it manages 60fps in 1920 x 1080 no problem.
glxgears on this machine pushes out 300 frames in 5 seconds with vsync enabled, and 29000+ frames without vsync enabled.
I've made some recent changes in the develop branch: the game is now using a sprite atlas and font atlas for rendering, so things might be a little faster. An upcoming version of SDL will allow batching in earnest.
Closing, as this issue is really old now and there's been on activity for many months (if this is still an issue, re-open it).