Josh

So you are saying the increased memory that mysteriously appears on some machines is due to stack memory? This code should be added to the main loop, but I don't think it explains the problem: while (PeekEvent()) WaitEvent();

This is what GetMemoryUsage does: uint64_t GetMemoryUsage() { uint64_t result = 0; #ifdef _WIN32 #ifdef _DEBUG //Exact memory usage, but only works in debug mode: _CrtMemState memstate; _CrtMemCheckpoint(&memstate); //_CrtMemDumpStatistics(&memstate); return memstate.lSizes[0] + memstate.lSizes[1] + memstate.lSizes[2] + memstate.lSizes[3] + memstate.lSizes[4]; #else PROCESS_MEMORY_COUNTERS process_memory_counters; if (GetProcessMemoryInfo(GetCurrentProcess(), &process_memory_counters, sizeof(process_memory_counters))) { result = process_memory_counters.WorkingSetSize; } #endif #endif return result; }

Just tried it on WIndows 11 (Nvidia mobile card) and it worked the same as on my other machine. The only thing I can think of is to update your Nvidia drivers.

I have a GEForce 1080 installed right now. Did you try running the EXE I sent?

Your application's memory usage in the titlebar looks exactly the same as mine, but my allocated memory in Taskview shows a steady 65-70 MB. https://superuser.com/questions/1846625/task-manager-shows-ridiculously-wrong-memory-consumed-by-processes There are other tools that might give a better reading: https://learn.microsoft.com/en-us/sysinternals/downloads/process-explorer Perhaps the problem is with Windows 11 task manager?

This approach has obvious problems and I don't think we need to continue trying it.

I also tried compiling with the Steam build, and got the same result. This is all using 0.9.7.

id Tech 7 makes heavy use of decals, although they are constrained by console support and can't actually do some of the things Ultra does. Decals in Ultra should render very fast, and can be used in a similar manner as seen here. They also have a multi-material painting system, sort of like a real-time version of Substance Painter materials. Again, we could actually do a better version that would not have the same limitations their system has. This would use something like the terrain material painting system, applied to all level geometry, so you could paint any material anywhere. I would love to add an better version of this to Ultra. This video has more info. (They talk about "geometry decals" which is actually a terrible idea, because it's slow and prone to problems.)

That is strange, my example shows a steady 12 MB in the window and 65 in task manager. I think the application is showing how much memory the application is using, and task manager shows how much memory Windows has allocated for the process. Windows allocates big blocks of memory and divides it up as the process requests it. light test.zip

https://3dassets.one/about-site Apparently they have an API, so if that is implemented it supports all these sites: https://3dassets.one/about-creators

This is a good material to test out decals. Decals.zip

0.9.7 Decals now use a create and edit mode that acts more like brushes, which seems to work well for these objects.

The mem usage will now be accurate in the debug build. It fluctuates quickly, but should stay within the same range.

0.9.7 Added Entity::Set/GetDecalLayers, but they don't do anything yet. Decals added in engine lib and Lua exes. GetMemoryUsage() is now accurate in debug builds.

The next build will have correct measurement of mem usage in the debug build.

Hi, I am from the future. This is what I did: //Exact memory usage, but only works in debug mode: _CrtMemState memstate; _CrtMemCheckpoint(&memstate); //_CrtMemDumpStatistics(&memstate); return memstate.lSizes[0] + memstate.lSizes[1] + memstate.lSizes[2] + memstate.lSizes[3] + memstate.lSizes[4];

Although GetMemoryUsage() might not actually be accurate, judging by some old posts. If you add malloc(4) in the main loop it does not increase memory at the rate I would expect each frame. Let me look into this more closely...

I am running in debug mode and memory is extremely stable. With a memory leak, you would see a steady increase in RAM usage. When the program starts, I see occasional increases until it steadies out after a few seconds, which indicates new systems are being initialized, or the number of camera visibility sets in memory is reaching its max it will have during usage, but the memory usage evens out quickly and remains stable. I believe that GetMemoryUsage() is only accurate in debug builds, but I don't know how much it can be off by in release builds. On Windows, it is using GetProcessMemoryInfo under the hood.

0.9.7 Added initial implementation of decals, in the editor only. No special shaders are needed for decal materials, just assign any PBR material to the decal in the entity properties. I am not sure how we should control what decals appear on what entities.

Hello, and welcome to the forum. Thank you for your suggestion, this is something I have thought would be nice.

You can just call ATan().

Maybe your shaders are outdated? It's hard to tell without seeing the texture the decal uses.

Okay, I forgot to add a check to only draw the mesh layers once before the first transparent material is drawn...

In Lua, I have made anything that is an array index one-based, since that is how Lua is designed. When you add a post-effect, one will be added to the index before it is returned. "AddPostEffect", [](Camera& c, shared_ptr<PostEffect> f) { return c.AddPostEffect(f) + 1; },

The index needs to be one-based in Lua.