how to improve the performance of blitz games?

Blitz3D Forums/Blitz3D Beginners Area/how to improve the performance of blitz games?

Santiworld(Posted 2010) [#1]
in my experience, Blitz3d, has a great ability to render polygons, and may even do amazing things with materials with multiple textures.

but I always find difficult to use alpha transparency, make effects like fire, smoke, brands, etc.

i use some libraries, as fastimage, Fasttext ... but fail if you wan't a excelent performance.

I guess this is because DirectX7.

I try to keep lowpolys objects, use LODS, use Mask vram textures and textures.

I wonder what methods could be used for games with huge scenes in cities, or have thousands of trees.

graphic capacity or limits are an issue of DirectX7 or blitz3d?.

the optimal maximum number of polygons per object, types of textures, is there any document that has information on how take the best of this engine?

in this game, i work hard for a good performance in all computers.



my blog :
http://indiesoftargentina.blogspot.com/

Last edited 2010

Last edited 2010


_PJ_(Posted 2010) [#2]
Particle Candy I think it's called might be worth looking at.?

Generally, try to limit the number of actual particles made and 'recycle' them rather than destroy/create when a continuous effect is needed.

I personally like to use Types for particles, since the iteration seems pretty fast, and they can be destroyed easily too.

Avoid sprites, not only because of the windows 7 issues, but they cause slowdown rapidly once you have a few on screen, especially if the sprites get rendered up-close.
Instead, use a single-surface mesh system using separate, tiny quads as part of a mesh. This is by far the fastest I've seen for number of particles.


Robert Cummings(Posted 2010) [#3]
For particles you need to use a single surface mesh (one mesh for all particles) with just the one texture atlas, which can contain lots of different images.

I'm guessing the huge number of particles is dragging down your gfx card with state changes.

For meshes, its much less of a problem to use different textures as there won't be hundreds of meshes.

On todays computers I'm not sure lod is even much of a big deal. The real problem is fill rate and state changes (but state changes only matter if there's a lot of different objects using a lot of different textures).

This engine is pretty simple - it groups stuff up best it can and throws it at the card. It's weakness is that it doesn't batch particles so don't use "sprites".


jfk EO-11110(Posted 2010) [#4]
You need to define a Tris-budget for your scene. Then try to stay below it all times. If you want the game to run at a decent rate on older Hardware too then this number may be rather smalll, eg. 50kTris.

Be careful with shiny FX that were added to Blitz using third party libs. Test them and their speed and if required ask yourself if you really need them.

Find a good ballance between number of surfaces and size of level chunks/clusters. Loading a Level as one single mesh may not be a good idea since the entire Mesh will be rendered, even if there is only one little part of it on the screen. So splitting your mesh into clusters may make sense, but only if not all clusters are going to be visible on screen nat the same time, because this would give you the same number of Tris as before, but also a higher number of surfaces and therefor it will be slower.

Optimize your LOD system. For many complex meshes a simple billboard quad can be used as soon as it isn't so close to the camera anymore.

Don't use Alpha and Masks close to the camera, in a way they cover half of the screen or more. especially when there are many of them at the same time. Be also careful with HUD elements (mesh or sprite) that are covering parts of the Screen.

Use animated Meshes only when it's absolutely neccessary. A dozen of animated NPCs can kill the rate.

Prevent too many Linepicks, CameraPicks, EntityVisibles and such.

Prevent texture editing during runtime, each time you edit a single texel, the entire texture must be reuploaded (flag 256 may partially fix this)

Prevent Highpoly Mesh Content. It's amazing what good Modellers can do with only a few Tris!

Prevent Clone Geometry: if two Triangles share the same space, even if they only partially share the same space, they may slow down Rendereing significantly (I think because the Z-Ordering will have to be refined repeatedly internally in order to sort two Tris that are located at an identic position), this may only be an issue on certain cards.

Make sure the game does not use more VRam than the user physicly has, otherwise there will be a nasty caching thing, making it unplayable.

Test your code, find the bottlenecks, using Millisecs() to see what part takes how long, is it the 3D hardware executing stuff or is it your code that takes the most time.


GfK(Posted 2010) [#5]
in this game, i work hard for a good performance in all computers
That's the problem. You're allowing people who haven't bothered to upgrade their PC in half a decade to govern the quality of your game. For casual games its not so much of an issue. For a higher demand (resources) full 3D game, then you have to make a compromise.

All you can do really is have your game looking its best on a 'recent' PC, then have a load of options to turn off all the pretty stuff for those people who can't be bothered to upgrade. That's what the big boys do.


jfk EO-11110(Posted 2010) [#6]
But could you really competite with the big releases using Blitz3D anyway? Even if you could, there would still be the sheer amount of work in those full 3D games. 20 People working hard for 3 years, that's probably what "full" stands for today. If I'd make Games for the latest hardware, I may not use Blitz3D. The Existing libraries for shadows and physics as extensions seem a bit "glued together" to me and correct me if I'm wrong but eg. stencil shadows are not really latest tech anyway.

But I most likely will not create games for the latest hardware only, because I would also hate it when a game of somebody else, even a simple indy game, has picky hardware requirements and locks me out, only because I haven't got shader 37 support or so.

Those full 3D games are really an interesting market and you can try to become a member of it. But you should know that you need a lot of people to work on it. It terms of salaries, 2 million dollars are rather realistic (~3 years development, 10 ppl)


Yasha(Posted 2010) [#7]
But could you really competite with the big releases using Blitz3D anyway? Even if you could, there would still be the sheer amount of work in those full 3D games.


....this is totally unconnected to the issue of performance. A large team of skilled artists could make a beautiful game in DX6; conversely the flexibility afforded by better hardware gives the lone coder more power to create a strong visual statement.

A good-looking game has a minimum hardware cost below which it simply can't be made to look as good or play as well. Having a development budget in the millions, or not, isn't going to change the fact that some customers have more capable machines than others. You still need to draw the cutoff somewhere; and it's still primarily a choice between your artistic principles and mass compatibility. That means that if you're concerned about the artistic merit of your game you are going to have to cut off the machines at the weaker end of the scale.


jfk EO-11110(Posted 2010) [#8]
Yeah but when you do that, why shouldn't you use DX9 or 10 right away. I am not an expert, but some FX like good shadows will bind much more resources when you try to do them in DX7. So if you are aiming to high end gaming rigs and if you're going to spend a lot of money and/or time for artwork, and let's be realistic, a "full" game requires several "manyears" of content creation, why should you work with Blitz3D. Don't get me wrong, I use it, I love it, of course. But the big boys out there, be it Clancy, Carmack, whoever, they don't play with Lego. It's a tough billion dollar business, and the tools are their weapons and they got to be sharp and latest tech. What do you think would the Magazines and Reviewers write, when IDs next game engine would be based on DX7.

But let's get back to the topic. For me it's ok to use Blitz3D. Not every successful product has to be a "Full 3D Game", full means FPS, Racing Sim, RPG or something like that, one of the big deals, stuff you can buy in every consumer electronic shop.

But if somebody wants to use Blitz3D and make a mid-scaled Indy Game. If this person is trying to get the best out of blitz and is working hard on optimation, so the game will run even on old machines, and the game will reach a performence that can be compared to professional DX7 games, then I think that's absolutely ok. Actually that's exactly what I'm doing too.

Santiworld, excuse me for starting this "ideological dispute" in your thread. BTW let me say your project looks amazing, very well done.

Last edited 2010


Kryzon(Posted 2010) [#9]
graphic capacity or limits are an issue of DirectX7 or blitz3d?.


I think it's neither; it's a limit on hardware. Even with today's GPUs, if you push it too much, they'll bend.

There are optimizations that you can do - some are related to the B3D internals (like with the case of Sprites), some are related to the way GPUs and the APIs work (like with batching and occlusion).
Some of these are commonly known, such as using a Quadtree or Octree to more quickly occlude stuff either from rendering or from computations such as collisions and picking\ray-casting.
These optimizations are documented in game engine development articles, tutorials and books. I suggest you surf GameDev.net as it has a lot of intelligent stuff.
EDIT: You can only tell if the optimization is worth implementing if you test it in your game engine. As complicated and mysterious "measuring performance" might sound when suggested by some people, it is but storing the current time, going through a block of code in question, then storing the current time again for comparison on how much it took to complete the section.
Test it WITH and WITHOUT the implementation so you can compare the [average] results, and see what took less time (= it's faster to go through).

Make sure you optimize everything on the CPU side of things as well: see if your code is clean, elegant, fast, etc. Going through loops is a killer (and is the only way to process collections of objects in Blitz3D), so make sure they are well-optimized as much as they can be.
Also, be aware that no matter how many optimizations you make, there will always be the inherent overhead of the Blitz3D engine - the friendly interface comes at a cost.

Last edited 2010


jfk EO-11110(Posted 2010) [#10]
I wouldn't say going trough loops is a killer - you can do a lot of For Next Loops until it can be measured with Millisecs at all. Other than that, I completely agree.

An other thing that I experienced is: some time ago I released a piece of code named Mesh-Clusterisation (see Archives). This would split a huge Level mesh into several pieces during loading. In fact it made the game faster, at least the framerate. But at some point I realized that the clustering process that is perfomed while the level is loading, is extremly slow, makes the loading process almost unbearable long. In this case the only alternative would be to save the Mesh as a number of pieces and then load them from the disk instead of the instant, slow splitting at runtime.


fox95871(Posted 2010) [#11]
But could you really competite with the big releases using Blitz3D anyway? Even if you could, there would still be the sheer amount of work in those full 3D games. 20 People working hard for 3 years, that's probably what "full" stands for today.


I think someone should start a thread about that in General discussion. It's easy to get discouraged when you see what huge game companies can do, but personally I don't think Blitz3D's limitations, or doing all the work yourself is a problem at all. I still like ancient games, and the things that make me like a new game are the same things that make me like an old one, good music, levels, and story, not graphical capabilities. If you could see every last hair on Cloud's head, would that make Final fantasy 7 a better game? Or if Shattered memories had come out on Playstation 1, would that have made it a bad game? I say don't improve the performance of your game, improve your game. Well, of course try to make the performance as good as you can get it, but the point is never mind what new consoles and office buildings full of game designers can do. One person using Blitz3D can make a game like Radical dreamers, and that game and many others like it, made with ancient tools by just a few people, are legendary.

Last edited 2010


jfk EO-11110(Posted 2010) [#12]
I agree, it's possible to make good games with Blitz3D. But it doesn't matter so much if a game is good when the leading publishers decide if they are going to publish a game. It's a bit like the Music Industry. So many good bands out there, but how many of them can live from it? How many have a deal with a big publisher like sony or so? Ever tried to get a deal with a record company?
<edit>
When you watch the AAA releases, they often feature a great, latest game engine, but doesn't offer anything in the story, has a repetitive gameplay and no drama-curve at all. At the other hand games often become popular because of their first version that had a weak game engine, but a great story etc. I can only repeat to mention Hitman 1, that had several weaknesses in the engine, but it was great fun to play. Hitman 2 had a great game engine, much better graphics (excluding of course those unfinished bits, most likely due to a deadline), but the story was sooo lame and each mission goal was the same, really boring and almost a pain to play trough it. (The only exclusion is the level where they give you fake ammo, the sniper rifle becomes useless and you have to "improvise") When I compare them, the one with the weak graphics was definitely better.
</edit>

But you can still try the indy way. The internet still offers a lot of possabilites for alternative publishing.

Last edited 2010