video memory and d3d_texfree

Posted By: Reconnoiter

video memory and d3d_texfree - 03/15/17 19:49

Hello,

I am developing my game on a laptop with a 840m gpu which has 2 gb ddr3 video memory (http://www.notebookcheck.net/NVIDIA-GeForce-840M.105681.0.html).
When I check d3d_texfree in my current game project, I seem to have alot of video memory free (on startup its something like 4095 and than goes to circa 3100). Except when I am nearing circa 3100 it eventually gives error messages when I am placing more models in the map with fairly big textures (2048x2048 with normal maps too). (It does not seem to be related to a specific model or texture).

The error message -> "Error E2005 - Can't create D3D texture
The texture format is invalid or unsupported by your video card. Very old video cards often don't support DirectX 9 and can not create textures of the given size or format."

So how come I get these messages when d3d_texfree seem to show that I have still enough free video memory?
Thanks for taking the time.
Posted By: Reconnoiter

Re: video memory and d3d_texfree - 03/25/17 16:55

Nothing? eek
Posted By: Iglarion

Re: video memory and d3d_texfree - 03/28/17 23:24

Unfortunately i also have this problem with randomly geting e2005 error and i really stuck with this. First i think that problem was in textures but after converting all textures today i got again this error.

Why this error/crash appear randomly, and how i can be sure that texture is problem? For example i just now get error where i can see some untextured model on screen and now i know exactly what is suspicious texture (it's an tga texture 2048x2048x32). This is first time that this texture is problem. A big problem is i need to play my game almost one hour to reach this crash.



Manual say that old video cards can't support some texture size, but i have a modern gpu (GTX 1060)and this should not be a problem. Any idea what else can make this crash, could it be possible that this is a engine bug beacuse i don't know what is wrong with this texture?
Only what i can try now is resize all textures to 1024 dds and wait did crash will appear again.
Posted By: Dooley

Re: video memory and d3d_texfree - 03/30/17 05:04

I'm having the same problem. Sometimes it mentions the "Can't create D3D texture" and sometimes it just says "Out of Memory."

I will be looking into this over the next few day (or weeks). I will definitely post my findings here, if I figure anything out...
Posted By: Superku

Re: video memory and d3d_texfree - 03/30/17 15:00

I sometimes get this error too when I switch resolutions (video_set) and it's worrying me.
I have more than enough free memory, my game doesn't use that much texture memory anyway (the memory for post processing stages is probably a big chunk of it). I only use TGA files or bmap_createblack images.

I had it all (deactivating render stages, switching resolutions, freeing memory and allocating textures for the new screen size) logged into acklog.txt and a console but can't seem to find any of those logs right now. Will report and come back here when I have more information to share.
Posted By: Ch40zzC0d3r

Re: video memory and d3d_texfree - 03/30/17 16:41

I also worked alot on this problem and I simply couldnt find a real fix.
It usually worked using dds textures which are compressed and damn small
Posted By: Dooley

Re: video memory and d3d_texfree - 03/30/17 16:44

I was able to solve it (I hope) by reducing a bunch of texture sizes. Whether the problem will reappear after extended play sessions is still a concern for me, but it's much more stable than it was before.

One thing I realized is that I could reduce the size of my normal maps without impacting the appearance as much.

I'm not sure what metric to use as far as how much texture size I can use, what's the limit, etc... it would be nice to have a specific number that we can make sure we stay under. Of course it would vary depending on video card, computer memory, nexus, etc...

I think this all falls under optimizing the game. I'm guessing that big name games have all sorts of tricks and methods of getting really big textures on screen seamlessly. Reduce, reuse, recycle ... that sort of thing.
Posted By: Dooley

Re: video memory and d3d_texfree - 03/30/17 16:46

Oh, also, I'm using bitmaps mainly. I have read that dds is better for performance, so maybe I can get some texture size back if I switch over?
Posted By: Reconnoiter

Re: video memory and d3d_texfree - 03/31/17 11:02

Quote:
Manual say that old video cards can't support some texture size, but i have a modern gpu (GTX 1060)and this should not be a problem. Any idea what else can make this crash, could it be possible that this is a engine bug beacuse i don't know what is wrong with this texture?
, I dont think your videocard is the bottleneck, but its the 32 bit Acknex engine I guess.

Quote:
I sometimes get this error too when I switch resolutions (video_set) and it's worrying me.
, I am not sure but perhaps higher video resolutions use more ram? Like they always say that for 4k or VR you need alot of ram.

Quote:
I had it all (deactivating render stages, switching resolutions, freeing memory and allocating textures for the new screen size) logged into acklog.txt and a console but can't seem to find any of those logs right now. Will report and come back here when I have more information to share.
, that would be helpful ty.

Quote:
I also worked alot on this problem and I simply couldnt find a real fix.
It usually worked using dds textures which are compressed and damn small
, tnx for the info, they seem to be the way to go when lossless/perfect image is not important. Though with .dds you cannot read the texture pixels right? (I am using pixel_for_bmap and pixel_to_bmap for a few things)

Quote:
One thing I realized is that I could reduce the size of my normal maps without impacting the appearance as much.
, reducing normal maps indeed helps, I did that for e.g. terrain where the difference in loss is not that noticeable.

The 'free mb' in the f11/diag window gives the same values as d3d_texfree. I noticed that when that gives e.g. 3667 (for a small intro map) in windows task manager it shows that Acknex uses 635 mb. For another map the d3d_texfree/free mb was something like ~3340 and in task manager Acknex used ~1620 mb (which is about the highest I can let Acknex get before I get that error again). There seem to be some difference between these values but I dont fully understand why.
I also tried setting nexus to e.g. 200 in Sed preferences but that doesn't seem to help either.
I did notice that other 32 bit programs like e.g. jasc paint shop pro also that that limit of ~1650 mb. While 64 bit corel paint shop pro can go much futher to e.g. somethig like >5600 mb in the task manager.
So checking task manager is probably the most reliable way to check if the game uses much ram.

I am personally using mostly .bmp. While the textures are not that high (with 2048x2048 as a max), I guess stuff like normal maps and shadow maps for lights double/triple their memory usage. In my game editor that doesn't use these shaders I could place alot more stuff (still not that much though).

So just keep to small maps than? Or maybe ent_purge some stuff (like terrain or buildings) when not visible? (though that does give a bit of lag when backtracking etc within maps...)
Posted By: Iglarion

Re: video memory and d3d_texfree - 03/31/17 13:09

Converting textures to DDS reduces the risk of a geting e2005 error, but i'm afraid this will not completely eliminate crash, and it's worrying me. I'll look deeper into this problem in the coming days and sure i'll let you know if i come up with some new information.
The most worrying thing is that the more people who have a lot of experience with Acknex has this problem.
Posted By: Dooley

Re: video memory and d3d_texfree - 04/09/17 23:34

I would try making a backup copy of your game, and reducing all textures by half, i.e. 2048 to 1024, 1024 to 512, etc...

This way, you can see if the problem is fixed, and also see if you can live with the smaller texture sizes. I was not thrilled to reduce all my texture sizes, but it's better than having the game crash.

Also, I believe you can go up to 500 with your nexus. I know the manual recommends keeping it lower, but I think that was written a long time ago... this could give you some extra needed memory.
Posted By: Superku

Re: video memory and d3d_texfree - 04/10/17 10:45

I don't think the issue really lies with big textures.
I barely use any (less than 128MB maybe) in my game, have near unlimited RAM and VRAM and yet it still crashes with DirectX errors, right now more than ever (which is not a bad thing for debugging).
There is something wrong with this engine I fear, I wish it was a user problem.

EDIT: The error:
Quote:
Error E2005: Can't create DirectX texture unnamed
D3D_TexCreate: 8007000e - E_OUTOFMEMORY


How is "unnamed" set (or not set), could you, Mr. Lotter, use that field to add debugging information?
Posted By: jcl

Re: video memory and d3d_texfree - 04/10/17 14:03

We did not make DirectX, so I can not comment on why it thinks that it has not enough memory. "Unnamed" means that it could not be determined when and how this texture was created. Otherwise you would see the name of the texture or object it belonged to.
Posted By: Reconnoiter

Re: video memory and d3d_texfree - 04/10/17 16:15

@Iglarion, your game is a sidescroller right? Have you tried ent_purge big models/textures that the player has passed?

@Superku, how much memory does task manager say your game/project is using?
Maybe you can debug your problem with dx debug runtime;
https://www.microsoft.com/en-us/download/details.aspx?id=6812
https://msdn.microsoft.com/en-us/library/windows/desktop/bb173355(v=vs.85).aspx
https://legalizeadulthood.wordpress.com/2009/06/28/direct3d-programming-tip-5-use-the-debug-runtime/

Originally Posted By: Dooley

Also, I believe you can go up to 500 with your nexus. I know the manual recommends keeping it lower, but I think that was written a long time ago... this could give you some extra needed memory.
, this does not seem to work for me (maybe because I dont use blocks but only models in my maps/.wmb). Cutting all normal maps in half is so far the best one for me since it doesn't decrease visual quality much. Also I noticed that Shade-C uses a noticeable amount of extra memory (probably for shadowmaps etc).

I found this quote also informative:
Quote:

In case you're not familar with address space starvation, on a 32-bit operating system, each executable has 4GB of address space to use, between 0x00000000 and 0xffffffff. The top 2GB is reserved by the operating system, some address ranges are reserved (E.g. the low 64KB (I think? Maybe more?)), and the EXE file and all the various system DLLs loaded into the process usually means that a single application has around 1GB to 1.5GB of free space to use for the heap (At most, the address space could be fragmented meaning there's not one contiguous chunk of memory that size).
(https://www.gamedev.net/topic/616046-d3dxcreatecubetexture-fails-with-e-outofmemory/)

Lastly found another A8 developer that had this problem to and solved it (maybe it helps):
https://steamcommunity.com/app/336200/discussions/0/618453594750526027/
Posted By: Superku

Re: video memory and d3d_texfree - 04/10/17 19:00

It's at 1066MB in development mode and 232MB in a published build (which temporarily goes up to 296MB for 5+ seconds after changing resolutions on 1920x1080, which is a tad strange IMO).

That DirectX SDK/ debugger stuff sounds like a good idea, too bad this does not work on Win7 SP1, Win 8 and Win 10 though. -.- It's just not supported anymore.

EDIT: Uhh, got it running on an old laptop but there the crash has not happened so far - obviously.
EDIT2: Activating the debug version of DirectX 9 results in a different error, usually related to outdated DirectX versions (apparently):
Quote:
D3D_DrawPrimitive: D3DERR_INVALIDCALL
D3D_DrawPrimitive: D3DERR_INVALIDCALL 0 lmaps 0 textures
D3D_DrawPrimitive: D3DERR_INVALIDCALL
Malfunction W1246: DirectX driver failure: D3DERR_INVALIDCALL...ok
LevelReady at 214.750

(listed as E1246 in the manual)
Posted By: Superku

Re: video memory and d3d_texfree - 04/11/17 14:47

When I set the nexus to 200+ MB in the SED command line parameters, my game crashes pretty much every time I switch resolutions (1920x1080ish) with
Error E2005: Can't create DirectX texture unnamed.
With a nexus of 300 I get that error message before loading the first real level or the menu.
With a nexus of < 150MB it seems to be working for a while. Still got the error message with a similar or lower nexus after playing for 20+minutes on my laptop a couple of days ago, on a published build.

The RAM usage shows pretty much the same value (~1055MB), both for a nexus of 150MB and 250MB. Does that make sense?
Posted By: Iglarion

Re: video memory and d3d_texfree - 04/11/17 19:03

Originally Posted By: Reconnoiter
@Iglarion, your game is a sidescroller right? Have you tried ent_purge big models/textures that the player has passed?
My game has multiple views, and i already use ent_purage on the few places where this is possible.

I haven't yet had a time to play my game a little longer time to check whether the error still occurs, currently i prepare complete game for this beacuse i need almost one+ hour to reach crash and before test i want to go once again through all suspicious parts. First i must see when exactly the e2005 occurs and where. I just found my topic from the year 2013 when i have the same problem but without any error message. It seems that the issue is only reduced after converting textures to DDS, but is still here. The RAM usage for my game is 1280MB in development mode and i try to keep all things as simple as possible - lowpoly models, extern dds textures 512 and 1024 and just five 2048 for terrain colormap and shadowmap.

Error "Can't create DirectX texture unnamed" in my case also happens only after switch resolution.

Error "Can't create DirectX texture skin(number)" appear after i pass trought many of my levels and at begining of new loaded level.

The part that scares me is that Superku not used at all too much video memory, and especially Starlaxis, and the question is how much reducing memory consumption can help in my game. Maybe we also should contact the author of Starlaxis and see if his update actually removed e2005 error from his game and what was the problem. I also afraid there is something wrong with engine and if this is the truth it will be very difficult for us to isolate this error for support.
Posted By: Superku

Re: video memory and d3d_texfree - 04/11/17 21:49

Given the severity of this issue and that rather many users and their game projects are experiencing this, I think the best solution or rather approach right now would be a dedicated unofficial A8 release for testing.
IMO this should only include logging or stuff like that, not any other change (fix) for now.

Forgive my DirectX (and general) noobiness but could you, Mr. Lotter, add logging to the texture creation in some way or another?
I did that for all my bmap_create[black] instructions with a macro but that obviously does not help where we don't have access to the CreateTexture calls or whatever it is (like for engine intern postprocessing bitmaps or on entity creation or level (texture) loading).

Could you maybe even output information like a stack trace (?) or data like free remaining memory when such a DirectX call fails?
Even if that A8 test version was a lot slower it would be a great relief to have this issue finally isolated.
Thanks.
Posted By: Reconnoiter

Re: video memory and d3d_texfree - 04/13/17 20:34

@Iglarion, yeah contacting Starlaxis dev is a good idea.

@Superku, could try setting this d3d_texdepth = 16; before level loading? (so e.g. in your main function)

I tried that and it saved me ~25% video memory without noticeable losses so far (not sure if its important but my maps only have models and not blocks).

Quote:
The RAM usage shows pretty much the same value (~1055MB), both for a nexus of 150MB and 250MB. Does that make sense?
, from what I read every 32 app that uses above 1 gb ram could technically give the error if the engine or used dll's etc use alot or there is to little ram and/or video ram in the computer itself. Maybe you use many plugins or such? Also the nexus does not seem make any difference for me too, I think it only matters for loading big maps with lots of blocks and wad textures or perhaps with big terrain shadow/light maps etc.
Posted By: Ch40zzC0d3r

Re: video memory and d3d_texfree - 04/13/17 20:40

x86 processes can only take a maximum of 2gb ram if the app wasnt compiled with a special flag (/LARGEADDRESSAWARE) which allows to address up to 4gb ram.
Posted By: Reconnoiter

Re: video memory and d3d_texfree - 04/13/17 20:43

Originally Posted By: Ch40zzC0d3r
x86 processes can only take a maximum of 2gb ram if the app wasnt compiled with a special flag (/LARGEADDRESSAWARE) which allows to address up to 4gb ram.
, maybe its possible to enforce that flag?
Posted By: Iglarion

Re: video memory and d3d_texfree - 04/13/17 22:26

Originally Posted By: Reconnoiter
Originally Posted By: Ch40zzC0d3r
x86 processes can only take a maximum of 2gb ram if the app wasnt compiled with a special flag (/LARGEADDRESSAWARE) which allows to address up to 4gb ram.
, maybe its possible to enforce that flag?

But we here talking about out of memory problem if game use just 1GB, so something is definitely wrong here. I agre with Superku idea about one unofficial relase for us who have this problem. I just hope is possible to put some extra debuging in engine to finally isolate the problem.
Jcl what do you think about this did you can help somehow? I really understand it's very difficult without enough information and test project say something more, but do you have any advice on what we should pay attention to find reason of this error.
Too many people with a completely different games have this problem, but none of us has any idea why this is happening.
Posted By: Superku

Re: video memory and d3d_texfree - 04/14/17 09:46

Originally Posted By: Reconnoiter
@Superku, could try setting this d3d_texdepth = 16; before level loading? (so e.g. in your main function)

Never tried that but I'm not trying to avoid this error message, I'm trying to isolate (and indirectly fix) that bug or error.
As I've said the game even gave me the DirectX error on my laptop (8GB RAM) while using less than 300 MB according to the task manager.
Trying to avoid that error by various measures is not helping, it's rather counterproductive IMO.
Posted By: jcl

Re: video memory and d3d_texfree - 04/21/17 16:09

Large address aware linking won't help with video memory issues.

But can't you just check and print the d3d_tex... variables in several steps during initialization of your game? This should tell you where the problem is. Maybe some particularly large textures.
Posted By: Superku

Re: video memory and d3d_texfree - 04/22/17 01:52

Code:
///////////////////////////////
#include <acknex.h>
#include <default.c>
///////////////////////////////

void main()
{
	fps_max = 60;
	video_mode = 6;
	camera.stage = view_create(0);
	set(camera.stage,PROCESS_TARGET);
	level_load(NULL);
	me = ent_create(CUBE_MDL,vector(128,0,0),NULL);
	var videoSwitchCounter = 32;
	var videoSwitchMode = 8;
	while(1)
	{
		my.pan += 6*time_step;
		draw_text(str_printf(NULL,"d3d_texbmaps: %.1f",(double)d3d_texbmaps),20,20,COLOR_WHITE);

		videoSwitchCounter = maxv(videoSwitchCounter-time_step,0);
		if(!videoSwitchCounter)
		{
			videoSwitchCounter = 16;
			videoSwitchMode++;
			if(videoSwitchMode > 12) videoSwitchMode = 8;
			video_switch(videoSwitchMode,0,2);
		}
		wait(1);
	}
}



d3d_texbmaps rises continuously (except a small bump going from highest to lowest resolution). Let a similar more resource heavy test run until > 65GB.
Does that make sense? Is this just a bug with the variable d3d_texbmaps (like that one nexus variable bug) or something else with the memory allocation for the post processing stage (target)?
Posted By: alibaba

Re: video memory and d3d_texfree - 04/22/17 08:33

I can confirm this behaviour
Posted By: jcl

Re: video memory and d3d_texfree - 04/24/17 12:05

d3d_texbmaps is indeed not reduced by releasing the old textures when switching the resolution. I have put this on the bug list. But you should still be able to find the problem this way when you don't change the resolution.
Posted By: Superku

Re: video memory and d3d_texfree - 04/24/17 15:01

Originally Posted By: jcl
But can't you just check and print the d3d_tex... variables in several steps during initialization of your game? This should tell you where the problem is. Maybe some particularly large textures.
[...]
But you should still be able to find the problem this way when you don't change the resolution.

I'm sorry but I don't really understand how. Here's the IMO relevant part of the acklog just created:

Code:
Video memory found: 4094 MB

main_event() at frame 4... (nexus: 31.7/ 150.0) (sys_memory: 219.3) (d3d_texfree: 4072.0) (d3d_texbmaps: 1.0) (d3d_texskins: 0.0) (d3d_texsmaps: 0.0) (d3d_texsurfs: 0.0).


create_rendertargets() START at frame 17... (nexus: 35.8/ 150.0) (sys_memory: 219.3) (d3d_texfree: 4071.0) (d3d_texlimit: 8192.0) (d3d_texbmaps: 1.0) (d3d_texskins: 0.0) (d3d_texsmaps: 0.0) (d3d_texsurfs: 0.0)
bmap_createblackDEBUG(1920,1080,24)...DONE. (CAMTARG1, d3d_texbmaps: 1.0)
bmap_createblackDEBUG(1920,1080,24)...DONE. (KUREF, d3d_texbmaps: 1.0)
bmap_createblackDEBUG(1920,1080,24)...DONE. (REFRAC, d3d_texbmaps: 1.0)
bmap_createblackDEBUG(1920,1080,24)...DONE. (CAMBMAP, d3d_texbmaps: 1.0)
bmap_createblackDEBUG(960,540,24)...DONE. (COMBINE, d3d_texbmaps: 1.0)
bmap_createblackDEBUG(480,270,24)...DONE. (BLOOM2, d3d_texbmaps: 1.0)
bmap_createblackDEBUG(1920,1080,24)...DONE. (COMBINE2, d3d_texbmaps: 1.0)
bmap_createblackDEBUG(1920,1080,24)...DONE. (LOADDISPLAY, d3d_texbmaps: 1.0)DONE
MEMORY NOW (after all bmap creations): (nexus: 35.8/ 150.0) (sys_memory: 219.3) (d3d_texfree: 4071.0) (d3d_texlimit: 8192.0) (d3d_texbmaps: 1.0) (d3d_texskins: 0.0) (d3d_texsmaps: 0.0) (d3d_texsurfs: 0.0) (sum: 1.0MB)

level_load(NULL)

main_event() at frame 20... (nexus: 42.8/ 150.0) (sys_memory: 219.4) (d3d_texfree: 4071.0) (d3d_texbmaps: 26.0) (d3d_texskins: 0.0) (d3d_texsmaps: 0.0) (d3d_texsurfs: 0.0)
main_event() at frame 21... (nexus: 42.8/ 150.0) (sys_memory: 219.4) (d3d_texfree: 4045.0) (d3d_texbmaps: 111.3) (d3d_texskins: 0.0) (d3d_texsmaps: 0.0) (d3d_texsurfs: 0.0)
main_event() at frame 22... (nexus: 42.8/ 150.0) (sys_memory: 219.4) (d3d_texfree: 3993.0) (d3d_texbmaps: 111.3) (d3d_texskins: 0.0) (d3d_texsmaps: 0.0) (d3d_texsurfs: 0.0)

level_load(...)

main_event() at frame 57... (nexus: 61.2/ 150.0) (sys_memory: 219.4) (d3d_texfree: 3993.0) (d3d_texbmaps: 111.3) (d3d_texskins: 0.0) (d3d_texsmaps: 0.4) (d3d_texsurfs: 0.1)

// now playing the game normally, task manager RAM usage at 1060MB
main_event() at frame 394... (nexus: 64.0/ 150.0) (sys_memory: 219.4) (d3d_texfree: 3962.0) (d3d_texbmaps: 127.5) (d3d_texskins: 4.5) (d3d_texsmaps: 0.4) (d3d_texsurfs: 0.1)


All values are the same as they used to be, right now it doesn't crash though. I had the d3d_... stuff in place before when it was crashing every time, did not see anything unusual there.
I don't think I've even added a single new texture or changed an old one (in size), just stuff in the code.

This cannot be "another" compiler related issue like in some past bug hunts where changing stuff in the code lead to crashes (mostly on MDL loading I think), right?
Posted By: jcl

Re: video memory and d3d_texfree - 04/24/17 16:17

If you mean with "crashing" not having enough video memory, then no, this is not caused by the compiler. The compiler translates C to machine language. It has nothing to do with your video memory.

However, I've meanwhile looked through some developer forums and it seems that E_OUTOFMEMORY can also happen when in fact video memory is still available. The object creation failed then for a different reason, for instance when the required format is not available or the system memory runs low. So we can not trust that E_OUTOFMEMORY always means that the 4 GB video memory are used up.
Posted By: Superku

Re: video memory and d3d_texfree - 04/24/17 16:32

Yes, sorry, I meant the old

"Error E2005: Can't create DirectX texture unnamed
D3D_TexCreate: 8007000e - E_OUTOFMEMORY"

message. Got this message again 15min ago after switching resolutions a couple of times.
However, I noticed I can continue playing after closing all of these messages. In fact, depending on the size of the resolution I get 0, 1 (just once) or 8 E_OUTOFMEMORY errors which is the number of newly (re-)allocated render targets.
The error messages appear at the end of the frame (esp. after all bmap_createblack(DEBUG) calls in the log above and after MEMORY NOW).
I had added a GetAvailableTextureMem() call after my previous post. It returned (GetAvailableTextureMem: 4278190080) before the D3D messages.

What can I do or try next?

EDIT: The ninja edit! ->
Originally Posted By: jcl
However, I've meanwhile looked through some developer forums and it seems that E_OUTOFMEMORY can also happen when in fact memory is still available. [...]

After closing all of the E_OUTOFMEMORY errors it seems like I can continue playing normally with my render chain still in tact. The bitmap pointers all have received new and non-zero addresses, too.
Posted By: jcl

Re: video memory and d3d_texfree - 04/24/17 16:38

If you have a script that reliably produces an E_OUTOFMEMORY error, like your d3d_texbmaps script above, post it and I'll look into it. I can then at least identify with which texture or other object it happened.
Posted By: Superku

Re: video memory and d3d_texfree - 04/24/17 19:33

Uhh... I'm not sure what I'm doing and what those values mean exactly but I've tried a program called VMMap (which I found in some non-Gamestudio thread looking for E_OUTOFMEMORY) and looked at my game's (process's) address space ~ I guess.

Committed: This graph shows the committed (memory that represents data or code) memory usage of the process: 1.402GB

Working Set: This graph shows the working set usage of the process by memory type. Working set represents the amount of commited virtual memory that's in physical memory and owned by the process: 1.120GB

Summary of the virtual and physical usage of the process by type (like Image, Mapped File, Heap, Private Data, ...), "Total": 1.845GB

RAM usage according to the task manager: 1.050GB



When I now change the resolution (from 1920x1080 to 1600x1050), memory for the render targets is reallocated. I read somewhere that DirectX does not flush (?) memory immediately on "release", instead you need to flush the data manually if you really need to (let's say when you're low on memory). I get the standard E2005.
The values are now as follows: 1.489, 1.153, 1.920, 1.079GB. The second to last value looks a little alarming to me (esp. if contiguous or fragmented memory is important in this case, which I assume it is).
The acklog part (after all bmap_create instructions are done):
Quote:
MEMORY NOW (after all bmap creations): (nexus: 63.5/ 150.0) (sys_memory: 210.7) (d3d_texfree: 3963.0) (d3d_texlimit: 8192.0) (d3d_texbmaps: 73.7) (d3d_texskins: 4.3) (d3d_texsmaps: 1.7) (d3d_texsurfs: 0.1) (sum: 79.7MB) (GetAvailableTextureMem: 4280287232)
Error E2005: Can't create DirectX texture unnamed
D3D_TexCreate: 8007000e - E_OUTOFMEMORY



Is that one value, the "summary/ total" value the one that matters? And the RAM usage in the task manager "totally irrelevant"?
To make sure this is not project related (or because of a damaged file):
Click to reveal..
Code:
///////////////////////////////
#include <acknex.h>
#include <default.c>
///////////////////////////////

#define MAX_BMAPS 196 // start with the default nexus/ "run current script"
BMAP* test_bmps[MAX_BMAPS];

#define EXTRA_BMAPS 1
BMAP* extra_bmps[EXTRA_BMAPS];

#define MAX_VIEWS 64
MATERIAL* mat_chain[MAX_VIEWS];
VIEW* view_chain[MAX_VIEWS];

void createExtraBmaps()
{
	int i;
	for(i = 0; i < EXTRA_BMAPS; i++) extra_bmps[i] = bmap_create("test8MB.tga");
}

void switchResolution()
{
	video_mode = 10+(video_mode == 10);
	video_switch(video_mode,0,2);
}

void main()
{
	int i;
	fps_max = 60;
	video_mode = 6;
	level_load(NULL);
	me = ent_create(CUBE_MDL,vector(128,0,0),NULL);
	for(i = 0; i < MAX_BMAPS; i++) test_bmps[i] = bmap_create("test8MB.tga");
	
	wait(1);
	VIEW* view_prev = camera;
	for(i = 0; i < MAX_VIEWS; i++)
	{
		//mat_chain[i] = mtl_create();
		//effect_load(mat_chain[i],"blur_h_test.fx"); 
		
		view_chain[i] = view_create(0);
		set(view_chain[i],PROCESS_TARGET);
		//view_chain[i].material = mat_chain[i];
		//if(i < MAX_VIEWS-1) view_chain[i].bmap = bmap_createblack(screen_size.x,screen_size.x,24);
		
		view_prev.stage = view_chain[i];
		view_prev = view_chain[i];
	}
	on_1 = createExtraBmaps;
	on_space = switchResolution;
	while(1)
	{
		my.pan += 6*time_step;
		draw_text(str_printf(NULL,"sys_memory: %.1f",(double)sys_memory),20,20,COLOR_RED);
		draw_text(str_printf(NULL,"d3d_texbmaps: %.1f",(double)d3d_texbmaps),20,40,COLOR_RED);
		wait(1);
	}
}


There I create a ton of 2048x1024 (8+MB) textures to get the RAM usage above 1.6GB and the "summary/ total" value > 1.9GB. When I now press [Space] twice, E2005 happens. (Which seems somewhat reasonable to me that it errors here, except the difference of 600MB -task manager- compared to my real project.) Btw. if you just add additional bitmaps (with the createExtraBmaps()) function you get a (probably legit)
Error E1005: Out of memory.
Posted By: jcl

Re: video memory and d3d_texfree - 04/25/17 08:40

I get no error with your script regardless of how often I press space, which indicates that it might be something different than insufficient memory. Maybe a certain render target size or format is not supported by your hardware.

For finding out, print GetAvailableTextureMem(). d3d_texfree works also, but is only updated once per frame. If it's really a video memory issue, GetAvailableTextureMem() should return a low value immediately before the error. If not, it's a system memory issue or something different.

Released memory is indeed not immediately flushed, but that should not be the problem since D3D has a memory manager.
Posted By: Superku

Re: video memory and d3d_texfree - 04/25/17 10:00

Originally Posted By: jcl
I get no error with your script regardless of how often I press space

Hmmm just tried it again and no error at first. However, I increased MAX_BMAPS gradually until I got an "Out of memory" error at start, then reduced it again (to 202) so it only gave me the DirectX error when pressing space. (Oh, it's a 32bit texture btw, 8.193MB.)

Originally Posted By: jcl
Maybe a certain render target size or format is not supported by your hardware.

Well those usually all work, no matter what I set the target to, except when there's a notable amount of stuff loaded into memory.

Originally Posted By: jcl
For finding out, print GetAvailableTextureMem(). d3d_texfree works also, but is only updated once per frame. If it's really a video memory issue, GetAvailableTextureMem() should return a low value immediately before the error. If not, it's something different.

Tried doing that as you can see in my previous post. The lowest value I ever got was still greater than 4.1GB. EDIT: Tried printing before and after manual bmap creation (not applicable in this test code), at the end of a frame and on_d3d_lost, on_d3d_reset).
Posted By: jcl

Re: video memory and d3d_texfree - 04/25/17 15:21

8 MB * 202 = 1.6 GB without mipmaps. So it the 4.1 GB can obviously not be right. Did GetAvailableTextureMem return 2.4 GB before the crash?
Posted By: Superku

Re: video memory and d3d_texfree - 04/25/17 23:55

Well I have 8GB of VRAM, not sure how that would work then. Therefore I've now grabbed my laptop with an Intel HD Graphics 5500, 3839MB shared system memory ("Gemeinsam genutzter Systemspeicher") - hopefully that doesn't make a difference in this case.
Same issue but with MAX_BMAPS = 212. Surprisingly, GetAvailableTextureMem() shows similar values here as well, and always > 4.0GB.
"Before the crash"
I put the call in the main function again, the switchResolution function, on_d3d_lost, on_d3d_reset, always > 4.0GB with only minor differences. I must be doing something wrong.
Tbh I'm majorly confused right now what I'm looking at or checking. Just for clarification:

Quote:
UINT GetAvailableTextureMem()
The function returns an estimate of the available texture memory. Remarks: The returned value is rounded to the nearest MB.

This is not true, right? Or is it? I assumed this was in bytes, as I get values like 4278190080 (which I just interpreted as 4,278,190,080 ~ 4.278GB). This value is awfully close to 4294967294, the range of uint (took the int range -2147483648 to 2147483647 from the manual, times 2). However, there's no unsigned int in lite-C - it's 4 bytes either way, so I guess %u interprets the bytes correctly.



So... back to the example/ test code:
I moved the bitmap creation into the main function like this:
Code:
if(num_bmaps < MAX_BMAPS)
{
	test_bmps[num_bmaps] = bmap_create("test8MB.tga");
	num_bmaps++;
}


sys_memory slowy builds up with each bitmap creation up until ~1641MB. However, d3d_texfree remains the same, that is the initial
Video memory found: 4094 MB (3838MB on my laptop)
minus 2MB (the nexus/ d3d_texbmaps). It just stays at 4092MB. GetAvailableTextureMem() always returns the same value, too (laptop and desktop). It only ever changes slightly when I change resolutions.
Just removed the render chain and this is what I got:
Click to reveal..
Quote:
D3D_DrawPrimitive: D3DERR_INVALIDCALL at 0.393
switchResolution() at frame 149: (GetAvailableTextureMem: 4290772992)
D3D_Resize Window: 1440x900
on_d3d_lost_event() at frame 149: (GetAvailableTextureMem: 4291821568)
on_d3d_reset_event() at frame 149: (GetAvailableTextureMem: 4284481536) -> Window: 1x1440x900x32
D3D_DrawPrimitive: D3DERR_INVALIDCALL
switchResolution() at frame 175: (GetAvailableTextureMem: 4278190080)
D3D_Resize Window: 1680x1050
on_d3d_lost_event() at frame 175: (GetAvailableTextureMem: 4279238656)
on_d3d_reset_event() at frame 175: (GetAvailableTextureMem: 4280287232) -> Window: 1x1680x1050x32
D3D_DrawPrimitive: D3DERR_INVALIDCALL
Malfunction W1246: DirectX driver failure: D3DERR_INVALIDCALL
Error E1005: Out of memory

This may be something else though, I get the first warning immediately (after "1st frame with 4094 MB").
Posted By: jcl

Re: video memory and d3d_texfree - 04/26/17 13:13

Hmm. If GetAvailableTextureMem really returned a wrong value with your 3D card, then the error message could be correct and you're in fact exceeding the memory. What 3D card are you using? Just to be sure, can you run a simple test like this?

Code:
void main()
{
	fps_max = 60;
	video_mode = 6;
	int i;
	for(i = 0; i < 10000; i++) {
		wait(1);
		BMAP *Bmap = bmap_createblack(1048,1024,32);
		draw_quad(Bmap,vector(10,10,10),NULL,NULL,NULL,NULL,50,0);
		draw_text(str_printf(NULL,"d3d_texfree: %d MB",d3d_texfree),20,60,COLOR_RED);
	}
}



At some point this will exceed either the available video memory or the available system memory, and the texture creation will fail. Does d3d_texfree then really display still your full 4 GB?
Posted By: Superku

Re: video memory and d3d_texfree - 04/26/17 15:34

Ran the test, draw_quad makes the difference here - in your or my example code.
With draw_quad, d3d_texbmaps increases and d3d_texfree gradually decreases!
1) Desktop (GTX 1080): E2005 appears after 201 bitmaps ~ d3d_texbmaps 1608MB, RAM usage of 1655MB and a remaining free memory of 2492MB = d3d_texfree. sys_memory does not increase.

2) Laptop (HD 5500): E2005 after 213 bitmaps, d3d_texfree 2141MB.

3) Old Laptop, < 4GB RAM:
A) Integrated graphics, HD 2200 or something like that, only ~1640MB shared memory: The test virtually kills this laptop, memory allocations take forever when d3d_texfree gets low. E2005 appears at d3d_texfree = 5MB (or less because of double buffering?). Memory usage in the task manager crawls up to > 1.5GB, then, when d3d_texfree gets lower, it jumps to 353-416MB in the task manager.(?)
B) Dedicated graphics card, Geforce 310M (not quite sure how much VRAM there is): E2005 after 210 bitmaps, d3d_texfree 990MB. Here the RAM usage in the task manager looks normal/ as expected, probably because of dedicated memory/ VRAM.


