Allegro game programming library

> the following program exploits a bug in floodfill.

Is it remotely exploitable? ;-)

> The problem is a limit of 32767 elements in a linked list, but with this
> evil example the linked list needs a number of elements proportional to the 
> number of pixels on screen.

The mere use of short ints in the structure is evil, but I'm not sure that I 
want to double the memory footprint so let's go for the status quo.

> Patch attached.

@@ -28,7 +28,7 @@
    short flags;                  /* status of the segment */
    short lpos, rpos;             /* left and right ends of segment */
    short y;                      /* y coordinate of the segment */
-   short next;                   /* linked list if several per line */
+   int next;                     /* linked list if several per line */
 } FLOODED_LINE;

Do you think it could be worth while to switch to 'unsigned int'? And you 
could put an ASSERT at the critical point.

-- 
Eric Botcazou

Eric Botcazou wrote:
>>the following program exploits a bug in floodfill.
> 
> Is it remotely exploitable? ;-)

OK, the program may look a bit strained, but it is very natural as a 
test case for floodfill :-)

> The mere use of short ints in the structure is evil, but I'm not sure that I 
> want to double the memory footprint so let's go for the status quo.

Yeah, I think it is necessary to keep the other fields as shorts, 
because the algorithm uses a huge array of this struct. I was even 
thinking of incorporating the flags field in the top two bits of next, 
but that would only reduce the size from 12 to 10 bytes, which is not 
that useful and could even give speed penalties.

> Do you think it could be worth while to switch to 'unsigned int'?

Probably not: this is merely an array index, which we usually keep as a 
signed int. But it does make sense for lpos, rpos and y, in case someone 
floodfills really big bitmaps (but note that in general, we assume 
bitmaps can be addressed with fixed point coordinates, i.e., <32768). In 
floodfill it can't hurt supporting up to 65535-sized bitmaps, so I 
attach an updated patch.

> And you could put an ASSERT at the critical point.

Sorry, what should be ASSERTed and where is the critical point?

-- 
Sven

> Yeah, I think it is necessary to keep the other fields as shorts,
> because the algorithm uses a huge array of this struct. I was even
> thinking of incorporating the flags field in the top two bits of next,
> but that would only reduce the size from 12 to 10 bytes, which is not
> that useful and could even give speed penalties.

I agree.

> Probably not: this is merely an array index, which we usually keep as a
> signed int.

Ok.

> But it does make sense for lpos, rpos and y, in case someone floodfills
> really big bitmaps (but note that in general, we assume bitmaps can be
> addressed with fixed point coordinates, i.e., <32768). In floodfill it 
> can't hurt supporting up to 65535-sized bitmaps, so I attach an updated
> patch.

Yes, but coordinates are signed for Allegro and this would not really buy us 
anything so I think we should keep signed shorts.

> Sorry, what should be ASSERTed and where is the critical point?

The index wrapping around and the place in the code where this may happen.

-- 
Eric Botcazou

Eric Botcazou wrote:
>>But it does make sense for lpos, rpos and y, in case someone floodfills
>>really big bitmaps (but note that in general, we assume bitmaps can be
>>addressed with fixed point coordinates, i.e., <32768). In floodfill it 
>>can't hurt supporting up to 65535-sized bitmaps, so I attach an updated
>>patch.
> 
> Yes, but coordinates are signed for Allegro and this would not really buy us 
> anything so I think we should keep signed shorts.

It buys us that floodfill works with bitmaps with 32768<=width<65536 or 
32768<=height<65536. Probably most other functions work with such 
bitmaps. And it doesn't un-buy us anything, anyway.

>>Sorry, what should be ASSERTed and where is the critical point?
> 
> The index wrapping around and the place in the code where this may happen.

Oh, but now that we have int's, this can't happen: the int is an array 
index, and the language guarantees that no array is so big that an int 
can't index it.

-- 
Sven

> It buys us that floodfill works with bitmaps with 32768<=width<65536 or
> 32768<=height<65536. Probably most other functions work with such
> bitmaps. And it doesn't un-buy us anything, anyway.

