could be... not everyone uses lightmaps but those who do, have these problems...

But I cant live without lightmaps !!

Impressive, Mookai.

THAT's exactly what I meant when - in another thread - I said that, if anything, GG used to impress me with particlarly lush sceneries other engines' results seemed to lack or deliberately avoid for reasons I could never fathom. And I assumed that condition now to be lost from GG, too. How did you achieve this ?

"The thing is with lightmaps ! You only have these issues when you use lightmaps ! Thats very important..."
No, lightmaps are not the problem, because I never use lightmaps .For me the result always look more ugly than realtime light.
With my last game I had the crashes after 5 levels too, but I never use lightmaps.

I'm using BETA 23 for my game, it's a stable version.
I'm not sure if the final release version will be avail. before Xmas. So I'm using B23 at the moment.

"How did you achieve this ?"
Light and Shadow, you have to set sliders on the right carefully...
I spent much time at each level, to get the light and scene atmosphere right....

I wish I could use more vegetation, but we know what happen then...
For the trees, plants, ground decals I always turn off the physics. I guess most players would not recognize, if they run thru a tree
Also the most NPCs running around with phys. off. + reduced cam distance + fog...
All the little tweaks and workarounds help me to get a good framerate + nice visuals.

Added some more "posters" for the walls...
Wow, the framerate goes down.... just a few posters...
Ok, I was able to finish all 10 levels. Looks like I'm not over the mem limit this time (compared to my previous game).
Tomorrow some final settings and another bug test and it's ready...

I remember 1-2 years ago (2015 ?), I had this problem with the mem. limit .
But that time I didn't know why my game was crashing at level 9... then later at level 12...
End of the story, I've canceled this project after I had created 15-16 Levels. So, it's an old bug, which need to be fixed.

Good night.

@Mookai



Ah ok. I was somehow assuming you had been using the public preview, with its strange lighting conditions.

how much ram do you have?

I think it also depends on the ram...

It certainly would be good to do this test while monitoring the system with hwm64.
In doing so, you'll have a visual on what is happening and how much you ask of your system and thus what is required from a system in order to run your game without problems.
And i agree wholeheartedly with everyone, your maps are a delight for the eye MooKai.
Your a true artist

thanks

about the ram, I think that doesn't matter, coz it's a 32bit app. (4GB limit).
my pc has 16GB, i5 4690k, GTX970... even with this card sometimes I've only less than 20fps in some areas of my game


thanks to: BSP
His trees are awesome, his jungle pack and tree pack are great. You find it in the store.
Also thanks to Wolf, for the nice & free asian dojo(?) you find it here in the forum. I wish he would do more asian styled buildings like that...

With the villagemap, the ram usage was 4.5gb, the editor itself used about 1.2gb with that level.

The demo 'the big escape' is quite friendly and it shows that with optimization a lot can be achieved.
With the big escape the memory usage was 1 gb and the editor uses only 800 mb.

yea... that might be it lol. Maybe you could run my game lol. I gotta release a test version to see who has problems and who doesnt..

I doubt it. 32bit software is limited to 4gb usage, it shouldn't matter whether you have 4gb or 400gb in your machine, it will cap at 4gb.

Not that I understand it all but interesting .

Dave

Actually it does matter because windows and other applications such as your antivirus/malware prevention uses up the first 4 gb or even more if there are more applications running in the background.
Having at least 8gb is therefore a must and more is even better so that there is less or no swapping.
Swapping (data to and from the harddrive) greatly affects the performance of your system.

I've run two tests with stand alone files, the latter contains an empty level to see if the ram usage drops.
There is a visible stacking of data in the memory when advancing to a next level, one would expect that certainly the empty level would show a reduction but it did not.

What is clear is that there are no entities from the previous level visible, so that (as has been mentioned) likely has to do with lightmaps.
L3 and L4 are empty levels, but L3 has a small army of soldiers trying to prevent you from going to the fench gate.

See the attachments for the memory reading.

Ime sure you guys looking into this will help Lee no end,there is a lot of information in these posts ,nice detective work guys .

Dave

lightmaps can not be the problem.
I never use lightmaps, and I had the same problem with my last game. after level 5 or 6 it always crashed.
I remember ... I also changed the levels from 5 to 1. I mean Level 5 was the first, level 6 the 2nd to make sure its not a problem with the level... no, after 5 levels, the game crashed.
each level was full of objects.... so the mem was full after 5 levels.... I guess

yeah ... could be. maybe its not the lightmaps

Why this happens, anybody has a clue?

During the test i noticed that the ram used was getting lower and lower so i downloaded eurotruck 2 in order to test another game with memory usage.

