Amr0

The background brush of the window class is used by the default message processor to repaint the background in response to WM_ERASEBKGND. If you are doing all your painting in WM_PAINT, or continuously in the render loop, then yes, you will not need a background brush. Note that if you use GetStockObject( BLACK_BRUSH ) to set the brush of the window class, then you won't need to delete the brush, because stock objects are shared between apps.

but why in almost every example, direct2d always renders in WM_PAINT and direct3d renders when no message processing

Well, it depends on how you want your application to behave, it has nothing to do with the application using D2D or D3D. If you want the application to render continuously, then you do all the rendering in the message loop when there are no messages. This is used when the contents displayed by the application is dynamic and changes frequently. If the contents change only when the user does something to change it (like painting programs for example), then the application will update its display only when needed, and in response to WM_PAINT.

They are also called volumetric lines sometimes. There was an NVidia paper about them, and I had written a C++ DX9 sample based on it. The sample is here, and the paper is in the Nvidia SDK here (search for volume lines).

Windows will only send a single message when a mouse button is pressed and held, but it will send multiple (repeat) WM_KEYDOWN messages when a key on the keyboard is pressed and held. So yes, your scrollbar widget will have to use timers (or some other mechanism for performing an action with a certain frequency) to mimic the standard scrollbar behavior. But using Windows' timers is not difficult at all, so I don't see why you would want to avoid them.

You are multiplying red by green, so it's 0.

(2) Separating comment from non-comment code at a glance is something you need to train your brain to do.  You could train it to ignore the greyed-out text set in an italic typeface, but then you better make sure your printouts, online listings, diff viewer, every coworker's workstation, and all the other tools that you use for that 80% of software development called maintenance also use the same scheme.  Or you could train it to see stars at the beginning of lines, which always just works.

// Then what's the advantage of using /* instead of using // if there is going to be

// something at the beginning of each line anyway? In fact, using // will allow

// you to use /* to disable blocks of code*/ quickly without the comments

// inside the disabled block getting in your way.

Precisely those messages needed to do its job - no more, no less.

Why even answer if that's all you have to say?

Actually his answer sums up a strategy which is important in order to not introduce unwanted quirks. The less messages that a window handles, the less likely it is to misbehave. DefWindowProc() does A LOT of things to implement standard behavior of windows, and it expects to receive certain messages with certain data in a certain order. If your window messes with the order (by calling certain functions in its message handler which cause certain events which will in turn send certain messages before they return, or by not passing certain messages to DefWindowProc()), then there is a chance your window will break one of the standard behaviors implemented by DefWindowProc().

So yes, only process the messages that you need to process.

I've just tested with a couple of the samples that come with the DX SDK, and I've noticed similar behavior as well! I've become interested in knowing why, though I can't say I hate this behavior - for me knowing that a game will not eat up all my CPU and GPU power even though it's in the background is a good thing. I suspect it's the doing of the nvidia driver (I have a 9800GT, Win7).

Instead of storing the window pointers in a vector, store them in the list. Mouse testing is then done from top to bottom, and drawing is done from bottom to top. Moving a window to the top requires that the window be removed and added to the front of the list.

On an unrelated note, the code you posted is somewhat hard to follow because of all the nested code blocks. Try to make it more flat. For example,

if(!WindowList[i]->WindowItemList[itemnum]->GetActive())
{
continue;
}
else
{/*do stuff*/}
 

is equivalent to

if(!WindowList[i]->WindowItemList[itemnum]->GetActive())
    continue;
/*do stuff*/

In that case, the sample linked to is irrelevant indeed. phil_t is correct, with the first choice he described being the more common one.

Providing a way out of the lava is treating godmode as a "legit" feature, in which case, why stop there? If the main idea/appeal of godmode is to allow the user to explore without worrying about dying, then why not have the AI stop shooting at you in godmode altogether? Why not give it a name (and context) that makes sense in the game's world, like obtaining some legendary armor, instead of leaving the user with the feeling of uncertainty of the game's stability and ability to still function correctly in light of the "hack" that is godmode? In fact, one could even go as far as suggesting changing the game's rules such that exploration would become the game's focus in a conscious way.

Does it worth? If your game needs it, it worths. Is your game 2D or 3D? Are your models complex (high polygon count) or simple?

Calculating vertex positions on the CPU then updating the dynamic vertex buffer will work, and having CPU access to the transformed geometry may be useful if your geometry is not complex; you could do hit-testing on the geometry itself rather than an approximation. Notice here I'm talking about skinning, not animation. Animation is always done on the CPU. That said, the big boys usually skin their big meshes on the GPU.

I don't know which signals you are defining in your system, or who exactly would receive mouse input notifications (the window object or the components which make up the window), but I will briefly describe how it's done in Windows, and hopefully this will at least give you ideas.

