I don’t see why PNG’s would give better framerates, as the textures are all decompressed when they are loaded, anyway. JPEG’s might take longer to load due to the decompression required, but they are good for reducing filesize while mostly preserving the quality(at high quality settings, the compression artifacts are almost unnoticeable). JPEG 2000(and some forms of JPEG, apparently) offers lossless compression which beats out PNG for filesize, though they probably take longer to decompress.
Here’s an obvious tip which I’m sure most of you have already figured out: RGB normal maps run faster than grayscale bump maps in the Game Engine, so avoid grayscale bump maps at all costs.
Many issues about jpeg and png, there are just one way to know. Let’s make some tests… I have one idea about methodology…
Testing the load time and the fps:
Make sure the 2 images have the same file size and get the load time and the actual fps. Trying it with large images can show more discrepancies.
What are you think?:eyebrowlift2:
If you have more tips please share here. After some weeks we can do a good PDF. send it for a review from devs and release it in more public channels like blender.org and blender nation as a official best practices/ tune tips.
Yeah thats true. The tips are absolutely cool and very helpful, and full respect to Vitorbalbio.
But as this days I am having a game project (big) and I am in a confusion to use BGE or not, that why I asked that question.:yes:
Blender can do “big” games depending on your definition of big. A huge, 100-hour epic with a large, open world and beautiful(though not really cutting edge) graphics? Blender can do that.
300 Enemy soldiers onscreen at once with 50 dynamic lights? Blender couldn’t come close.
in loading time it says “- Don’t make copies (SHIFT+D) make instances (ALT+D) they loads faster.”
How do I do that in python? Right now I have scene.addObject(“Cube”, own)… I haven’t been able to
find a addObject instance anywhere in the api docs…
Move the objects you plan to spawn on layer 2, next create group for them, ex : chair-- ctrl+ g-- chair_instance, now you can easily spawn it using python. addObject “chair_instance”
This is not a golden rule. It is something to keep in mind when creating a game. As all tips it must fit your situation.
Sharing meshes has side effects.
E.g. you edit a mesh in-game. In this case all the objects sharing this mesh change their representation. The same happens with video-texture because materials are bound to the mesh (not to the game object).
You can share meshes …
in Blender:
use <alt+D>
select another mesh in the object data panel
in the BGE:
on loading - it takes what it gets from the blend file (if it is shared it stays shared)
using the replace mesh actuator to change a mesh
replace the mesh via Python
Obvious it makes no sense to change the mesh to reduce loading time when the game is already loaded!
I really do not know what you mean with that.
Added objects share all data of the original object except the game object itself. In other words: It is the same as <alt+D>.
The same belongs to group instances.
this work -only in blenderplayer- :
save the blend with resolution
H 4
W 4
bits 32
FPS 4
load the blend with blenderplayer.exe
(4/4/32/4 work on my PC, try to change someting if not work but keep it low)
other tips :
valid for obj-armature with tons of mesh “superimposed”(google traslator!) or overplaced : set -not visible- for all mesh which not see (make big difference if material have GLSL effect , no matter if is shadowless)
don’t use DDS/DXT for normal maps, use .jpg of high quality with 1x1 color subsampling instead. it’s an advice not for blender only.
p.s. use .png for simple normal maps (with many one-color plain areas)
To put things into perspective on beforehand: I am a Blender noob, a rookie just starting to learn Blender,… let stand having solid knowledge of BGE.
This post may appear to be quite critical, but it is written with the best of intentions, to help you all inform yourself in the best possible way I can. (no I didn’t read through the whole thread,… ,… see below: ====)
It doesn’t work like that.
That is just the filesize, which is based on the calculation method used to save some data.
It is just like comparing 7zip files with rar and zip,…
they all contain exactly the same data inside them, but they compress it differently using a different algorithm.
But once you load the data into memory, it is all uncompressed data, a bunch of zeroes and ones.
The amount of data required to describe certain data isn’t compressed any longer when it is required realtime.
It just resides in the memory, taking exactly the same amount of space, whether it is a png or jpg.
For images it is about the SIZE in pixels that matters, the AMOUNT of colors used and the ORDER the data is provided.
Order? Use DDS, this is a format optimized for use by graphics cards. Since the graphics card doesn’t need to encode/decrypt or anything else to get it in a workable state, since that is already been done by providing it as dds, this is probably the only (there are similar solutions!) texture format you want to use… (correct me where I am wrong!).
So using DDS is speeding up your your hardware’s performance.
WTF? (What The Format?)
But hey you say the DDS format is freakishly BIG! Yes,… and your PNG and JPG would be exactly the same size,… once they are converted and loaded into memory,… besides the fact that they need to be converted or require calculation to interpret what the data describes.
Based on what can you go in a bit more detail, I would like to learn why the BGE works differently?
====
no I didn’t read through the whole thread,…
because I noted some flaws from the beginning, tips/hints/advice based on assumptions of knowledge, where there isn’t a good solid foundation to base these assumptions on. (I refer to the first post, not the quoted one, I just used this “user experience” to provide direct feedback).
hmm so I wonder how solid the rest of the thread is…
Not saying it is a bad thread or wrong intention or anything like that.
But please before you advice rookies, make sure you at least mentioned your level of experience (or lack of for that matter).
So I ain’t saying everything I state is correct, but I definitely know for sure there is some more in depth information required to advice regarding “Best-BGE-Practices”.
To emphasize I do lack every knowledge regarding the BGE or blender for that matter!
So I do not know of any specifics,
so please inform where/why things are based on false assumptions and irrelevant knowledge.
So I hope the original poster is able and willing to skim through the findings in this thread, to make sure the first post does contain the best information available for the time being.
Hey, I just found this out trying to do voxels in the BGE again, this time with some nice results. I found that the more objects that are in the sce.objects list, the more time it takes to look through the list to find objects - even just a few. I suppose that’s pretty basic, but if you find that logic’s slowing down with your growing game, look into using more ‘static’ lists. For example, create a global enemy list, and when you create an enemy, add it to the list. If an enemy is destroyed, remove it. This way, you won’t have to look through a huge list of objects just to find an enemy - you can just look in the global enemy list.
EDIT: Or, just find an object once. For example, if you’re looking for a game camera, don’t run a cam = sce.objects[‘Camera’] every frame, but just find it once with obj[‘camera’] = sce.objects[‘Camera’]. Should it change, change the variable. This might save you some FPS.
You can use an always sensor with no pulse mode to execute a script or a module only 1 time. (Good for startup script)
The command ‘sensor.reset()’ can be called to execute the script another time.
The command ‘sensor.reset()’ can be called to execute the script another time.
interesting.
so, its like a state initialisation ?
did you compare with the property changed sensor (no pulse) ?
I use them to trigger modules : if a module (like the one that cares about inputs) has updated the game dict, it wakes up the other one (that distributes the inputs to actors).
the always/no pulse/sensor.reset could be used for the same kind of purposes, maybe its faster since it does not need a prop check to send a signal ?
Not sure about the first question, but there’s a quick way to check to see if an object is occluded or not (though it’s not really efficient). It would just involve checking to see if the object is inside the view frustum with camera.boxInsideFrustum() and also checking to see if a ray between the camera and the object is broken by something with camera.rayCast() - if so, the object’s occluded.
yes thanks SolarLune I came yesterday to the same conclusion :
for obj in wellLocatedEmptiesThatRepresentMyArmaturedObject :
if cam.pointInsideFrustum(obj.position):
there = obj.rayCastTo(tg,laserlength,prop)
if there ..
sooo I don’t need occluders finally
(+ 5 fps when the huge armatured mesh is out of sight)
it looks more efficient (so far) to use this kind of code than occluders. also it does not always need to be run at full throttle.
Wow so many tips…
I am learning the BGE and I know that optimization is very important, but I have a powerful PC (i7 2600k - 16 Gb RAM at 1333 - GeForce GTX 560) and a was wondering… Should I take all that advices too seriously? I mean, I have power to move last-generation games smoothly… Is BGE so slow to give me problems if I add (as said above) 50 soldiers and 25 dynamic lights? really?
I like to use realtime materials and effects and lighting to achive so much realism as possible and I don’t think to publish any game until I can make something decent, so I dont have to worry (for the moment) about making the game suitable for other people’s hardware.
Moving on to another topic, Don’t you think that woul’d be grate a kind of fusion between the BGE’s logic brick system and the Ogre game engine? Ogre is much better optimized and faster than BGE but its hard to code. Ogre with logics bricks… :eyebrowlift:
Both the BGE and Ogre are Open Source… any coder with free time? jeje
No, you do not need to take them serious. Better keep it in your mind. Look if it fits your situation.
Always look for the reasons why a hint should be preferred. You will quickly see they do not fit to all situations. The difference between beginners and experts is to know how to evaluate different solutions.
A hint without reasons is a bad hint as you can’t judge if it fits you situation. In some cases it is just repeating weak semi-knowledge.
For example: Enable True Pulse on a Sensor
In 50% of cases this is plain inefficient, in 50% of cases it is the necessary solution. But you can’t decide if you do not know the background of the hint.
BTW. There are other best-practice threads in this forum.
:eyebrowlift: