Author Topic: Terrain Test  (Read 6175 times)

Offline White Claw

  • Hero Member
  • *****
  • Posts: 854
Terrain Test
« on: September 08, 2007, 08:33:16 PM »
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)
« Last Edit: September 09, 2007, 02:38:30 PM by White Claw »

Offline Mcshay

  • Administrator
  • Sr. Member
  • *****
  • Posts: 404
Terrain Test
« Reply #1 on: September 08, 2007, 09:04:38 PM »
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.
« Last Edit: October 06, 2018, 10:44:50 PM by leeor_net »

Offline Leviathan

  • Hero Member
  • *****
  • Posts: 4055
Terrain Test
« Reply #2 on: September 09, 2007, 07:42:00 AM »
Cool work :D

Offline White Claw

  • Hero Member
  • *****
  • Posts: 854
Terrain Test
« Reply #3 on: September 09, 2007, 08:23:12 AM »
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.)

 

Offline Sirbomber

  • Hero Member
  • *****
  • Posts: 3237
Terrain Test
« Reply #4 on: September 09, 2007, 08:29:29 AM »
Works fine for me, and I couldn't notice any substantial "blinking".
"As usual, colonist opinion is split between those who think the plague is a good idea, and those who are dying from it." - Outpost Evening Star

Outpost 2 Coding 101 Tutorials

Offline Mcshay

  • Administrator
  • Sr. Member
  • *****
  • Posts: 404
Terrain Test
« Reply #5 on: September 09, 2007, 09:16:59 AM »
Well, that was my second guess :P. 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).
Quote
    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");
« Last Edit: September 09, 2007, 09:18:36 AM by Mcshay »

Offline White Claw

  • Hero Member
  • *****
  • Posts: 854
Terrain Test
« Reply #6 on: September 09, 2007, 10:05:43 AM »
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.

Offline Mcshay

  • Administrator
  • Sr. Member
  • *****
  • Posts: 404
Terrain Test
« Reply #7 on: September 09, 2007, 10:20:24 AM »
It should let you do that.... are you doing this in C++ (Win32)?

Offline White Claw

  • Hero Member
  • *****
  • Posts: 854
Terrain Test
« Reply #8 on: September 09, 2007, 10:34:01 AM »
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.

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4954
Terrain Test
« Reply #9 on: September 09, 2007, 11:52:05 AM »
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.
 

Offline White Claw

  • Hero Member
  • *****
  • Posts: 854
Terrain Test
« Reply #10 on: September 09, 2007, 12:32:31 PM »
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.

Offline White Claw

  • Hero Member
  • *****
  • Posts: 854
Terrain Test
« Reply #11 on: September 09, 2007, 02:37:31 PM »
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).

Offline Mcshay

  • Administrator
  • Sr. Member
  • *****
  • Posts: 404
Terrain Test
« Reply #12 on: September 09, 2007, 03:28:57 PM »
I'm still getting the white flashing now, but its accompanied by a black flash too.

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4954
Terrain Test
« Reply #13 on: September 09, 2007, 08:40:38 PM »
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.
 

Offline White Claw

  • Hero Member
  • *****
  • Posts: 854
Terrain Test
« Reply #14 on: September 09, 2007, 09:12:29 PM »
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.)

Offline White Claw

  • Hero Member
  • *****
  • Posts: 854
Terrain Test
« Reply #15 on: September 11, 2007, 07:42:44 PM »
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...

Offline White Claw

  • Hero Member
  • *****
  • Posts: 854
Terrain Test
« Reply #16 on: September 16, 2007, 02:30:44 PM »
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.

Offline Leviathan

  • Hero Member
  • *****
  • Posts: 4055
Terrain Test
« Reply #17 on: September 16, 2007, 04:02:43 PM »
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.

Offline White Claw

  • Hero Member
  • *****
  • Posts: 854
Terrain Test
« Reply #18 on: September 16, 2007, 07:44:24 PM »
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).
« Last Edit: September 16, 2007, 07:58:19 PM by White Claw »