Gamestudio Links
Zorro Links
Newest Posts
hold key code returns very high value instead of 0 or 1
by 3run
Today at 16:08
oldschool fps project
by 3run
Today at 15:46
Sam Foster Sound | Experienced Indie Game Composer for Hire
by titanicpiano14
Today at 15:02
Project Aum - Winter Contest 2017 - Update
by Ayumi
Yesterday at 22:34
[ALL STYLES] 2D Videogame Artist (pixel, vector, painted)
by DesixStudios
Yesterday at 14:45
Easy question
by jcl
Yesterday at 13:47
Cheap bouncing shells/gibs
by 3run
Yesterday at 00:36
AUM Magazine
Latest Screens
RPG PARTY
Triton Wing now available on Steam
AckCon'17: Lotter vs The World
Triton Wing
Who's Online
17 registered (Ch40zzC0d3r, Ezzett, Lobo, Hredot, AndrewAMD, 3run, alibaba, ChrstphFr, firecrest, 2 invisible), 454 Guests and 5 Spiders online.
Key: Admin, Global Mod, Mod
Newest Members
Amocfx, cme, pataba, byano, Tuguldur717
17834 Registered Users
Page 7 of 8 < 1 2 3 4 5 6 7 8 >
Topic Options
Rate This Topic
#466440 - 06/14/17 11:55 Re: compiler and memory usage [Re: Superku]
jcl Online

Chief Engineer

Registered: 07/22/00
Posts: 26002
Loc: 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.

Top
#466441 - 06/14/17 12:32 Re: compiler and memory usage [Re: jcl]
Superku Offline
Senior Expert

Registered: 09/13/03
Posts: 6614
Loc: 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

Superku side-scroller: ~98.5% (??????!??)

Steam® Store Page ("Coming Soon"): http://store.steampowered.com/app/407570 Wowowowow!

Top
#466446 - 06/14/17 18:40 Re: compiler and memory usage [Re: Superku]
jcl Online

Chief Engineer

Registered: 07/22/00
Posts: 26002
Loc: Frankfurt
How about static data structures in your code? Large global arrays? Nexus? The compiler also allocates memory for them.

Top
#466453 - 06/14/17 22:40 Re: compiler and memory usage [Re: jcl]
Superku Offline
Senior Expert

Registered: 09/13/03
Posts: 6614
Loc: 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

Superku side-scroller: ~98.5% (??????!??)

Steam® Store Page ("Coming Soon"): http://store.steampowered.com/app/407570 Wowowowow!

Top
#466485 - 06/16/17 17:20 Re: compiler and memory usage [Re: Superku]
jcl Online

Chief Engineer

Registered: 07/22/00
Posts: 26002
Loc: Frankfurt
I don't know. But I'll check your example in the next days and will look into it.

Top
#466494 - 06/17/17 12:24 Re: compiler and memory usage [Re: jcl]
Superku Offline
Senior Expert

Registered: 09/13/03
Posts: 6614
Loc: Kiel (Germany)
Thanks, looking forward to your findings!
_________________________
"Falls das Resultat nicht einfach nur dermassen gut aussieht, sollten Sie nochmal von vorn anfangen..." - Manual

Superku side-scroller: ~98.5% (??????!??)

Steam® Store Page ("Coming Soon"): http://store.steampowered.com/app/407570 Wowowowow!

Top
#466497 - 06/18/17 11:52 Re: compiler and memory usage [Re: Superku]
BlackJack Offline
Member

Registered: 02/10/11
Posts: 111
Loc: 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?

Top
#466503 - 06/18/17 23:33 Re: compiler and memory usage [Re: BlackJack]
Reconnoiter Offline
Serious User

Registered: 12/26/11
Posts: 1781
Loc: 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).


Edited by Reconnoiter (06/18/17 23:35)

Top
#466519 - 06/19/17 11:33 Re: compiler and memory usage [Re: Reconnoiter]
jcl Online

Chief Engineer

Registered: 07/22/00
Posts: 26002
Loc: 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.


Top
#466566 - 06/21/17 15:43 Re: compiler and memory usage [Re: jcl]
Superku Offline
Senior Expert

Registered: 09/13/03
Posts: 6614
Loc: 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.


Edited by Superku (06/21/17 15:45)
_________________________
"Falls das Resultat nicht einfach nur dermassen gut aussieht, sollten Sie nochmal von vorn anfangen..." - Manual

Superku side-scroller: ~98.5% (??????!??)

Steam® Store Page ("Coming Soon"): http://store.steampowered.com/app/407570 Wowowowow!

Top
Page 7 of 8 < 1 2 3 4 5 6 7 8 >


Moderator:  elsewood, old_bill, Tobias 

Gamestudio download | chip programmers | Zorro platform | shop | resources | magazine | manual | support faq | bugs

oP group Germany GmbH | Birkenstr. 25-27 | 63549 Ronneburg / Germany | info (at) 3dgamestudio.net