Starcraft Graphics Secrets

As some people around here may know, I'm a 2D-isometric game enthusiast. For me, the dream games that I'd like to recreate are isometric classics like Starcraft, Age of Empires, and Diablo.

For the past year or so I've been teaching myself a lot of the basics that go into a game like this, including tile-scrolling and A* pathfinding, among others. But recently I'd hit a wall. The laptop that I use for game development only has 8 megs of VRAM, and at 16 bit display mode, I could get no more than 6 screens of graphics into my game in 800x600 mode. Changing to 640x480 only improved these numbers slightly. (You can actually overload graphics beyond your VRAM limits, but the extra graphics go into RAM, where they are drawn to screen very slowly).

I was, needless to say, frustrated. How was it that these classic games worked fine on my laptop, but I couldn't even come close in Blitz?

So I started doing a bit of research and came up with some nuggets that I thought my fellow Blitzers might be interested in. Here they are:

(1) 8 bit Mode: The first thing I discovered was that all 3 of the games I mentioned were rendered in 8 bit graphics (256 color) mode, using palettes (so you can pick which 256 colors you want). This isn't possible in Blitz, where the lowest display mode is 16 bit. Using 8 bit display mode allows you to get more than twice as many graphics into VRAM as 16 bit because the frontbuffer and backbuffer are also only 8 bit. Using 8 bit mode, I could load 14 screens worth of graphics into memory rather than just 6. This prompted me to learn C++ and Dx, and to create the Extended 2D dll that I've recently posted in the Blitzcoder showcase.

http://www.blitzcoder.com/cgi-bin/showcase/showcase_showentry.pl?id=turtle177605192003023744&comments=no

Was this the answer? Well, not totally. Turns out that 8 bit mode alone wasn't good enough to get a comparable amount of graphics into the game. What was going on here? So I recently had a discussion with a guy who used to work for Ensemble Studios who knew a bit about this, and come up with this ...

(2) RAM Blitting: Turns out, Starcraft barely used *any* VRAM at all. The game only used about 1 meg of VRAM -- enough to have just a front and backbuffer. All of the other graphics (by my estimate, about 10-15 megs of 8-bit images) were loaded into RAM where they were used to compose the on-screen scene. That was then blitted to the backbuffer in a RAM-VRAM blit. I've since added the ability to load images to RAM in my dll. It's also now possible in B+ and (for textures) B3D.

The downside is that RAM-VRAM blitting is *slow*. Starcraft got around this in a few ways, including:

- because it was 8 bit, the time it takes to do a RAM-VRAM blit is much lower (it takes about half the time of doing the same thing in 16 bit).

- they only updated the map portion of a 640x480 screen (the upper 2/3) on a regular basis, which reduced their requirements even further.

- lower fps were not as apparent, because the units moved relatively slowly. The mouse may have been implemented separately as a DirectX "overlay", so its position could be updated more frequently than the rest of the screen, thus disguising the lower fps.

- because the screen was composed in RAM, not VRAM, alpha-blending was fast because there were no VRAM-reads (which are *really* slow). They used a 256x256 lookup table to implement fast alpha blending in paletted mode. This alpha blending method is important, because you can't otherwise implement alpha-blending very quickly using Direct Draw and VRAM surfaces. Today, hardware supported alpha-blending is available using 3D technology, but they were doing it back in 1998 with 2D technology and DirectX 2 (!).

Some of what these folks did is now doable in Blitz. The 8 bit stuff is not supported by Blitz, but you can get this through my dll. Personally, I'm focusing on developing 2 separate blitting modes for my game, one using the 8 bit dll that will be used on older platforms, and the other using 3D-enabled, native Blitz when the user's computer is good enough to handle it.

I hope somebody out there finds this interesting. If anybody has any additions/corrections, I'd be curious to hear your feedback.

This is exactly what I'm talking about. See how damn difficult it is to make a decent 2d game on a modern PC. It's disgraceful.

yeah, i've been twisting about this for years, but what're you going to do, eh? it's not as if things are going to change unless a 2d game comes out that's so hugely popular the world and his wife start ripping it off - and since a game's popularity these days is largely defined by it's graphics, we're not likely to see such a game unless the hardware changes first

