Texture Memory Used: 700.00 Mb

Solar2D General Questions/Discussion
#21

This thread has been a bit hard to follow, but let me try to address a few things.

  1. Power of Twos:  In the case of a 225x1380 image sheet, a 256 x 2048 x 4 amount of memory will be allocated for it. In other words it will use 2,097,152 bytes of memory (2 Megabytes or 2MB).

  2. The act of loading an ImageSheet will allocate the needed texture memory. After that display.newImageRect()'s and display.newSprites() will actually use the ImageSheet’s graphic memory.

  3. On Android, we automatically scale image sheets that exceed 2048 on the long side to 2048 to help older devices work. 

  4. How much memory your app has to work with is a function of the device, operating system and memory allocated to other apps.  You might find your app starts struggling with memory problems at 50mb of texture memory. Yet on my Mac, I’ve got 1.5 GB of memory on the GPU and a 700mb amount of texture memory would only be using half of what I have available. On some mobile devices 700mb is more memory than the entire device has and I’m surprised that you can run at all on them.  Clearly that memory has to be getting paged in and out if you’re even able to start up. This isn’t a Corona limit, it’s a hardware/OS limitation.

Rob

#22

Thank you Rob!

For information I don’t publish the game who use 700mo of memory, I divide all image by 4.

I will work on image size, because I thank it don’t change anymore with vulkan and other new soft.

With texturepacker, I can optimize image.

For example I have actualy two animation in different image. TexturePacker will put them in a same image. And I create two imagesheet (like this: https://github.com/codepaladin/SpriteSheet ) does it use less texture memory or the same as previous because I create two imagesheet?

#23

Let’s say you have two image sheets, each one is 225x690. This requires a 256x1024x4 or 1MB image each or 2MB total.  Your single image sheet of 225x1380 is really a 256 x 2048 x 4 image is a 2MB image, there for they use the same amount of texture memory. There will be some Lua memory overhead for the tables holding the two image sheets. There is probably some additional OpenGL memory being used by two sprite sheets, but on the scale of bytes vs. megabytes it’s not that relevant. 

Now the more you slice up the image sheet into smaller chunks, say each character’s animation in their own image sheet, now you’re starting to get into a chase where the overhead adds up even though the texture memory for the images isn’t increasing significantly. 

Rob

#24

Thank you! Two imagesheet on one image it doesn’t use much more texture memory than a imagesheet on one image

#25

Hi,

TexturePacker don’t change anythings. I replace 350 images by 32 images and the texture memory increase of 10mo. It’s because now we use openGL 2.0 or higher. 

For test I have write a code who change the actual code to the new one.

Old code:

l.attgauche=graphics.newImageSheet( "AnimVF/mechant/balrog/balrogatg.png", { width=169, height=300, numFrames=6,sheetContentWidth=169,sheetContentHeight=1800 } )

New one:

l.depgauche=graphics.newImageSheet("test-30-.png",{sheetContentWidth=2048,sheetContentHeight=2048,frames={{x=248,y=0,width=228,height=230},{x=248,y=230,width=228,height=230},{x=248,y=460,width=228,height=230},{x=248,y=690,width=228,height=230},{x=248,y=920,width=228,height=230},{x=248,y=1150,width=228,height=230}}}) --AnimVF/mechant/assassin/assassinmvmg

If corona decide to open 8bits image in 8bits instead of 32bits I can divide by 4 the texture memory size.

Someone has other idea to improve the memory texture?

#26

Hi.

Do you have a good idea of how that memory is distributed? Is everything on screen at once, either regularly or in worst case scenarios? Is much of it static? Would it matter to have comparable amounts of memory sitting around in RAM? (These are situations where I can see some opportunities for plugins to help.)

It might be worth putting in a feature request for compressed texture support, which I didn’t see listed (there is this, though). I suspect this is already implemented in part, for masks (their peculiar size requirement sounds like S3TC blocking), but was a hassle to do more completely. Just a guess, of course.  :) In any case, it would basically have to be built into Corona.

Possibly relevant info:

There are some open-source libraries for this, e.g. in gli (the loaders for DDS, KMG, KTX), mojodds, and (somewhere, not sure exactly where) in NVIDIA’s tools, for loading files, as well as on-the-fly memory stuff like stb_dxt (and maybe crnlib).

#27

This is when nothing is display but a lot of imageSheet are load.

I have already give some point to this request a long time ago :slight_smile:

I will try to use those libraries but I am not good for using libraries. :frowning:

Thank you for informations!

#28

Oh, sorry, I should be more explicit.  :) Those aren’t Lua libraries, but I thought they might be good supplemental material (“look, there’s support!”) in case you wanted to make a feature request.

Going back to an earlier question, will these image sheets all be on screen at once? (If this is for Stronghold, for instance, you might only see some of the terrain.) If the answer is no, maybe you could split your sheets up and stream them on-demand into a canvas and build tiles off that? For instance, evict any tiles that aren’t inside the screen and that the camera couldn’t reach within X frames.

If it’s also a problem of image caching, maybe you’d want to go a step further and use texture resources too.

(This is giving me some ideas to improve a plugin or two, as well.)

#29

Can you give some more information on what you load for one screen? File dimensions - file type - file size would definitely help. Something like this: 1920x1080 - jpg - 90kb

#30

ok, I am sorry I am not cristal clear. :frowning: This texture memory used is when there is nothing display but a lot of imageload (with " graphics.newImageSheet( " ) I load near 400 images. I load all image when user are on the game menu. I load every things expect maps, I load only the map of the play level.

