"Frames are go?" = Can we please get some Frame Rate Increase forum feedback?
I am contemplating resurrecting my game that is currently getting ~10 FPS
on my weak AMD integrated machine, and ~16 on a GTX 2060 Super machine.
Probably with a fair Intel chip. (My brother laughed at me, and hasn't talked to
me since sending him that standalone!)

Help with any and all tricks that will do (scripting, textures, settings- whatever.)
There are tutorials already posted for it- just a link there would be great.
Is this a bad thing to put everything together in one spot?
Thanks much.

Perhaps a demo in WIP may help.
see what others get.

Thanks for that tip. And it's a good idea- though it's an ugly map!
It's just a stock map (no grass, no trees, no rocks, no water), the aesthetics
of the level would be about zero for forum prettiness competition.
Some things are not showing up on the Standalone... but you never know!

I will consider getting to that, but today I gotta get level 2 is needing
a LOT of attention. I have been kinda bummed about some hurdles
there- but the work must continue.

https://forum.game-guru.com/thread/218003

Maybe some of these pointers help.

Wow, Wolf, that's pretty cool. All those topics would have piqued my
interest from the very get go! That's a good little instruction book!

This one right here-- "Keeping up motivation / getting a game done"
is getting challenging at the moment.

Tab mode can show you where the frames are being lost, if the top bar labelled 'AI' is more than about 30% then that indicates a scripting problem, usually because the scripts are rubbish. If that bar is low then look down at the others.

I've never seen the 'physics' bar being an issue, mainly because Bullet is just too darn efficient. But the others can indicate where the problem lies.

Hi AmenMoses.
"more than about 30% then that indicates a scripting problem"
Yeah, it seems like it was a bit more than that. There's a rough estimate
of maybe ~50 items custom scripted.
"usually because the scripts are rubbish."

Wonder what can be done with the rubbish? Any idea how to turn rubbish
into steel or even lightweight aluminum?

50 scripts all running at once may slow things even if they are decent You may want to limit how many run at once where possible. Try not to have too many scripts doing vast loop checks of objects (or anything else) as well as they will drag the game down fast if you have a few on the go.

When you can, once a script has served it's purpose, also best to destroy the object and so stop the script running at all. That is if GG stops them running now, at one point even when deleted, the scripts still ticked away in the background If this is still the case then you may be able to get round it by switching the script to the default one. It would still be running, but as it is basically empty, incur a minimum cost.

Draw calls will be the big frame killer overall. In the Tab Tab menu you will see on the left a draw call count. The higher that is the slower things will get. The optimiser really helps with this in the main, but you can still choke a level up fairly quickly if you don't keep an eye on it. As soon as you start hitting a thousand or so, even a reasonable system will start to slow a little, especially if they are big textures.

On the same note, if you use objects with multiple textures, they will slow the game down a lot more as the texture increase is exponential. One object would normally use at least 3 textures, diffuse, normal and specular, that's 3 draw calls per object, more if you use other textures like an illumination map etc. PBR is an even higher amount potentially using even more textures. So a multi texture object that has 3 or 4 diffuse textures would potentially have 16 or more draw calls per object!

Occlusion can also make a game run better if used wisely, but can be troublesome with pop up unless well planned or tweaked accordingly after.

Last tip, make sure any object that does not need to do anything other than sit still, static. GG slows a lot more with dynamic objects. The editor in particular will suffer here. So when placing default or purchased objects make sure they are set correctly before you start plonking loads down all over! Trees can be troublesome speed-wise. Can't be sure if they are still as bad, but some of the foliage trees really slow things down massively when you use a bunch, indicating there is something slowing things more than usual there.

I could probably go on, but I think that's covered the main areas to check. I'd mention cam distance, but it makes less difference than it used to and also seems slightly bugged at the moment. But it may scrape you a few fps if you can lower it. I find unless you drop it down to about 10 or less the speed increase is negligible.

Hope that give you some ideas.

I'm always banging on about script performance, btw if an object has the default.lua attached it doesn't get called! So switching the script to "default.lua" once you don't need to anymore does effectively remove it from the map (assuming the same script isn't attached to another entity of course.

Lots of things you can do to improve the performance of your scripts, here are a few:

