Gamestudio Links
Zorro Links
Newest Posts
Zorro Trader GPT
by TipmyPip. 03/06/24 09:27
VSCode instead of SED
by 3run. 03/01/24 19:06
Deeplearning Script
by wolfi. 02/26/24 12:46
Sam Foster Sound | Experienced Game Composer for Hire
by titanicpiano14. 02/22/24 16:22
AssetAdd() vs. modern asset list?
by jcl. 02/21/24 15:01
How many still using A8
by Aku_Aku. 02/20/24 12:18
AUM Magazine
Latest Screens
The Bible Game
A psychological thriller game
SHADOW (2014)
DEAD TASTE
Who's Online Now
2 registered members (degenerate_762, TedMar), 519 guests, and 12 spiders.
Key: Admin, Global Mod, Mod
Newest Members
sakolin, rajesh7827, juergen_wue, NITRO_FOREVER, jack0roses
19043 Registered Users
Previous Thread
Next Thread
Print Thread
Rate Thread
Page 7 of 10 1 2 5 6 7 8 9 10
Re: compiler and memory usage [Re: Superku] #466440
06/14/17 09:55
06/14/17 09:55
Joined: Jul 2000
Posts: 27,977
Frankfurt
jcl Offline

Chief Engineer
jcl  Offline

Chief Engineer

Joined: Jul 2000
Posts: 27,977
Frankfurt
I don't think that you've written 980 MB of code. Even from extremely laborious coders, I've never seen code of more than a few MB.

Unless you've programmed a new Windows in lite-C, the allocated 980 MB are probably used for your images, sounds, large data structures, and so on. Go through your game and check what you really need and what you can reduce. Use DXT images rather than BMP, and OGG sounds rather than WAV.

Re: compiler and memory usage [Re: jcl] #466441
06/14/17 10:32
06/14/17 10:32
Joined: Sep 2003
Posts: 6,861
Kiel (Germany)
Superku Offline
Senior Expert
Superku  Offline
Senior Expert

Joined: Sep 2003
Posts: 6,861
Kiel (Germany)
Haha no... I did not. As I've said before it's "less than 3MB in code" which results in an *.exe size of 6MB (an executable includes all global "large data structures", right?).
I don't have acknex sounds in my project (the whole sound part is deactivated for now as well) and I have replaced all global BMAPs with "= NULL" pointers instead.

That is pretty much my point or question rather, why the code compiling uses so much memory (up to the point where all code has been "scanned" through, before creating global struct objects like TEXTs and PANELs or loading files for global BMAPs - which I checked by putting invalid code there or wrong file names).
(My whole game puts ~380MB-440MB on the heap in the published version, including images, render targets, a 150MB nexus and level and mesh data.)


"Falls das Resultat nicht einfach nur dermassen gut aussieht, sollten Sie nochmal von vorn anfangen..." - Manual

Check out my new game: Pogostuck: Rage With Your Friends
Re: compiler and memory usage [Re: Superku] #466446
06/14/17 16:40
06/14/17 16:40
Joined: Jul 2000
Posts: 27,977
Frankfurt
jcl Offline

Chief Engineer
jcl  Offline

Chief Engineer

Joined: Jul 2000
Posts: 27,977
Frankfurt
How about static data structures in your code? Large global arrays? Nexus? The compiler also allocates memory for them.

Re: compiler and memory usage [Re: jcl] #466453
06/14/17 20:40
06/14/17 20:40
Joined: Sep 2003
Posts: 6,861
Kiel (Germany)
Superku Offline
Senior Expert
Superku  Offline
Senior Expert

Joined: Sep 2003
Posts: 6,861
Kiel (Germany)
I'm just using the default nexus and "run current script".

I've created a small test example thingy that demonstrates the problem: http://superku.de/codeCompileTest.zip
VMMap if you do not have it already: https://technet.microsoft.com/en-us/sysinternals/vmmap.aspx