A window has basically two areas: client and non-client. The non-client area consists of the title bar if it has one (along with the close/minimize/maximize buttons and other stuff in the title bar), the window borders if it has any, and even the scrollbar. The client area is everything else, which is basically the "content" area of the window. When the user presses down the left mouse button, windows will inspect the window to determine whether the cursor is in the client area or the non-client area of the window. If it's in the client area, it sends a "mouse down" notification to the window, and if it's in the non-client area, it sends "non client mouse down" notification.

The default implementation in Windows of the message handler for the "non-client mouse down" event is what should be interesting to you. It goes something like this:

switch( Msg )
{
	// This is the non-client mouse down notification sent
	// by the OS.
	case WM_NCLBUTTONDOWN:
	{
		HitLocation hl = DoHitTest( GetCursorLocation() );
		if( hl == CLOSE_BUTTON )
			CloseWindow( this );
		else if( hl == MINIMIZE_BUTTON )
			MinizeWindow( this );
		else if( hl == BORDER_TOP || hl == BORDER_BOTTOM ||
				 hl == BORDER_LEFT || hl == BORDER_RIGHT )
		{
			// Tell the OS (in your case the GUI manager??) that we want
			// mouse messages to be sent to this window even if the cursor
			// is outside the window.
			CaptureMouse( this ); 
			m_dragBorder = hl;
		}
	}
	return;
	
	case WM_MOUSEMOVE:
	if( m_dragBorder != NONE )
	{
		int dx = GetCursorLocation().x - prevCursorLocation.x;
		int dy = GetCursorLocation().y - prevCursorLocation.y;
		if( m_dragBorder == BORDER_TOP )
			SetWindowPos( this, oldWindowPos.x, oldWindowPos.y - dy, oldWidth, oldHeight + dy );
		else if( m_dragBorder == BORDER_BOTTOM )
			SetWindowPos( this, oldWindowPos.x, oldWindowPos.y, oldWidth, oldHeight + dy );
		// etc.
	}
	return;
}

It would be very helpful if your GUI library implements some mouse capture functionality, which enables a window to receive mouse event notifications even when the cursor is moved outside that window.

Again, I'm not saying this is how you should do it, but this is basically how it's done in Windows. I hope you will be able to get some useful ideas from this. Good luck anyway.

MrJoshL, on 24 Feb 2013 - 08:57, said:
@Amr0     Something tells me that that is not a screenshot of your editor...
It is. It's not my engine though if that's what you mean...

 

Sorry for the broken quote but the reason for the down votes, and going out on a limb here, is the fact the top of the window it says very clearly L. Spiro Engine Editor. Many of the users of this site know L. Spiro has made many posts related to his engine in development. It came across at first that you were stating the everything in the image was made entirely by yourself. The title of the window sorta comes across as being the complete opposite.

 

While you state the engine is not yours we as forum readers are not aware if you and L. Spiro are working together/sharing builds of the engine. As far as I was aware his engine has not been released for the general public to use. I hope this offers a little bit of understanding why you were down voted.

 

Sorry for the post not being on topic I just figured no one was going to answer why they down voted him. 

Aha! Thanks for taking the time to clarify.

Actually, everything in the image was indeed made by myself, despite the title of the window. However, I posted the screenshot as an example of what can be accomplished using the win32 API, and nothing more. It did not occur to me that people would even care whether it was made by me or not. I mean it's just a textured sphere! Anyway, an up-vote for you, kind sir.

I call it the node graph editor. It's a custom win32 control/window, but it uses DX9 for drawing for maximum responsiveness, but that's it, no third party libraries. Currently it does all its drawing using simple shapes (rectangles and lines) and a single texture for the plugs, so it looks plain. But I wanted to make sure it's functional before looking into making it look good.

I'm working on an editor for an engine, and I'm using the win32 API! I swear I'm not lying! I can't prove even to myself that I'm not crazy though.

I'll quote a previous post of myself for my opinion and experience with the API.

I'm one of the few that actually don't hate the win32 GUI API. It's object-oriented, light-weight (compared to the alternatives), it's native, and it has a rich set of controls. On the other hand, it's a C API, it's not easy to get into for lack of comprehensive introductory documentation, MS did not include a designer with the free versions of VS, and it's not so popular these days. But it's a very powerful library once you get your head around how it works and how to write your own custom controls, and most importantly, it's native, so you wouldn't have to deal with all that interop bulls**t to have the editor work with your native graphics engine, and you wouldn't have to learn C#/VB if you don't already know them.

Anyway, whether you end up using it or something else is up to you, and I wouldn't blame you for turning to another library, but maybe what you're aiming to accomplish isn't really that difficult to make in win32. From your description, a thin wrapper library like win32++ sounds like a perfect fit for your needs. It has lots of samples to start from.