Thread: Best way to deal with my (pseudo)graphics in Win32 console game?

Okay. So our team (4 people) needs to make a game that runs in a Windows console window.

It has to be programmed in C (I forget if it's C89 or C99), and we can only use pretty basic libraries, with the exception of Windows.h ... so we can't use conio.h or curse or any graphics API.

We've got a basic 'engine' set up and now we've been troubleshooting on how to deal with models and graphics. I think we're going to do a tile-based editor, which should be relatively simple to program in a while.

We're trying to decide whether to build our own graphics editor for models, or to use bitmaps so we can have all the functionality that a program like MSPaint (or countless others) already provides.

Problem is, bitmaps seem to store there info in RGBQuad's, while Windows console changes it's colors uses this RGBI format (I is intensity).

So in order to load a bitmap and have it load to our console buffer, we'd have to read in the pixel array and convert the colors to our format and place them accordingly.

My question is this:

Is it worth it to write a program that reads in these bitmap files, or would it be easier for us just to write our editor? Are there any potential drawbacks to using bitmaps vs. using our own models?

And does anybody know of any way to convert easily from RGBQuad to RGBI, or do I just have to guess and check?

Thanks. I'm sure there was more I meant to put here but I've got a headache and may have missed something. Any help greatly appreciated.

Originally Posted by Bubba

You can prob use this for intensity:

r = g = b = 0.2125*r + 0.7154*g + 0.0721*b

Bitmaps in console mode are a lost cause. Why can't you use basic GDI for this? If you can use windows.h that says to me that you can make a win32 application. The console mode choice is going to fight you every step of the way.

Thanks dudes. Yeah. It's a freshman project at my school that we have like 6 months to complete, and I think a huge part of it is just dealing with the huge limitations of the console.

Unfortunately, the console color setup is pretty awful.

So basically here's RGBI (in my understanding):

for each character in the buffer, there is a foreground and background color. Each is represented by one HEX digit.

Each HEX digit is composed of this:

If it has blue in it, add 1

If it has green, add 2

If it has red, add 4

It it has intensity, add 8.

A brief note about intensity: Intensity makes it an entirely different color basically. Purple with intensity becomes pink. Dark red becomes super bright red. Black becomes white (i think).

So you end up with a number between 0 and 15. that's the 16 colors we can work with.

So I was trying to write a tool that could convert bitmaps into this format...generally speaking.

I'm just going to use 16 color bitmaps and completely ignore the idea of ASCII characters and foreground colors by making everything a space.

And then just map that into my screen buffer. That's my basic idea.

But the big question was whether to write our own tool or to find a way to use standardized tools. I appreciate the input.

Making our own tool would probably be the biggest timesink. I mean, we could make a basic one, but to have things like layers, rotations, etc etc, it would be a substantial thing to undertake.

I guess the best way to is to figure out which RGB bitmap values correspond to the RGBI colors and go from there. Basically just hardcode it. Hm.

If you guys think of anything else, let me know! If not, thanks again.

Originally Posted by jdragyn

Back in my BBS days, we used a program called TheDraw to make ANSI graphics for the BBS title screens and door games. We also used various utilities to convert bitmap graphics to ANSI pictures (the one I used the most was called GIF2ANS.EXE). It basically broke a GIF image into a bunch of squares and then used the best ASCII character to represent the closest coverage, intensity, etc. of that square of the image. Simple one-color images or large output files worked pretty ok (at the time they were awesome!), but small and detailed images lost most of their quality and tended to be unrecognizable.

I second Bubba's comment, if you can use windows.h, why not use the basic windows GDI? The end result will look a lot nicer for the same amount of effort.

Man, I really wish this was an option. But it's a project for school, and the guidelines are strict. They basically want us to work with something awful and outdated so we can understand limitations and work within them.

Here are two relatively cool games made last year that met the criteria:

https://www.digipen.edu/?id=1170&proj=18870

https://www.digipen.edu/?id=1170&proj=9588

and here's a video of a game from a team that went WAYYY over the top with their game last year:

YouTube - The Y-Front - 3D ASCII Shooter

However, they went so far over the top that they're game wasn't very fun, and it came off a little cocky. They didn't score very well. Amazingly though, I guess that stuff was all done in ASCII with the console.

So yeah, this stuff is pretty awful, but it looks like we're stuck working with it. I'm thinking I'll write a program that parses the bitmaps into a "sprite" and then have that program also able to line up several sprites for animations. Then it can export our model files.

But it's time I actually got to programming. Again, I appreciate any other ideas you guys have! All feedback welcome, thanks again

Man, brain is hurting. Before I go to bed, thought I'd post where I'm at with this and see if anybody can see where I'm being retarded.

Here's an MS-DOS logo:
http://images.maketecheasier.com/2009/08/msdos-logo.jpg

Here's my console dump of it:
here

NOTE: this image looks especially worse in console because of the amount of colors in it. but obviously I've just some stupid error in the way I'm lining things up, because the colors and shapes are right, but if I had a line that had the numbers

1 2 3 4 5 6 7 8 9 10

it has been coming out like this

1 3 5 7 9 2 4 6 8 10

I think I've just been looking at it too long for one day and it'll probably make more sense in the morning.

I'd post my code but it's 600 lines and half of it is garbage. Anyways, progress, not perfection. Thanks again and still always open for help

Would this then be significantly harder because I'm not reading it line by line from the file, but byte by byte?

In the file, how is it designating where an old line is ending and a new line is beginning?

I've attached my code as well in hopes you might be able to point out where I'm going wrong, but I don't blame you if you have trouble sorting through it. It's pretty jumbled since I've just been learning about this stuff as I've been going along.

Heh, sorry guys. I took out a line that broke it.

Okay, nice. Got it totally working! So I accounted for the extra padding bytes and it works awesome now. Also, I had it reading half of the pixels wrong before. Anyhow, here's a picture of my output, and a copy of the code for anybody who is interested in this. Thanks and goodluck

http://i243.photobucket.com/albums/f...g?t=1293612612

okay but currently the code isn't dynamically sizing the screen buffer, so if you load an image bigger than 400 in either height or width it will probably corrupt the stack.

haha okay last time uploading code, but the last one was set at the exact padding bytes for that image, so i just added a little part to make it figure that out. this should work for most 16 color bitmaps that are within the size of the screen buffer. good luck