• Hey! Guest! The 39th GMC Jam will take place between November 26th, 12:00 UTC and November 30th, 12:00 UTC. Why not join in! Click here to find out more!
  • Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

Discussion Why doesn't GM2 have texture compression?

S

Sezer

Guest
One of the reasons I cant consider Game Maker a professional 2D games tool is because it doesn't give us any option for texture compression.

A 1024*1024 texture page takes up 4mb in vram. Spine assets take up even more memory in vram and have to be all loaded when the game starts. This makes it impossible to create a game project with a large number of Spine assets or a game project with many items on screen as vram bloats up very quickly.

Texture Compression techniques such as DTX1, ETC, PVR, etc offer a huge amount of savings in both disk and vram size.
http://2.bp.blogspot.com/-ue4ga_0fTc4/VooH_esJ5WI/AAAAAAAAAIo/jVax_Uyl8VQ/s1600/image02.png

For a beginner this might not be necessary but for advanced users we should be given the option. This is really holding game maker 2 back from being taken seriously as game development tool. I had lot of high hopes for GM2 but when I saw the changes it feels like game maker is moving toward becoming more of a learning tool. None of the serious issues brought up by the developers have been addressed but instead we got more promises and an unnecessary update to the image editor (there are already tonnes of free programs to edit images we don't need a new Gimp or Photoshop).

At this point I feel like I have no other choice but to look for another engine which is annoying because i already wasted over two years learning Game Maker.
 
S

Sezer

Guest
I think you misunderstood read this article:|

"For most Android game developers, PNGs are a simple, easy to use texture format that offers ‘good enough’ compression alongside alpha support, which is important since the dominant form of game in the mobile market is 2D based. But the truth is that while PNGs may help with distribution, they don’t help you when it comes to GPU residency; they are still full, fat textures eating up your available memory. But, it doesn’t have to be that way."

http://mainroach.blogspot.com.au/2014/03/the-png-vs-gpu-battle-on-android.html
 
Last edited by a moderator:

Rushad

Member
I agree completely. I feel like there should have been a redo of the way textures are managed.

We should also be able to flush textures individually instead of all at once, and external sprites are still useless because they create a new texture page each time.

Some of these changes would really make GM2 an instant upgrade. I feel like we are being sold the same product twice. I really love game maker, it has a lot of potential to be the best 2d games tool but these are big setbacks.
 

gnysek

Member
Mike was telling something about different image format in future. I may be wrong, but from what I remember, no matter in what format texture is, it's still unpacked into memory as 32bit per pixel in case of RGBA.

Also, nobody said, that GMS:2 won't get new features, you need to remember, that they are currently relased IDE for Windows, and runner for Win/Mac/Linux, but in same time they working on:
- GMS 1.4.x runner fixes
- GM:S 2.x IDE for Mac, and updates for Windows
- GM:S 2.x runners for Android, iOS, HTML5, PS4, Xone, M$ UWP, and fixes for Mac/Linux/Windows

So, they are working on 12 different sub-products, while there's probably less than 12 programmers in YYG. Giving all nice features takes time because of it - so they will provide many new features (that's why GM:S2 was created), but at a later time (year or even two).
 
Last edited:

rwkay

YoYo Games Staff
YYG Staff
OK for a 2D engine texture compression is not the way to go...

There are no lossless hardware texture compression formats - none - we initially had support for both DXT formats and PVRTC and have since moved to just using RGBA as the quality loss was unacceptable to our authors.

As soon as we get a good lossless texture compression scheme supported in hardware then we will jump on it - we are planning on allowing compressed textures to be loaded at runtime but have no plans to support them in the IDE directly.

Russell
 

GMWolf

aka fel666
In 2D, simply reducing your texture size gives much better results than using compression.
Generally speaking, a 1.6x reduction from 1:1 scale looks nice enough for background elements, and 1/2s your memory usage.
 

rwkay

YoYo Games Staff
YYG Staff
It should have been mentioned in the 1.4 release notes when we added it... not sure it was (I cannot find it)

Russell
 

Rushad

Member
@rwkay
Those functions look awesome , cant wait to try them out :)

About the texture compression does Game Maker use RGBA8888 or RGBA4444 ? Also why does a spine 1024*1024 texture take up double the memory of a normal 1024*1024 texture ?
 

