Gamestudio Links
Zorro Links
Newest Posts
Blobsculptor tools and objects download here
by NeoDumont. 03/28/24 03:01
Issue with Multi-Core WFO Training
by aliswee. 03/24/24 20:20
Why Zorro supports up to 72 cores?
by Edgar_Herrera. 03/23/24 21:41
Zorro Trader GPT
by TipmyPip. 03/06/24 09:27
VSCode instead of SED
by 3run. 03/01/24 19:06
AUM Magazine
Latest Screens
The Bible Game
A psychological thriller game
SHADOW (2014)
DEAD TASTE
Who's Online Now
2 registered members (AndrewAMD, VoroneTZ), 831 guests, and 5 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
What happens with particles, Memory wise? #468101
09/18/17 14:29
09/18/17 14:29
Joined: Apr 2002
Posts: 1,246
ny
jumpman Offline OP
Serious User
jumpman  Offline OP
Serious User

Joined: Apr 2002
Posts: 1,246
ny
Hello!

How does the engine allocate memory for particles, image/textureMem wise? If you make a 2048x2048 texture 3d model, and move the camera to it, the engine pauses slightly while it loads into memory, and the game continues. If you decide to unload that model, you can ent_purge.

But what happens if you have for example a 2048x2048 image particle? Does the engine ever deallocate that memory used by the image? Besides level_load, is there a way to reclaim the memory used by that particle?

Re: What happens with particles, Memory wise? [Re: jumpman] #468164
09/21/17 12:06
09/21/17 12:06
Joined: Sep 2003
Posts: 6,861
Kiel (Germany)
Superku Offline
Senior Expert
Superku  Offline
Senior Expert

Joined: Sep 2003
Posts: 6,861
Kiel (Germany)
For particles you assign global BMAP pointers. Unless you create them dynamically/ manually yourself they are created and allocated at game start (this is while the default acknex compile window is still active, printing out the "..." dots).
Like here:

Code:
BMAP* coolParticle_tga = "coolParticle.tga";

void p_coolParticle(PARTICLE* p)
{
 p.bmap = coolParticle_tga;
 ...
}



You could write

BMAP* coolParticle_tga = NULL;

and then bmap_create the image at runtime - once. Once is the keyword though, as there's no memory allocation in terms of image memory done for particles or their instances. So... you wouldn't have to worry about that case normally.

Btw 2048^2 sounds awfully large for a particle, do you really need that size?


"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: What happens with particles, Memory wise? [Re: Superku] #468169
09/21/17 16:32
09/21/17 16:32
Joined: Apr 2002
Posts: 1,246
ny
jumpman Offline OP
Serious User
jumpman  Offline OP
Serious User

Joined: Apr 2002
Posts: 1,246
ny
2048 is just a hypothetical, i wanted to exaggerate tongue

So help me understand, if I got it right:

So when you declare a non-null BMAP* in the script, the engine loads that image during the dots and puts it into memory, so when you run the effect, even with a 2048/huge image, the engine wont pause/stutter while the camera sees it for the first time. However the image is still loaded into memory correct? From the dots and onward, that image has been placed into memory, its area flagged as being used. Is there a way to purge this image later? What if I dont ever want the particle image used in a level? I would still have that area marked for usage in a level that wouldnt require that effect.

bmap_create on a BMAP* that was initially declared NULL, then fills that BMAP* with an image, as if you declared it regularly in the beginning. How does this help, besides saving memory in the beginning, before the image was filled with bmap_create? How will you remove that image from memory?

Re: What happens with particles, Memory wise? [Re: jumpman] #468170
09/21/17 16:38
09/21/17 16:38
Joined: Apr 2002
Posts: 1,246
ny
jumpman Offline OP
Serious User
jumpman  Offline OP
Serious User

Joined: Apr 2002
Posts: 1,246
ny
Another example would be this:

In my volcano level, I have an animated sprite (emulated particle) that is used on the top of the volcano, a 32 frame animation of a cool fire cloud effect, it looks all cool and magma laugh. I use BMAP* SuperMagma+32.tga; in the script.

But in the next level, which is a snow level, I have no use for the magma sprite, I want to get rid of it from memory, so that I can use a snow avalanche animated sprite. How will I purge the magma sprite from memory?

Re: What happens with particles, Memory wise? [Re: jumpman] #468171
09/21/17 18:07
09/21/17 18:07
Joined: Sep 2003
Posts: 6,861
Kiel (Germany)
Superku Offline
Senior Expert
Superku  Offline
Senior Expert

Joined: Sep 2003
Posts: 6,861
Kiel (Germany)
BMAP* SuperMagma_tga = NULL;

action volcano()
{
if(!SuperMagma_tga) SuperMagma_tga = bmap_create("SuperMagma+32.tga");
...
}

Now you can either bmap_purge or ptr_remove that BMAP:

bmap_purge(SuperMagma_tga);
level_load(...);