My code example (tested on computer 2):
- Without draw_quad, sys_memory increases with each bitmap creation, d3d_texbmaps does not and d3d_texfree does not decrease. This is probably working as intended, right? Memory is copied over/ sent to the graphics card/ VRAM when it's needed..?
I can create 212 bitmaps.
- With draw_quad(test_bmps[num_bmaps],...) (see previous post) sys_memory increases as well as d3d_texbmaps. E2005 after 105 bitmaps at 889MB sys_memory, 824MB d3d_texbmaps. RAM sits at 1722MB though.
-> If I replace bmap_create("test8MB.tga") with bmap_createblack(2048,1024,32), I can create 212 bitmaps again. sys_memory does not increase, d3d_texbmaps does and d3d_texfree decreases.


Btw. texture creation should already fail at > 2GB, right? Because of reasons mentioned earlier in this thread.
Oh, and yesterday I read that GetAvailableTextureMem() is unreliable and includes some system/ shared memory as well.
Posted By: jcl

Re: video memory and d3d_texfree - 04/27/17 12:05

d3d_texfree only decreases with draw_quad, because video memory is only allocated when the bmap is rendered. From what I now learned, generating a texture fails not only when not enough video memory is available, but also when not enough normal memory is available. So you must have enough of both.

Posted By: Superku