As you can see in the reading, it is quite flat, no drop in usage.
Than i started the stand alone again to play a game of chess while monitoring the system, again the drop in memory usage is visible.

I guess only Lee knows whats going on with the mem management of his engine...

And probably only after a human sacrifice in a dark English forest on a full moon night...

Ertlov, in your experience with working on Father's Island. How many levels did you start with and how many did you end up having in your final game? Also did you find you had to remove any assets to avoid hitting a memory cap when doing your standalone?

Will this little program help any?
http://www.ntcore.com/4gb_patch.php

I think GG is already x64 large address aware.

Cheers.

@Teabone: Fathers Island is all on one level.

@MooKai: Glad to hear you like them! The dojo was supposed to be part of a pack but... heh! I'm somewhat lazy when it comes to complicated modeling and most asian structures have these curvy things going on on their ceilings. Back then that was a show stopper for me.

@MK83: No. this is not so much about ram as it is about v-ram. But thanks for the consideration.



-Wolf

Yeah, and we still hit the memory cap many, many times

^ wow

@Wolf
It’s really a great building. And it match perfectly to the scene, game, levels.
If u send me a PM with your real name, then I add your name to the credits, at the moment.... your name appear as : Wolf

The main Game Guru program is not running out of memory. yes it a 32bit .exe program and has to stick to the 2GB rule, but as Earthling45 posts above, the Game Guru engine is some way short of the 2GB limit, even with a map size of 3500 entities it's still well stort of the 2Gb with my map.

It's the Video Memory, the stuff that's stuck on your Graphic Card thats running out, and when it runs out, it starts to flood into the main system ram as (shared GPU Memory) as Windows 10 calls it.

Windows 10 has just had a big update, and with that update has come a few new tools to Task Manager. Now shows Dedicated GPU Memory usage in my case 2GB and shared GPU Memory usage 3GB. So I can store 5GB of graphics.

You don't have to be a brain surgeon to work out that as your maps get bigger so will your Graphic GB size sitting in your main ram, and at the same time so will the Game Guru .EXE be getting bigger and at some point they will meet, so too speak.

___________________________8GB System________________________________
Game Guru----> Spare System Ram <----Overflow of Video Graphics

See Pictures:- Of DX11 version of Video Ram.

1, Blank Map = 0.9GB. up from .5GB
2, The Big Escape = 1.9GB. up from .9GB
3, Return to blank map after The Big Escape. Still at 1.9GB
4, My One Level Map, 4.7 GB up from 3.5GB with DX9 Version. Has now been cut into three levels see WIP The Last Call.

See pictures below

Most of the AAA games these days all clock in at just under the 2GB Video Memory (as most gamers have 2GB cards) because they know it's not a good idea to exceed the video card Memory and start using system ram. And this is what we must do!

So keep a eye on your Graphic size, with Windows 10 it's all in your Task Manger now (if you've been given the update).

I gave the new DX11 Version a very short run and found it has some way to go before I can use it. The main problem is a blank map now clocks in at 1GB of video Memory up from 500MB and 'The Big Escape' has gone from under 1GB of Video Memory to 2GB and a good 60% of this map is missing.

infinisearch user on Steam also picked up on this see below.

"My task manager now shows GPU utilization and GPU memory consumption. When I use the GG editor and load up the Big Escape it uses 1.9 to 2.0 GB of VRAM and about 91% of the GPU. I don't know if that is normal or not, just figured I'd share in case it comes in handy."

I have all I need with Versions 1.121 and 1.13, but I'm still looking forward to the new version and will be testing it from time to time in the back ground.

1, Blank Map = 0.9GB. up from .5GB

2, The Big Escape = 1.9GB. up from .9GB

3, Return to blank map after The Big Escape. Still at 1.9GB

4, My One Level Map, 4.7 GB up from 3.5GB with DX9 Version. Has now been cut into three levels see WIP The Last Call.

Nice Post 25-Watts

here is my screenshot it seems a lot higher for me for some reason

I'm going to test the maps on win10 with a ryzen cpu and a amd390 8gb graphics card this saturday i hope.

I'm curious what the results will be.

Cool.

Have been doing some testing again and i think it is fair to say that Lee has done an incredible job so far.
I base this on my last test in which is monitored the villagemap first in DX11 and then in DX9.
It is quite visible in the graph that not only the loadingtime is reduced, but also the usage of the gpu and cpu is a lot lower.
In DX11 on lowest settings i had a minimum framerate of 37 while in DX9 the framerate dropped as low as 27 while on lowest settings.
That should be enough indication that DX11 is a huge improvement in terms of performance.
What is hampering gameguru currently is obviously the load on the memory, in the square is visible what 25-WATTS says about flooding the memory when the memory on the videocard if fully utilized.
When recording this difference in framerate something strange happens, the framerate goes from 27/30 to above 40 in DX9, stop te recording and it drops back to 27/30.
This does not happen in DX11.

