Okay, I've mentioned this before. I'm making a little program for my class that draws up a window on the second monitor of the computer, which is set up to be displayed at the front of the room via projector. Works fine and dandy, and there's been three versions. One that's just an Allegro GFX_AUTODETECT_WINDOWED, one that's Win32 and OpenGL, and one that's Win32 and uses Allegro to draw the double buffer to the device context via draw_to_hdc(). Those last two are made with the class style WS_POPUP and just drawn to cover the second monitor, making it appear fullscreen (the pure Allegro program I just drag over there ) since I couldn't figure out how to make it go actually fullscreen on monitor two.

Now, I'm hammering out the final version of this thing after all my experimenting. And the third program setup works the best for me; I can use all the fancy Win32 GUI stuff with the simple Allegro graphics routines. Works great. One catch: it's slow. Like, really slow. Like runs at a quarter the speed of the other two programs slow, at best.

Now I assume this is an issue with hardware acceleration of some kind. The other two programs are fine so I know the machine is (barely) capable. The pure Allegro setup won't work because I need a dialog box or two and it's got the ugly border. The Win32/OpenGL version is okay, but OpenGL is a pain to set up compared to Allegro, plus the Allegro code is already done anyway (the Win32/OpenGL test was actually a completely seperate program).

So, I'd really like to know what Allegro is doing that it works fine in the plain version, but runs so slow in the Win32 version. I'm guessing there's some DirectX of some kind running in the background? How hard would it be to add that as a wrapper between Allegro and Win32? I've never used DirectX. Should I just bite the bullet and do the best I can with OpenGL 2D and Win32, and forget Allegro? I'm hoping someone with insight into Allegro's guts can tell me how hard it is to reproduce what it's doing. Otherwise I'll just go with OpenGL, clumsy as I am with it.

I can try to provide some skeleton code of any of these programs if it would help.

If I'm right, blit_to_hdc() should rely on GDI, not on DirectX.

Do I understand correctly that you have one Allegro application that needs to go fullscreen on the second monitor? So it's not a matter of multiple windows?

I won't have any real solution, though.

[edit]

A quick look at the sources under /win shows that function is in gdi.c, so I guess I'm right.

Yes.

GDI is always slow as hell.

If he switches to OpenGL, we will never see TMS!

02:20 am idea (so discard it if sounds strange, tomorrow I'll reread it ^_^): Can't you have all the fancy Win32 GUI stuff in a window and have Allegro manage its other? Or even use a pipe to connect a Win32 program to the Allegro one, and you pass anything you get from the Win32 GUI program to the Allegro program through the pipe or some other IPC system?

MR: no, because the whole point is the Allegro window is ugly. It's got a border I can't get rid of.

MM: I'd love to "go figure how", but the Allegro source code does not make for light reading the last time I examined it. :p

DD: Can I use that with Win32? I already know OpenGL fairly well, the point is to avoid re-writing old code that already works fine in Allegro. I may just bite the bullet and go that path if I can get it running at a decent speed though ....

In the other words, there is nothing special Allegro doing in GFX_GDI mode.

That's why we mentioned DirectX. IT USES DIRECTX!. I hope you read that this time.

Oh, threre is, win_set_window will let you give allegro your own window. or win_get_window, and you can MODIFY allegro's.

win_set_window HAS to be done before a call to set_gfx_mode iirc.

It runs on windows as well as linux. On linux you must compile with NO_D3D=1.

If by win32 you mean to ask if it can be placed inside a win32 control, then no.

Two requests:
1. Please define "Whicked Fast" (especially compared to DDraw and D3D emulated DDraw)
2. Prove it.