Re: video memory and d3d_texfree - 04/27/17 12:43

Originally Posted By: jcl
So you must have enough of both.

But I do have enough of both, no?

Can you please comment on the following:

Originally Posted By: Superku
- With draw_quad(test_bmps[num_bmaps],...) (see previous post) sys_memory increases as well as d3d_texbmaps. E2005 after 105 bitmaps at 889MB sys_memory, 824MB d3d_texbmaps. RAM sits at 1722MB though.
-> If I replace bmap_create("test8MB.tga") with bmap_createblack(2048,1024,32), I can create 212 bitmaps again. sys_memory does not increase, d3d_texbmaps does and d3d_texfree decreases.

Does that make sense? If so, why?
Posted By: jcl

Re: video memory and d3d_texfree - 04/27/17 16:36

Yes, that's fine since bmap_createblack, as long as nothing else happens, just creates an empty bmap and has no impact on sys_memory or d3d_texbmaps.
Posted By: Superku

Re: video memory and d3d_texfree - 04/27/17 17:06

Originally Posted By: jcl
Yes, that's fine since bmap_createblack, as long as nothing else happens, just creates an empty bmap and has no impact on sys_memory or d3d_texbmaps.

But d3d_texbmaps does increase as I'm using draw_quad...

Code:
///////////////////////////////
#include <acknex.h>
#include <default.c>
///////////////////////////////

