Just to clarify, some textures can be split up to save VRAM in rare circumstances - if you have a 32x4096 image, for example, some graphics cards might place that on a 4096x4096 surface in memory, wasting a large amount of VRAM. In that case, splitting it up in to smaller chunks might save VRAM (it depends on the design of the graphics card though, I think). However Tulamide's example shows how it is easy to split up a texture and not save any VRAM at all.

It's also a good point that games are not typically designed with large, pre-rendered images. If you have 100mb of textures for a large level this may not even fit in the memory of a 128mb graphics card (due to operating system/other stuff stored there) and instantly you have a huge requirement to have a 256mb card to play the game! Even most commercial 3D games don't use that much memory - they use the principle of a smaller set of textures which are tiled and repeated as well, but with a lot of processing on top. So you should definitely prefer building your levels out of tiled backgrounds and sprite elements rather than pre-rendering - graphics cards aren't designed for huge prerendered images.

If you are aiming to make a high qaulity 2D game, I don't think you should be scared of 100mb of VRAM. Steam's survey [>] is probably an okay way to see what a lot of PC gamers are using, only about 7% have 128mb or less VRAM. So unless you're making one of those mythical games that everyone can run (or a game for non-gamers), I think you'll be fine using 100mb or so of VRAM.

@Arima- I'd love to make a level editor. Not only to save on VRAM, but to speed up the level building process, and have friends and fans build their own levels too. Unfortunately, as far as I'm concerned, level editors can get really complicated and time consuming Maybe next time lol.

@alspal- Well that's quite reassuring

I've added a lot to my map and realized it might not take up as much VRAM as I thought, especially when using some of the techniques mentioned here. Shouldn't be too difficult to stay under 100mb now.

Talking about importing an array with tile's locations, Construct could do that with the tiles that Tiled exports? (http://www.mapeditor.org/) Or it's imposible? If construct has python it shouldn't...

[quote="Arima":2722kle9]What you should probably do is make your own level editor to make the process easier, then have the level editor export an array with tile's locations that can be loaded by the game.

As a bonus, you can release the level editor with the game and people can make their own levels![/quote:2722kle9]This is a very interesting idea. Could you expand upon it? How would we go about creating a level editor to work with Construct?

The idea is simple, you make a utility with construct where you can select tile types and place or move them. Upon saving, loop through each tile and set the tile type and position to the array, then have the game read the array at the start of the layout and create the tiles from it.

There is some other stuff too, like starting locations and such, but I think it's easier than it seems. I was able to make a basic level editor in a day.

[quote="alspal":v6wksn27]If you are aiming to make a high qaulity 2D game, I don't think you should be scared of 100mb of VRAM. Steam's survey [>] is probably an okay way to see what a lot of PC gamers are using, only about 7% have 128mb or less VRAM. So unless you're making one of those mythical games that everyone can run (or a game for non-gamers), I think you'll be fine using 100mb or so of VRAM.[/quote:v6wksn27]If you make levels as a single large graphic, you'll end up with a single level consuming all your memory budget and leaving little space for other objects. Also it'll look really static.

I'll just quote the Wii's memory limit (88MB) and that memory is SHARED (both textures and code and data). Then I'll link to Muramasa. [url:v6wksn27]http://www.youtube.com/watch?v=tSefPi8vpUc[/url:v6wksn27]

Your best bet for high quality 2D games (and any other high quality games) is NOT disregarding limitations, it's finding workarounds to them. It's SMOKE AND MIRRORS.

Draw your art in layers.find parts that repeat. Use only one graphic for each. You have a huge tree? ok, do you really need each part of the trunk to be unique? no. Use a trunk section and place copies in Construct. Place branches on top of that. You just saved 50MB of VRAM.

tlr;dr..... draw the basic blocks of your art in another software, assemble it into it's final form in Construct.