Map Art Discussion

[Blind Pilot]

I got my drawing pad
It came with Adobe Photo-shop Elements, so here's my first go with it.
I'm pretty sure the official Cave map and my obsession with Zion-style rock formations were the inspiration for the piece.






I was interested in how backgrounds were done, so I downloaded the official tdm_cave map to have a look (due to its very effective parallaxing effects)...
Lo and behold! Both background pieces are made up of ONE big image (c. 2800 x1 300 or so).

I have been under the impression that images (both backgrounds and foregrounds) should be split up into several smaller images to help computers process them more quickly. Indeed I have noticed when making maps that when I add a single, larger background image, the map is noticeably more choppy.

However, when I play the cave map it's as smooth as can be.

In this case, perhaps the smaller size of the cave map allows for a single image to function well?

[nesnl]

I was the one who put TDM_cave together and I believe that it was made prior to the "Import Large PNG" function. Ideally, if that map were map today, the middle layer that stays stationary would be imported using that function in order to eliminate all the blank space in the graphic.

Your map shouldn't be choppy because of a single background image. Try using the Import Large PNG for all your graphics (even if it's a solid background) and see if that helps.

[silent skies]

But even with the import large PNG function, doesn't the single object get chopped up into a bunch of smaller images?

Is it more or less efficient to directly place the single-file background in the map's own sub-directory, then 'refresh resources' in the editor and 'place sprite' to put the background in? That's what I've been doing and it seems okay in my playtests, dunno if that will change once I export the full map...

[nesnl]

Originally Posted by silent skies

But even with the import large PNG function, doesn't the single object get chopped up into a bunch of smaller images?

Is it more or less efficient to directly place the single-file background in the map's own sub-directory, then 'refresh resources' in the editor and 'place sprite' to put the background in? That's what I've been doing and it seems okay in my playtests, dunno if that will change once I export the full map...

I can't speak that technically on the subject as I don't understand the finer points behind how graphics get loaded into the game. Maybe Lamster or Karl could shed some light on the subject.

I know in the case with images that have transparent portions that it is always better to use the import large PNG. This is because it will cut out the transparent portions of the image that otherwise would still be loaded into VRAM even though there is technically 'nothing' there.

However, in the case of a large solid image, I am not sure if using large PNG helps at all. I know that one time I was having a problem with a map because I had a like a thousand individual sprites (no joke, really that many) and Karl explained something about the advantages and disadvantages of having to load a lot of smaller images versus one larger image.

Anyway, unless they post otherwise, I suggest just using import large PNG for everything as that will always optimize images with transparency and hopefully it optimizes images with no transparency.

[NastyManatee]

I know that for my last map, sketchpad, my background was all a solid image. I used the import large PNG functionality, and it beefed up the map size by about 2.5MB, which is fairly ridiculous. I have yet to try keeping it as one large image, I may do it for the sake of science to get some closer on this topic.

[nesnl]

Originally Posted by NastyManatee

I know that for my last map, sketchpad, my background was all a solid image. I used the import large PNG functionality, and it beefed up the map size by about 2.5MB, which is fairly ridiculous. I have yet to try keeping it as one large image, I may do it for the sake of science to get some closer on this topic.

The size of a map and the graphical stuttering people are describing are two separate things. If you import that image as one large image or if you keep it cut up will have no effect on the size of the map.

What I am referring to, and what the discussion ultimately is about, is how people's computers are loading and rendering the map. The things that affect this include how many images are being loaded at once and how big the images are that are being loaded (when I say big I mean actual size on the screen not in terms of MB). I was always told that the upper limit was 2.5 screens worth of graphics can be loaded at the same time without causing graphical problems. By 2.5 screens I mean that if you had a solid graphic taking up an entire screen, you could load 2.5 of those at the same time. Now, you might be asking "how can you load more than 1 screen's worth of image?" This happens when there is transparency, or overlapping images. So think in the case he originally referred to which was tdm_cave. That map has one giant solid background, so that always counts for 1 screen. Then it has a stationary midground that contains transparent areas, so that also always counts for 1 screen at the same time as the background. Then on top of that are the rocks on the game layer. So you can see that at any given point in playing tdm_cave, you are loading in somewhere between 2 and 2.5 screens worth of graphics.

Now I am not sure how that all works out, but it was just what I was told. I really wish Karl or Lamster would just chime in here and explain it all.

[lamster]

What nesnl has said is right. It's safest to always use Import Large PNG for every large image: import allows the editor to trim away transparent regions that would unnecessarily soak up VRAM and slow down rendering. A very large, completely opaque background image should work about the same as a sprite or imported png: it might compress a little better as a single, non-imported image (though I doubt the size difference is ever significant in real world situations) but it will not be any more efficient for rendering. All large images are decomposed into smaller images in one way or another before rendering; Import Large PNG ensures the decomposition is performed efficiently.

[pig_bomb]

Import large png rocks. I imported every asset in justice using it.

Does using interlaced PNG files affect how the game interacts with them at all? Using interlaced images caused some problems in my own game.

On another note Lam could you please add a function for grouping pieces of pngs together because it can be a headache selecting every tiny piece of an imported png when your whole map is made of them.

[nesnl]

Originally Posted by pig_bomb

Import large png rocks. I imported every asset in justice using it.

Does using interlaced PNG files affect how the game interacts with them at all? Using interlaced images caused some problems in my own game.

On another note Lam could you please add a function for grouping pieces of pngs together because it can be a headache selecting every tiny piece of an imported png when your whole map is made of them.

Interlaced images shouldn't affect your map because when you export the map I assume that it goes through it's own graphics compression that may or may not include interlacing.

As for a group function, that would help, but in the meantime just group your objects onto different layers. And when you import a new image just create a new view to import it onto. When it is on that new view adjust which layer it is on (the 1-9 layers) and then just move it to the correct layer after that. This should eliminate the headache of trying to select all the individual pieces of an image.