Can't we use the flood() function with negative coordinates too?

> Oh, but now that we have int's, this can't happen: the int is an array
> index, and the language guarantees that no array is so big that an int
> can't index it.

Are you sure? I find only "the expression shall have an integer type" in ISO 
C99. Moreover, there is no array in flood.c at all, only a pointer to 
scratch mem.

-- 
Eric Botcazou

Eric Botcazou wrote:
> Can't we use the flood() function with negative coordinates too?

No, because the first thing that floodfill() does is make sure 
coordinates are in range. Only nonnegative values are in range. Well, it 
doesn't really matter, I can take away the `unsigned' and use my first 
patch.

>>Oh, but now that we have int's, this can't happen: the int is an array
>>index, and the language guarantees that no array is so big that an int
>>can't index it.
> 
> Are you sure? I find only "the expression shall have an integer type" in ISO 
> C99.

OK, you are possibly right in that the language can accept arrays so 
large that they can't be indexed by an int. But on the other hand we use 
int as array index throughout the library, and I think it's safe to say 
that most other code in the world does, too. Are you seriously 
suggesting to check explicitly that an array does not have more than 
2,147,483,647 elements??? With 12 bytes per element, we would first have 
to allocate 6 times more bytes than can be addressed by a 32-bit word, 
which is absurd (especially since crucial parts of Allegro still assume 
sizeof(pointer)=sizeof(int)=sizeof(long)>=4). With the same logic, we 
would have to check integer overflow every time we change an array 
index. We don't want to do that :-)

> Moreover, there is no array in flood.c at all, only a pointer to 
> scratch mem.

It is used as ((FLOODED_LINE*)_scratch_mem + p->next), so it is used in 
pointer addition, which is equivalent to array indexing.


More seriously though, it could be useful to do

    ASSERT(bmp->w<32768 && bmp->h<32768)

But that test would probably be better to do once and for all when the 
bitmap is created, because there are too many places that need this 
assumption.

Sven

On Mon, Oct 13, 2003 at 02:30:49PM +0200, Sven Sandberg wrote:
> OK, you are possibly right in that the language can accept arrays so 
> large that they can't be indexed by an int. But on the other hand we use 
> int as array index throughout the library, and I think it's safe to say 
> that most other code in the world does, too. Are you seriously 
> suggesting to check explicitly that an array does not have more than 
> 2,147,483,647 elements??? With 12 bytes per element, we would first have 
> to allocate 6 times more bytes than can be addressed by a 32-bit word, 
> which is absurd (especially since crucial parts of Allegro still assume 
> sizeof(pointer)=sizeof(int)=sizeof(long)>=4).

Out of curiosity, does the language specify a preffered variable type to use
for indexing arrays? If it does, I'd expect that to be an (unsigned ?) int
as well.
For practical purposes, the question is moot. A 32 bit unsigned integer
allows addressing of 4GB, which is the i86 upper limit to addressable memory,
IIRC.

Evert

> No, because the first thing that floodfill() does is make sure
> coordinates are in range. Only nonnegative values are in range. Well, it
> doesn't really matter, I can take away the `unsigned' and use my first
> patch.

I'd prefer.

> Are you seriously suggesting to check explicitly that an array does not
> have more than 2,147,483,647 elements??? With 12 bytes per element, we
> would first have to allocate 6 times more bytes than can be addressed by a
> 32-bit word, which is absurd (especially since crucial parts of Allegro
> still assume sizeof(pointer)=sizeof(int)=sizeof(long)>=4). With the same
> logic, we would have to check integer overflow every time we change an
> array index. We don't want to do that :-)

Yes, the ASSERT would be probably never trigger. My suggestion was made 
essentially from the maintenance viewpoint: when someone will look at the 
diff in the future, he will only see a 'short' -> 'int' change.

But I'd be happy with a comment instead.

