Iso games with prerendered backgrounds in GLBasic

[doimus]

By now everybody must have played or at least heard about the great 2d isometric RPG's of the late 90s/early 2000s which were all the rage on the PC back then.To be precise I'm talking about games that used Infinity Engine, the series of games that started in 1998 with Baldur's Gate and ended in 2002 with Icewind Dale 2.
You may read about them here: http://www.mobygames.com/game-group/graphics-engine-infinity-engine and also here: http://en.wikipedia.org/wiki/Infinity_engine.

What I'd like to discuss is actual technical implementation of the engine if done in GLBasic. I'm not thinking of complex RGP game mechanics in general (inventory, dialogue and combat system) but just of graphical part of the engine.
In Infinity they used 2d sprite masks basically for everything. They started with prerendered background image, then there were smaller bitmaps drawn in solid colours to define walkable areas, height maps, shadow maps etc. There were masked aread for animations such as streams of lava or fountains and most importantly, masks that defined walk-behind areas (for example when a character walks around the back of the house and is covered by it).
It is important to mention this is not an tile-based isometric engine (like in Fallout or Ultima series), although it seems like it. This is technically more common to 2D adventure games of early 90s.

I was wondering how would this be possible to implement in GLBasic, considering it uses 3D as base for 2D graphics. We may start with solution to displaying huge backgrounds (that went up to 8000x8000 pixels or more) - some kind of tile-engine would be logical to use. Then we may go on to masking areas (this could be done with polygons, since I don't believe pixel maps are viable in an OpenGL engine). Then to pathfinding etc etc.
Discuss!!


ps. Oh, and you got great language and community going on here, nice to meet you all. 

[Moru]

Just draw the grafics in the order they appear on-screen. Start with the background, then paint the players and other moving object and finnish off with painting houses and trees that you have rendered with alphachannel on. Then do nice clouds or other things that is flying above everything (birds or whatever).

Povray is perfect for creating prerendered grafics since it handles alphachannel perfectly.

Oh, and for making pillars and similar objects that you can walk both in front and behind you need to sort them on Y coordinate so you paint the ones with the lowest Y coordinate first. The characters that is higher up is supposed to be covered by the tree that is lower down on the screen but when the characters walk down the screen below the tree, the tree should go behind them.

Collision should be made with boxes or circles I guess, for example a circle under the base of the tree for an area you are not allowed to walk on.

[doimus]

That was my idea at first also, but I don't know how practical that option is. That's the standard procedure for tiled games allright, but we're talking prerendered backgrounds here and that means not much data is repeated as in tile games where you can reuse "grass tile" or "tree tile" many times in one map. In prerendered you may have an entire forest the characters must walk through, or a castle you could walk behind, or an entire city (check Baldur's Gate screenshots). Now consider that castle could as well be 1024x1024px big, or that forest could be even bigger. Then you have A LOT of data, which is drawn using graphics card texture memory, and there you run into problems. Not to mention that precise placement of all that different sprites would be a major PITA.

I actually considered using huge (1024x1024) tiles for backround (layer 0) then characters layer (with smaller sharacter sprites), and then on top of all that another 1024x1024 alpha-mapped tileset to serve as "walk-behind" mask (treetops and such). Those 1024 tiles would be streamed from hdd as character moves close to them.
Then I run it all through a calculator and came to an incredible huge amount of texture memory needed, and I just can't require 512mb graphics card for 2D tech demo!

Now, my instinct tells me there's more rational solution out there...

[Moru]

I tried a big example in Mappy with 1024 x 1024 tiles but it doesn't support that large bitmaps. However some editing and cheating later I got it working. Try this on some hardware with smaller grafics card since I have an Nvidia GeForce 6600 GT.

The demo should use 192 MB of texture memory if I counted right. Textures are loaded dynamically by GL-Basic, I haven't changed anything in my code to support that big tiles except for a quick hack to change from 32-1024 pixel tiles after loading the map.

There is a big delay on startup due to the big size, just be patient :-)

Download from here: Big Tiles Test

[doimus]

Moru, thanks for this little demo, at least now I know it is possible. It works fine here, but I have 512mb card. What worries me is memory usage, as you said it's 192MB just for those four 1024 tiles, and I would need at least 9 loaded at the same time to produce seamless terrain effect (I am counting on 1024x768 screen resolution or more, minimum graphics card it must run on should be Intel GMA950). And than at top of that come various sprites like characters, animations etc. I somehow think I set my goals too high, sadly.

I was thinking about this today (that's why discussion is important - it makes you think!!  ). I may go for a "hybrid" approach to this. I think I'll spread the terrain into smaller tiles, ie. 128x128 or 64x64, and then on top of that do what you suggested in the firs reply - draw various objects on screen as they appear (trees, pillars, etc).
That way things can be further optimized: I can find out what tile the character is on and just draw additional objects there, while all other "unoccupied" tiles are drawn just as background.

And if I have for ex. 8192x8192px terrain, separated into 128x128 pixel tiles, thats 64x64 = whooping 4096 tiles! All different and unique! (now there's a clear difference between tile-based and prerendered backgrounds)
Obviously I can't load them all into memory, so there must be some streaming going on from the hard drive. Putting them into two-dimensional array and shifting it in appropriate direction when needed, or something.

Ok, I think I dabbled way too much words here, I think I have to go and code something out of this to find out what works and what doesn't, but if someone has to add something useful or maybe steer the whole thing in another direction, please do so... let it be for the benefit of the community.

And one more thing. Being of a more designer/artist background (now you know why so many words  ) and with BASIC being the only language I ever managed to turn into something meaningful.... if I come on with some obviously stupid programming questions, don't go hard on me, please. 

[Kitty Hello]

There's 2 ways.
Either just make smaller tiles and dynamically load the ones you need, dropping ones you don't need anymore.
Or: (limited effect) try using a compressed texture format. You must use OpenGL directly for that.
I'd go 1st way. You can load a png pretty quickly if you limit the size to 512x512 or even 256x256.

[Moru]

That is what I meant with my first post, tilemapping makes it so much easier with almost everything and you can still place objects like trees and houses as you want, pixel perfect. Just make your tiles as one big picture and load it into Mappy (link on my homepage). Specify how big the squares is supposed to be and Mappy will split them for you.

My demo was 8x8 squares so 64 individual tiles (just saving some work by loading the same four 16 times).

The tile-engine I am building I have tested on the GP2X and it runs nicely with eight layers and 4000x4000 tiles of 32 pixel each. That was only 300 different tiles though, I haven't tested bigger tiles yet :-).

Animations are also easier to make with small tiles, with Mappy you can make tile animations easily and load them with my engine.

Source code for the demo and tile-engine on my homepage too btw.