1. Here's a Win32 one. See this? I also want the option of having no background, but in that case I'd like to be able to eliminate the child window's border. Can I change a window's style at runtime or am I stuck with it?

2. It's nice that one can use Win32 and Allegro together while eliminating conflicts with things like BITMAPs and RGBs. But what if I need a Win32 version of something Allegro overrides? I had to reproduce the Win32 RGB macro:

    #define WINRGB(r, g ,b)  ((DWORD) (((BYTE) (r) | \
          ((WORD) (g) << 8)) | \ 
          (((DWORD) (BYTE) (b)) << 16))) 

Is this the best way to handle that? What if I need a Windows BITMAP for something? How do I juggle that? Or can I?

3. Back in my newbie days, I thought it was a good idea to have a base class for enemies and derive a class for every new enemy type I needed (see STL shooter). Then I thought it was bright to have one class running Lua scripts to handle every enemy I need (see current platformer). While the last is cool for implementing new enemies fast, it's slow. To get my speed back, I thought of going back to my old way. The thought of dozens of source files again doesn't amuse me much, but after I thought about it for a while, I'm thinking it may be the way to go. I was afraid of wasting memory or something; not sure. Can I get some input on this?

All for now

See ::ModifyStyle (or CWnd::ModifyStyle in MFC).

BTW, MSDN is an excellent reference for this sort of thing. It took me less than 5 minutes to hunt this down.

Doesn't Allegro redefine those as something else (like WIN_BITMAP or something)? Check winalleg.h.

It is a good idea.

Any memory that extra classes take up is nothing compared to actual game data (sprites, tiles, etc).

Also, why does this method have to use "dozens of source files"? Unless you're one of the OOP fanatics who absolutely believes that each individual class needs its own .h/.cpp files, there's no problem.