> > Moreover, there is no array in flood.c at all, only a pointer to
> > scratch mem.
>
> It is used as ((FLOODED_LINE*)_scratch_mem + p->next), so it is used in
> pointer addition, which is equivalent to array indexing.

Essentially, yes. 

> More seriously though, it could be useful to do
>
>     ASSERT(bmp->w<32768 && bmp->h<32768)
>
> But that test would probably be better to do once and for all when the
> bitmap is created, because there are too many places that need this
> assumption.

Sure.

-- 
Eric Botcazou

> The problem is a limit of 32767 elements in a linked list, but with this
> evil example the linked list needs a number of elements proportional to the
> number of pixels on screen. Patch attached.

Patch applied to mainline and branch.

-- 
Eric Botcazou

> The problem is a limit of 32767 elements in a linked list, but with this
> evil example the linked list needs a number of elements proportional to the
> number of pixels on screen. Patch attached.

Applied to mainline and branch with a comment.

-- 
Eric Botcazou

Hi people,

I have experienced the following problem with the
mouse pointer using allegro (4.1.9 thru 4.1.11):

When the application start, it goes to
GFX_DIRECTX_ACCEL mode, then as I don't use mouse, I
do not use "install_mouse".

The problem is that sometimes (didn't got which
sequence does this) I have in the middle of the main
screen the mouse pointer. I've tried to make a
"install_mouse" and hide it, but I have this "phantom"
mouse appearance, which, if you re-plug the mouse and
move the pointer, dissapears, but my application is
standalone-kiosk alike so it's a mess to have to do
this...

BTW, if I initialize the RS-232 interface, the mouse
pointer appears almost always...

Thanks in advance,

Hugo Caro
Gaming software developer.

------------
Internet GRATIS es Yahoo! Conexión
4004-1010 desde Buenos Aires. Usuario: yahoo; contraseña: yahoo
Más ciudades: http://conexion.yahoo.com.ar

> The problem is that sometimes (didn't got which
> sequence does this) I have in the middle of the main
> screen the mouse pointer. I've tried to make a
> "install_mouse" and hide it, but I have this "phantom"
> mouse appearance, which, if you re-plug the mouse and
> move the pointer, dissapears, but my application is
> standalone-kiosk alike so it's a mess to have to do
> this...

Sure. Could you try the following hack, which is currently the only thing I 
can think of?

-- 
Eric Botcazou

Thanks a lot Eric!

I'm testing it right now, will tell you if it worked
so you can add the patch to the project.

BTW, I have another question: 

Is it possible to handle two video cards/monitors with
allegro in Windows/MSVC?

Thanks a lot again,
Kind regards,

Hugo Caro
Gaming software developer.

------------
Internet GRATIS es Yahoo! Conexión
4004-1010 desde Buenos Aires. Usuario: yahoo; contraseña: yahoo
Más ciudades: http://conexion.yahoo.com.ar

> Is it possible to handle two video cards/monitors with
> allegro in Windows/MSVC?

Do you mean handling two screens, from the Allegro point-of-view? If so, the 
answer is no.

-- 
Eric Botcazou

Hi Eric,

I had tested the patch, and worked fine... at the
beginning. 

I found the glitch: when you are at "fullscreen" mode,
there are still some applications than can "invade"
your screen, for example, Yahoo Messenger "new e-mail"
announce.

I found that after booting the machine, and putting my
application at 

May be it's a matter of setting the priority so NO
application at the "start up" folder, there were some
other applications running when I was at the main
screen that makes the mouse appear... regardless you
are at fullscreen mode and you expects "nobody" can
invade "your screen".

I made a "quick-and-dirty" patch to my application,
adding a "SetCursorPos(0,0)" in the main loop, not
very efficient, but works by now. I don't know how
does this (parent?) applications manage to invade "my"
fullscreen, but I guess allegro should put windows in
that mode (modal fullscreen??) to avoid this kind of
"intruders"...

Thanks a lot for your support!

Kind regards,
Hugo Caro
Gaming software developer.

