[AD] Re: Alleg-developers digest, Vol 1 #1389 - 13 msgs

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


Hi, Team

Happy New Year 2006!

I tried to install allegro-4.2.0 on GNU/HURD running on  GNU/Mach 1.3
I was able to successfully ./configure, make and make install

when i tried to run the example programs nothing came up.
I feel the graphic modes were not initialised.
what value should i Add in the system.h

#define OSTYPE_MACH        AL_ID('M','A','C','H')
#define OSTYPE_HURD       AL_ID('H','U','R','D')

Is this the pattern?? where should i tell allegro to use this macro if the above delclaration is correct, should i have to write the mach/hurd dependent code?? in order to make my allegro
program to work???

please help me with this issue :)

cheers
harsha

----- Original Message ----- From: <alleg-developers-request@xxxxxxxxxx>
To: <alleg-developers@xxxxxxxxxx>
Sent: Friday, December 30, 2005 5:22 AM
Subject: Alleg-developers digest, Vol 1 #1389 - 13 msgs


Send Alleg-developers mailing list submissions to
alleg-developers@xxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/alleg-developers
or, via email, send a message with subject or body 'help' to
alleg-developers-request@xxxxxxxxxx

You can reach the person managing the list at
alleg-developers-admin@xxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Alleg-developers digest..."


Today's Topics:

  1. Re: Problem with remove_mouse() and video bitmaps. (Peter Wang)
  2. Re: fbcon backgrounding (Peter Wang)
  3. Re: Problem with remove_mouse() and video bitmaps. (Stef)
  4. Re: Problem with remove_mouse() and video bitmaps. (aj)
  5. Re: Problem with remove_mouse() and video bitmaps. (Stef)
  6. Re: Problem with remove_mouse() and video bitmaps. (Evert Glebbeek)
  7. Re: Problem with remove_mouse() and video bitmaps. (aj)
  8. Re: Problem with remove_mouse() and video bitmaps. (Peter Wang)
  9. acquire_bitmap weirdness (Elias Pschernig)
 10. 4.2.0 release failed build on VC 2005 (Karthik Kumar)
 11. Re: Problem with remove_mouse() and video bitmaps. (Stef)
 12. Re: Problem with remove_mouse() and video bitmaps. (Elias Pschernig)
 13. Re: Problem with remove_mouse() and video bitmaps. (Stef)

--__--__--

Message: 1
Date: Fri, 30 Dec 2005 19:24:44 +1100
From: Peter Wang <tjaden@xxxxxxxxxx>
To: alleg-developers@xxxxxxxxxx
Subject: Re: [AD] Problem with remove_mouse() and video bitmaps.
Reply-To: alleg-developers@xxxxxxxxxx

On 2005-12-29, Andrei Ellman <ae-a-alleg@xxxxxxxxxx> wrote:
Peter Wang wrote:
>
>Just to be sure, calling show_mouse(NULL); before destroying the video
>bitmap had no negative side effects, correct?

That is correct. Adding show_mouse(NULL) also solved the problem that
was reported on the other machine failing to change the resolution back,
so it looks like the documentation needs to be changed.

How's this?  The text goes in the entry for show_mouse:

--- docs/src/allegro._tx (revision 5645)
+++ docs/src/allegro._tx (local)
@@ -2860,6 +2860,10 @@
pointer whenever you draw onto the screen. This is not needed if you are
   using a hardware cursor.

+ Note: you must not be showing a mouse pointer on a bitmap at the time that
+   the bitmap is destroyed with destroy_bitmap(). This does not apply to
+   `screen' since you never destroy `screen' with destroy_bitmap().
+
@@void @scare_mouse();
@xref unscare_mouse, scare_mouse_area, show_mouse
@shortdesc Helper for hiding the mouse pointer before drawing.





--__--__--

Message: 2
Date: Fri, 30 Dec 2005 19:35:56 +1100
From: Peter Wang <tjaden@xxxxxxxxxx>
To: alleg-developers@xxxxxxxxxx
Subject: Re: [AD] fbcon backgrounding
Reply-To: alleg-developers@xxxxxxxxxx