The villagemap is one and the same, the only difference is the version of gameguru, yet in DX11 the memory usage is clearly higher and exceeding the video memory on my card.
Is that all due to the improved shadow quality?

I did this test after making a comparison of eurotruck and gameguru whereas i loaded the chmap with some pbr assets on it.
Eurotruck is DX9 so i thought it best to stick with gameguru and test this one level in both DX9 and DX11.

Results in the attachments.

The chmap contains some trees, the orbs, the chessgame and a winzone as you can see in the video, yet the memory on my videocard is filled completely with some flooding of the system memory.
This level was made in the DX11 public preview and contains no lightmaps.
It also makes no difference if it is a stand alone or started within the editor.
Only the editor with an empty map did not fully load the video memory.





When looking closely, it kind of shows how they manage to get such a good looking map and yet use so little, the fence in front of the truck is actually a texture on a polygon, just like the vegitation which simply aimed towards and turns with the moving player just like the fire-decal does in the village map.

Back to where i started, if this exesive load on memory is solved, than the huge gain which Lee has managed to unlock will be visible to all, that i'm quite sure of.

There are two memory issues with the current build, one I can deal with and one that requires a little more head scratching. The video memory issue you might be experiencing now is due to the Big Escape (and indirectly things like the larger PBR terrain textures) gobbling more video memory, and in the case of 2GB video cards, this is likely causing some FPS throttling (my best guess right now).

The main memory issue and the subject of this thread is the system memory cap imposed by the 32-bit addressing used by GameGuru. It's not a simple matter of calling the 'empty map' command and loading in level two, the memory used to load level one has been allocated in memory chunks of varying size, allocated randomly from the available landscape of allocatable memory afforded to the application. When these chunks are continually allocated, deallocated and expanded over the range of our available 2GB, something called memory fragmentation happens. Essentially your nice clean sheet of paper has doodles all over it, and at some point when you want to allocate a 2x2 inch square on the paper sheet, there is no clear space large enough to accommodate the square, and the memory is not created, thus we crash. Memory is allocated by the GameGuru application, but also by the DirectX subsystem and all other systems that connect via the application and out of GameGuru control such as the Steam API layer, LUA engine, Bullet Physics, the list goes on for a long time. The longer you create and destroy these allocations, the messier the paper becomes and eventually you can no longer allocate a sufficiently large chunk of memory for such things as loading terrain height data, vegetation landscapes, work textures and larger bitmap buffers. Consoles and some PC game engines handle things differently, by allocating a large chunk of the heap and then manage this heap directly for all game data and resources. It is then easy to say this heap is for 'level one', use it to the max, then discard the whole heap ready for 'level two'. Unfortunately, to implement this would require taking over quite a large chunk of aforementioned systems with some kind of custom memory manager and I would not even know where to start on a mission of that magnitude.

I can assure you that when level one ends, all the resources such as entities, textures, models, sounds, LUA buffers and suchlike are freed before the next level loading phase begins, but it would only take a few allocation/deallocation events during the initial creation of level one to impact how much contiguous memory remains for level two, and so on. There is a hope that if there are some small memory leaks, and some items are not being deallocated when they could be, then this would go a long way to ensuring levels can load without significant fragmentation worries. The question is locating when an allocation should be deallocated, as the number of memory allocations during a level load probably number in the tens of thousands and these requirements are spread across the above-mentioned modules, not to mention the strings, data and other data required by the highest level of GameGuru engine logic.

