11 replies to this topic

[BPzeBanshee]

I couldn't find anything with the search function and there seems to be no other discussion about it, so here goes.

In response to the admin's post on this bug report, will the GMSPR/GMBCK format be replaced with an alternative external format? It seems silly to remove it if you're not going to replace it as memory usage and EXE filesize bumps up a fair bit in GM when internalised and existing projects that make heavy use of this are going to be a pain to internalise again without some kind of alternative.

[Robert3DG+]

I think it has been mentioned several times to finish your project in the respectful program you started it, or be prepared for losses.

As for the reason it was removed and if it's going to get replaced, I do not know. Maybe someone more inside can explain if they see the need to.

[Erik Leppen]

The cool thing is...the file format is already there: just look for the .sprite.gmx files in the Sprites folder of your games. The same format could be used for "loose sprites".

[alexandervrs]

I never really had the chance to try loading a sprite externally from a gmspr. However I do a lot of external resource loading and store all the external files inside a passworded zip file using an extension for convenience and consistency.

I noticed though that there's a huge memory usage when sprites, background and sounds are loaded externally from PNG/WAV etc. files. Don't see how gmspr or internal sprites would be any different from this.
A while ago in the GM6 days, all external images had to become bitmaps expanded in memory which used a lot of RAM, but wasn't it supposed to be fixed when PNG came along? I think I had filed a bug about this before the bug database maintenance.

[BPzeBanshee]

I think it has been mentioned several times to finish your project in the respectful program you started it, or be prepared for losses.

As for the reason it was removed and if it's going to get replaced, I do not know. Maybe someone more inside can explain if they see the need to.

That much I already knew well before I joined the forum. I also realise that GM:Studio is currently a buggy and unstable program undergoing a significant rewrite, which is why I ask if there's going to be some kind of replacement system now - if there is a replacement and its open to suggestions this could well be the place to put them.

Ideally it'd be great for some kind of easy way to have all the external resources in the form of a heavily compressed/encrypted file of some sort, like I've seen some programs written with Allegro do, but that's just wishful thinking.

Erik Leppen might be on to something though: I don't know if those .sprite.gmx files are encrypted/compressed or anything but they could do - I'm thinking that a future GM Studio build exporting to the Windows C++ Runner could have a external file structure similar to how someone would have <localdir>\images\whatever.gmspr and <localdir>\backgrounds\whatever.gmbck but with this .sprite.gmx etc instead. I don't know about how much external images affect memory usage as opposed to internal images but I think anyone who externalises their files knows how much of an improvement on the GM runner's loading times externalising such stuff is.

[Erik Leppen]

I don't know if those .sprite.gmx files are encrypted/compressed or anything

No, they're XML.

[Nocturne]

There will be no replacement system. Those commands are going as they are no longer necessary due to how the files are being stored now (as Erik Leppen has pointed out).

[BPzeBanshee]

There will be no replacement system. Those commands are going as they are no longer necessary due to how the files are being stored now (as Erik Leppen has pointed out).

So let me get this straight: when EXE support is brought back (it seems to be greyed out for me) and we distribute Windows apps we're stuck with sprites/whatever.sprite.gmx having to be in the same folder as the EXE and/or included into the EXE like the old versions?

[rwkay]

No... the GMX format is only for the Maker we are deprecating support for the .gmspr and any of the external resource .gm* formats at runtime as they are not multi platform friendly, for v1.0 of GameMaker:Studio there will be no replacement on day 1.

In the future we will have a system for creating multiple resource files that can be dynamically loaded and unloaded at runtime so you can have a base resource pack and then load other resource packs in (these will allow the full gamut of resources to be present not just single sprites or backgrounds).

Until this comes to fruition though we are deprecating the older external formats and starting from a clean slate - if you have a huge game that requires them then stick to GameMaker 8.1 - Studio is not for you. We will be supporting the larger games in the future but I cannot say what timeframe that is, it really depends on demand for it.

Russell

[BPzeBanshee]

Oh, okay. So I was kinda on the money about Allegro's resource files then. Thanks for clarifying.

[kburkhart84]

No... the GMX format is only for the Maker we are deprecating support for the .gmspr and any of the external resource .gm* formats at runtime as they are not multi platform friendly, for v1.0 of GameMaker:Studio there will be no replacement on day 1.

In the future we will have a system for creating multiple resource files that can be dynamically loaded and unloaded at runtime so you can have a base resource pack and then load other resource packs in (these will allow the full gamut of resources to be present not just single sprites or backgrounds).

Until this comes to fruition though we are deprecating the older external formats and starting from a clean slate - if you have a huge game that requires them then stick to GameMaker 8.1 - Studio is not for you. We will be supporting the larger games in the future but I cannot say what timeframe that is, it really depends on demand for it.

Russell

For me, the demand for this feature(or similar) is high, not so much to keep things out of the executable, rather in order to control the resources(graphics especially) that are in the video RAM at a given moment in the game. I know that the "5 texture page limit" doesn't apply exactly to mobile platforms, and rather depends on the video RAM of the given device, but since GM at the moment keeps everything loaded from the start, it limits game creation as far as longer/bigger games(like RPGs) go. But, with something to control loading and unloading of graphics from video RAM, we could have as much as we need, with the only limiting factor being the phones storage space and the limits of downloads, like where some carriers won't show certain apps due to size, or only when on WIFI to avoid data usage, and other similar limits.

It is true that mobile games in general are not so "hardcore" and tend to be only a few MBs, but it will be nice when the limits are space related instead of video RAM related.

[rwkay]

These functions are not coming back...

Russell