Avoid globals like the plague.

Make a local pointer to any globals you do have to access, especially if you access them a lot. ( that's why you see in my scripts things like 'local Ent = g_Entity[ e ]', 'local rand = math.random', 'local sub = string.sub' etc)

Wrap functionality that doesn't need to be executed every frame in scheduler code, this really needs to be done to the AI modules because they are perfect example of inefficient coding. Here is an example of this:


Oh and avoid globals like the plague, this includes functions, _init and _main have to be global so the engine can access them to call your script but any custom functions you add within your script should be defined as local.

The lua libraries I have provided do things properly so use them wherever you can, for example instead of:
if GetPlayerDistance( e ) < 100 then

use :
if U.PlayerCloserThan( e, 100 ) then

If you need the position and orientation of an object use GetObjectPosAng( objectId ) which gives you all six values (or as many of them as you are interested in) in a single call.
For example if you need the x & z position plus the y angle then do:
local x, _, z, _, ya = GetObjectPosAng( objectId )

Thanks for the tips guys. Very good.
I do use GetPlayerDistance( e ) quite a lot since this is a resource
collecting game. I activate items (so have to know if the player is
at the item), etc.

I have to compare distances and attributes between objects, so also it
seems like they would have to be global-- but I will check out the
suggestion to make globals local -- interesting. (and sounds like I might
have a large job ahead to commandeer this spaghetti dish!)

Actually that is not how draw calls work, regardless of having various additional maps, it is still one draw call as it is just one texture which equals one call the actual shading of the object is a draw call, lighting the object is a call, AA a call, bloom is call, each effect a draw call basically. The reason why PBR is more expensive to render is due to the particular object, requiring various angles for the specific shader effect but it is still only one draw call per texture.

However once you apply more then one physical texture per object you get additional draw calls, it is cheaper to render one 4k texture then drawing one object with 4 x 512k texture as you will have a draw for each texture. Performance isn't based on the size of the texture either, either you have the video ram to cache the texture or you don't.

Performance isn't based on the size of the texture or how many pixels the texture has is pretty much irrelevant, but rather the amount of pixels needs to be rendered in a particular frame, the higher the screen resolution the higher the amount of pixels that needs to be rendered the slower the overall performance.

Max is an entirely different rendering beast, and does far better with regards to objects having more then one texture, corresponding with Lee, he pointed out multi textured object rendering will be much improved and shouldn't see the same performance hit as with game guru.
It still doesn't mean you should go crazy, it just means you would have a little more freedom and it won't cost FPS and arm and a leg.

I just thought I would clear that up, as there seems to be some confusion lately especially with using large textures with the assumption that large textures drastically decreasing performance, which if you have enough vram wouldn't matter at all, draw call is going to be exactly the same whether it is a 512k or a 4k texture.You are more likely to hit a brick wall on performance when you run out of vram which to be honest if have a very recent mid range 4gb GPU would be pretty hard thing to do with game guru it would require some serious amount of textures. You are more likely to have performances issue relating to the amount of draw calls and too many triangles before running into issues regarding filling up the video memory. A 4k texture without an alpha costs in total about 80 ish mb.Would require about 50 4k textures to fill up a 4 gig vram, in many instances, if the object with the same texture map is used again it only gets loaded into memory once, even if you load a different object that uses the same teture map. So theoretically you could have far more then 50 textures, you would run into issues relating to triangles and draw calls way before textures fills up the memory entirely with gameguru.

Secondly the higher the screen resolution the more the overall performance will suffer the more triangles that needs to be render the more the performance will suffer. With game guru classic every object is being rendered whether visible or not with the exception of objects that have not yet been spawned it doesn't render a level in chunks every thing is basically loaded into the memory for the entire level.

I have to disagree on at least one point there. Image size for certain affects performance. The smaller the image the less work to be done regardless of in game resolution. It's not huge on modern cards, but still exists and of course some people who play your games may have a lot slower machine than the one the game is developed on.

This has quite few default cardboard boxes. Which has a puny 512x512 texture by today's standards.


This is identical but has the texture reduced with the setup.ini. There's a clear 20+ frames gained with them reduced.

It's a little extreme, but just to show that there is indeed a penalty for using larger textures. Every frame helps if you can reduce texture size when not needed on unimportant scenery items.

As for draw calls I couldn't say, whenever I make a 2D game in other apps draw calls are increased with each texture you use, so sprite sheets are a major way to speed things up. I just carry the same logic over into GG. Keeping them as low as possible is still advisable

Cool, Dvader. In fact my level uses crates. (Level 2 does). Did I mention that
I replaced the textures of those crates from 2048x2048 down to 512x512 and
there's hardly any visual diminishment for this size of an entity...
It was also an easy task, there weren't the glitches for doing so that I had come
to expect. The glitch that is still annoying is that you have to restart GG in order
to get it to recognize changes (like new textures/ objects) in the level--

Anyhow, modest textures seems like a viable help. But sad thing is that on my
computer, the "help" might be from 35-40 FPS up to 40-45 FPS -- and that's a big "if"!

Hard for everyone else (people in general) to determine what other peoples
situation is when you're not in that other persons shoes...
Just saying-- try using this computer, and scripting almost all objects!

@Dvader

Directly facing the barrels without moving the mouse after pressing the test game button, one without terrain, physics, water, sky, ai ect only thing not disabled is the entity it self, which was made static to give it a fair chance before taking a screenshot I let the frame settle takes a minute or two. Additionally I actually change the texture size directly, you adding overhead by let the engine reduce the texture size that isn't exactly accurate now is it ? I increased the DDS texture size in gimp, with the same DTX 1 compression.

512 x 512




4096




to make it really, really fair I went into the setup and set dividetexturesize=0 so it does not reduce the texture resolution, on 8192 x 8192.



8192 texture is within two frames of the others.

While max doesn't show the actual frame rate ingame you can get frame while in editor clicking the left mouse button, this is 512 vs 8192, basically the frame rate there isn't stable, basically luck of the screenshot with regards to the framerate regardless it doesn't drastically degrade between the two textures, as you would imply, what you get in the editor is basically what you would get in game for the most part.
512


8192



However tab menu metrics isn't that accurate, it is better to use F11 for frame rates. If you want even more accurate frames, disable post processing, set every thing to lowest settings possible.You can then also download GPU-Z which you can run in the back, enable log file, and it will record, GPU load and memory usage of a particular resolution.

But let me pull out the GPUZ logs for you, you can see there is a higher memory load between 512 vs 8192. But has zero impact on the actually frame rate. But I guess you still going to disagree. Actual texture size has very little impact on the performance, unless you fill the memory entirely, the difference between the two was 47mb for the 8k textures versus 170k for the 512 and 22mb for the 4096, and it literally made no impact on the actual framerate, between 512 and 4k texture, it dropped two frames on 8k texture, but I think that was an anomaly if I were to run the test again at 8k I should get the exact same frame rate.


512


8192


Like I said texture is still only ONE draw call, adding more then ONE texture on a object adds additional draw calls.

But I will quote to two important bits in case missed it.

Wouldn't the frame rate depend on the GPU being used?

Of course unless it is locked to the vsync, 60, 80, 120, 144 ect. You can disable the vsync in the setup, which gives you unrestricted framerate.But the point was to show that texture size doesn't actually impact the frame rate drastically, nor will you gain massive speed increases as a result.Texture still needs to be rendered by the GPU whether cached on the GPU or system memory, it wouldn't make a huge difference with the hybrid graphics cache systems in use by graphics cards.

But I think I need to further add, some assume that if you run out of video memory will result in a game slowly down drastically enough to make it unplayable. Video card developers would have you believe that more video memory is better, however modern memory cards uses a hybrid system of being able to cache textures and graphics in the system ram.

The penalty for this isn't significant enough to cause drastic issues, especially with the hybrid system, the caching of textures is handled directly by the GPU and drivers.A badly coded driver is the biggest overall culprit with regards to frame rates.

Video memory is almost exclusively used for graphics caching for fast access by the GPU, and with the hybrid system texture size as mentioned is mostly irrelevant for the most part.

Biggest killer is the draw calls as I mentioned gameguru is able to use and load a texture once into memory if it is used again on a duplicated object.If you have a look at the gpuz stats you will see that the memory controller load is actually pretty low, and dedicated memory used is around 130mb.

For the scene is pretty low, which is why I said you are much better off having a single 4k atlas texture which you can fit 16 1024 textures or 32 512 texture or 8 2048 textures. Which means you can have 32 512x512 different textured barrels in a scene.You will have 32 draw calls for the barrels but only ONE draw call for the texture.

32 barrels with 32 textures will result in 64 draw calls, if the textures are small enough it wouldn't make much difference, it would only use about 5mb memory, but add 31 additional draw calls.Using the 4k texture uses more video memory at about 23mb for a dds dtx1 texture but reduces the draw calls in half.

512 x 512 texture just about fits on a 100 x 100 x 100 cube and should display fine on a resolution of 1024 x1280, up that resolution to 1080 x 1920. Which is HD the 512 x 512 texture will start looking pixalated. It then requires a 1024 x 1024 texture to compensate for the loss of quality.

The alternative is to subdivide the block if using a seamless texture, from 12 triangles to 24, and basically tile the texture on the cube, but this isn't real world solution as not every texture is seamless and not every object requires it.

So while is the past there was heavy reliance on optimizing memory usage beyond the point of being insane, there far more freedom with regards to actual texture size.What you should concern you self with is the draw calls and triangles, textures will take care of them self.

I didn't say texture size significantly affected speed, but it does affect it. Also, using the divide texture option should not impart any speed cost bar when loading and is simply a quick way to test things. If it does impart a performance cost as you suggested, then my example is even better, still 20+ frames faster with many objects (not just 12 barrels). Try hundreds of barrels and see what happens.

Running out of video memory doesn't slow your video card? That would be very much down to the individual system, not everybody has a 4 gig+ video card. I know people who still use cards with 2 gig or less.

Draw calls are the most significant thing to worry about yes, but I did mention that as well. I may be wrong about how many each object uses, but otherwise what I said about them is valid.

I wouldn't say reducing all your textures is an absolute must by any means. Just an option if your map is struggling and you are running out of options to claw back a few fps. It really depends on how much polish you want really and if you want to speed up loading speeds a smidgen as well. Minor gains compared to batching your objects together to reduce draw calls, yes, but still gains. I would only do it on really small items you will never get close to.

You are aware, why gameguru uses DDS textures ? For one it is the easiest and quickest texture format to decompress into the raw data needed for the engine. PNG format actually has a large overhead for the one or two textures in a level it should be fine, an entire level just with PNG textures will run even slower compared to DDS textures. Does it look like I have a 4gb video card have a look at my sig, I have a pretty average rig.

I should know this as lee has asked me during the cold war pack to convert to DDS textures and the overhead from PNG adds quite a hit.
Imagine you add additional overhead by having the GPU physically having to reduce the texture size of an object in a complex level with multiple textures and objects.

I actually just showed you with the previous screenshot and GPUZ stats, that is caches the texture ONCE. If it didn't the 12 barrels each would be 44mb a texture times 12 and would have shown up in the GPUZ stats in the dedicated memory tablet as such, but it didn't and you are still arguing semantics, which you lost already, but still insist you are correct.

Gameguru also makes use of instancing in regards to meshes which means it is pretty pointless adding 1200 boxes with 12 triangle each it would barely load a GPU.

The acid barrel I used actually has LOD enable and has far more physical polygons then an average box. I don't need to add more to prove a point I can do it with ONE barrel and the results will be exactly the same, you are aware gameguru uses mesh instancing ?

While this is for a android analysis, it is pretty much laymans terms.
https://developer.oculus.com/documentation/native/android/mobile-draw-call-analysis/
https://docs.microsoft.com/en-us/dynamics365/mixed-reality/import-tool/best-practices

Enjoy at your own leisure. If you can't take my word for it let some one else do it. I am done arguing. !!!!

What it simply means is that you have MUCH MUCH more to gain from reducing draw calls and polygons then you would from texture, these two articles don't even deal with the hybrid memory system even. You are aware that the new nvidia RTX GPU's will be able to directly process textures on SSD's making you argument even more invalid, and it will be supporting 8k textures without even the slightest performance hit ?

Additionally as far as I am aware Nvidia 9XX series supports the hybrid memory system.