Giant assets, texture page size limit - best approach?

[Nathan Laing]

G'day all!

Working with an 'asset' that is multiple times the size of the 2048x2048 texture page size limit.
Currently, this asset has been broken down into squares each exactly equal to this limit, and is then later 'stitched' together in code.

As you might imagine, with various other objects and their sprites continually swapping in and out of memory, there is some occasional stutter.

What options exist for working with such a giant asset, eliminating the stutter, and (ultimately), maintaining both size and quality?

 

[ajan-ko]

Is your picture/sprite more than 2048? or you're creating a map more than 2048?

 

[anomalous]

What max monitor resolution are you trying to support? You typically cannot display multiple assets that size stitched together, so I'm not sure why this would be an issue.
I also don't see why it needs to stutter, it may be how you are doing it, or other things going on. Did you run the profiler to see precisely where your slow down is?

 

[Nathan Laing]

ajan-ko: The image files are exactly 2048x2048 pixels in size---specifically cut to this size to adhere to the texture page size limit.

anomalous: Of course, on monitors with smaller resolutions than this, each image will not fit on the screen unless one is zooming in and out (which incidentally is possible), and the view can be panned about. I am not attempting to support any particular resolution. I have not yet used the profiler, but given the current simplicity of the room and the effects I am seeing, I believe it is clearly an issue of having many large-sized sprites.

For the sake of the example, imagine a floor plan of a house; The entire house has been drawn on one giant png file, and from there (in Photoshop), I have cut the image into several 2048x2048 pieces and then imported them as sprites into Gamemaker. After this, each sprite is simply drawn ('stitched' together) according to where each piece should be to recreate the house.

 

[ajan-ko]

Wait, you mean, each parts is 2048? and you're drawing them together on a room?

 

[Nathan Laing]

Wait, you mean, each parts is 2048? and you're drawing them together on a room?

Yes, 12 parts in fact, each 2048x2048.

 

[ajan-ko]

Of course it's gonna be glitch out... ~_~a
You cannot do that, image you open 12 2048x2048 image.
Do you want to make a map with size 2048 x 2048 x 12?

 

[anomalous]

So you ran the profiler and saw what that indicated a slow down?

If you really are trying to draw all of that, even though you can't display all of that, consider that in general one only needs to draw what fits on a display.

Also, zooming will introduce another layer of issues probably no matter the method you use, just be aware.

In any case, people use a variety of methods to draw on screen.

- break it up into tiles instead of sprites, and place tiles. This is how many 2D engines handle "stitching together". If there are not too many, you simply place all the tiles, and GMS handles drawing them if in view. You want to make them small enough so that you benefit from not drawing them out of view. Start with maybe 128x tiles or 256x tiles.
- draw the parts of the sprite in view. use your view coordinates and draw sprite part or draw background part, to only draw what's on screen
- do the above draw sprite, but draw it to a surface, and then draw the surface...see if its faster than the above. (it all depends on a number of factors that is best tested not guessed)
- get exotic and use buffers.

Note: this has nothing to do with texture pages or texture page size limit, at this point in the discussion.

 

[Nathan Laing]

I mentioned I have not yet run the profiler.
I am aware of, and am using "draw only if in view" logic/code - this would be potentially more effective if the pieces were smaller, as (depending on the zoom) a smaller number pieces would need to be drawn at one time.
Zooming out to 500%+ let's you see all of the images on one screen.
Tiles versus sprites; Aren't tiles just essentially sprites? (at least in terms of texture memory used). If so, using tiles will mean I will have 2048x2048 tiles instead of 2048x2048 sprites. But I get it, you are suggesting I break the pieces into smaller pieces--which is doable of course, and it coincides with the use of the "draw only in view" concept.
I have considered using surfaces, but they too use texture memory--- so I think I'd run into trouble here.
I have not looked up buffers at this point.

I understand the concept of using 'terrain' tiles to create large maps. And that is what I'll do for terrain. But this "house" instance, is not made of tiles---it is hand drawn as one large asset(and object)---hence my having to break it down (at this point) into (12) pieces.
I am after alternative ideas as to how one might "construct" a house that is essentially not (initially) made of little tiles.

