Re: [AD] Two monitors... anyway (ups)

[Hugo Daniel Caro <hugo_caro@xxxxxxxxxx>]

Hi AJ,

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
"set_allegro_monitor""? 

- Or you are saying "what are the advantages of
having" set_allegro_monitor?

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,
etc.etc.).

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
"multiplatform" wrapper.

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
all.

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.

Kind regards,
Hugo.
 --- aj <aj@xxxxxxxxxx> escribió: > ok so what
are the issues with having a  
> set_allegro_monitor(HMONITOR *hmon)


------------
¡Ayudá a los chicos navegando!
En noviembre, Yahoo! dona un plato de comida por cada usuario que nevegue gratis con Yahoo! Conexión.
Conectate ya en http://conexion.yahoo.com.ar