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 (TipmyPip, 1 invisible), 595 guests, and 7 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 6 of 10 1 2 4 5 6 7 8 9 10
Re: video memory and d3d_texfree [Re: Ezzett] #465490
04/30/17 15:59
04/30/17 15:59
Joined: Sep 2003
Posts: 6,861
Kiel (Germany)
Superku Offline
Senior Expert
Superku  Offline
Senior Expert

Joined: Sep 2003
Posts: 6,861
Kiel (Germany)
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?


"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: video memory and d3d_texfree [Re: Superku] #465492
04/30/17 17:30
04/30/17 17:30
Joined: Aug 2003
Posts: 118
Deutschland
E
Ezzett Offline
Member
Ezzett  Offline
Member
E

Joined: Aug 2003
Posts: 118
Deutschland
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.

Last edited by Ezzett; 04/30/17 17:40.
Re: video memory and d3d_texfree [Re: Ezzett] #465505
05/01/17 10:46
05/01/17 10:46
Joined: Jul 2000
Posts: 27,977
Frankfurt
jcl Offline

Chief Engineer
jcl  Offline

Chief Engineer

Joined: Jul 2000
Posts: 27,977
Frankfurt
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.

Re: video memory and d3d_texfree [Re: Ezzett] #465506
05/01/17 10:51
05/01/17 10:51
Joined: Dec 2011
Posts: 1,823
Netherlands
Reconnoiter Offline OP
Serious User
Reconnoiter  Offline OP
Serious User

Joined: Dec 2011
Posts: 1,823
Netherlands
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.

Last edited by Reconnoiter; 05/01/17 10:52.
Re: video memory and d3d_texfree [Re: jcl] #465510
05/01/17 13:32
05/01/17 13: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)
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!


"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: video memory and d3d_texfree [Re: Superku] #465511
05/01/17 13:37
05/01/17 13:37
Joined: Jul 2000
Posts: 27,977
Frankfurt
jcl Offline

Chief Engineer
jcl  Offline

Chief Engineer

Joined: Jul 2000
Posts: 27,977
Frankfurt
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.

Re: video memory and d3d_texfree [Re: jcl] #465520
05/02/17 13:55
05/02/17 13:55
Joined: Sep 2003
Posts: 6,861
Kiel (Germany)
Superku Offline
Senior Expert
Superku  Offline
Senior Expert

Joined: Sep 2003
Posts: 6,861
Kiel (Germany)
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.


"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
compiler and memory usage [Re: Superku] #466330
06/09/17 10:21
06/09/17 10:21
Joined: Sep 2003
Posts: 6,861
Kiel (Germany)
Superku Offline
Senior Expert
Superku  Offline
Senior Expert

Joined: Sep 2003
Posts: 6,861
Kiel (Germany)
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".

Last edited by Superku; 06/09/17 15:24.

"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] #466365
06/12/17 07:50
06/12/17 07:50
Joined: Jul 2000
Posts: 27,977
Frankfurt
jcl Offline

Chief Engineer
jcl  Offline

Chief Engineer

Joined: Jul 2000
Posts: 27,977
Frankfurt
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.

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

Joined: Sep 2003
Posts: 6,861
Kiel (Germany)
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?


"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 6 of 10 1 2 4 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