#define MAX_BMAPS 196 // start with the default nexus/ "run current script"
BMAP* test_bmps[MAX_BMAPS];
int num_bmaps = 0;

void main()
{
	int i;
	fps_max = 60;
	video_mode = 6;
	while(1)
	{
		draw_text(str_printf(NULL,"sys_memory: %.1f",(double)sys_memory),20,20,COLOR_RED);
		draw_text(str_printf(NULL,"d3d_texbmaps: %.1f",(double)d3d_texbmaps),20,40,COLOR_RED);
		draw_text(str_printf(NULL,"nexus: %.1f/ %d",(double)nexus,(int)max_nexus),20,60,COLOR_RED);
		draw_text(str_printf(NULL,"d3d_texfree: %.1f",(double)d3d_texfree),20,80,COLOR_RED);
		if(num_bmaps < MAX_BMAPS)
		{
			test_bmps[num_bmaps] = bmap_createblack(2048,1024,32); //bmap_create("test8MB.tga"); //
			draw_quad(test_bmps[num_bmaps],vector(10,10,10),NULL,NULL,NULL,NULL,50,0);
			num_bmaps++;
		}
		draw_text(str_printf(NULL,"num_bmaps: %d",(int)num_bmaps),20,120,COLOR_RED);
		
		wait(1);
	}
}



