I'd wrap it if I were you.
Things always seem to have a way of growing on me
Who knows what may be reused in another project some day

Agreed. This project might be small, but your next project may be less small, and it would be nice if you can start your less small project based on work you did for your small project. Your choice at this point will have a lasting effect on your neuron pathways for years to come.

I'd wrap it, but not necessarily into one hulking monolithic class. Have specific classes (input, graphics, windowing, etc.) instead, and if you wanted to drop in a specific input system, while keeping the rest of your API in use, then its a much simpler process.

So basically, organize by function, not by tool.

The last project I worked on had to throw out becouse I depended waaaay too much on the DX9 framework and when I needed to switch to OpenGL everything broke.

A Bad Thing

-Frank Cashio

Abstract the windows messaging system one level and have the graphics engine receive game messages that you have created instead of windows messages.

So instead of having the graphics engine respond directly to WM_MOUSEMOVE, have WM_MOUSEMOVE result in the creation and sending of game event called Event_MouseMove(dx, dy) or something. This adds some extra cycles to your game loop execution, yes, but you gain a completely platform independent graphics system as a result.

As a general rule around here, if Kain and garbob are telling you the same thing, don't second-guess it.

What messages from the pump are you passing to the game engine?

Hmm...
I guess I am confused as to definition of game engine. I assume graphics engine covers screen output, but what game application functions are covered by the game engine? Is it everything else? (user input, network management, disk I/O).

Is your graphics engine an event listener that can receive your customized game events such as Event_ObjectMoved?

Having the separate parts of your engine be independent structures is definitely a great way to go, and they should all talk to each other the same way: through the event system.

I guess that is where I am not understanding something about your question. Why is the event system not a viable means of passing messages to your graphics engine?

ok, so messages are coming from the windows message pump to game logic.

And if I understand correctly, you are wondering how you can keep the graphics portion of your engine independent while still having it respond to these messages?

Maybe the piece you are missing is having the game logic be a sender of messages. For maximum independence, you don't want to send ALL messages directly from the message pump to the graphics engine (as you were already saying), but that means the graphics engine will need to respond to another source of messages. That source could be your game logic.

Would you say that the graphics portion of your engine is set up in such a way that it would be possible to replay the events of the game based on automated serialized data recorded from the game logic? (sort of like the automated testing described on page 826 of 2nd edition, but with game logic actions as opposed to keyboard/mouse input)

If the answer is yes, then I think you already have the solution to your question. If the answer is no, then try making it so that the graphics portion of your engine does not respond directly to messages from the windows message pump; that is what I meant by the single layer of abstraction between windows messages and the custom events described in McShaffry's book. Something translates those windows messages into game-specific events. Like W-A-S-D keypresses are translated into forward-left-back-right movement events.

There's a good chance that I still don't understand your question. But I am a firm believer in the process of elimination.

I think I understand, now.

What you are wanting (graphics engine to be easily replaceable without a massive reworking of game structure) is not possible for the reason that your graphics engine is married to the operating system's interface.

You can lessen or possibly eliminate your problem by separating the the message pump from the "graphics engine" as much as possible, thereby treating the whole message pump portion of your graphics engine as a separate entity.

That way, you will have an independent OS interface entity (which holds the message pump). This would abstract all of the OS-specific messages into SEvents. Your "graphics engine" will be a receiver of these SEvents, as well as your game logic. Your game logic will also be a sender of those SEvents. Ideally, the core of your application should be the game logic, not the graphics engine. Think of it as building your game around the logic portion and not the graphics portion.

At this point, you're just going to have to ask yourself if it is worth it to do this reorganization just for the sake of not having to redo the OS interface portion of your app if you were to change graphics engines. Sometimes, you just have to pick your battles and leave the rest for version 2.

...Although separating that OS interface from graphics might not be as big a task as I'm making it out to be.

Heh.Are you really really sure that the graphics engine doesn't have an option to turn off its interception of signals?

SDL and ncurses (the two I've worked with most) handle input, and I've found them to be easy to wrap or simply use (ncurses doesn't have much competition to port to). A normal game/logic view, as described in Mike's book, would keep the user's raw input as far away from the logic as possible. But, take comfort in the fact that changing your input system is WAY easier than the graphics system, so if you gain weeks of development time by simply not worrying about it, then I'd say just do it as it works.

If this is one of your first projects of this sort, you probably won't find yourself re-using a whole lot of your code. The second tgime around, you'll probably write a version of this code that is 3x better, in half the time. Mike's book is geared to teams (well, usually), and he certainly doesn't emphasize the one major thing that a single-man (or small team) needs to focus on: get it done! Just do it!