------------
Internet GRATIS es Yahoo! Conexión
4004-1010 desde Buenos Aires. Usuario: yahoo; contraseña: yahoo
Más ciudades: http://conexion.yahoo.com.ar

Hi Eric,

I realized Allegro does not handle two monitors
(videos) -and you confirmed it-, but for my
application I only need to "activate" the screen
(fullscreen) in which allegro will blit the active
screen... is there an easy way?

I guess Allegro always write to "MONITORINFOF_PRIMARY"
only in fullscreen mode? Must I have to cheat Allegro
putting this flag to the Monitor I want to write?

Or may be I can handle all this via HDC?

Thank you very much in advance,

Hugo Caro
Gaming software developer

__________________________________
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/

Here's an idea for using Allegro with two or more monitors. I think some
GFX-cards / OS's let you stretch the desktop accross multiple monitors.

If it is possible to create a large virtual desktop where each of the two
monitors is a window into a different area of the desktop, then the program
should run in Windowed mode and open a large window that stretches accross
the length and height of the desktop. One half of the window will be on the
first monitor, and the other half of the window will be on the second
monitor. Of course, the app would need to know the resolution of each of the
physical screens so it can correctly scale the graphics in each part of the
large window. In order to prevent ther window from being moved around, once
it's positioned, the windows-procedure for the window would have to
over-ride the standard windows procedure for windows movement, so that the
Allegro window cannot be moved.



AE.




>Hi Eric,
>
>I realized Allegro does not handle two monitors
>(videos) -and you confirmed it-, but for my
>application I only need to "activate" the screen
>(fullscreen) in which allegro will blit the active
>screen... is there an easy way?
>
>I guess Allegro always write to "MONITORINFOF_PRIMARY"
>only in fullscreen mode? Must I have to cheat Allegro
>putting this flag to the Monitor I want to write?
>
>Or may be I can handle all this via HDC?
>
>Thank you very much in advance,
>
>Hugo Caro
>Gaming software developer

> I found the glitch: when you are at "fullscreen" mode,
> there are still some applications than can "invade"
> your screen, for example, Yahoo Messenger "new e-mail"
> announce.

Does the same happen with other fullscreen DirectX apps?

> I made a "quick-and-dirty" patch to my application,
> adding a "SetCursorPos(0,0)" in the main loop, not
> very efficient, but works by now. I don't know how
> does this (parent?) applications manage to invade "my"
> fullscreen, but I guess allegro should put windows in
> that mode (modal fullscreen??) to avoid this kind of
> "intruders"...

Does the attached patch make any difference?

-- 
Eric Botcazou

> I realized Allegro does not handle two monitors
> (videos) -and you confirmed it-, but for my
> application I only need to "activate" the screen
> (fullscreen) in which allegro will blit the active
> screen... is there an easy way?

Basically, you want to specify which monitor Allegro must select, right?

Currently, Allegro uses the default (NULL) DirectDraw device, so I guess the 
OS decides which monitor Allegro will be assigned. According to the DirectX 
docs, specifying the monitor is not very difficult (you need to enumerate 
the displays and pass the right GUID instead of NULL) so I think it should 
be feasible to have a configuration option.

There appears to be a subtlety though ("focus window" vs "device window") 
that doesn't exist for single-monitor systems, so I'll try to set up a 
two-monitor system before coding anything.

> I guess Allegro always write to "MONITORINFOF_PRIMARY"
> only in fullscreen mode? Must I have to cheat Allegro
> putting this flag to the Monitor I want to write?

Yes, I guess that currently the only solution is to fool Allegro into 
thinking that the monitor you want it to use is the default monitor. I don't 
know whether this is really doable though (you might want to ask the 
question in a Windows-related newsgroup or something like that).

-- 
Eric Botcazou

Hi Eric,

I delayed the answer because I made several tests
before answering this.


 --- Eric Botcazou <ebotcazou@...>
