if allegro at some place in the source code specifies the HMONITOR it is to=
then a set_allegro_monitor(HMON) would need to be added just before that.
then it should work.
what other problems would this create ?
allegro should then use the monitor specified.
At 07:37 AM 5/11/2003 -0300, you wrote:
>I didn't get your question (I'm not native English
>speaker) but this I what I guess you are asking me:
>- "what had I found as issue trying to implement
>- Or you are saying "what are the advantages of
>If your question is the first, my issues are that I
>don't know the allegro windows port internals so I
>can't make this work by myself.
>If your question is the second one, I was arguing
>yesterday about this with a windows c++ programmer at
>work, more or less, as the following:
>When I begun this development, I tested several
>libraries until I found Allegro, which I liked very
>much, because you can program your application even in
>"plain c/c++" and worked fine "as it is" in every
>platform you want.
>I first tried to use it on DOS, but I had the same
>troubles nowadays DOS developer has: the new hardware
>has NO support to DOS, I couldn't even get Allegro to
>recognize the basic "SB16" emulation for SB PCI 128
>provided by Creative. Basically, for my app, it would
>be very desirable having the DOS version working,
>because is a single user-single task app.
>Then I decided to "migrate" to Windows in the Visual
>Studio/C++ 6.0 environment and up to know this port
>showed a very solid way to make a game on Windows, and
>the best of, I could avoid learning how to program in
>Win32 "low level" way (CreateWindowsEx, Messages,
>For an Win32 C++ guru this is not a feature, but for
>me, that basically worked on DOS with Turbo C years
>ago, then got my way to Client-server VB - ASP - php -
>SQL arena, and now I'm back to C/C++ in this
>embedded-multiplatform "workspace", it is a big
>feature, you bet! hehe.
>Then I made the "mini-port" to my embedded platform
>and I have the same project working in C++ in both
>platforms, which gives me big flexibility.
>But if I have to deal with Windows C++ internals
>programming just to make this "multimon" stuff, then I
>have to leave Allegro apart, because I would have to
>learn all the Windows "native" programming issues and
>use allegro just for some functions, not as a
>When Eric told me Allegro does not deal with
>multimonitors, my approach was to have a way to
>"cheat" Allegro for Win32 so I only have to create two
>devices for each monitor and then only have to set the
>monitor on which Allegro will work (not for the rest
>of the application, but when I need this) and that's
>In my mini-allegro port worked that way, because our
>embedded system handles the two videos just changing
>the chip select address, and you have both monitors
>working with Allegro mini-port library at once. I've
>just added "gcpu_set_allegro_mon(short mon)" to my
>video driver and worked ok.
>Of course the "addon" approach is ok for me also, but
>I would need some guidance to make it work. The two
>apps is a very good one (in fact the first I thought
>when the multimon issue appeared) but have some side
>effects with the timing I would like to avoid.
>Thanks for your patience, and I share my experience as
>my "two cents" for this great project.
> --- aj <aj@...> escribi=F3: > ok so what
>are the issues with having a
> > set_allegro_monitor(HMONITOR *hmon)
>=A1Ayud=E1 a los chicos navegando!
>En noviembre, Yahoo! dona un plato de comida por cada usuario que nevegue=
>gratis con Yahoo! Conexi=F3n.
>Conectate ya en http://conexion.yahoo.com.ar
>This SF.net email is sponsored by: SF.net Giveback Program.
>Does SourceForge.net help you be more productive? Does it
>help you create better code? SHARE THE LOVE, and help us help
>YOU! Click Here: http://sourceforge.net/donate/