Game Development Community

Is possible to make Iso game in TGB? (video memory problem)

by Tomas Hron · in Torque Game Builder · 07/17/2008 (4:01 am) · 14 replies

Hi, i started prototyping new iso game and I encounter a problem with video memory.
I dont know too much about video memory handling and this stuff ,so there should be major mistakes in my hypothesis that you should correct.

Lets start little counting:
- In iso game there are 8 directions
- Each character shoudl have 5 different animations (idle,walk,die,attack,run)
- and you will use 256x256 png for each animation.

- 8 directions 5 animations 8*5= 40 40 * 256x256 pictures for each character.

So if you want to have 8 different characters in one scene ,you will have to load 8*40=320 256x256 pictures in to video memory?
This means for 24bit PNG 256*256*24= 1 572 864 bits = 0,196 Mb . For 320 pictures 62,9 Mb of video memory?

And what if you want more characters, more animations or better resolution? (256x256 is really small for 9 frames animation)

So my question is that is it somehow possible to make this kind of game in TGB.
And for example how they did it in Fallout ? Good old game, very old.. but it worked. I wonder how?

Thanks for your suggestions, advices and corrections!

#1
07/17/2008 (10:36 am)
Theres a plan floating around about optimizing TGB texture memory usage by automatically trimming off the transparent parts of sprites...

You can compress all your textures to .dds

Those are the only tricks I'm aware of at the moment. Maybe check out the Graphics Programming Gems books.
#2
07/17/2008 (10:52 am)
Another optimization "trick" is that even with eight directions you don't really need eight images per animation.

Move left and move right can be the same image for example just flipped, as could move up and move down, etc.

This would reduce the memory requirements in half - I think.
#3
07/17/2008 (12:06 pm)
Mirroring really only covers 6 of the 8 directions under isometric, as forward/up and back/down require different animations. Also, if the characters are assymetic, that rules out mirroring (i.e. weapon in right hand, misc/shield in left).
#4
07/17/2008 (12:48 pm)
Fallout didn't have 256x256 sprites. They were most likely 32x32 or 64x64. Also, judging by some of the graphical hangups in fallout, I imagine they dynamicaly loaded image strips on demand. You can do the same thing in TGB with allow unload and turning off preload.

Going further, you might want to preload all the walk and run images since direction can change so rapidly.

Hope this helps.
#5
07/18/2008 (1:45 am)
Fallout used 8bit pictures, and characters are about 30x70 (6 frames are still 140x90 which will in TGB result in 256x256) , so they used smaller 8bit graphic but it was 11 years ago, in the time of the first voodoo graphic.
I will dig it up more in fallout and tell you what I discovered.

Dynamical loading and unloading maybe should work in turn-based game, where you can wait a little until the animation is loaded, but if you want realtime game you have to preload all moves.
#6
07/18/2008 (2:23 am)
Little research about FO:
Looks like they used for most characters 28x64 indexed 256colors (they used also bigger chars.). Animations are made from this small pictures and saved as .FRM file. FO also used only 6 directions (hexagons).

Maybe the dynamical loading of these small images can be done without any lags as mentioned Greg.
#7
07/20/2008 (1:21 pm)
Don't forget that its possible to just flip sprites horizontally so for symmetrical sprites you'll only need 4 directions.

Also it's possible to separate components and then mount them together, ie 4legs and 4 upper bodies gives you more variations to play with, and then you can tint each individual part as well so you can do color variations easily.
#8
10/07/2008 (2:41 pm)
I'm curious if anyone has done a significant amount of work on this style of game and had any success. I'm looking at doing something similar (an isometric game that will need quite a few sprites for different characters and animations) and would hate to waste a ton of time prototyping and developing only to find out that the engine really can't handle my design.

Anyone have any actual examples or success stories of games like this made with TGB?
#9
10/08/2008 (2:50 pm)
With TGB you have a lot of work ahead of you to complete an isometric game, and it is entirely dependent of your skill set or how willing you are to stretch yourself. I consider myself an intermediate game programmer/developer and I am trying to get my isometric game to alpha again. There is some work that Neo Bindel did floating around the forum somewhere that is an excellent place to get started.

At any rate, I tried, and somewhat succeeded at doing an Isometric game in TGB purely with Torque Script, but the load times were horrible. To do it right you really need to dig into the engine and make some changes. The code is formatted well and is usually pretty straight forward.

You can download my old clunky beta here and have a look. Just don't let that be your only judge, it can be much better, I promise. :)
www.codeugly.com:12001/aegesroad/
#10
10/09/2008 (3:27 am)
Greg -

Wow! Well done. Don't be too hard on your work. That is one of the better TGB games I have seen. You have implemented a number of features that I was thinking about including. Seriously - nice work.

I'm a big fan of what Neo was doing, and would *kill* for that Animation builder. Hopefully he will be able to finish it up someday.

I'm a total novice when it comes to scripting and coding. I've learned a great deal about it since I started working with Torque, but I'm not strong enough to go out on my own yet and just code without a tutorial or example holding my hand, so I'm still trying to look through examples as much as possible. Seeing your work shows me that my ideas are feasible in TGB, although I seriously doubt I'll be able to make any engine changes anytime soon.

Thanks!
#11
10/09/2008 (12:36 pm)
Thanks

If you get stuck on an implementation I can offer some tips from what I have learned. I usually browse the forum around this time every day. :-)
#12
10/27/2008 (1:46 pm)
James, can you tell me any more about the .dds texture compression? How is this done, and what does it accomplish? Or point me to where I can learn more?
#13
10/27/2008 (1:50 pm)
Maybe this is what you were referring to James?

http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=9125

If so, sounds like a Windows-only hack. I'm doing a cross-platform game for both Mac and Windows... but the notion of compressed textures sounds wonderful if a cross-platform solution is available, lossy or not. Particularly if I could easily choose which textures are compressed, and which are not. Some are less important than others for fine detail.
#14
10/27/2008 (7:20 pm)
Hey that was me ;)

No it wasn't windows only..it was through an OpenGL extension that is pretty commonly supported. I was able to load .dds files and use them as StaticSprites but there were some issues. I think most of the problems were due to the way TGB "pads" textures. I did this with an old version of TGB. I honestly don't understand enough about how TGB handles textures or have the patience to try it again. I was just screwing around to see if I could do it. I basically just followed some online OpenGL texture compression tutorials and applied what they taught to TGB...