That code creates 196 bitmaps, 8MB per image, and consumes about 1.6GB of memory. EDIT: d3d_texbmaps at 1552MB, no error.

If I replace
bmap_createblack(2048,1024,32)
with
bmap_create("test8MB.tga"); // 2048x1024x32
the application errors E2005 after ~100 bitmaps, ~1.6GB of memory (task manager), with sys_memory at 849MB and d3d_texbmaps at 776MB. After closing that message it prints "Out of Memory" (E1005).

This cannot be correct, right?
Posted By: jcl

Re: video memory and d3d_texfree - 04/27/17 17:17

There can be many reasons, for instance that your graphics driver needs less memory for monochrome textures, using some compressed format. You could test this by comparing the memory consumption of different images, some monochrome, some with content.
Posted By: Superku

Re: video memory and d3d_texfree - 04/27/17 18:27

So it is intended that version A)

test_bmps[num_bmaps] = bmap_create("test8MB.tga");
draw_quad(test_bmps[num_bmaps],...);

uses twice the memory (read: 16MB per 8MB (source) image) compared to version B)

BMAP* source_bmp = "test8MB.tga"; // global bitmap
...
test_bmps[num_bmaps] = bmap_createblack(2048,1024,32);
bmap_blit(test_bmps[num_bmaps],source_bmp, NULL, NULL);
draw_quad(test_bmps[num_bmaps],...);

(which both display the same content to the screen)?
Posted By: jcl

Re: video memory and d3d_texfree - 04/28/17 12:22

No, it's the other way around. If your video driver compresses monochrome bitmaps, then "test8MB.tga" uses 8 MB video memory, and bmap_createblack(2048,1024,32) uses an unknown, but smaller amount. And when you blit some content into it, they should use the same memory amount. Unless your 8 MB test image is bigger than 8 MB.
Posted By: Superku

Re: video memory and d3d_texfree - 04/29/17 14:43

Please download this code plus bitmap then and give it a try: http://superku.de/crash_test5.zip

The problem:
Originally Posted By: Superku
the application errors E2005 after ~100 bitmaps, ~1.6GB of memory (task manager), with sys_memory at 849MB and d3d_texbmaps at 776MB. After closing that message it prints "Out of Memory" (E1005).

Changing
Code:
if(0) // < ---------- here


to true results in sys_memory not rising and me being able to create twice as many bitmaps.


EDIT: If I'm not mistaken I only then have ~800MB of memory to work with to make PC games with A8.
Posted By: Ezzett

Re: video memory and d3d_texfree - 04/29/17 17:29

I can confirm what Superku said. On my Asus UX360UAK-BB285T I got the following results with bmap_createblack and bmap_blit:

sys_memory 65.6
d3d_texbmaps 1560.0
nexus 0.4/40
d3d_texfree 2557.0

num_bmaps 194

Error 2005 until MAX_BMAPS. After that d3d_texfree is 2549.0 and the engine continues to run.

With bmap_create I got:

sys_memory 841.6
d3d_texbmaps 776.0
nexus 0.4/40
d3d_texfree 3325.0

num_bmaps 98

Error 1005 and the engine crashes.
Posted By: Superku

Re: video memory and d3d_texfree - 04/29/17 18:06

Thanks for testing!
Posted By: Ezzett

Re: video memory and d3d_texfree - 04/29/17 23:09

I tested it also with the engine sdk in Visual Studio Community 2015. Maybe this is helpfull, because it's possible to look inside the structs.

Code:
#define WIN32_LEAN_AND_MEAN		
#include <windows.h>
#include <stdlib.h>
#include <malloc.h>
#include <memory.h>
#include <tchar.h>

#include "var.h"
#include "adll.h"

ENGINE_VARS *ev;
COLOR COLOR_RED = { _VAR(255), _VAR(0), _VAR(0) };
COLOR COLOR_WHITE = { _VAR(255), _VAR(255), _VAR(255) };

#define MAX_BMAPS 196 // start with the default nexus/ "run current script"
BMAP* test_bmps[MAX_BMAPS];
int num_bmaps = 0;

int APIENTRY WinMain(HINSTANCE hInstance,
	HINSTANCE hPrevInstance,
	LPSTR     lpCmdLine,
	int       nCmdShow)
{
	ev = engine_open(NULL);

	int i;
	v(fps_max) = 60;
	v(video_mode) = 6;
	engine_frame();
	static BMAP* source_bmp = bmap_create("test8MB3.tga");
	
	while (engine_frame()) {

		if (num_bmaps < MAX_BMAPS)
		{
			if (1) // < ---------- here
			{
				test_bmps[num_bmaps] = bmap_createblack(_VAR(2048), _VAR(1024), _VAR(32));
				bmap_blit(test_bmps[num_bmaps], source_bmp, NULL, NULL);
			}
			else test_bmps[num_bmaps] = bmap_create((char *)"test8MB3.tga");
			draw_quad(test_bmps[num_bmaps], vector(_VAR(10), _VAR(10), _VAR(10)), NULL, NULL, NULL, NULL, _VAR(100), _VAR(0));
			//cprintf4("n%d) w %d, h %d, b %d",(int)(num_bmaps+1),(int)test_bmps[num_bmaps]->finalwidth,(int)test_bmps[num_bmaps]->finalheight,(int)test_bmps[num_bmaps]->finalbytespp);
			num_bmaps++;
		}
		draw_text(_CHR(str_printf(NULL, "sys_memory: %.1f", (double)v(sys_memory))), _VAR(20), _VAR(20), &COLOR_RED);
		draw_text(_CHR(str_printf(NULL, "d3d_texbmaps: %.1f", (double)v(d3d_texbmaps))), _VAR(20), _VAR(40), &COLOR_RED);
		draw_text(_CHR(str_printf(NULL, "nexus: %.1f/ %d", (double)v(nexus), (int)v(max_nexus))), _VAR(20), _VAR(60), &COLOR_WHITE);
		draw_text(_CHR(str_printf(NULL, "d3d_texfree: %.1f", (double)v(d3d_texfree))), _VAR(20), _VAR(80), &COLOR_WHITE);
		draw_text(_CHR(str_printf(NULL, "num_bmaps: %d", (int)num_bmaps)), _VAR(20), _VAR(120), &COLOR_WHITE);
	}
	engine_close();
	return 0;
}



