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

This is a discussion on Best way to deal with my (pseudo)graphics in Win32 console game? within the Game Programming forums, part of the General Programming Boards category; Okay. So our team (4 people) needs to make a game that runs in a Windows console window.
It has ...

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.

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.

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.

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.

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:

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

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.

Okay I tossed in some more comments and cleaned it up a little bit. should be a bit more readable and easier to understand. Far from perfect but I felt bad asking anybody to look through what I had just uploaded before.

EDIT: didn't need wingdi.h and also had removed one line that broke the code. looks like i have to upload it again below

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

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