VRAM & Pow 2 Textures

— 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.

— 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.

Thanks for all the info everyone.

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...

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!

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.

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.

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.

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.

What about old games like Torment with prerendered backgrounds of huge sizes? Game itself perfectly runs on low-end computers. How do they manage this?

The second exapmle is 3d fps games like Crysis. They use HUGE amount of big textures and millions of polygons. Does mipmap system helps with memory dump or something wrong with 2d system?

How to make something like this, when you need to load 3 images instead of 1? Diffuse, normal and height map.

to Tokinsom: how level editor can helps to save VRAM? when construct loads level it loads every newly created sprite to VRAM.

Level editors help because I used to use Tiled then export these giant images for use in Construct (probably the most retarded thing I could have done.)The empty space was hogging up a ton of VRAM.

Put it this way : 10 levels using giant images racked up about 20mb VRAM, and the more I added the higher the VRAM went. 10 tilesets for use in my level editor racks up about 5mb VRAM, and because I'm re-using the textures I can make an infinite amount of levels / gigantic maps with no increase in VRAM. Also, Tilesets & BGs are global and kept in another layout, and are discarded when not in use.

You could use sprite objects/import frames/ change starting frame, and use the built-in editor. That will have the same affect on VRAM as a level editor would, but then your game will run at 10fps and it will take around 5 seconds just to place or delete a single tile once the map gets too big.

The reason those old 2d games could have huge prerendered backgrounds is because they're software rendered. That means they were storing those images in system ram, which even at that point computers had hundreds of megs worth of - easily enough to store those images. There are some integrated graphics cards out there that use system ram as VRAM, doing essentially the same thing.

Construct CAN do the same as long as a card has enough vram (and the image should be split up into 1024 square tiles just in case a card doesn't support higher). However, the more you use, the less people will be able to play it due to legacy cards out there not having as much vram.