For me it has the exact same result like running the script with SED.

I don't know if this is relevant (I really doubt it has something to do with the memory problems), but when I use if(1), the u1,v1- and u2,v2-coordinates of the bitmaps are not zero but slightly off:

Code:
u1	0.000244140625	float
v1	0.000488281250	float
u2	0.999755859	float
v2	0.999511719	float



This is even true for the source_bmp which is declared before the if branch. I have no idea what is going on here.

Here is something more interesting. When I'm using if(0) and I look inside the bmap members I can see that the pixel member is filled:

Code:
pixels	0x0bd3d020 "T^nÿWaqÿYctÿZduÿZeuÿ\gwÿ]hxÿ]hxÿ\fvÿYduÿXbsÿYctÿYctÿXbsÿWbrÿWbrÿXbrÿWaqÿV`pÿU_nÿT^mÿT^mÿS]kÿR\jÿS^kÿT^lÿS]kÿQ[iÿPYgÿOXfÿOXfÿPYgÿOYfÿNWeÿOXeÿOXeÿOXfÿQZhÿQ[iÿQ[iÿQZhÿOXeÿNWdÿNWdÿNWdÿNWdÿOXfÿOXfÿPYgÿPYgÿ...	84 'T' unsigned char *



But when I'm changing the branch to if(1) the pixel member of the bitmap created by bmap_createblack can't be read:
Code:
pixels	0x00000000 <NULL> <Unable to read memory>	unsigned char *


This is also true, after bmap_blit is used.

Could it be, that the pixel member of a bitmap takes up 8 MB of memory? If bmap_create is used, the pixel member is filled. But when bmap_createblack or bmap_blit is used, the pixel member is NULL. Maybe this is the cause the first function can only create half as many bitmaps until the memory is full. (1.6 GB equals 200 * 8 MB or 100 * 16 MB)
Posted By: Ezzett

Re: video memory and d3d_texfree - 04/30/17 11:19

I made some other tests in SED and VSC 2015.

If I remove draw_quad I can create as many bitmaps with bmap_create as I can create with bmap_createblack and bmap_blit.

If I also remove bmap_blit I can create thousands of bmap_createblack bitmaps. It seems that bmap_createblack writes into the same memory area every time.

It also seems that the sys_memory and d3d_texbmaps need to be added together. If d3d_texbmaps stays at 0 then sys_memory can rise up to 1.6 GB before the out of memory message appears.

If sys_memory + d3d_texbmaps are just before 1.6GB and sys_memory rises while d3d_texbmaps stays the same Error 1005 appears.

When sys_memory stays the same and d3d_texbmaps rises you'll get Error 2005.

The sum of both values need to stay under 1.6 GB.
Posted By: Superku

Re: video memory and d3d_texfree - 04/30/17 15:59

That coincides with my findings. jcl said that about bmap_createblack previously, without draw_quad (and other bitmap operations) it's just an empty bmap.
Yes, and I wondered about sys_memory increasing. Apparently you've found the reason though, that is the pixels member of BMAPs being filled when bmap_create("") is used.
Otherwise it's just d3dtex/ the (LP)DIRECT3DTEXTURE9, I assume. I hope the pixels content can be omitted and is not used anymore by anything to save some precious memory.


Btw. I still don't understand why we can only use ~1.65GB (including the nexus and some other stuff). If it was 1.9XGB and not a full 2GB I'd easily accept that but 1.6GB leaves me wondering. Is this normal?
Posted By: Ezzett

Re: video memory and d3d_texfree - 04/30/17 17:30

I've searched a little bit on maximum 32 bit heap sizes per application and it seems the 1.6GB heap size limitation is caused by Windows. For example, here is a small explanation by Oracle:

Quote:
Why can't I get a larger heap with the 32-bit JVM?

The maximum theoretical heap limit for the 32-bit JVM is 4G. Due to various additional constraints such as available swap, kernel address space usage, memory fragmentation, and VM overhead, in practice the limit can be much lower. On most modern 32-bit Windows systems the maximum heap size will range from 1.4G to 1.6G. On 32-bit Solaris kernels the address space is limited to 2G. On 64-bit operating systems running the 32-bit VM, the max heap size can be higher, approaching 4G on many Solaris systems.

As of Java SE 6, the Windows /3GB boot.ini feature is not supported.

If your application requires a very large heap you should use a 64-bit VM on a version of the operating system that supports 64-bit applications. See Java SE Supported System Configurations for details.

http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#gc_heap_32bit

2GB should be possible if Gamestudio is ported to Solaris. wink

I would suggest not to come even close to 1.6GB. On some Windows systems this might work while on others 1.4GB could be to much.
Posted By: jcl

Re: video memory and d3d_texfree - 05/01/17 10:46

The difference between bmap_blit and bmap_create:

Bmap_blit blits into video memory. It does not allocate system memory.

Bmap_create stores the image in system memory.

Both methods use video memory, but only bmap_create allocates also system memory. This - and not some compression by the video driver as I previously suspected - is the reason why you can blit twice as many bitmaps than create.

1.6 GB system memory limit is normal. Theoretically, video memory has no per-process limit, but in practice it has since the d3d memory manager also uses system memory. This might also depend on the video driver.
Posted By: Reconnoiter

Re: video memory and d3d_texfree - 05/01/17 10:51

Ty Ezzett that was informative laugh . So far for me reducing the size of normal maps and setting d3d_texdepth helped the most (while keeping quality). Though lowering d3d_texdepth probably doesn't make much of a difference if one already uses .dds textures right? (/since the .dds is often already compressed?)

@jcl, thanks for the info.
Posted By: Superku

Re: video memory and d3d_texfree - 05/01/17 13:32

Originally Posted By: jcl
Both methods use video memory, but only bmap_create allocates also system memory.

Yes, but I'm wondering what bmap_create is using that (pixels) memory for?
Does it really need to be there or can that memory allocation be omitted (in the next update, optionally with a new addition to the compatibility variable)?

@Ezzett: I see, thanks!
Posted By: jcl

Re: video memory and d3d_texfree - 05/01/17 13:37

Bmap_create is storing the image for a video device change, f.i. switching resolution or window to fullscreen, since this deletes all textures and generates them again when they become visible.
Posted By: Superku

Re: video memory and d3d_texfree - 05/02/17 13:55

Hm okay, that makes sense.

Did a quick test yesterday with a published build. According to VMMap, the game's heap size ranged from ~370-440MB (with that "Total" value at about 7XXMB). Time to find out what's causing the DirectX error there.
Posted By: Superku

compiler and memory usage - 06/09/17 10:21

Well, the trouble continues:

Since yesterday I have not been able to play test my game. The first launch already took a while if I'm not mistaken, then I got an "Error E1241: Can't open DirectX device" (three D3D_Init Window: 640x352 failed messages before that in the acklog).
Since then my game has taken twice as long to compile as it did before. Old values: 15.Xs for the first compile, then 12.Xs for subsequent compiles. Now it takes 29.Xs, until the game starts with an OUT OF MEMORY DirectX error.

Just once it worked correctly with the old compiling time after a reboot, otherwise always the same result.
I've tried several old builds from my external hard drive, including one from over a year ago, surprisingly the same result.
Reinstalled everything, no Windows update since May, thought it could be the DirectX loader that's making trouble but no change.
(1) Do you have any idea what could be causing this behavior?


When I put
Code:
#define PRAGMA_PRINT "n>superku.c END<";


at the end of my main file (finally found this helpful define in the manual) I can see that the "..." progress almost comes to a halt after it's done compiling my code. Most dots now take about 3-5times as long, the first dot after my last PRAGMA_PRINT/ last line in my code takes about 10 times as long as the previous average.
I'm not sure what the compiler is doing right after it's done with my source code as it takes a while until it reaches the first global dummy TEXT or PANEL object (where I put in invalid code).
(2) Can you please share some insight on this process?



Publishing and compiling the exe there takes as long as it does now too, however, the published version seems to work fine. This is not quite feasible for development though.
VMMap returns a Heap size of 380MB for my game running in the published version and a level loaded and running.
When I put invalid code after my last PRAGMA_PRINT and stop the compile process that way, VMMap returns a Heap size of about 1245MB (EDIT: 961MB on my laptop?). After that it crawls up to about 1550MB, starting the game and then resulting in that OUT OF MEMORY error on level_load (which seems reasonable because of the 2GB/ ~1.6GB heap limit - the previous 380MB seem to coincide as well).
(3) I am aware that the development build is different to the published build but does it seem reasonable that the compiling of less than 3MB in code result in that huge heap size in the development version?


Thanks for your time.

EDIT2: Although it probably does not matter in this case, the exact error is "DirectX driver failure: D3DERR_OUTOFVIDEOMEMORY".
Posted By: jcl

Re: compiler and memory usage - 06/12/17 07:50

After compiling, the code is linked by calculating the absolute addresses.