On 2005-12-28, Peter Wang <tjaden@xxxxxxxxxx> wrote:
Here's a patch to fix this.  It solves the problem by using the existing
display switching mechanism for saving the screen state to redirect
writes to the screen to a memory bitmap while we are switched away.

Committed (4.2 and 4.3).



--__--__--

Message: 3
To: alleg-developers@xxxxxxxxxx
Subject: Re: [AD] Problem with remove_mouse() and video bitmaps.
Date: Fri, 30 Dec 2005 10:45:13 +0200
From: Stef <stapostol@xxxxxxxxxx>
Reply-To: alleg-developers@xxxxxxxxxx

On Fri, 30 Dec 2005 10:24:44 +0200, Peter Wang <tjaden@xxxxxxxxxx> wrote:

+   Note: you must not be showing a mouse pointer on a bitmap at the
time that
+   the bitmap is destroyed with destroy_bitmap(). This does not apply to
+   `screen' since you never destroy `screen' with destroy_bitmap().

If the destroy_bitmap() function automatically nulled out the bitmap
pointer, it would be trivial to add a check to avoid drawing onto an
invalid bitmap. While this wouldn't be the end of this kind of problems,
it would help allegro become more robust. It wouldn't break compatibility
either (though programs using an old dll would be more crash prone).

Is there an obvious reason against this that I missed? (very probable).
Otherwise, I think I could submit a patch for this one if the following
days.


--__--__--

Message: 4
Date: Fri, 30 Dec 2005 19:55:02 +1100
From: aj <aj@xxxxxxxxxx>
To:  alleg-developers@xxxxxxxxxx
Subject: Re: [AD] Problem with remove_mouse() and video bitmaps.
Reply-To: alleg-developers@xxxxxxxxxx

Stef wrote:

On Fri, 30 Dec 2005 10:24:44 +0200, Peter Wang <tjaden@xxxxxxxxxx>
wrote:

+   Note: you must not be showing a mouse pointer on a bitmap at the
time that
+   the bitmap is destroyed with destroy_bitmap(). This does not
apply to
+   `screen' since you never destroy `screen' with destroy_bitmap().


If the destroy_bitmap() function automatically nulled out the bitmap
pointer, it would be trivial to add a check to avoid drawing onto an
invalid bitmap. While this wouldn't be the end of this kind of
problems,  it would help allegro become more robust. It wouldn't break
compatibility  either (though programs using an old dll would be more
crash prone).

Is there an obvious reason against this that I missed? (very
probable).  Otherwise, I think I could submit a patch for this one if
the following  days.


explain how that would work ?


--__--__--

Message: 5
To: alleg-developers@xxxxxxxxxx
Subject: Re: [AD] Problem with remove_mouse() and video bitmaps.
Date: Fri, 30 Dec 2005 11:09:37 +0200
From: Stef <stapostol@xxxxxxxxxx>
Reply-To: alleg-developers@xxxxxxxxxx

On Fri, 30 Dec 2005 10:55:02 +0200, aj <aj@xxxxxxxxxx> wrote:

Stef wrote:

On Fri, 30 Dec 2005 10:24:44 +0200, Peter Wang <tjaden@xxxxxxxxxx>
wrote:

+   Note: you must not be showing a mouse pointer on a bitmap at the
time that
+   the bitmap is destroyed with destroy_bitmap(). This does not apply
to
+   `screen' since you never destroy `screen' with destroy_bitmap().


If the destroy_bitmap() function automatically nulled out the bitmap
pointer, it would be trivial to add a check to avoid drawing onto an
invalid bitmap. While this wouldn't be the end of this kind of
problems,  it would help allegro become more robust. It wouldn't break
compatibility  either (though programs using an old dll would be more
crash prone).

Is there an obvious reason against this that I missed? (very
probable).  Otherwise, I think I could submit a patch for this one if
the following  days.


explain how that would work ?


I have a hunch that the crash is caused by the draw_mouse() function
accessing the _mouse_screen bitmap (which in this case is invalid, since
it is destroyed). If the destroy_bitmap function nulls automatically nulls
out the bitmap pointer, the draw_mouse could check if the _mouse_screen
exists, and do nothing if it doesn't. It would be better though if we had
a bitmap_exists() function, though it is out of the question now.

