Currently texture management within the IDE is only for VRAM which is memory loaded into a dedicated graphics card. You might be wondering why is this needed? Doesn't GM already pack sprites onto texture pages efficiently to reduce memory usage and don't we have memory management with texture_flushing? Yes this is true however its still rather limited. This is because GM1.4 creates a 32bit application when you compile your game, I'm not sure if GM2.0 compiles a 32bit game. Currently in GM, that memory limit is 2GB (but you really only have ~1.7GB) meaning that the game will not run if you use more than this amount. One of the main problems we have to solve especially for the large projects is running out of memory. If anything in the spoiler is inaccurate, please inform me so I can modify it! (skip to the tutorial if you know about this) GM does a fine job on its own for smaller games and unless you desire this amount of control and extra work, you are better off using GM's built in IDE capabilities Its useful mainly for those who have really large projects and large resolution games where memory tends to be a source of concern. This method is not necessary for everyone and every project. This provides you with the freedom to proper memory management natively without dlls or extensions which results in allowing you to create bigger games and use more texture memory at once than you otherwise would be able to. Doing so will allow you to take control over your texture pages to optimize texture memory instead of having GM do it for you.
#TEXTUREPACKER FREE TRIAL HOW TO#
In this tutorial I will be demonstrating and showing you how to integrate the program TexturePacker by CodeandWeb into your graphics workflow. But the techniques are applicable to other JSON data applications.
#TEXTUREPACKER FREE TRIAL SOFTWARE#
This particular example uses texture pages created with a commercial software package called TexturePacker. This is a tutorial about creating and decoding JSON data structures.
0 kommentar(er)
