Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

Help Screens and Whatnot

Sign in to follow this  


One of the less interesting parts of a Jetlag project are the title screen, the main menu, the help screen, and a few other odds and ends like that. Typically, I do these last. This is a process that I decided on long ago, back when I had a whole lot of very neat-o title screens and very few games. During my development, I typically put placeholders here. The title screen will simply have the word "Title Screen" written on it, and the rest will be black. Similar idea for the help screen.

Often, the actual rendering methods consist of the following:

There is a class/struct that contains a foreground color, a background color and a character number to describe a cell. This, to a degree, mimics what went on in video memory for the DOS text screen, where JetLag grew up. The main differences are that instead of 16 colors to pick for foreground (and a choice of blinking or not) and 8 colors for background, I have standard 24 bit color for both items, and no blinking (although, if I really wanted, I could do the blinking if I want, but JetLag causes enough siezures as it is).

There is a class/struct that contains a 2D array of 40 columns and 30 rows. These numbers are used because the intended destination is 640x480 (although it could really be 320x240 and no one would notice). The DOS text screen I used to use was 40x25, so when JetLag moved to windows, it added five rows. For this class/struct, there are typically function which mimic plotting individual character, horizontal and vertical lines of characters, filled rectangles of characters, and strings.

The screen class kept track of each character cell, and had a flag that tells whether or not it has changed. This sped along the rendering process, because I would then do dirty rectangle updates with ONLY the invalid parts.

It's not going to be as simple, this time. Smoothe scrolling, shaking the screen, having floating score adds, flying bricks, and other similar items mean I have to redraw the screen every time. Fortunately, the poly count is relatively low: 4,800 for just the 40x30 screen (two polys for background, two polys for foreground).

Another fortunate thing is that I don't have to do a two stage rendering for each character. The entire rom font bitmap gets loaded into a texture. The characters on this bitmap are white, so the only thing I have to do to color them is change the diffuse color. Before, I had a small 16x16 surface(the size of a character in the bitmap) that I would clear out the color I wanted the character to be, and then I would render from the rom font bitmap, using white as the transparent color, and then blit from the 16x16 surface onto the screen using black as the transparent color. This means I never have been able to use true black characters. I always had to settle for dark gray (#101010).

Now I'm using alpha testing to do the transparency. I can use black! Real black!

Another issue has always been that I first had to clear out the cell with the background color, and then build the character image, and finally blit the character onto the screen. With a simple z-buffer, I can render the alpha tested character in the foreground first, and then render the background behind it, and the character pixels will not be overwritten.
Sign in to follow this  


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!