Ajan-ko: The room is much larger than the 12 pieces of 2048x2048. The 12 pieces represent a house within the room.

 

[Mike]

Just to point out.... that's over 200Mbs of RAM. GFX cards don't usually like to try and read from that size or number of uncompressed textures. It's a classic area where you would mip your images....

 

[ajan-ko]

That's gonna be harsh to your memory...
So basically, if you load a texture, it's gonna be stored in memory.
If you're using tilesets, you're using your processor to work. So If you have more than 2048px room, and only using 2048 px tilesets.
That mean it's huge help to memory, because processor nowadays are super powerfull.

The only sugestion that I have are grouping your texture
https://docs.yoyogames.com/source/dadiospice/001_advanced use/global game settings/texture groups tab.html

Use your sprite as background, then adjust your horizontal, vert
only visible it when your view in your background range.

then THE MOST IMPORTANT THING: using draw_texture_flush(), each time you change room.

Edit: I have a room with 2048 x 5 or 6 texture. and it takes around 50mb ram.

 

[Mike]

RAM calculations are easy for normal texture pages. Width*Height*4*NumberOfPages=SizeInBytes. Sometimes the images are held twice due to low level drivers....

Not all pages output at full texture size, some might be smaller (due to cropping and groups)

 

[ajan-ko]

Ah, I see... I didn't know that info.
BTW, if a texture have transparent area, game maker not gonna put that space on RAM?

 

[Mike]

That's not how textures work. The WHOLE texture goes up. GameMaker DOES crop surrounding empty space, but once a TPage is generated, the whole thing is used. There is a "preview" in the windows settings you can see your texture pages.

 

[anomalous]

Yes, if you're trying to show all of that zoomed, you don't need that high of a resolution, because you can't display it anyway.

So reducing the resolution in some intelligent increments based on your zoom levels is I think what Mike recommends (mip map).
I have no experience doing that, maybe someone on the forums does. You can do a poor man's version if you limit the zoom to fixed increments that are paired with your duplicated lower resolution versions. But where is the fun in that?

 

[ajan-ko]

That's not how textures work. The WHOLE texture goes up. GameMaker DOES crop surrounding empty space, but once a TPage is generated, the whole thing is used. There is a "preview" in the windows settings you can see your texture pages.

Ah, I see... Thank you for the information.

Yes, if you're trying to show all of that zoomed, you don't need that high of a resolution, because you can't display it anyway.
So reducing the resolution in some intelligent increments based on your zoom levels is I think what Mike recommends (mip map).
I have no experience doing that, maybe someone on the forums does. You can do a poor man's version if you limit the zoom to fixed increments that are paired with your duplicated lower resolution versions. But where is the fun in that?

Welp, just give button --> 500% zoom --> click --> 100% zoom, 200% max.

 

[Nathan Laing]

I'd like to come back to basics a little;

Top down perspective, a human character is 64 pixels wide. (without any zoom applied) The house is also in perfect top down perspective, and completely to realistic scale with the human character. That equates to a fairly large house. In this case, an 8192x6144 size house, within a much larger game room. One can pan around the entire game room, outside the house and into the surrounding gardens for example.

As stated, the house art has been cut into 12 pieces (4x3), and each piece is drawn as it needs to be displayed. (if one zooms out, more pieces can be seen at once, obviously, and one can eventually see the entire house if zoomed out to about 500% or so)
Given that the house art is one sprawling 'illustration', and not a series of (small) occasionally repeated tiles specifically put into place to "construct" the house, what might be the best way to handle this situation, if one wanted to reduce overall processing overhead?
Should I simply cut it into many more smaller pieces and draw as sprites, stitching them together later as I am doing now? Or, should I do the same, but convert them to tiles instead? Zoomed out to 500% will mean that most or all of the sprites/tiles will need to be displayed and so ultimately the amount of texture memory needed at any one time will end up being the same, no? Even if I cut the the house into pieces (sprites/tiles) they are all unique images, not repeated tiles.

 

[Mike]

