I'll start.

Will the world burn if I don't redraw in WM_PAINT? Does it have bigger ramifications than just skipping a frame?

It depends on what exactly you mean with not redrawing on WM_PAINT.

If you mean do nothing about the WM_PAINT message Windows sends the program, you will run into problems because the region needs to be validated by either the BeginPaint() EndPaint() Casey currently uses in the code or by just passing it on to DefWindowProc.

However, if you mean not painting as in not passing it any new information, the way it is being done right now would not work at all in a real game. As the window is resized the images in the game are stretched... and stretched images almost never look good.

And when I say "almost never" I mean the only cases where I've seen stretched images look good is either in abstract or cartoony images that were specifically made to look interesting or funny when stretched, or in some news channels where they stretch some data chart so the results look more appealing for their audience. Other than that, stretched images just look wrong.

Casey did mention he would implement some kind of aspect ratio locking so we will see what he does with WM_PAINT then.

This is not even a coding question. But how far off topic do we consider off topic? For example, I am working on a cool little toy program where I have been using what I've learned in handmade hero. The code looks a lot like Casey's and some of it is direct copy and paste, some of it comes from handmade penguin, and some of it is my own twist. Would it be cool if I posted it the code here at some point?

Someone posted their Ludum Dare entry, that was kinda build on handmade hero code.

https://forums.handmadehero.org/i...hp/forum?view=topic&catid=4&id=63

So I would assume it's ok.

ikerms

If you mean do nothing about the WM_PAINT message Windows sends the program

I mean this. BeginPaint() and EndPaint() seem to be mandatory for the window to be usable (as you pointed out). In addition the only time that it would have to be answered is when you can't continue with your normal loop (meaning you can't render as normal). I guess I was worried about some unexpected factors, that would cause a problem during actual gameplay. Like random OS interrupts at rapid intervals, where the lack of painting would make it very jaggy.

The reason for the question was originally that I made an OpenGL project with some bits of HH code. But at the point WM_PAINT is called I don't have my renderer set up yet, so the easiest solution was to just call BP(), EP() and ignore it. I guess the preferred way would be to initialize all that stuff in WM_CREATE, to make it in time for the WM_PAINT. I will need at least two separate calls I need: update game (and possibly render) and only render. Not that it's the end of the world, and very natural divide at that. Worth it for the "user-dragging-the-window-around" use case alone.

Thanks for the response, it provoked me to materialise the actual problem pretty well. Too bad I don't have any too relevant additions, so here's my unhelpful talking-my-thoughts-aloud instead.

If you want to do nothing with the area, just whatever is necessary for Windows to not complain I think you can call ValidateRect() (which BeginPaint() and EndPaint()do for you), but not too sure what the correct procedure is to call it.

The code looks a lot like Casey's and some of it is direct copy and paste, some of it comes from handmade penguin, and some of it is my own twist. Would it be cool if I posted it the code here at some point?

I'm sure he wouldn't mind if you use the win32 platform code or whatnot for whatever project you want to share, but it IS his source of income for this show, and he has requested that you ask him for permission first.

So I'd say ask nicely.

@Mr4thDimension

I think you've asked an important question here... I wish I better understood the nuances of licensing and how all that really works, but I'm totally out of my depth wrt that sort of thing.

All of my uncertainty/apprehension around this issue is part of why I wanted to do that ludum dare entry from memory. (Of course the main reason being it's just better to practice that way -- not to mention dems da breaks of LD anyway). But even that is kind of a grey area to me, because even from memory you end up with things that can be very similar. How similar is too similar? Etc. etc..

I know Casey addressed this on the stream at some point (probably in a Q&A) but I'm afraid I'm not sure which session. The sentiment though, AFAIR, was something like what's on the main page / FAQ:

How will the source code be licensed?
Two years after the final version of the game is released, 100% of the source code will be released into the public domain. Prior to that, all rights are reserved, so please contact me for permission before you use it in your own projects. This is a precaution to prevent people from directly cloning the game until after it has been out for a reasonable time, since this project is an expensive endeavor and I hope to offset some of the cost through sales of the game proper.

There's also a license file included with the HH source code with some of the finer points (I won't attempt my layman's interpretation).

As chebertapps said, it's probably best just to run things by Casey first.


P.S. I'd love hear anyone well-versed in how licensing usually works chime in here. Any sort of general "intro to sharing code" resource recommendations?

@schme

I had the same question actually. I ended up just letting all WM_PAINT messages fall through to DefWindowProc, but I'm curious what the possible ramifications of this are.

For example, in our main while loop, we process all the window messages in a loop before getting back to our rendering. So if the queue got clogged up with messages so much that we only started rendering every 100ms or something, could that look all janky for the player? But then, if we're only rendering every 100ms, that means we're only updating that fast too, so maybe any extra WM_PAINT scattered among that clogged up queue wouldn't help us anyway?

...dunno, I'm just thinking out loud here.

schme
I'll start.

Will the world burn if I don't redraw in WM_PAINT? Does it have bigger ramifications than just skipping a frame?

TL;DR No the world won't burn, you don't have to redraw in WM_PAINT in a game.

You can do as @ikerms mentioned, and that tells windows you've taken care of the WM_PAINT message. You won't be skipping any frames since your render loop is taking care of that.

The small (and annoying) catch is window resizing. When a window is grabbed to be resized, windows starts its own little dispatch loop and directly spams your WindowProc() with WM_SIZE and WM_PAINT messages until you let go of the mouse button. If you're not repainting the window in WM_PAINT, then the window contents will be frozen until the resizing has finished.

If you don't care about that resizing glitch, then yes you can safely ignore the WM_PAINT message when you have your own render loop.

For a game you probably want some default window sizes the player can choose from and not let them arbitrarily set the window size anyway.

For now I opted to do "the right thing": repaint in WM_PAINT and adjust the viewport in WM_SIZE. I'll probably end up locking the window size, but I feel this is a good setup for testing. I think calling the renderer is a good idea if just for the "user drags the window around" case. Fullscreen might be a different story.



This is good, thanks! BeginPaint/EndPaint felt a bit silly anyways.

You can actually see that Visual Studio is pretty slow in answering those WM_PAINT commands. Just wave a window on top of it, and compare it to the command line, your browser or whatnot.

schme
You can actually see that Visual Studio is pretty slow in answering those WM_PAINT commands. Just wave a window on top of it, and compare it to the command line, your browser or whatnot.

Visual Studio is kind of slow in many many ways :silly: