Magic tip to improve the fps of a game

Blitz3D Forums/Blitz3D Programming/Magic tip to improve the fps of a game

RemiD(Posted 2012) [#1]
Hi, :)

I just want to share with you an important way to improve the fps of a game and decrease the ressources it needs.

Basically it is about having quality importers/exporters of meshes, joints, animations...

I was not aware of this problem because i assumed that a person who sells/distributes a modeling software has taken care of this but apparently not ! And it seems to be a problem with several softwares depending on how the importers/exporters are coded.

I was trying ot optimize my meshes so that they have the less surfaces, vertices, triangles possible in order to avoid too many calculations for the rendering of shadows with DSS.

After several tests and tweaks i realised that the .b3d exporter of Fragmotion produces many errors (it adds one joint, it adds one animation, it adds 3 vertices for each triangle)

So instead of having a low tris low vertices mesh that requires a few calculations, i had a low tris high vertices mesh that requires 3 times more calculations.

I don't say this is a problem with all modeling softwares, but i say that if clean meshes are important for your game, you should check if the exporter/importer you use produces clean meshes.

Oh by the way, this .obj importer produces 3 times the number of vertices...
http://blitzbasic.com/codearcs/codearcs.php?code=1323

So my next step is to write a clean .obj importer for Blitz3d.

This was my tip of the day.

Last edited 2012


Ross C(Posted 2012) [#2]
Some more tips for increasing speed in blitz:

Reduce the amount of bones in your meshes.
Use md2 animations where you can get away with it.
Don't use the TEXT command.
Try and use less surfaces.
Single surface particle system.
Forcing a texture to VRAM can sometimes cause slowdowns.


Rroff(Posted 2012) [#3]
Another tip - don't rebuild the whole UI every frame (does take some special case handling of keyboard/mouse input). Mine renders the UI to a buffer and draws that buffer every frame (I'm actually using a system now with a front and backbuffer and rebuilding the UI a little at a time as much as possible before forcing it to finish everything once it hits 30ms since the last UI update then flipping the UI drawing buffer as rebuilding it all in one go once every 30ms means you get a spike of one much longer frame).

Tempted to try threading UI building with fastpointer to tho theres a few potential issues with that.

Last edited 2012


Yasha(Posted 2012) [#4]
Tempted to try threading UI building with fastpointer


Do note that there is no thread-safe, fast way to share data in FastPointer, as it doesn't include locks (for... some reason?). The lock-free algorithms you might find on Wikipedia or in 90s CS textbooks will not work on a modern CPU, as they rely on it not performing instruction reordering or other hardware optimisations.

You can obviously share data using something that the OS will lock for you, like a stream, but that might eat up all of your performance gains. And anything going through the renderer has to be coordinated around it anyway (i.e. all threads handling graphics have to be paused and their data committed before you can call RenderWorld, or chaos will ensue).


Rroff(Posted 2012) [#5]
Yeah aware of that - probably will be done via spawning threads on the fly and waiting til they've finished to flip from building graphic buffer to renderering graphic buffer (not sure if spawning and killing threads fairly frequently has any performance implications) and obviously going to have to manually "lock" the data set its drawing from while the thread is active (possibly have to have 2 sets to work from).

I'm currently using fastpointer as part of my system for attaching the win32 console to the b3d application (without threading it doesn't work properly with b3d) - this means I can have debug output and enter CLI commands to the program without having to have a functioning UI in the program.

Last edited 2012


Yasha(Posted 2012) [#6]
not sure if spawning and killing threads fairly frequently has any performance implications


It does, unfortunately. This is why thread-pools and things like Grand Central Dispatch exist - to avoid this scenario. If you create a thread, make sure to get a good deal of work out of it.

While there's no "technically" thread-safe solution for FastPointer, you might be able to get away with certain assumptions if you enforce, e.g. single-ownership of resources, in documentation. A timer-based lock system (each thread object is assigned a "slot" on the system time during which it is allowed to read from the coordinating main thread, with buffer slots in between) would work in most cases, allowing for 1) the above documentation layer, 2) the assumption that the "slots" are wide enough being enforced by the app's processor requirements, and 3) a radically different application design from a lock-based or STM threading model that assumes threads can go for human-scale timespans (or at least, spans that can be described by the timer's granularity, which with B3D's MilliSecs is pretty long - could mean skipping frames) without communicating. And it'd still be pretty fragile.


my system for attaching the win32 console to the b3d application (without threading it doesn't work properly with b3d) - this means I can have debug output and enter CLI commands to the program without having to have a functioning UI in the program


Sounds very cool.

Last edited 2012


Rroff(Posted 2012) [#7]
Quick screenshot (no pretty picture as its just an engine framework at the moment):

http://aten-hosted.com/images/b3dcli.jpg

Last edited 2012


_PJ_(Posted 2012) [#8]
Use Quad meshes rather than Blitz Sprites
Minimise where possible the Blitz collision checking system
Smart use of 'portalling' and/or LOD changes to distant mesh polycounts