Terrain Test

[White Claw]

Well, here's my first hack at a terrain display for my new "game" or whatever it might become. The scrolling buttons work (North, South, East, West) but the "Turn" button doesn't do anything. If you click "Rand Terrain", you'll get a randomly generated map. If you click "Test Terrain" you'll get a known, steady terrain layout (which the program defaults to).

Just open it up in some folder. There's no install, just 1 directory with 2 files. (Make sure you have the .bmp file in the same directory as the .exe)

Nothing is optimized and it's might blink a bunch when you scroll. What I'm asking from the forum is if you can try it out and see if it displays. I'd like to know if the approach I'm taking is valid (in case this project turns into something).

Thanks!

(EDIT: New File)

[Mcshay]

Sweet! Although it would be nice if you used a double-buffer to prevent the flashing. Or you could just turn InvalidateRect(hwnd, NULL, true); into InvalidateRect(hwnd, NULL, false);. If your going to repaint the whole display, why white it out?

(Or you could change the background color to black, however this would still cause a bit of flashing where the tiles are.)

PS: Sorry if you already know how to fix it and are now annoyed with me... I only mention this because it took me weeks to figure out how to stop it with no help.

EDIT: More on track with the intent of this thread, it would be nice to have some sort of bar-like-thing that appears next to the map when you hit the edge (on the side where the edge is of course).

Also: arrow keys!


EDIT (leeor_net): fixing formatting.

[Leviathan]

Cool work

[White Claw]

Sweet! Like I said, I was wanting to make sure it worked on other people's computers before I went further.

The blinking is because the opposite of what you said happens. I don't paint the background white, I have to repaint it black over the system default. Double buffering is what I'm used to, but I'm still trying to fully understand the whole "device context" thing (I've been able to use it, but not abuse it).

I wasn't able to figure out how to change an existing window's background color. (I don't think I found the right function yet.)

 

[Sirbomber]

Works fine for me, and I couldn't notice any substantial "blinking".

[Mcshay]

Well, that was my second guess . But anyway, here's how you change it:

In your WNDCLASS, you can replace WHITE_BRUSH with BLACK_BRUSH in the wndclass.hbrBackground member, assuming your using the same method I am (calling stock objects).

    wndclass.style = CS_HREDRAW | CS_VREDRAW;
    wndclass.lpfnWndProc = WndProc;
    wndclass.cbClsExtra = 0;
    wndclass.cbWndExtra = 0;
    wndclass.hInstance = hInstance;
    wndclass.hIcon = LoadIcon(NULL, IDI_APPLICATION);
    wndclass.hCursor = LoadCursor(NULL, IDC_ARROW);
    wndclass.hbrBackground = (HBRUSH)GetStockObject(BLACK_BRUSH);
    wndclass.lpszMenuName = TEXT("MenuName");
    wndclass.lpszClassName = TEXT("ClassName");

[White Claw]

I've tried that but it keeps telling me that hbrBackground is not a member. And the online documentation is killing me because it doesn't say what functions ARE available for a given class.

[Mcshay]

It should let you do that.... are you doing this in C++ (Win32)?

[White Claw]

I think I figured out why though I still don't really understand. I think the window I'm creating is a dialog box and even though it tells me it's derrived from the window class, it doesn't act that way. I guess this is what I get from using the class wizard.

[Hooman]

That's pretty cool looking.

He's right about the flickering though. It's especially noticable if you resize the window. The whole thing is getting repainted twice. Once to clear it, and once to put the image on top. If you can, you should avoid clearing the background like that unless maybe you're doing double buffering. There won't be any graphical glitches if you double buffer, but by eliminating the background clear you'll also save time. It will still be necessary from time to time though, such as on initial startup, and when you resize, or another window overlapped yours and yours just got uncovered.

I'm gonna guess from the icon that you used MFC. In which case I can't really help you much or suggest how to go about fixing that. All my experience is with DirectX, raw Win32 API, and VB.


Since you have buttons on your window, I would assume it is a dialog though. That alone isn't necessarily a bad thing, but I think they do have a default behavior to paint their own background when they need to. At least your buttons should work right as long as you're using a dialog. They handle a bunch of things you'd take for granted in a language like VB, such as tabbing between controls and such. You can simulate that behavior with just a plain window, but it might not be consistent with other apps. Particularly if Windows ever gets an upgrade. I think scroll wheels made use of an upgrade to the dialog type window class, although I'm not certain.
 

[White Claw]

The program I put up is mostly a testbed for the terrain mapping functions. I'm trying to decide how best to handle the flickering when resizing (in OP1 you couldn't resize the window). But I did want you guys to tell me how bad it was because I have a pretty new comp and it is almost un-noticable.

