Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (803)
Games in Android Showcase (237)
games submitted by our members
Games in WIP (867)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  libgdx The need to dipose assets on desktop  (Read 6444 times)
0 Members and 1 Guest are viewing this topic.
Offline Cero
« Posted 2015-08-07 12:16:09 »

Using libgdx, desktop only game:

The docs are very much Android focused. So on Android its obvious, you gotta dispose everything.
My question is: Do you need to dispose things on desktop at all? Some of them? Never, always - which ones?

I do dispose but I also kinda assume that its not really necessary.

Offline Springrbua
« Reply #1 - Posted 2015-08-07 12:26:58 »

I was asking my self the same question sometimes...
I forgot disposing/unloading thigs verry often, but i never noticed any drawback cause of this (always only on desktop, while debugging, i never used libgdx on an android device till now...).
So i guess it is not really neccessary cause of performance, but you should do it, just because it is clan.
Just my thoughts...
Offline Cero
« Reply #2 - Posted 2015-08-07 13:54:46 »

My only slight concern would be VRAM/OpenGL cleanup. But even there not sure.
Since the Lwjgl probably cleans up by itself upon kill.

I am using the LWJGL backend.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline DavidBVal
« Reply #3 - Posted 2015-08-07 17:13:21 »

well... other than the academic curiosity, I don't see why not disposing. Your call to dispose is in the core project anyways, right?

Offline Jervac
« Reply #4 - Posted 2015-08-07 17:19:29 »

In LibGDX the dispose methods are used for disposing things like Spritebatches, Textures, Audio, etc. If you're making a Desktop version as well, you should still do cleanup.
Offline klaus
« Reply #5 - Posted 2015-08-10 15:34:03 »

In LibGDX the dispose methods are used for disposing things like Spritebatches, Textures, Audio, etc. If you're making a Desktop version as well, you should still do cleanup.
Yeah, you should - but as @Cero asked: is it actually necessary or will everthing still be disposed if you don't manually do it? Smiley
Offline theagentd
« Reply #6 - Posted 2015-08-11 21:56:11 »

I'm sure the OS will dispose all objects automatically on program exit, but that doesn't mean that you shouldn't dispose of unused objects. Otherwise you'll get memory leaks and your program will continually use more nad more memory, which might crash the process or even the entire driver in some cases.

Offline gouessej
« Reply #7 - Posted 2015-08-12 09:39:28 »

theagentd is right. Avoid keeping references on unused objects so that the garbage collector can do its job and keep in mind that the management of the native memory is up to you, i.e you can run out of native memory and then it's probably your fault, look at the method BufferUtils.freeBuffer() or disposeUnsafeByteBuffer() depending on which version of LibGDX you use. This utility creates direct NIO buffers, those buffers are used under the hood when creating textures for example. I advise you to ensure that you know which native resources are really necessary when you start a level and to release them when you leave it.

Look at all instances of classes implementing the interface com.badlogic.gdx.utils.Disposable.

Of course, this advice concerns the developers who use the JogAmp backend too.

Julien Gouesse | Personal blog | Website | Jogamp
Offline Cero
« Reply #8 - Posted 2015-08-12 22:21:22 »

@theagentd Yeah I'm just taking about libgdx stuff using native memory or VRAM, not arbitrary objects in java

but yeah you guys are right
I kinda have it on my todo list since forever but never really done it: disposing routines for when something is no needed anymore... I guess the question is what and when. unloading everything not need on a given map during map change means I can never use the cache pretty much. Which is lame... hmm. Gotta have to calculate stuff.

Its a shame there isnt like a definitive reliable VRAM tool

Offline gouessej
« Reply #9 - Posted 2015-08-12 22:45:42 »

Why do you still wonder when to do it? Do it when the player isn't playing for example, typically when leaving a level, or somewhere in background when there is no such structure in a game.

Concerning "what", look at the disposable objects.

Actually, there is a more complicated solution to use the cache even when unloading useless resources. You can compare the resources you used in the previous level with the resources you're going to use in the next level in order to unload only the useless resources without wasting the interest of a cache. It's doable, it's just trickier to implement but it can decrease the time required to unload them. Imagine that there is an enemy that appears both in the level 2 and in the level 3, you won't unload its meshes and its textures when you go from the former to the latter.

Julien Gouesse | Personal blog | Website | Jogamp
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Cero
« Reply #10 - Posted 2015-08-12 23:15:22 »

Yeah I would do that in any case. I mean you just compare the list of textures and sounds you have loaded to the one needed for the next map.
But I was unsure whether to unload everything I dont need each map change... well overall i guess my loadings and unloadings are rather quick so it should be fine; I really dont wanna have memory leaks.

However I have though about having a game without loading screens, with everything streaming... but yeah that seems like a huge pain. But also considering my game does feature cutscenes and jump to other locations occasionally, I probably shouldnt do that in the first place.

Offline Springrbua
« Reply #11 - Posted 2015-08-13 07:43:27 »

I guess it depends on the size of the game (or actually on the number and size of the ressources you use for it).
In a little game i started, i was planning to use 2 TextureAtlases, one for UI, one for the Game. When loading a level, i can simply load the GameAtlas, when leaving the level (and goind to MenuScreen), i can easily unload them. UIAtlas is alwas used, for example for the In-Game-Menu.
In some cases, at least for desktops, it might also be enough to load everything on startup and unload them when the game is closed.
Ofc, in bigger Games, with more and bigger Textures, Sounds, Models... thats no solution.
Offline Cero
« Reply #12 - Posted 2015-08-13 15:57:30 »

Yeah for casual games I did indeed just load everything in. But yes... little bigger now

Pages: [1]
  ignore  |  Print  

Riven (397 views)
2019-09-04 15:33:17

hadezbladez (5280 views)
2018-11-16 13:46:03

hadezbladez (2204 views)
2018-11-16 13:41:33

hadezbladez (5544 views)
2018-11-16 13:35:35

hadezbladez (1150 views)
2018-11-16 13:32:03

EgonOlsen (4584 views)
2018-06-10 19:43:48

EgonOlsen (5462 views)
2018-06-10 19:43:44

EgonOlsen (3119 views)
2018-06-10 19:43:20

DesertCoockie (4015 views)
2018-05-13 18:23:11

nelsongames (4708 views)
2018-04-24 18:15:36
A NON-ideal modular configuration for Eclipse with JavaFX
by philfrei
2019-12-19 19:35:12

Java Gaming Resources
by philfrei
2019-05-14 16:15:13

Deployment and Packaging
by philfrei
2019-05-08 15:15:36

Deployment and Packaging
by philfrei
2019-05-08 15:13:34

Deployment and Packaging
by philfrei
2019-02-17 20:25:53

Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!