For the moment, this is only a theory. I'll try to test is today.


--__--__--

Message: 6
From: Evert Glebbeek <eglebbk@xxxxxxxxxx>
To: alleg-developers@xxxxxxxxxx
Subject: Re: [AD] Problem with remove_mouse() and video bitmaps.
Date: Fri, 30 Dec 2005 11:01:42 +0100
Reply-To: alleg-developers@xxxxxxxxxx

> If the destroy_bitmap() function automatically nulled out the bitmap
> pointer, it would be trivial to add a check to avoid drawing onto an
> invalid bitmap. While this wouldn't be the end of this kind of
> problems,  it would help allegro become more robust. It wouldn't break
> compatibility  either (though programs using an old dll would be more
> crash prone).
>
> Is there an obvious reason against this that I missed? (very
> probable).  Otherwise, I think I could submit a patch for this one if
> the following  days.


explain how that would work ?

As far as I can tell, I think he means something like

void destroy_bitmap(BITMAP *bmp)
{
  /* do stuff */
  ...
  bmp = NULL;
}

which obviously wouldn't do anything. Unless we're going to do specific
checks from within destroy_bitmap() to see wether or not the mouse is
displayed on that bitmap (ugh), the only thing we can do is to tell people
that the mouse muct be removed from the bitmap before it is destroyed.
Which does make some sense, let's be honest.

Evert


--__--__--

Message: 7
Date: Fri, 30 Dec 2005 21:13:50 +1100
From: aj <aj@xxxxxxxxxx>
To:  alleg-developers@xxxxxxxxxx
Subject: Re: [AD] Problem with remove_mouse() and video bitmaps.
Reply-To: alleg-developers@xxxxxxxxxx

Evert Glebbeek wrote:

If the destroy_bitmap() function automatically nulled out the bitmap
pointer, it would be trivial to add a check to avoid drawing onto an
invalid bitmap. While this wouldn't be the end of this kind of
problems,  it would help allegro become more robust. It wouldn't break
compatibility  either (though programs using an old dll would be more
crash prone).

Is there an obvious reason against this that I missed? (very
probable).  Otherwise, I think I could submit a patch for this one if
the following  days.


explain how that would work ?



As far as I can tell, I think he means something like

void destroy_bitmap(BITMAP *bmp)
{
  /* do stuff */
  ...
  bmp = NULL;
}



that is what i thought he meant, but wasn't sure, so i asked him to explain.


which obviously wouldn't do anything. Unless we're going to do specific
checks from within destroy_bitmap() to see wether or not the mouse is
displayed on that bitmap (ugh), the only thing we can do is to tell people
that the mouse muct be removed from the bitmap before it is destroyed.
Which does make some sense, let's be honest.


Adding specific mouse code to the destroy_bitmap() is not really an option.
Perhaps with much twisting of arm,  a debug assert could be added, if
its not going to greatly impact the performace of destroy_bitmap().



--__--__--

Message: 8
Date: Fri, 30 Dec 2005 21:29:07 +1100
From: Peter Wang <tjaden@xxxxxxxxxx>
To: alleg-developers@xxxxxxxxxx
Subject: Re: [AD] Problem with remove_mouse() and video bitmaps.
Reply-To: alleg-developers@xxxxxxxxxx

On 2005-12-30, aj <aj@xxxxxxxxxx> wrote:

Adding specific mouse code to the destroy_bitmap() is not really an option.
Perhaps with much twisting of arm,  a debug assert could be added, if
its not going to greatly impact the performace of destroy_bitmap().

Performance is not a problem.  It's just ugly, but an assertion is not
_too_ bad, I suppose.

Peter



--__--__--

Message: 9
From: Elias Pschernig <elias@xxxxxxxxxx>
To: alleg-developers@xxxxxxxxxx
Date: Fri, 30 Dec 2005 12:11:17 +0100
Subject: [AD] acquire_bitmap weirdness
Reply-To: alleg-developers@xxxxxxxxxx