I also think I may go the route that OP1 did and replace some of the default system colors for the baseline windows. I was initially going to steer away from that, but it seems like it will be easy enough and gives a slightly more immersed feel. I just want to make sure that a crash won't leave your windows looking all screwed up (like OP1 would do from time to time).

Yep, I did break down and start using MFCs (in C++). They take care of a bunch of grunt work, but on the other hand I have to undo some of their work (and I'm learning the limitations you mentioned). I leaned away from DirectX because I couldn't find information that was actually helpful to even get started. But I didn't want to do my own thing either because I'd like to be able to use it on other computers too. (Which means it will probably be slow graphically, but that doesn't matter much with OP1-ish style.)

I will probably go with a double buffer once I get into the layout design planning. This will eliminate the need to Invalidate() the entire screen while scrolling.

[White Claw]

Lol. It took me a bit to figure out why I couldn't upload my new file. I didn't realize the topic had moved... Can regular users not upload in general threads? (Sorry if I can, I wasn't able to figure it out.)

Anyway, here is an "update". I did some adjustments to the background coloring (finally figured out how) and now it loads all the tile sets. You can select any of the 7 original tile sets. The "Rand Terrain" also creates a larger map (50x50) than the default test (21x21) for testing of different sizes.

Sorry, no arrow keys or terrain boundaries yet. Those will probably be something included in the actual product. Let me know if the "blinking" has improved (it did slightly for me, but it's still not double buffered).

[Mcshay]

I'm still getting the white flashing now, but its accompanied by a black flash too.

[Hooman]

The flickering doesn't seem quite as bad in the newer version. I only notice a black flash now, instead of a brief white flash before a black flash and then the image. At least that's what I think I'm seeing. It's a little hard to tell when it's going by that fast.

Can you try not clearing the background where the map is? That might be a little harder due to it's non rectangular shape though. But that would eliminate at least most of the flashing. I'm not sure about the area with the buttons.

Where did this thread used to be? I know most forums don't allow file attachments. Should be just the file forum and the programming forum I think.
 

[White Claw]

Lol. Without getting to hung up on the flickering, I haven't done anything to actually prevent it (yet). There's no double buffer or anything.

The reason everything goes black is because windows is repainting everything each time you scroll. It's more of a stand in program to test the underlying tile and terrain mapping functions, not so much the actual display (which will probably be double buffered eventually). I didn't know how to double buffer (in Win) before so that's why it wasn't started that way.

More importantly, I'm glad you guys are seeing all the tiles and that it looks correct on the screen, and that you're actually able to scroll!

I think I'm gonna have to fix the tile files because I don't really like how they're implimented in OP1. There's not really any structure to them (because there's only 7 sets of 10 tiles). I'm planning to set it up so that it's a bit more structured and expandable.

(I think the orginal post was in the "Spam/Test" forum.)

[White Claw]

Sorry there hasn't been anything new on this the last couple days. Expect most of my work here to be accomplished on the weekends as work/school/family takes up nearly all my time during the week. (And I'm already 2 weeks behind in school work...  :ph34r: )

My goal is to work on this at least several hours every weekend and (when school is under control) potentially a couple hours during the week. Depending on how things get going, I'll post some more structured information(if the project heads that way...

[White Claw]

Sorry there still isn't anything new. I have been working on it. I've been trying to get the video buffering up and running but I've hit a new block from windows. It seems you can't just continuously update the video of a dialog box without invalidating the whole thing. I know the buffer is working because I can build it, then blt it with an Invalidate() call in the OnPaint handler. But it won't let me draw to the screen on a whim.

Not to mention that working with bitmap buffers as handles is a pain in the butt.

[Leviathan]

Well glad to hear your still working on it. Intrested in making it open source? Only a suggestion as maybe some people here could help you out.

[White Claw]

There isn't really much source to make open yet. I haven't done much programming in windows but I'm pretty sure modal dialog boxes is not the way to go. So I would imagine anyone with windows programming experience would find my hack job humorous at best.

I've just been hammering away at that method because it seems most likely that it will be widely supported by all versions of Windows (98+). I've got a feeling that if I go this route, it will be graphically challenged. I think it would actually be okay if I could figure out how to get around invalidating the entire window but force it to let me paint the buffer. (Anyone know how to make a window send a message to itself? I can't figure out how to get the handle...) I thought about trapping the WM_PAINT message and never posting it back. But I have to figure how how the MFC buried that. Plus I don't know if there are problems with stacking up the WM_PAINT messages (or if it matters).