Moving to 64-bit would increase the addressable memory to such a size that the application could use as much memory as you have installed, but it alienates everyone still on 32-bit systems (of which there are so many it's not viable to stop 32-bit support at this time). Fear not though, the engine has never really had an overhaul that specifically focused on the memory management of the engine and chunks of the code derived from the even older DBP technology that pre-dates even FPS Creator, so there is plenty of scope for memory management improvements. A quick hack could be to restart the application for each level loaded, thus clearing the fragmentation issue, but this would add 5-10 seconds onto your level loading time, and is a bit crude, but it's another solution that might work for the short-term while plans are put in place to solve the larger issue of game engine memory management.

Hopefully, this casts some light on GameGuru and Memory and goes some way to explain why this has not already been tackled. Now that we've converted the original engine to C++, and now DirectX 11, we are definitely one step closer and one reason less to solve the memory issue for good, and giving you the power to create games with hundreds of levels. Perhaps until now there has been so much feedback on visuals and performance that internal memory management has not had the limelight, but it's a worthy topic of discussion and a serious obstacle to releasing commercially viable titles (I would also feel a little cringy if I had to demo a large 5 level game at an Expo with the current version that's for sure).

Lee, thanks for your answer on this.

The benchmark of the village map is with pbroverride=0
I don't know if that also means that the terrain is excluded from pbr.

Thanks for your answer Lee! Though I am not sure what to think now... Will it be adressed, or not?

[edited-posted in haste.]

It's not overall system fragmentation that's the issue, it's the fragmentation in the limited application heap. If you simply moved memory about to fill the gaps, ALL the pointer references to that memory would become invalid and you get monster crashes. It's one of the downsides to using C++ and direct memory commands. You get the speed of access, but you lose some flexibility in how that memory is tracked and managed. This issue will be addressed in time, but the big question is at what level of priority and to what degree. From feedback so far, there is a camp which argues that GameGuru does not yet produce games of sufficient quality to warrant efforts to improve the standalone game side of things (including multi-level games), and much prefer energy spent on performance, AI and general core features. Like all things though, opinion is divided, but I have a few ideas how we can start to look at this issue in 2018, so watch this space.

It can't be any clearer than this, real time monitoring what is happening.

Each time i close the level, the video memory is not cleared, but when the level is loaded again the data is simply loaded on top of the data that is already present in the videomemory and flooding the system memory because of that.

I could load this level a fourth time and it would crash my system because i've run out of memory.

Edit: geheugen gebruik means memory usage from the videocard.

It fills up at the first time loading and the exceeding data is than loaded into the system memory.
When quiting the level, the data remains in the video memory and thus also the exceeding data in the system memory.
When the level is loaded again, the data is simply loaded on top and completely loaded in the system memory.

@LeeBamber-ah yes if it's not overall system memory I posted in haste. I will have to reread your post again. I will remove the link to the defrag program.

Add it to the voting board and we will see.

Who would have guessed, it's a script that is causing the unusual high load in video memory.

See the video, in the first stand alone the chessboard and pieces have the default lua script.
The second stand alone is the same as the first, but now the piece.lua is used by the pieces and garbochess.lua for the chessboard.

Well it is playing chess so it isn't going to be very snappy!

Try CPU-Z for your video memory tests, it will keep an active look at video memory actually used rather than that which has been committed (it's a tricky topic to be sure)!

It is active but not playing yet, if i let it play, my framerate swings from 60 to 12.

It sure is



This is the hardware monitor of cpu-z, is this the one you mean?
Like the other programs i've tried, it shows the full memory being utilized.

You clicked start with the CPU selected to be white so it launched straight into play mode, garbochess creates some crazy large data structures on initialisation and when 'thinking' is using re-entrant functions to find the best move. I didn't write the chess engine part so not sure how much data it generates on the fly, bit puzzled about why it should be in vram though!

if I remember rightly Lee moved some of the grunt work off to the video card in a past update when he was performance tweaking

That it is loaded in vram is what puzzled me too.
I was of the opinion that some graphic or entity would somehow generate such a load, so i step by step removed the terrain, sky, entities, tested the map and eventually was left with a blank map with only the chess on it.
So in order to be sure that there is not somehow data left somewhere from the removed items, i've started a blank map to build up.
First some trees, than the board, than the pieces, than the scripts.
That it builds up in vram, i would never have guessed.

@GraPhiX, if that is the case, this riddle is solved.

Now the two last riddles are why it does not use the data already loaded and present in the memory when re-entering the level, but instead loads it again on top of it.
This would essentially mean no loading time because the data is already there.

Th second why the old data is not cleared when a new level is reached and loaded.

@Earthling45

I like all the tests you have been doing but It's always a good idea when doing tests to keep the conditions the same, so restart your computer between tests as there is a lot left in the memory after the first test. Windows holds onto the data for faster startup if the program is run again.

Look up TechpowerUp GPU-Z and download. you have CPUID open in picture above this is mainly for CPUs not GPUs.

If you have a Nvidia Card GPU-Z won't show you the Dynamic Memory only Dedicated Memory. both will show on AMD cards

Dedicated Memory = Memory on graphic card.
Dynamic Memory = System ram being used for graphics.

Use HWiNFO64 to show both, if you have a 4GB graphic card then I doubt you will see any Dynamic Memory used.

Edit :- I see CPUID HWMonitor does show Video memory used by % but can't see Dynamic Memory % read out which is what we need for our small 2GB cards


@GraPhiX

Thanks for posting your screen shots. You have a nice 6GB graphic card so you should be ok without any memory problems. 3GB in use is way to much for that level. Lee did a great post above about this and sounds like he's on the case.