Tricks of the Windows Game Programming Gurus:Vector Rasterization and 2D Transformations

All ITKnowledge Source Code Search Tips Advanced Search |

| Tricks of the Windows Game Programming Gurus by Andre LaMothe Sams, Macmillan Computer Publishing ISBN: 0672313618 Pub Date: 09/27/99

Search this book:

Previous | Table of Contents | Next

#### Sparse Bitmap Tile Engines

The only problem with tile engines is that there are a lot of bitmaps to draw. Sometimes you may want to make a scrolling game but you don’t have a ton of graphics to scroll around. Moreover, you might not want to make all the tiles the same size. This is true for a lot of space shooters, because those games are mostly blank space. For those types of worlds, you want to create a universe map that’s very large (as usual)—let’s say 4×4 (or 40×40) screens for argument’s sake. Then, instead of having tile maps for each subscreen, you simply place each object or bitmap at any location in world coordinates. Using this method, not only can each object bitmap be any size, but it can be placed anywhere.

The only problem with this scheme is efficiency. Basically, for any position where the current viewport resides, you must find all the objects that are within it so they can be rendered. If you have a small universe with a small number of objects, testing 100 or so objects for inclusion in the current windows isn’t going to kill you. But if you have to test thousands of objects, it just might kill you!

The solution to the problem is to sectorize the game universe. In essence, you create a secondary data structure that tracks all the objects and their relations to a number of cells that you break the universe up into. But wait a minute, aren’t you just using a tile map set again? Yes and no. In this case, the sectors can be any size and don’t really have any relationship to the screen size. The selection of their size is more related to collision detection and tracking.

Take a look at Figure 8.48, which shows the data structures and their relationships to the screen, world, and viewport.

Figure 8.48 Sparse scrolling engine data structures.

Note that this is only one method of solving the problem; there are many more, of course. Nevertheless, the point is that you have a collection of objects that are spaced out in a universe that is much larger than the screen—maybe 100000×100000—and you want to be able to move around in it. No problem, just position all the objects with their real-world coordinates and then, based on where the viewport window is (which is 640×480), map or translate all the objects in the window to the screen or video buffer. Of course, I’m again assuming that you have good clipping, because many objects will partially extend off the video display surface when drawn.

As an example of sparse scrolling, I’ve created a space demo (this isn’t a high-budget production, you know) that allows you to move around in a starfield along with a number of stellar objects. In this demo, there isn’t very much data structure support for the sectorizing, and the objects themselves are placed randomly. In real life, you would of course have world maps, sectorizing for collision and rendering optimization, and so on. I’ve written a demo of sparse scrolling named `DEMO8_12.CPP|EXE`. Again, it makes use of the `T3DLIB1.CPP|H` files, so make sure to include them in your project.

`DEMO8_12.EXE` basically loads a number of bitmap objects and then randomly places them in a space that’s 10×10 screens in size. Then you navigate around the world with the arrow keys as usual. The beauty of this type of scrolling is that the entire screen doesn’t need to be rendered. Only the bitmaps that are visible or partially visible are rendered. Hence, there’s a clipping phase in this demo where each object is tested, and if it’s totally invisible, it isn’t sent to the bitmap rendering code.

### Fake 3D Isometric Engines

I have to admit, I’ve been getting so much email on this topic, I feel like I should have just written a book called Isometric 3D Games! What are those, you ask? Well, they’re games in which the viewpoint is at some skewed angle, such as 45 degrees. Some of the old isometric (ISO) 3D games include Zaxxon, PaperBoy and Marble Madness.

These days ISO games are making a comeback—Diablo Loaded, and a slew of RPGs and wargames use it. Its popularity stems from that fact that the view allows a lot of cool gameplay and fairly interesting visuals as compared to full 3D. And of course, ISO 3D is about 10 times easier to create than full 3D. So how do you do it?

Well, this is a secret in the game community, and it’s not something that anyone writes about too much. What I’m going to do is give you some food for thought and describe a couple of ways to do this. The hints I give you here should be more than enough for you to implement an ISO engine yourself.

There are three ways to approach ISO 3D:

  • Method 1—Cell-based, totally 2D.
  • Method 2—Full-screen-based, with 2D or 3D collision networks.
  • Method 3—Using full 3D math, with a fixed camera view.

Let’s talk about each…

Previous | Table of Contents | Next

Copyright © Macmillan Computer Publishing, Inc.

Products | Contact Us | About Us | Privacy | Ad Info | Home
Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.