I was just trying to update a docs patch from some time ago for
acquire_bitmap, in response to the mouse freezing thread, but I'm not
sure if that is enough.. acquire_bitmap just seems really weird.

As discovered by Thomas Harte in this thread,
http://www.allegro.cc/forums/thread/554054 , some HW accelerated
functions under DirectX do release an acquired bitmap implicitly.
Therefore, the current docs are wrong, they say this:

"the bitmap will only be truly released when the lock count returns to
zero"

But apparently, the "only" there is sort of wrong.. also those HW
accelerated functions will unlock the bitmap (And the "true" release in
release_bitmap may only set the reference count to 0, but does nothing
besides that). I see some ways to deal with it:

a) Update the documentation to reflect the behavior under DirectX, and
mention that this is platform specific behavior.

b) Update the documentation like above, but make the following behavior
part of the API under all platforms: If gfx_capabilities indicates that
certain drawing functions are HW accelerated, then those functions
implicitly unlock the bitmap, and you need to re-lock it afterwards.

c) Make the behavior sane. What I mean is shown by the example code
sequence from allegro.cc:

// Behavior in 4.2.0
acquire_bitmap(buffer_for_page_flipping);      // bitmap is locked
clear_to_color(buffer_for_page_flipping, 0);   // bitmap is unlocked
circle(buffer_for_page_flipping, ...); // bitmap is implicitly locked and unlocked line(buffer_for_page_flipping, ...); // bitmap is implicitly locked and unlocked putpixel(buffer_for_page_flipping, ...); // bitmap is implicitly locked and unlocked
release_bitmap(buffer_for_page_flipping);      // -

I would change the behavior to this:

// My proposed behavior
acquire_bitmap(buffer_for_page_flipping);      // bitmap is locked
clear_to_color(buffer_for_page_flipping, 0); // bitmap is implicitly unlocked and locked
circle(buffer_for_page_flipping, ...);         // -
line(buffer_for_page_flipping, ...);           // -
putpixel(buffer_for_page_flipping, ...);       // -
release_bitmap(buffer_for_page_flipping);      // bitmap is unlocked

I.e., acquire_bitmap would be the *only* way to permanently lock a
bitmap, and release_bitmap would be the *only* way to permanently unlock
a bitmap.



Personally, I'd tend to go for c). I'm slightly worried about
compatibility with existing code - but in the worst case it can decrease
performance in existing code. Next best would probably be b).. since DX
is the only useful driver to advertize hw accel in gfx_capabilities, I
believe we would not need any code changes with it.

--
Elias Pschernig



--__--__--

Message: 10
Date: Fri, 30 Dec 2005 16:53:10 +0530
From: Karthik Kumar <karthikkumar@xxxxxxxxxx>
To: Allegro Developers <alleg-developers@xxxxxxxxxx>
Subject: [AD] 4.2.0 release failed build on VC 2005
Reply-To: alleg-developers@xxxxxxxxxx

------=_Part_7252_2269984.1135941790280
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
Content-Disposition: inline

SGksCgpUaGVyZSdzIGEgcGFydGljdWxhciBidWcgaW4gTWFrZWZpbGUudmM6Cgp3aGVyZTogTVNW
Q19MSUIgPSAkKE1TVkNESVJfVSkvYmluL2xpbmsgL2xpYgoKZmFpbHMuLi4KCkl0IGlzIGNvcnJl
Y3RlZCBieSBzZXR0aW5nOgoKTVNWQ19MSUIgPSAkKE1TVkNESVJfVSkvYmluL2xpbmsgLWxpYgoK
UGxlYXNlIGxvb2sgaW50byBpdC4KCi0tCkthcnRoaWsKaHR0cDovL2d1aWx0LmJhZnNvZnQubmV0
Cg==
------=_Part_7252_2269984.1135941790280
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: base64
Content-Disposition: inline