So the same program suddenly runs slower than before? My guess is that something on your PC has changed, f.i. by installing something or modifying the VM or other Windows settings.
Posted By: Superku

Re: compiler and memory usage - 06/14/17 08:35

Strangely, the problem did not happen for the last 3 days. I cannot explain that or even guess why.


However, my concern is the following:
Right now compiling my source code alone uses 980MB of (heap) memory (and 1245MB+ as something was wrong a couple of days ago), using "Run current script" from SED with the default nexus (40MB?).

Assuming my code base does not grow (which it does continuously though), this leaves me with a very finite pool of memory of ~500MB for my whole game, including sound/ music, render targets and textures (which even gets subjectively less because the BMAP struct may occupy twice the memory for one image as outlined earlier in this thread) - at least in the development version.

This is only getting worse the bigger the project becomes, from a code perspective. If I'm not mistaken that's a considerable restriction on all acknex products, not just mine.
The development version needs extra memory for memory allocation safety and debugging features and similar stuff, right? Can this memory footprint be reduced though, even if that would mean cutting a few safety measures?
Posted By: jcl

Re: compiler and memory usage - 06/14/17 09:55

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.
Posted By: Superku

Re: compiler and memory usage - 06/14/17 10:32

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.)
Posted By: jcl

Re: compiler and memory usage - 06/14/17 16:40

How about static data structures in your code? Large global arrays? Nexus? The compiler also allocates memory for them.
Posted By: Superku

Re: compiler and memory usage - 06/14/17 20:40

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.
Posted By: jcl

Re: compiler and memory usage - 06/16/17 15:20

I don't know. But I'll check your example in the next days and will look into it.
Posted By: Superku

Re: compiler and memory usage - 06/17/17 10:24

Thanks, looking forward to your findings!
Posted By: HenWoll

Re: compiler and memory usage - 06/18/17 09:52

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?
Posted By: Reconnoiter

Re: compiler and memory usage - 06/18/17 21:33

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).
Posted By: jcl

Re: compiler and memory usage - 06/19/17 09:33

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.

Posted By: Superku

Re: compiler and memory usage - 06/21/17 13:43

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.
Posted By: jcl

Re: compiler and memory usage - 06/22/17 10:13

It can not be optionally skipped. The compiler has no function for easily deallocating those data structures. It had to be explicitely implemented.
Posted By: preacherX

Re: video memory and d3d_texfree - 11/09/17 21:38

Originally Posted By: jcl
d3d_texbmaps is indeed not reduced by releasing the old textures when switching the resolution. I have put this on the bug list. But you should still be able to find the problem this way when you don't change the resolution.


I'm getting many reports on Steam from people who have problems when switching between programs and then returning to the game that they get "Error E2005: Can't create DirectX texture unnamed" errors and the game stops. I'm not sure if I understand the discussion here correctly, but is this problem the d3d_texbmaps bug? When will this be fixed? I also don't find this on the bug list? Is there a workaround?
Posted By: sivan

Re: video memory and d3d_texfree - 11/15/17 08:25

I have the same issue when replacing terrain textures by ent_setskin()
Posted By: jcl

Re: video memory and d3d_texfree - 11/16/17 07:32

The wrong value of d3d_texbmaps is not a very serious bug and will be fixed in the next update. A deallocation of the compiler data is not planned at this point.
Posted By: Superku

Re: video memory and d3d_texfree - 02/04/18 12:38

Originally Posted By: jcl
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.
[...]
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.
[...]
It had to be explicitely implemented.

Although I've optimized it already over the months and years (not loading any big files like music, creating any big textures only on demand (of which there are < 10) and deleting 99% of all unused code), I've finally reached the point where I cannot play-test my game anymore.
The code is the issue, not other files. Most of the code is already in place but a little more is yet to come.