Let's assume your BMAP is 8MB big. Then bmap_create with allocate 8MB first, then additional 8MB when the bmap is visible for the first time.
When you bmap_purge your bitmap the latter 8MB will be freed. In case it needs to be drawn again it will automatically be recreated (once until you purge it), based on the 8MB data which have been allocated firstly.



The alternative and probably the better solution would be to ptr_remove it:

ptr_remove(SuperMagma_tga);
SuperMagma_tga = NULL;
level_load(...);

Now all memory allocated for SuperMagma_tga has been freed, but you have to recreate the image yourself when it's needed.



I'm not sure if you could ptr_remove a globally pre-launch defined BMAP and get the memory back, maybe that would work as well. Do it the other way though!


"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: What happens with particles, Memory wise? [Re: Superku] #468180
09/22/17 17:33
09/22/17 17:33
Joined: Apr 2002
Posts: 1,246
ny
jumpman Offline OP
Serious User
jumpman  Offline OP
Serious User

Joined: Apr 2002
Posts: 1,246
ny
hi superku, thank you!

"Then bmap_create with allocate 8MB first, then additional 8MB when the bmap is visible for the first time."

An 8mb image actually takes up 16mb of space? The first 8mb is allocated, meaning its marked for this specific bitmap, then why is an additional 8mb consumed when you see it for the first time? I thought it was already loaded into memory.

How does ptr_remove() work better? Im assuming ptr stands for pointer, which means it just an address, like an address to a house for example. Wouldnt ptr_remove just remove the address to that house, instead of removing the house altogether? But if that works, that looks like I should use that method, thank you.

So level_load only frees up memory that was loaded into the wmb file correct? It doesnt automatically free up all memory, especially BMAP* that were declared (not null)

Do you manually ptr_remove stuff when level_loading in your game? Or do you make automatic systems?

Re: What happens with particles, Memory wise? [Re: jumpman] #468185
09/22/17 19:52
09/22/17 19:52
Joined: Apr 2007
Posts: 3,751
Canada
WretchedSid Offline
Expert
WretchedSid  Offline
Expert

Joined: Apr 2007
Posts: 3,751
Canada
The bitmap lives in VRAM as well, which is where the second 8Mb come from.

ptr_remove() frees up the memory the pointer points to. Although that only works for engine objects that are created via xyz_create (eg. ent_create, bmap_create etc)


Shitlord by trade and passion. Graphics programmer at Laminar Research.
I write blog posts at feresignum.com
Re: What happens with particles, Memory wise? [Re: WretchedSid] #468187
09/23/17 04:48
09/23/17 04:48
Joined: Sep 2003
Posts: 6,861
Kiel (Germany)
Superku Offline
Senior Expert
Superku  Offline
Senior Expert

Joined: Sep 2003
Posts: 6,861
Kiel (Germany)
Yes, the additional 8MB come from or for DirectX and the DIRECT3DTEXTURE9. In case the video device is lost/ you change the video resolution the 8MB allocated first will be used to create a new DirectX texture for rendering.


I've cut pretty much all big textures from my game (apart from render targets) so the only memory allocations I do dynamically are rather small arrays, maybe a few hundred KB in total. I don't clean them up on level change (but of course I only create them once).
However, I use quite a bunch of global pointers so I have a "free_pointer()" function which I call before any level_load, it just sets them all to NULL again.
If you only have a few (let's say < 20) bigger memory allocations to clean up just do it manually. If you expect to have more than that you could try and write an automated system, like a ~custom memory allocation function~ that registers the allocation somewhere (in an array or list) and then call a cleanup function before level_load.


"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: What happens with particles, Memory wise? [Re: Superku] #468194
09/23/17 18:26
09/23/17 18:26
Joined: Apr 2007
Posts: 3,751
Canada
WretchedSid Offline
Expert
WretchedSid  Offline
Expert

Joined: Apr 2007
Posts: 3,751
Canada
The good news is that render targets on pretty much every newer GPU are compressed and aren't eating the full VRAM cost or even the full bandwidth cost. AMD has a good overview here. Nvidia does something similar for much longer already (around Fermi times, potentially even before with Tesla). In any case, render targets aren't that expensive anymore these days.

Although I guess one big problem with Gamestudio is that it's 32bit so not only VRAM is a concern.


Shitlord by trade and passion. Graphics programmer at Laminar Research.
I write blog posts at feresignum.com
Re: What happens with particles, Memory wise? [Re: WretchedSid] #468217
09/25/17 22:41
09/25/17 22:41
Joined: Apr 2002
Posts: 1,246
ny
jumpman Offline OP
Serious User
jumpman  Offline OP
Serious User

Joined: Apr 2002
Posts: 1,246
ny
thank you friends, for giving me the technical as well as the practical information about memory and how it is handled.


Moderated by  HeelX, Lukas, rayp, Rei_Ayanami, Superku, Tobias, TWO, VeT 

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