escribió: 
<CUT>
> Does the attached patch make any difference?
> 
> -- 
> Eric Botcazou> ---
/home/eric/cvs/allegro/src/win/wddmode.c	Fri Nov
> 15 11:39:39 2002
> +++ allegro/src/win/wddmode.c	Fri Oct 31 16:11:18
> 2003
> @@ -399,8 +399,11 @@
>     /* remove the window controls */
>     SetWindowLong(allegro_wnd, GWL_STYLE, WS_POPUP);
>  
> -   /* maximize the window */
> -   ShowWindow(allegro_wnd, SW_MAXIMIZE);
> +   /* maximize the window and make it always-on-top
<CUT>
------------------------

I tried it and found that the mouse pointer still
appears on the foreground when another application
runs.

BTW with this patch I found that when I ran the
application within Visual C++ 6.0 environment, the
mouse pointer appeared at the front of the fullscreen
window, as the "cursor like" pointer (owned by
VStudio).

Then I tried setting the line 

ShowWindow(allegro_wnd, SW_MAXIMIZE);

after the "SetWindowPos" call and the mouse at Visual
C++ environment dissapeared. Anyway this pointer
appears on the machine that runs the application at
the startup.

BTW, Y! messenger's "new-e-mail" little windows still
appears in fullscreen after the patch.

I tried also a different approach, I used an example
from the OpenGL course by "Neon Helium" (NEHE)
(http://nehe.gamedev.net/lesson.asp?index=01)
-thinking on using AlegroGL...- and found that any
fullscreen example on OpenGL ALSO let the mouse
pointer appear, even though you don't do anything for
this! (Another application just runs and make it
appear).

SO... I guess Windows does permit anyone to "touch"
your screen with this unwanted pointer, even in
"fullscreen-modal-don't bother my application" mode
(hehe)...

Don't know if it's a matter of running priority or
what... My tests where made on Windows 98 SE and
Windows 2000 Professional with all the last patches
and updates applied.

Thanks for your help!
Kind regards,
Hugo Caro
Gaming software developer.


------------
¡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

Hi Eric,

What I really need about this two monitors stuff is
the following:

My application runs on "fullscreen" mode, now I was
asked to do the same over the second monitor. There
are several options to fit the requirements, from best
to worst (that is, if I can't do 1) then do 2), and so
on:

1) I could select which monitor to send BLITs commands
and then allegro blits bitmaps or does it's stuff over
it. The other monitor stays with the same image,
frozen until you focus it and then you continue
BLITting to it back and forth. I thought I could do
this creating two "allegro windows", one on each
monitor device, and then setting it on the
"allegro_wnd" variable back and forth.

2) I do a "set_gfx_mode" command over the "other
monitor", rebuild the entire screen, but the other
remains unchanged until I refocus it, with the same
approach ("set_gfx_mode", load background bitmap,
etc).

3) I do a "win_set_window()" and then an
"allegro_init" call. I used 2 and 3 approaches but
only worked the 3) one and I guess the problem about
"focus windows" still exists.

4) The two "monitor devices" or windows has their own
instance of the allegro library running. I guess this
is not possible because of allegro limitations on
concurrency... is that right?

5) Be my guest! You are the one who knows this port's
internals! hehe

Count on me if you can think of a patch or approach
that I could test, just send it to me and I will test
it ASAP.

IMHO, having multiple monitors capabilities on Allegro
(I guess almost every platform it runs has this
capability) would be a very useful add-on.

Thank you very much, in advance,
Hugo Caro




------------
¡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

> SO... I guess Windows does permit anyone to "touch"
> your screen with this unwanted pointer, even in
> "fullscreen-modal-don't bother my application" mode
> (hehe)...

Yes, another regression with regard to DOS :-)

> Don't know if it's a matter of running priority or
> what... My tests where made on Windows 98 SE and
> Windows 2000 Professional with all the last patches
> and updates applied.

I'm afraid I can't help much more. I think a Win32/DirectX wizard is really 
needed at this point.

-- 
Eric Botcazou

i think the multi-monitor "solution" is not an easy one.
as there is so many options.

monitors vs desktops vs virtual screens  etc.

this multi-monitor thing does not fit well with the "allegro is a games=20
programming lib"

i dont think this approach is going to work,  trying to convince allegro=20
developers to write multi-monitor support for allegro.

it might get done if it went the other way around....  someone (you!) write=
=20
a multi-monitor program,  in linux or win32  then document ever single=20
thing in it..
then reduce it to the bare minimum,  then present it to the allegro=20
developers, and say "here,  i have a working multi-monitor app"  could it=20
be intergrated into allegro.
that is the only way i truly see it actually getting done.


my ideas on how to do it.....
have another complete allegro program running as the second monitors=20
SCREEN,  then create an inter process communitions (IPC) channel between=
 them.
then send BITMAPs from the main program(1st monitor) to the dummy(2nd=20
monitor) program to just blit them.

this should be do-able...


aj.











>Hi Eric,
>
>What I really need about this two monitors stuff is
>the following:
>
>My application runs on "fullscreen" mode, now I was
>asked to do the same over the second monitor. There
>are several options to fit the requirements, from best
>to worst (that is, if I can't do 1) then do 2), and so
>on:
>
>1) I could select which monitor to send BLITs commands
>and then allegro blits bitmaps or does it's stuff over
>it. The other monitor stays with the same image,
>frozen until you focus it and then you continue
>BLITting to it back and forth. I thought I could do
>this creating two "allegro windows", one on each
>monitor device, and then setting it on the
>"allegro_wnd" variable back and forth.
>
>2) I do a "set_gfx_mode" command over the "other
>monitor", rebuild the entire screen, but the other
>remains unchanged until I refocus it, with the same
>approach ("set_gfx_mode", load background bitmap,
>etc).
>
>3) I do a "win_set_window()" and then an
>"allegro_init" call. I used 2 and 3 approaches but
>only worked the 3) one and I guess the problem about
>"focus windows" still exists.
>
>4) The two "monitor devices" or windows has their own
>instance of the allegro library running. I guess this
>is not possible because of allegro limitations on
>concurrency... is that right?
>
>5) Be my guest! You are the one who knows this port's
>internals! hehe
>
>Count on me if you can think of a patch or approach
>that I could test, just send it to me and I will test
>it ASAP.
>
>IMHO, having multiple monitors capabilities on Allegro
>(I guess almost every platform it runs has this
>capability) would be a very useful add-on.
>
>Thank you very much, in advance,
>Hugo Caro
>
>
>
>
>------------
>=A1Ayud=E1 a los chicos navegando!
>En noviembre, Yahoo! dona un plato de comida por cada usuario que nevegue=
=20
>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/
>--
>https://lists.sourceforge.net/lists/listinfo/alleg-developers

Hi AJ

Thanks for your fast response.

I'm not trying to convince Allegro developers to write
multimonitor support, just trying to get some help on
it.

Some time ago, I asked about a particular Embedded
port I made, and I finally get it work at a 16-bit CPU
environment. This OEM platform supports two video just
changing a pointer to the display memory and this
"tiny allegro" works ok. I want to mimic this
environment in Win32/PC environment, with allegro, and
that's why I just asked about multimonitors.

But I guess a multimonitor game nowadays is an
included feature on almost every video game... so I
guess (IMHO of course) it's a "desirable" feature.

On the other hand, the "multiprocess" client-server
alike approach is what I think first to do, but I just
drop my questions to this community because is not the
same to call something like: 

"set_allegro_monitor(HMONITOR *hmon);"  (as I did in
my "tiny-allegro") 

than writing two applications with all the IPC
communication issues...

Is multimonitor a game "established" feature nowadays?
That is what I would ask in the first place.

Thanks to you and Eric and all the developers
community for the support received,

Kind regards,
Hugo Caro
Gaming software developer



------------
¡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

ok so what are the issues with having a   set_allegro_monitor(HMONITOR *hmon)

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

if allegro at some place in the source code specifies the HMONITOR it is to=
=20
use.
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:
>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@...> 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=
=20
>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/
>--
>https://lists.sourceforge.net/lists/listinfo/alleg-developers