i found it quite interesting... :D

Hi Folks,

@Patrick: Good stuff.

Later,

Jes

"i found it quite interesting... :D "

me too, although I was hoping for hints and tips on how to draw the little isometric chappies in the game...

Vorderman, check out:

Isometric Tricks
http://www.gamedev.net/reference/articles/article1911.asp

Intriguing. Looks like you've really done your homework, Patrick. From your experience, which is the best Oracle to learn C++/Direct X programming from. How much effort did it take?

Also, can anyone tell me; are 8-bit graphics always about twice as fast as 16-bit, or does it depend a lot on your GFX card? What is the norm with modern machines?

my advice is not to try to learn C++ and DirectX at the same time... learn some C++, i started learning DX8.0 after only one week at a programing camp (big mestake) take a month or 2 to learn C++ then, in my oppinion the single _BEST_ book on D3D is "The Zen of Direct3D game programing", it shouldnt be too expensive now, and it is really good, it takes you through programing windows -> 2D directX apps -> 3d directX apps

Well, I picked it up by first learning C++ using one of the Dummies books. I also had to pick up Visual C++, which isn't cheap. (Dev C++ is free on the net, but seemed a little buggy and lacks support).

I then learned Direct Draw, which Microsoft is no longer developing, but is easier to learn in my opinion than Direct3D (now Direct Graphics), but I learned that next. For both, I purchased two older books from Microsoft Press called Inside DirectX and Inside Direct 3D. I also spent a lot of time with the SDK help files and doing searches on the internet for example code. Tutorials at GameDev were also helpful.

Overall, I have spent about 3 months learning it all. I've learned enough to consider myself good enough to do whatever I need to, but I'm still basically a beginner.

It depends on the machine. First, 8-bit graphics are rarely supported in 3D. Most machines still support 8-bit in 2D, though. It is a technology that is probably being phased out. For me, I am developing two drawing modules for my game. One is 8-bit and best for older computers and laptops. The other is for newer computers. All other stuff in the game, pathfinding, AI, etc., is independent and will work the same regardless of which graphics module is implemented.

As for speed, it depends on what you are doing. RAM-VRAM 8-bit blits, as Starcraft was doing, tend to be much faster, taking anywhere from 1/2 to 2/3 the time to do the same thing in 16 bit. Normal VRAM-VRAM blits, however, are about the same (really fast in both cases).

Bottom-line = don't bother with 8-bit stuff if your game targets modern computers (less than a year old), especially if it is 3D. Consider including it as a backup option, however, if you want to make your game playable on older machines.

Man, that has inspired me. It's so nice to hear how someone else's tricks on a reall, finished, commercial game. I remember back in the Amiga days buying Blood Money have reading that two pages in the back of the manual where the programmer talked about how he developed a way of "splitting" hardware sprites on the Amiga...allowing DOZENS (a lot back then) of sprites on screen...

I bet I read that thing 500 times.

These last few months I have been toying with the idea of going 3D...but you know what? Screw it! lol

I love 2D....B+ rocks....I think it is 10 times more fun to figure out how the get a 2D card to rotate a sprite fast than it is to "cheat" and use 3D hardware.

The neat thing about B+ is the simplicity and the pure "no-frills blitting". Reminds me of when I was 13 and figured out how to get a Commodore 64 to display hundreds of colors on screen...by flipping two colored pixels very fast...emulating a third color...and how I could get one of the colors to stay on screen longer than the other to control "hues"
That's programming! :-D

-cb

Patrick/SSS- thanks for the nfo. I really liked the idea of making a 256 game with faster gfx and lovely paletted screen fades, but if those modes may not be supported in the near future, I probably won't bother. It's a shame.

CBmeeks- Don't even get me started about the Amiga. The music on Blood money rocked and the graphics were excellent. Just goes to show what you can do with just 64 colours.

Oh yeah..Amiga rocked.

However, on the Amiga, if you used its HARDWARE parallax scrolling, it is limited to I think 16 colors...but lots of tricks were used for more colors.

Amiga = great game maching

-cb