Thread: Looking for feedback on graphics handling

  1. #1
    Registered User
    Join Date
    Sep 2001
    Posts
    412

    Looking for feedback on graphics handling

    OK, I'm a pretty experienced programmer (I learned C 11 years ago, C++ 9 years ago and I've been developing Windows apps since the Win 3.1 days). So I'm tackling a graphics engine for a top-down 2D game, somewhat akin to the FF games, perspective-wise.

    I'm using DirectX for graphics, and all is going pretty well. I currently have the background tiles displaying and scrolling correctly; I need to do overlays and sprites still. But, I'm really looking for comments on my approach to graphics.

    First off, tiles --

    * I allow 1024 different tiles at the moment, if this is too many/too few I can always change this with moderate ease; only one filetype I've developed (the .MAP file) makes any assumptions about the maximum number of tiles, and I can always change this specification.

    * I store the tiles in a .TLS file -- this is basically a collection of palettes and indices for 32x32 bitmaps, each in 256 colors but NOT all with the same palette. This is a trick I had picked up from analyzing other games, as a way to minimize file size while still having a high color depth ingame. I'm thinking, though, that I could store them completely as BMP files concatenated end-to-end -- I could probably draw them faster, because it isn't that challenging to load a bitmap into a directdraw surface, wheras with a special tileset, it can be tricky to do it rapidly.

    * The engine tracks which tiles are "dirty" and only redraws those which need updating, as a result of screen scrolling or sprite movement.

    * The real issue is, how should I store the tiles in memory, for efficient storage, and speed of blitting? My current thought would be to make a 1024x1024x32 offscreen DirectDraw surface (the game is hardcoded, at the moment, to use 32bpp color depth -- DD won't allow 24 bpp?). I'd then copy the bitmaps to this (which would take long but hopefully, as long as none of the surfaces "get lost", I won't need to do this more than once per game.)

    Now, I was thinking that I'd prefer sprites to load into video memory (as they will be redrawn more), then I'd try to load overlays, and I'd probably load the tiles into video memory only if there was still room.

    Comments? Is this a good way to store the images in memory?

  2. #2
    Registered User
    Join Date
    Aug 2001
    Posts
    411
    Sounds like you have it under control, but you might want to look at DevIL, its a graphics library that can load any format, useing it you could make your textures jpg, and therefore take up less space.

    I dont normally reccoment .jpg textures for gameing, but with a 2d tile engine it would probably be just as good, if not faster.

    read this

    and here is DevIL.

  3. #3
    Linguistic Engineer... doubleanti's Avatar
    Join Date
    Aug 2001
    Location
    CA
    Posts
    2,459
    hmmm... allegro [for djgpp] has datafile formats... but i suppose if you don't have another third-party convention for doing so you are stuck... look for one...
    hasafraggin shizigishin oppashigger...

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. event handling is serialized in MS Visual Studio C++ 2005 ??
    By mynickmynick in forum Windows Programming
    Replies: 3
    Last Post: 08-07-2008, 04:47 AM
  2. Handling mouse in graphics mode in Turbo C/DOS
    By sureshkumarct in forum C Programming
    Replies: 2
    Last Post: 12-24-2006, 09:36 AM
  3. Beginning Game Programming Type Books
    By bumfluff in forum Game Programming
    Replies: 36
    Last Post: 09-13-2006, 04:15 PM
  4. Graphics Programming :: Approach and Books
    By kuphryn in forum Windows Programming
    Replies: 4
    Last Post: 05-11-2004, 08:33 PM
  5. Graphics Devices and Cprintf clash
    By etnies in forum C Programming
    Replies: 6
    Last Post: 05-09-2002, 11:14 AM