The code_creator.c creates a few files with copy pasted dummy functions and different names. That has been done already though, just run main.c.
The compiler will stop after it has processed all the code and reached "asasda" after the main function. When you select that acknex process with VMMap, it will show a heap value of ~1041MB (unless my system is bugging out right now again, which I don't think it is). No images or global objects, except stuff from default.c (and acknex.h).


Remove "asasda" and run current script again. The A8 window appears. VMMap on that process returns a heap size of ~~1223MB.
If you now press [Space], bmap_createblack(2048,2048,32)+draw_quad is executed each frame. The application throws the known DirectX error after about (on my machine) 22 bitmaps (which makes sense, 22*2*8MB = 352MB, default critical heap value).



------------------------------

Btw. I've copy pasted some more (of the same) dummy code into dummyFunction.txt, ran code_creator.c again and main.c after. Got no code size warning but a

Quote:
Microsoft Vusual C++ Runtime Library
Runtime Error!
Program: ... acknex.exe
This application has requested the Runtime to terminate it in an unusual way.

VMMap: Total 2028MB, Heap 1864MB.
This is not working as intended, right?

Thanks for your time.


"Falls das Resultat nicht einfach nur dermassen gut aussieht, sollten Sie nochmal von vorn anfangen..." - Manual

Check out my new game: Pogostuck: Rage With Your Friends
Re: compiler and memory usage [Re: Superku] #466485
06/16/17 15:20
06/16/17 15:20
Joined: Jul 2000
Posts: 27,977
Frankfurt
jcl Offline

Chief Engineer
jcl  Offline

Chief Engineer

Joined: Jul 2000
Posts: 27,977
Frankfurt
I don't know. But I'll check your example in the next days and will look into it.

Re: compiler and memory usage [Re: jcl] #466494
06/17/17 10:24
06/17/17 10:24
Joined: Sep 2003
Posts: 6,861
Kiel (Germany)
Superku Offline
Senior Expert
Superku  Offline
Senior Expert

Joined: Sep 2003
Posts: 6,861
Kiel (Germany)
Thanks, looking forward to your findings!


"Falls das Resultat nicht einfach nur dermassen gut aussieht, sollten Sie nochmal von vorn anfangen..." - Manual

Check out my new game: Pogostuck: Rage With Your Friends
Re: compiler and memory usage [Re: Superku] #466497
06/18/17 09:52
06/18/17 09:52
Joined: Feb 2011
Posts: 124
Germany Nrw Herford
HenWoll Offline
Member
HenWoll  Offline
Member

Joined: Feb 2011
Posts: 124
Germany Nrw Herford
I have a similar problem, and it does not occur until after a level load.
A year ago I solved the problem by having all my textures in the DDS format.

Now, however i can only Maximum change to 2 level,s after this i become the Error E1513, In the most diverse varieties!

The levels individually can be run and error-free, only that my video memory fills quickly after Level Load .

Someone has a suggestion where I should start?

Re: compiler and memory usage [Re: HenWoll] #466503
06/18/17 21:33
06/18/17 21:33
Joined: Dec 2011
Posts: 1,823
Netherlands
Reconnoiter Offline OP
Serious User
Reconnoiter  Offline OP
Serious User

Joined: Dec 2011
Posts: 1,823
Netherlands
Originally Posted By: BlackJack
Now, however i can only Maximum change to 2 level,s after this i become the Error E1513, In the most diverse varieties!

The levels individually can be run and error-free, only that my video memory fills quickly after Level Load .

Someone has a suggestion where I should start?
, perhaps it some texture(s) that is not freed by level_load (bmap_create and/or extra panels?). If yes, try bmap_purge / ptr_remove them. I think I can keep loading quite big (in terms of memory) levels but I mostly use entities so they get automatically purged. My panels are currently mostly placeholder tiles and I dont think I really use bmap_create except for some initialization of some icons. I quess its something bmap / bmap_create related. Perhaps also try debugging with sys_marker incase you already haven't.

Also d3d_texdepth = 16; helps (but not for memory leaks ofcourse).

Last edited by Reconnoiter; 06/18/17 21:35.
Re: compiler and memory usage [Re: Reconnoiter] #466519
06/19/17 09:33
06/19/17 09:33
Joined: Jul 2000
Posts: 27,977
Frankfurt
jcl Offline

Chief Engineer
jcl  Offline

Chief Engineer

Joined: Jul 2000
Posts: 27,977
Frankfurt
Ok, I've checked your example. The compiled code size is not 980 MB, but about 10 MB. This is indeed a problem, since the compiler first compiles the script to an interim code and then to the final machine code. The interim code can be much larger than the machine code, up to factor 30. The compiler also allocates all sorts of additional data structures since it's made for speed, not for memory preservation. All this inflates the memory allocation at compile time to a large multiple of the original code size.

When the script is then run afterwards, some of the memory is freed, but a large part stays allocated for the purpose of debugging and accessing variables. Only when the script is compiled to a published exe and then executed, that memory is not allocated.

There's certainly room for optimization since I think 90% of the allocated memory by the compiler is not needed at runtime. But that's how it works at the moment.


Re: compiler and memory usage [Re: jcl] #466566
06/21/17 13:43
06/21/17 13:43
Joined: Sep 2003
Posts: 6,861
Kiel (Germany)
Superku Offline
Senior Expert
Superku  Offline
Senior Expert

Joined: Sep 2003
Posts: 6,861
Kiel (Germany)
Thanks for looking into it.

Originally Posted By: jcl
a large part stays allocated for the purpose of debugging and accessing variables

Is that for the "Debug run" in SED (only)? If so, could that be optionally skipped/ excluded from the acknex build for "Run current script"/ "Test run"?
I actually never use the "Debug run" as it for some reason never worked for me. When I see its features I should probably have dug more into it. If that (quote) includes stuff like sys_marker, sys_malloc and so on it has definitely got to stay though.

Originally Posted By: jcl
There's certainly room for optimization since I think 90% of the allocated memory by the compiler is not needed at runtime. But that's how it works at the moment.

Ok, glad that this memory mystery is finally solved! Would be nice if this could be improved/ done some time in the future as it's such a big issue for non-published test runs.

Last edited by Superku; 06/21/17 13:45.

"Falls das Resultat nicht einfach nur dermassen gut aussieht, sollten Sie nochmal von vorn anfangen..." - Manual

Check out my new game: Pogostuck: Rage With Your Friends
Page 7 of 10 1 2 5 6 7 8 9 10

Moderated by  old_bill, Tobias 

Gamestudio download | chip programmers | Zorro platform | shop | Data Protection Policy

oP group Germany GmbH | Birkenstr. 25-27 | 63549 Ronneburg / Germany | info (at) opgroup.de

Powered by UBB.threads™ PHP Forum Software 7.7.1