Mr. Lotter, can you free some of the memory (not 90% but let's say 30%, optimistically, some big chunks) and release a new version? That would be a huge thing/ relief, probably not just for me.
How much time would that take you to do/ implement? I'd throw some money in the company's coffee tip jar if it helped thinking.
Posted By: 20BN

Re: video memory and d3d_texfree - 02/05/18 10:04

too bad! confused
[img]https://imgur.com/3b43df0f-5138-4e5e-a126-f9aa55a36c54[/img]

mem not free.

screenshot:
https://imgur.com/Zg0ywNm

Posted By: jcl

Re: video memory and d3d_texfree - 02/07/18 09:56

The problem with freeing the memory is that the Chinese developers that developed lite-C for Atari disappeared a long time ago. We do partially understand the compiler, but its memory management looked totally Chinese to us and we do not like to touch it.

This leaves 3 options when you hit a roadblock with extremely large code:

- you make your code smaller by putting a part of it in a DLL.
- you make it smaller with some tricks, especially replacing large static arrays with dynamically allocated arrays.
- you or someone else undertake the task to free the memory. The license allows us to give the lite-C source not to the public, but to select developers. If someone with enough C++ knowledge volunteers, I'm happy to give him a contract and the source code.
Posted By: Superku

Re: video memory and d3d_texfree - 02/07/18 10:54

Thanks for the response.
I went through the code again after my last post, optimizing it and commenting/ excluding temporarily unused code (for levels I'm not working on currently). This saved me about 45MB (compile time 14.9->14.1) which means I could test the game again for now but that's obviously going to change/ break in the near future.

Putting code into a DLL is a neat idea! Too bad I wrote this project's code very acknex-y but I will do that if I have no other choice.

Originally Posted By: jcl
The license allows us to give the lite-C source not to the public, but to select developers. If someone with enough C++ knowledge volunteers, I'm happy to give him a contract and the source code.

Sounds great! I have sent an e-mail to the support.
Posted By: jumpman

Re: video memory and d3d_texfree - 02/07/18 21:14

how much would it cost to hire chinese programmers to read through and translate the memory management section? How can you put lite-C code in a dll? Would a C++ progammer be able to make a "just enough difference" for a new license/product?
Posted By: Garrettwademan

Re: video memory and d3d_texfree - 11/10/18 04:17

Bummer, just ran into this bug too. Has there been any updates since February? This is really killing me on certain machines.
Posted By: Superku

Re: video memory and d3d_texfree - 11/10/18 12:43

Not that I'm aware of, sorry. I've signed said contract and dug through the compiler source code (and looked at test interim code) for a bunch of days. I think I roughly know how it works but actually changing anything in there is something completely else, the memory management code might as well be Chinese.
You'd probably need some wise guy and compiler enthusiast like JustSid to have a look at this. *wink wink*

Btw. as a workaround I wrote a small tool in lite-C which checks the alteration dates of code files, compiles a new exe version like this:
exec_wait("C:\GStudio8\WED.EXE","-r superku.c -nx 128 -ns");
and then starts the exe.
If I only do changes on levels, models or something like that it heavily cuts down on the compile times, otherwise (changing code) it's only slightly slower. I don't have any memory issues then and the game is running faster as well, but... you don't have any debugging features (like sys_marker) or informative error messages then. Not an optimal solution.
Posted By: Garrettwademan

Re: video memory and d3d_texfree - 11/13/18 20:30

Interesting about your tool, is this something that you would share? I have .WDL (using C-SCRIPT) with A8 latest version and willing to do anything to get over this issue.

So my error only happens when I open a certain panel (the panel image is rendering white only), and when I face the model that is causing me an issue. I seem to only see this on my laptop, but my desktop doesn't have the problem.

My plan of action is to...

-remove all unused files in the game folder (I understand PATH will load all items in that folder regardless if it is used or not)
-Shrink audio / video / graphic files (assuming JPG is better than BMP for sizing, keeping BMP and TGA for special transparency)
-Remove unnecessary code or shrink it down (I have maybe 20Mb of code)
-use LoS and remove entity when player isn't close, maybe using .visible options
-Test with a smaller level (I have about 300 items in the level for objects such as walls and tables, maybe I can shrink this down)
-Test the .EXE compared to using SED in development
-Look at options to use .DLL files for code
-Test making custom EXE file that have resolution locked down instead of changing it every time to see if it crashes.
-I do not use any special engine functions to clear memory as I understand that they don't work perfectly, maybe I am wrong?
-Any other suggestions?

Luckily I made my game very modular, so a Visual Studio app moves the ACKNEX to the root folder before loading the game, I have a ton of .EXE files which are loaded on demand.

I really hope we get a surprise message from the developers that they figured out the Chinese code.
Posted By: sitrep

Re: video memory and d3d_texfree - 11/14/18 06:41

Where is that “feb update”?

Where is link to download latest A8 PRO update?

Thanks!
Posted By: Superku

Re: video memory and d3d_texfree - 11/14/18 17:00

@Garrettwademan: My "tool" is the following code:
Click to reveal..
Code:
///////////////////////////////
#include <acknex.h>
#include <default.c>
#include <windows.h>
///////////////////////////////

STRING* str_tmp = "";

TEXT* tDir = { pos_y = 40; strings = 200; flags = SHOW;}

void main()
{
	fps_max = 60;
	video_screen = 0;
	video_window(NULL,NULL,0,"Superku Launcher");

	var fhandle = file_open_write("launchLog.txt");

	file_str_write(fhandle,str_printf(NULL,"Superku Launcher Logn%02d:%02d:%04d - %02d:%02d:%02d...",(int)sys_day,(int)sys_month,(int)sys_year,(int)sys_hours,(int)sys_minutes,(int)sys_seconds));
	file_str_write(fhandle,str_printf(NULL,"nCurrent work_dir: %s",_chr(work_dir)));
	str_cpy(work_dir,"C:\GStudio8\Superku\");
	str_cpy(save_dir,work_dir);
	SetCurrentDirectory(_chr(work_dir));
	char cbuffer[256];
	GetCurrentDirectory(256,cbuffer);
	file_str_write(fhandle,str_printf(NULL,"
	nGetCurrentDir: %s",cbuffer));

	int doCompile = 0;
	int numFiles = txt_for_dir(tDir,"*.c"); 
	int i;
	for(i = 0; i < numFiles; i++)
	{
		file_str_write(fhandle,str_printf(NULL,"n
		Is file (%s) newer than superku.exe? ",_chr((tDir.pstring)[i])));
		if(file_date((tDir.pstring)[i]) > file_date("superku.exe"))
		{
			file_str_write(fhandle,"Yes!");
			doCompile = 1;
			break;
		}
		else file_str_write(fhandle,"No...");
	}
	if(!doCompile)
	{
		int numFiles = txt_for_dir(tDir,"*.h"); 
		int i;
		for(i = 0; i < numFiles; i++)
		{
			file_str_write(fhandle,str_printf(NULL,"n
			Is file (%s) newer than superku.exe? ",_chr((tDir.pstring)[i])));
			if(file_date((tDir.pstring)[i]) > file_date("superku.exe"))
			{
				file_str_write(fhandle,"Yes!");
				doCompile = 1;
				break;
			}
			else file_str_write(fhandle,"No...");
		}
	}

	printf("nndoCompile : %d",doCompile);
	file_str_write(fhandle,str_printf(NULL,"n
	ndoCompile: %d",doCompile));

	if(doCompile)
	{
		printf("nSet Build options: %s...",_chr("options_skbuild.scr"));	
		file_cpy("C:\GStudio8\data\options.scr","C:\GStudio8\data\options_skbuild.scr");	
		printf(" Done.");
		printf("nCompile exe and dll...");	
		exec_wait("C:\GStudio8\WED.EXE","-r superku.c -nx 128 -ns");
		printf(" Done.");
		wait(1);
		if(key_esc) sys_exit(""); // in case of compile errors
		file_cpy("C:\GStudio8\Superku\acknex.dll","C:\GStudio8\Superku\superku.cd\acknex.dll");
	}
	file_close(fhandle);
	if(key_esc) sys_exit("");
	wait(1);
	if(key_esc)
	{
		sys_exit("");
		return;
	}
	exec("C:\GStudio8\Superku\superku.exe","-nx 128 -ns -diag");
	sys_exit("");
}


I have no clue about C-Script, forgot everything about it, but it should work still.
Go to the "data" subfolder in your Gamestudio installation folder, duplicate (and backup) the options.scr file and create one for your script compilation. I've pretty much excluded all files there (like images, MDL, WMB) so it only compiles the code. I think there's a command line option for the publish process to do that normally but it did not work for me for some reason, which I forgot.

Btw. have you checked the amount of memory your game uses when it crashes using VMMap?
Posted By: Garrettwademan

Re: video memory and d3d_texfree - 11/15/18 23:58

Thanks for sharing, will review and try it! I just found the command d3d_texlimit and was about to do a cartwheel after reading the description, but when I actually implemented it, the game crashes every time for certain models on several different machines.

I have used VMmap, so I clocked 1.984Gb RAM on my Desktop machine, and about 1.8Gb something on my laptop. My Desktop DOES NOT CRASH or throw any texture memory errors (it runs perfectly), but my laptop always has the issue. I cleaned up my code so I am seeing about 1.7Gb but my laptop still says NOPE and craps itself! Now I use built in checks for vid_memory and nexus, and I am only using 78/600Mb nexus, and about 250Mb of video memory. Its like these are not logging properly or related to the bug. At game launch it says it found 750Mb of video memory.

Now I did some testing, the same texture file that kept crashing on my laptop didn't crash when I didn't load the world models (walls, floors, tables, etc) with the culprit model, and it only crashes when I look at the item in the game. There may be things I can potentially do to work around this (but not coming to me right now).

All in all Windows OS only really supports up to 2GB of RAM per software instance unless you do some crazy stuff.

BTW Superku, your game on Steam looks awesome. The specialFX and detail is amazing! 7 years too. I am a little worried about posting my game on steam even though I paid the fee and working on the page layout. I wanted to finish this last detail before going live, but worried this issue may severely delay my project now. I have been dragging playing other games now, thinking, researching, and performing little tests here and there. I don't want to be bummed because I have been able to get around and even abuse the bugs from A8 to my advantage lol, but this one is scary. This is my first 1 million+ lines of code project, so I plan on grinding until its done! Thank you for your input and experience too! It has been very helpful to me over the years.
Posted By: Ezzett

Re: video memory and d3d_texfree - 11/16/18 10:01

Quote:
I have used VMmap, so I clocked 1.984Gb RAM on my Desktop machine, and about 1.8Gb something on my laptop. . My Desktop DOES NOT CRASH or throw any texture memory errors (it runs perfectly), but my laptop always has the issue.

Depending on the system even 1.4Gb could be too much for a 32 Bit application. You should stay way below that. I wouldn't risk to make a Gamestudio game that needs more than 1 Gb at a time.

Today's HD textures and high poly models fill up RAM very quickly. Because Gamestudio is a 32 Bit software you would need to work around that limit by a clever resource management in the game.

Quote:
Now I use built in checks for vid_memory and nexus, and I am only using 78/600Mb nexus, and about 250Mb of video memory.

If I remember correctly some things like textures are saved twice in memory to recreate them if you ALT+TAB out and back into the game. This is not shown correctly when you use these helper variables. You basically need to multiply some of the allocated memory by two.
Posted By: Garrettwademan

Re: video memory and d3d_texfree - 11/16/18 16:40

Thanks for the info Ezzett. I read that 1.4Gb is the max GS can support safely. I luckily bloated my textures / models / code so I knew I could go back later to shrink / optimize them.

My levels are pretty massive, so I may shrink them down. I luckily built a world editor that can add models / properties, doors, lighting systems, etc. so this should be fairly quickly.
Posted By: Superku

Re: video memory and d3d_texfree - 11/18/18 10:17

Keep in mind that the culprit most likely is the size of your code or rather the interim code created by the compiler (in development mode at least), not bitmaps or other files. Re-read the last 15 posts or so in this thread for clarification.

Publish your game, run it, then check memory usage with VMMap. It might even be a GB less than what you're currently seeing.
Posted By: jumpman

Re: video memory and d3d_texfree - 11/25/18 00:28

im getting out of memory and d3d unamed errors as well frown

its been happening when recreating render chains, but also when I add in objects with huge textures. However I did not optimize my levels nor the texures, but its a little concerning nonetheless.



what Im worried about is optimizign all these textures and models and levels and still hit that out of error when creating new objects in realtime.
Posted By: Superku

Re: video memory and d3d_texfree - 11/25/18 17:59

That's just for your testscene, right? The script shouldn't be the issue then. However, try the following:
Download VMMap if you haven't already.
Put bad syntax at the very end of your script. Compile it, wait for the compiler to throw an error message but keep the process open. Start VMMap, pick the acknex.exe process and look at the memory (total/ heap).
You can remove the dummy line at the end of the script and check memory usage at runtime if you want to.

If the script compiling does not consume a ton of memory it's indeed your files, probably the textures (and/ or maybe even a huge nexus?).
Posted By: jumpman

Re: video memory and d3d_texfree - 11/25/18 21:02

Thanks for taking a look superku. Yes, this is my test scene. My nexus is 500

I put "fart" at the bottom of my script lol, saved, ran the engine, it caught the error, then i ran VMMap, and here is what I see:



901,468 k total
742,624 k heap

What is the difference between total and heap? Does my screenshot/stats look ok?
Posted By: Superku

Re: video memory and d3d_texfree - 11/26/18 17:59

The heap pretty much is where you can request memory from at runtime. Its limit is about 1.4-1.6GB, you have to stay below that.
If your heap usage after code compiling is 740MB with a nexus of 500MB then your code uses 200-240MB or so I think. When you publish your game and run that process you should have additional ~200MB to work with then.
Posted By: jumpman

Re: video memory and d3d_texfree - 11/27/18 14:11

Is 200-240 mb of code a decent amount to use? How much does your game use in code?

It makes sense that I was running into more errors when I was using 1.4gb of memory, because I just kept adding more models, some with huge textures just for testing.
Posted By: Superku

Re: video memory and d3d_texfree - 12/01/18 14:09

>Is 200-240 mb of code a decent amount to use? How much does your game use in code?
First one isn't really a sensible question (no offense!). Superku's interim code was at ~1100MB already, not leaving much room for anything else, but I've been working on a different game since April which uses pretty much the same amount of memory for code (again, during development builds) as your game.


You might want to think about stylizing your game's visuals more then, usually needing a lot less textures (and smaller in size) and less effort to develop in the end.
© 2024 lite-C Forums