rIKmAN

Member
So, they are working on 12 different sub-products, while there's probably less than 12 programmers in YYG. Giving all nice features takes time because of it - so they will provide many new features (that's why GM:S2 was created), but at a later time (year or even two).
That's not really an excuse, why not devote people to fixing/updating an existing product (1.4) first, THEN focus on GMS2 and all the various runners etc?

It's not like people hadn't already been waiting for GMS2 for a while so another few months would have been no real big problem except maybe to YYGs bottom line. The way it has been handled means you have existing 1.4 users waiting for fixes and updates and GMS2 users waiting for fixes and updates to the beta because the time devoted to working on each product has been spread so thin.

Does GMS2 still load every single sprite into memory at game start, or has that changed?
Does GMS2 still create a new texture page each time you add a single external sprite?
Do these new commands (that aren't in the 1.4 EA release notes) allow any viable workaround to the above problem?
 

gnysek

Member
GMS1.4 doesn't load any sprite into memory. It loads texture pages. And it's loading only those texture pages, on which are sprites you're drawing.
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
Moderator
Does GMS2 still create a new texture page each time you add a single external sprite?
Yes. How else would it work? Do you expect your game to use a texture packer to create (or recreate) a texture page "on the fly" as sprites are loaded?

Do these new commands (that aren't in the 1.4 EA release notes) allow any viable workaround to the above problem?
They have been in 1.,4 for quite some time, just that the manual wasn't up to date with them (but I'm pretty sure they were mentioned in the release notes a few months back when they were added). And yes, it permits you to load/discard texture pages as required.
 

HammerOn

Member
A 1024*1024 texture page takes up 4mb in vram. Spine assets take up even more memory in vram and have to be all loaded when the game starts. This makes it impossible to create a game project with a large number of Spine assets or a game project with many items on screen as vram bloats up very quickly.
I fell like you are proposing the solution for an issue other than the actual problem you are talking about.
We don't fix this using other formats for GPU but simply not loading all textures to VRAM at game start.
 

rIKmAN

Member
Yes. How else would it work? Do you expect your game to use a texture packer to create (or recreate) a texture page "on the fly" as sprites are loaded?
I don't know, that's why I'm asking the question - so I do know.
I don't "expect" anything - I'm just asking a question - but since you ask I think being able to add a sprite to an existing texture page wouldn't be too far out in the realms of possibility.

just that the manual wasn't up to date with them
The manual is my first port of call, as it is with any software - so yeah that explains it.

Regarding the manual, has it been updated with any new stuff yet from the latest EA?
If not, is there any documentation anywhere on usage of ie. Spine Events (and the new functions that were mentioned)
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
Moderator
Regarding the manual, has it been updated with any new stuff yet from the latest EA?
I have to take responsibility for this I'm afraid... With all the documentation that GMS2 required I haven't been able to get the 1.4 docs up to date. :( However, I've been working on them this week and I'll hopefully have them all done for the next update...
 

Rushad

Member
I fell like you are proposing the solution for an issue other than the actual problem you are talking about.
We don't fix this using other formats for GPU but simply not loading all textures to VRAM at game start.
hmmmmmm
 
Last edited:
S

Sezer

Guest
we are planning on allowing compressed textures to be loaded at runtime but have no plans to support them in the IDE directly.
If you use the right art style and modify your graphics a little theses textures can look very good for amount they get compressed.

Can you elaborate on this please? Will we be able to use the most important ones PVR (ios), ETC2, ATTIC, S3TC?
 

gnysek

Member
Yes. How else would it work? Do you expect your game to use a texture packer to create (or recreate) a texture page "on the fly" as sprites are loaded?.
spite_add_to_texture(filename, textureId, textureX, textureY); - would replace pixels on existing texture page. Width and height would be computed from image size. For runner, every sprite is just a coordinate on texture page, so in theory they can even overlap and there's nothing wrong in it (if it's programmer mistake, then he should fix it).

Also, there could be a function to add empty texture page (alpha transparent). That would be EXTREMELY useful for downloading sprites from web - for example new items to game (JSON + sprites), and they could be cached on disk this way (or even whole texture page, as PNG + JSON/XML with coordinates).
 

Mike

nobody important
GMC Elder
Isn't going to happen like that.

Creating (our) standard texture pages is a complex, recursive process and you can't just decide at runtime to add a random size to a page.

There are simpler processes what will just use a basic POW2 subdivide that could work better, but again you'll never be able to add to a texture - more a dynamic texture group. If a sprite can't fit on a page, it'll have to add another to the group. These methods aren't nearly as optimal as the compile time one, but it would work.

We have a lot of other things to do before we start getting to anything like this though, and to be honest, having IDE built "level packs" (or something) would still be what I'd prefer.
 

gnysek

Member
If you allow to create external textures in IDE, that would be great. In what I proposed, drawing sprite bigger than texture, would just cut sprite - so bad programmer would just break what he wants, and that could be only for advanced users, but I also like having "level packs".

Still, having a game using facebook which could load users profile photos, would create lot of new texture pages with avatars, so that's why I came up with my idea.
 

GMWolf

aka fel666
You could write your own texture packer. A simple greedy algorithm should perform well enough.
Use surfaces and convert to background to get the texture.

Then build vertex buffers with the correct UV s, and use those as sprites.

Of course, it would be much, much better if YYG could include this in GM.

@Mike could you explain further what you mean by 'level packs'?
 

Ricardo

Member
@rwkay, @Mike, sprite_flush and sprite_flush_multi are going to be implemented in HTML5? I'm testing here (webGL ON) and I got:
Uncaught ReferenceError: sprite_flush is not defined
Uncaught ReferenceError: sprite_flush_multi is not defined

Looking in the JS file, now I can see that draw_texture_flush() isn't empty anymore (GMS 1.99.525), but it still doesn't release any VRAM (webGL on, Chrome) :(
I know this isn't the first time I ask for this (1, 2), but this is affecting a very important (paid) project.

I remember in August @Mike said "We're hopeful the flush stuff will be looked at reasonable soon as there are several other issues with the WebGL resources".
Unfortunately for my project, looks like "reasonable soon" isn't gonna be anytime soon :(
 

rwkay

YoYo Games Staff
YYG Staff
draw_texture_flush() has been implemented in HTML5 now, at least as much as we can - it is calling the WebGL function to remove the resources - though I suspect that Web browsers may do a form of garbage collection so the memory is not freed immediately... how are you checking???

We will implement the sprite_flush etc on HTML5 (did not realise they were missing)

Russell
 

Ricardo

Member
draw_texture_flush() has been implemented in HTML5 now, at least as much as we can - it is calling the WebGL function to remove the resources - though I suspect that Web browsers may do a form of garbage collection so the memory is not freed immediately... how are you checking???

We will implement the sprite_flush etc on HTML5 (did not realise they were missing)

Russell
hey @rwkay, I'm using Chrome's task manager (there's a specific tab you can enable on it that shows video memory. Anyway, there are some "memory" tabs available there, and in none of them you can see a memory reduction when the texture flush is called, no matter how much you wait). On Firefox I'm using about:memory.
If you close all programs in your PC leaving only one tab with a game, a program like GPU-Z can be also used to check indirectly how many VRAM is being used.

About the browser's garbage collector, I agree that the browser can take a while to release memory, but, when webGL is on, I can left my game running 1 hour straight that nothing happen. The memory usage is always the same no matter how much times I call draw_texture_flush().
(a curiosity: with webGL off, it takes a while, but the VRAM is released).

I know that exist a way to release video memory in webGL, as I've tested the commands by myself in small examples (no GMS, just JS and webGL). Also, there are game-engines out there which use webGL and they can release memory correctly.

I suspect that GMS isn't cleaning right the reference variables for the textures, thus preventing the garbage collector to works as expected.
 

Rushad

Member
Hey Russel,

Im using EA v1.99.493 and I tried these functions on Android and they dont work. Are they functions only for windows ?

sprite_flush and sprite_flush_multi were not clearing the textures from vram.
 

Ricardo

Member
Hey Russel,

Im using EA v1.99.493 and I tried these functions on Android and they dont work. Are they functions only for windows ?

sprite_flush and sprite_flush_multi were not clearing the textures from vram.
You should try using the last EA version (1.99.525). From what I know these functions are expected to work in all platforms.
 
Top