Near all my image are png (17.8ko)

{ width=225, height=230, numFrames=6,sheetContentWidth=225,sheetContentHeight=1380 } )

and property are like this one.

I perhaps make a too big game for corona sdk :frowning:

#31

Actually, that’s just bad practice. You shouldn’t load all your assets at once if you are not using them at the same time. Considering CPU, GPU, RAM power / speed of today you can easily create some of your assets while the game is on the run. Also, when you try to load all of your assets at once, you will face serious performance issues on various devices. Players will have hard time playing your poorly optimized game. They will need far better devices / configurations to play your game than it’s needed.

Technically speaking, as far as I know, OpenGL frees up texture memory in powers of 2 like when you are trying to create a 225x1380 image sheet, OpenGL will free up a memory of 256x2048 (or 2048x2048, I’m not sure about that) which is the core of your problem here. This is how it will allocate memory for your single animation. Remember, you have 399 more of that animation. Best practice here should be partially loading your sprite sheets like StarCrunch said. It’s also the right way to do it.

Lastly, you should also check out Texture Packer. It works pretty great when you are trying to optimize your assets.

https://www.codeandweb.com/texturepacker

Hopefully, someone with more knowledge could appear and let us know how texture memory allocation is handled in OpenGL and Corona :slight_smile:

#32

I thank for image it was not anymore like that. OnpenGL2 use the size of the image for the memory. Need to be confirm.

Most of the time there is no loading in my game and no lag. Loading are less than 1sec.

And for perf, the game is at 30fps with more than 100 characters on maps for 80% of device. 

What do you mean by “partially loading your sprite sheets”? Don’t load all image or load by a different way?

“Hopefully, someone with more knowledge could appear and let us know how texture memory allocation is handled in OpenGL and Corona  :)” I hope someone show and tell us how it realy work

#33

Are you sure that loading 400 images of that size takes less than 1 second? I’ve tried loading a 720x1280 png on an iPhone 5 and Samsung Galaxy S3 once and it took more than 1 second for that single image. If you pulled this on device that’s impressive. Can you tell me the device you are testing the game on?

Do you show 100 characters at the same time? Even if this is a game for PC, that’s too much. I can only recall Total War series, Mount & Blade series, No Russian level in Call of Duty and a level in Hitman that shows that many characters on the screen at the same time and they all use their own engine to optimize those scenes. Maybe you should try loading those characters when you show the related part of the screen.

Again, we would be glad if someone who knows how this works in Corona and OpenGL can shed some light on it.

#34

Loading are during the game menu. And when the player have finish to choose what he want, he have to wait a sec, my data are create with 10 000 users.

I have 100 units who walk or fight. You can try it, ( Stronghold on google play). Some user with good phone do some game with more a thousand of unit on the map.

I have optimize everythings, I have create my own game motor, 3 isometrics, physics, AI…

#35

Sorry, I don’t have an Android device to explore Stronghold at this point but I must say, I’m very impressed by what I see in the trailer. Really great work, congratulations :slight_smile:

I can’t test it right now so my questions will be based on the trailer video. Are you loading all soldiers, zombies etc. at the start of the level? If so, can you try creating soldiers right before they appear on the screen? This way, some of them will already be dead by the time the reinforcements have arrived so you can remove their “walking” sheets and display the gravestone.pngs. You should know that I’m assuming animation sheets and gravestones are two different files.

#36

I load all unit because it’s only in a few level we have many identical unit.

I will try to do it, I will save in a table all display image who are not use any more on the screen and use them again when I will need them for another units.

( Hopefully, someone with more knowledge could appear and let us know how texture memory allocation is handled in OpenGL and Corona  :)   )

#37

Sorry for butting in here, but I don’t really see a problem being presented. Are you saying that performance is hindered by the high amount of texture memory? Since Corona can build for desktop machines, 700mb isn’t a taxing load for some installs. 

There have been some viable options decreasing texture memory load. These solutions are common practice when developers are working with Corona. Perhaps you could outline the  problems you’re encountering, and how they may relate to the high amount of texture memory used in your game? That might spur some Corona support engineers to give a more focused response to the issue.

#38

To use a lot of memory is not big problem but some phone don’t have much texture memory and the game crash and on some device there is app in background who are kill. 

#39

You’ve received quite a few very good suggestions and solutions that should present clues to resolve the issue. The main sugestion is really the only one you should be investigating given by bgmadclown below:

Actually, that’s just bad practice. You shouldn’t load all your assets at once if you are not using them at the same time. Considering CPU, GPU, RAM power / speed of today you can easily create some of your assets while the game is on the run. Also, when you try to load all of your assets at once, you will face serious performance issues on various devices. Players will have hard time playing your poorly optimized game. They will need far better devices / configurations to play your game than it’s needed.

“Optimization” is important when dealing with mobile development, since resources are at a premium, and one cannot just run rampant on lower-spec devices available on the market. To sum up, this is a device/optimization problem, not a Corona problem.

Could you let us know what you’ve done to try to mitigate the issue, and why you can’t perform the optimizations that have been suggested already?

#40

The problem on google play if you app crash on some device, these users write a bad comment and it’s a big problem. Secondly with corona when we load image it’s stop the game runing. The game freeze until the image is load. If I load on demand image it’s going to lag. The only issue is to reduce the image size, I divide all image size by 4 or more. I have try many things for exemple put in one image a lot of image but it’s don’t change the texture size but the loading time(1ms by image remove). It’s make 3y I am on this project, I can correct every things by myself but not this problem