This is where you'd use tile sets. Not every pixel in your room has to be different. This also cuts down massively on memory as the tilemap will be (say) one 2048x2048, but you can have vast rooms for next to nothing as a tile is pretty light weight.

No one really has a bitmap level room larger than say 2K as its a memory hog. if you want to do that, you'd need to look into mega-texturing, which is far from simple to implement. All older 16bit console games use tiles, and newer ones might look like large bitmaps, but will use some kind of tile system - even if they aren't square.

 

[anomalous]

There is no need to convert anything to tiles per se.

To use tiles in your case, just add those assets as a background, and look up the tile_add and similar functions.
You can easily write a script to automatically tile the entire house worth of tiles, since they are ordered in the same positions. No need to place them using the room editor, and probably no need to edit the textures.

Start by placing every tile from every background in the appropriate position in the room.
See how that works for you. Then you'll probably still have zoom issues, but at least then you have a platform from which to test it.

 

[ajan-ko]

I'd like to come back to basics a little;

Top down perspective, a human character is 64 pixels wide. (without any zoom applied) The house is also in perfect top down perspective, and completely to realistic scale with the human character. That equates to a fairly large house. In this case, an 8192x6144 size house, within a much larger game room. One can pan around the entire game room, outside the house and into the surrounding gardens for example.

As stated, the house art has been cut into 12 pieces (4x3), and each piece is drawn as it needs to be displayed. (if one zooms out, more pieces can be seen at once, obviously, and one can eventually see the entire house if zoomed out to about 500% or so)
Given that the house art is one sprawling 'illustration', and not a series of (small) occasionally repeated tiles specifically put into place to "construct" the house, what might be the best way to handle this situation, if one wanted to reduce overall processing overhead?
Should I simply cut it into many more smaller pieces and draw as sprites, stitching them together later as I am doing now? Or, should I do the same, but convert them to tiles instead? Zoomed out to 500% will mean that most or all of the sprites/tiles will need to be displayed and so ultimately the amount of texture memory needed at any one time will end up being the same, no? Even if I cut the the house into pieces (sprites/tiles) they are all unique images, not repeated tiles.

So, basically, game maker is not 2D, it's 3D based program simplified to 2D. Image you watching a projector.

If you draw a sprite, what game maker does:

load the texture -> store it on memory(your sprite)-> make the 3d vertex (this is where tilesets been made) -> view it via camera. (CMIIW)

Your texture will be on memory until you called draw_texture_flush();

I remember 3d modeler always said "it's better if you have too much vertex rather too much texture"

That's why if you view 2 texture in 100% zoom, you need to make sure 10 other texture not in your memory.
If you zoom out and DRAW those 12 texture, you automaticly store those 12 texture on your memory.

 

[Nathan Laing]

So the take away is;

Cut the house into several (max size) 2048x2048 pieces (as I am currently doing), load these as backgrounds. Use the tiling system to 'grab'/create tiles of X/Y size from these background images and then draw these tiles in the correct position/order. (much like I am drawing the 2048x2048 sprites now).
Reason: In terms of processing, memory etc. Gamemaker handles tiles differently(faster) than sprites

I am still going to have to mix in some sprites for collision detection/walls and furniture, etc.

This also cuts down massively on memory as the tilemap will be (say) one 2048x2048, but you can have vast rooms for next to nothing as a tile is pretty light weight.

Doesn't this only apply if the tiles within that one 2048x2048 texture page are reused and recycled? (like grass terrain, or bathroom tiles). In the case of this house, there are almost no parts that can be 'recycled'. Each tile would be a unique tile...

 

[Nathan Laing]

Just wanted to report back;

I converted 16, 2048x2048 sprites to 16, 2048x2048 backgrounds. I made 16, 2048x2048 tiles from these 16 backgrounds and added each 2048x2048 tile to the room.

Smooth. as. glass.

Thank you very much all, for your time on this thread!

 

[anomalous]

That big and they run fine? That's great to hear, thanks for the update on the thread, those are rare...

 

[Mike]

Will be machine dependent....newer cards should manage, but take care when you start to do more complex stuff.