SGksPGJyPjxicj5UaGVyZSdzIGEgcGFydGljdWxhciBidWcgaW4gPGEgaHJlZj0iaHR0cDovL01h
a2VmaWxlLnZjIj5NYWtlZmlsZS52YzwvYT46PGJyPjxicj53aGVyZTogTVNWQ19MSUIgPSAkKE1T
VkNESVJfVSkvYmluL2xpbmsgL2xpYjxicj48YnI+ZmFpbHMuLi48YnI+PGJyPkl0IGlzIGNvcnJl
Y3RlZCBieSBzZXR0aW5nOjxicj48YnI+TVNWQ19MSUIgPSAkKE1TVkNESVJfVSkvYmluL2xpbmsg
LWxpYgo8YnI+PGJyPlBsZWFzZSBsb29rIGludG8gaXQuPGJyIGNsZWFyPSJhbGwiPjxicj4tLSA8
YnI+S2FydGhpazxicj48YSBocmVmPSJodHRwOi8vZ3VpbHQuYmFmc29mdC5uZXQiPmh0dHA6Ly9n
dWlsdC5iYWZzb2Z0Lm5ldDwvYT4K
------=_Part_7252_2269984.1135941790280--


--__--__--

Message: 11
Date: Fri, 30 Dec 2005 15:05:38 +0200
From: Stef <stapostol@xxxxxxxxxx>
To: alleg-developers@xxxxxxxxxx
Subject: Re: [AD] Problem with remove_mouse() and video bitmaps.
Reply-To: alleg-developers@xxxxxxxxxx

I was in hurry so I did not explain myself enough. Let me explain what I
meant:

As far as I can tell, the problem is that the draw_mouse() function
(called by the show_mouse()) tries to draw the mouse pointer to a
non-valid bitmap (one that has been deallocated). If we had a way to tell
whether a bitmap is valid, draw_mouse() could bail out without crashing.
(Note: There is NO reason to put mouse specific code in destroy_bitmap() -
that's out of the question. It is the mouse code that checks if the target
bitmap is valid!)

The follwoing code provides a (half-correct) way:

void destroy_bitmap(BITMAP *bmp)
{
   /* do stuff */
   ...
   bmp = NULL;
}

(ideally there would be a bitmap_exists(BITMAP *bmp) function, and all
allegro functions that use bitmaps (read from them or draw to them) would
bail out if one of their arguments is not valid.)

Since we don't have a bitmap_exists() function (and for compatibilty
reasons can't add one now), we could at least place a check against NULL
in draw_mouse().

This is orthogonal to the documentation issue (ie. that one should not use
a non-valid bitmap as a target, or crashes may occur).

Does this seem reasonal?


--__--__--

Message: 12
Subject: Re: [AD] Problem with remove_mouse() and video bitmaps.
From: Elias Pschernig <elias@xxxxxxxxxx>
To: alleg-developers@xxxxxxxxxx
Date: Fri, 30 Dec 2005 14:11:51 +0100
Reply-To: alleg-developers@xxxxxxxxxx

On Fri, 2005-12-30 at 15:05 +0200, Stef wrote:


This is orthogonal to the documentation issue (ie. that one should not use
a non-valid bitmap as a target, or crashes may occur).

Does this seem reasonal?


The problem is:

destroy_bitmap(screen);

void destroy_bitmap(BITMAP *bmp)
{
  ...
  bmp = NULL
}

The above won't set screen to NULL.

--
Elias Pschernig



--__--__--

Message: 13
To: alleg-developers@xxxxxxxxxx
Subject: Re: [AD] Problem with remove_mouse() and video bitmaps.
Date: Fri, 30 Dec 2005 15:21:11 +0200
From: Stef <stapostol@xxxxxxxxxx>
Reply-To: alleg-developers@xxxxxxxxxx

On Fri, 30 Dec 2005 15:11:51 +0200, Elias Pschernig
<elias@xxxxxxxxxx> wrote:


The problem is:

destroy_bitmap(screen);

void destroy_bitmap(BITMAP *bmp)
{
   ...
   bmp = NULL
}

The above won't set screen to NULL.


True, but shouldn't the screen always be valid (while there is a gfx mode
set)? I think that the problem was with video bitmaps, which the above
code would cover.



--__--__--

_______________________________________________
Alleg-developers mailing list
Alleg-developers@xxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/alleg-developers


End of Alleg-developers Digest





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/