Allegro game programming library

On Sun, 2011-06-19 at 15:42 -0500, Matthew Leverton wrote:
> Attached is a sample implementation of native system menus for
> Windows. I put it in the native dialog addon and updated the
> native_file_chooser example. The API is functional, but not complete:
> 
> ALLEGRO_MENU *al_create_menu(void);
> bool al_append_menu (ALLEGRO_MENU *parent, ALLEGRO_MENU *popup, char
> const *title, int id);
> void al_set_display_menu(ALLEGRO_DISPLAY *display, ALLEGRO_MENU *menu);
> 
> Basic usage:
> 
> ALLEGRO_MENU *menu = al_create_menu();
> ALLEGRO_MENU *file = al_create_menu();
> al_append_menu(file, NULL, "Open", OPEN_ID);
> al_append_menu(file, NULL, "Exit", EXIT_ID);
> al_append_menu(menu, file, "File", 0);
> al_set_display_menu(display, menu);
> 

Nice. Will be especially important under OSX since if I remember right
the MAC Store guidelines require you to have certain menu entries to
pass validation.

> A higher level function could take some sort of A4-like structure to
> make creating the menu less verbose.
> 
> Events are sent via the display's event source:
> 
> if (event.type == ALLEGRO_EVENT_MENU_CLICK && event.menu.id == EXIT_ID)
> 

I wonder if that can work under OSX - the menu seems to be per-process
and not per-window there. E.g. in XCode with all its separate windows
the menu stays mostly the same no matter which window is selected. If
someone implements this for OSX and this really is a problem we probably
need to tell the user to call al_set_display_menu again in response to
window-activated messages.

> 
> Now to the dirty implementation details:
> 
[..]
> 3) I don't know about OS X or GTK menus, but I assume they could use
> the same sort of API as above.
> 

I might do the GTK version (if I don't forget).

-- 
Elias Pschernig <elias.pschernig@...>

Can you make it so the menu can be hidden/shown programmatically? Maybe
it would only appear if the mouse was near it or something (just as an
option).

On 06/19/2011 02:42 PM, Matthew Leverton wrote:
> Attached is a sample implementation of native system menus for
> Windows. I put it in the native dialog addon and updated the
> native_file_chooser example. The API is functional, but not complete:
>
> ALLEGRO_MENU *al_create_menu(void);
> bool al_append_menu (ALLEGRO_MENU *parent, ALLEGRO_MENU *popup, char
> const *title, int id);
> void al_set_display_menu(ALLEGRO_DISPLAY *display, ALLEGRO_MENU *menu);
>
> Basic usage:
>
> ALLEGRO_MENU *menu = al_create_menu();
> ALLEGRO_MENU *file = al_create_menu();
> al_append_menu(file, NULL, "Open", OPEN_ID);
> al_append_menu(file, NULL, "Exit", EXIT_ID);
> al_append_menu(menu, file, "File", 0);
> al_set_display_menu(display, menu);
>
> A higher level function could take some sort of A4-like structure to
> make creating the menu less verbose.
>
> Events are sent via the display's event source:
>
> if (event.type == ALLEGRO_EVENT_MENU_CLICK && event.menu.id == EXIT_ID)
>
> Now to the dirty implementation details:
>
> 1) It requires hooking into the Allegro Windows message callback
> (window_callback). I just hacked on an extra callback as part of the
> ALLEGRO_DISPLAY_WIN structure that the native dialog addon uses.
> Obviously that's not a great solution. What about adding a public
> function like:
>
> al_win_add_message_callback( /* my callback function */ );
>
> That would add a callback that would be processed before Allegro's. If
> it returns TRUE, then Allegro does not process the event. Obviously a
> person could break things with this, but I don't see why that's our
> concern.
>
> 2) I added a "first class" ALLEGRO_MENU_EVENT, but I assume addons
> shouldn't do that.
>
> I was going to just create and emit a user event (I assume that's what
> the audio streams do), but I wanted to use the display's event source.
> The docs say "The event source must have been initialised with
> al_init_user_event_source." Does that mean I'm not allowed to emit a
> user event through the display's event source?
>
> 3) I don't know about OS X or GTK menus, but I assume they could use
> the same sort of API as above.
>
> --
> Matthew Leverton
>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev

On Mon, Jun 20, 2011 at 2:56 PM, Elias Pschernig
<elias.pschernig@...> wrote:
> On Sun, 2011-06-19 at 15:42 -0500, Matthew Leverton wrote:
>> Events are sent via the display's event source:
>>
>> if (event.type == ALLEGRO_EVENT_MENU_CLICK && event.menu.id == EXIT_ID)
>>
>
> I wonder if that can work under OSX - the menu seems to be per-process
> and not per-window there.
>
If so, the menu event would go to whatever the active window is. The
bigger problem would be switching the menu whenever a new display is
activated.

I'll have to give the API a bit more thought though with regard to
single menu systems.


On Mon, Jun 20, 2011 at 3:12 PM, Jon Rafkind <workmin@...> wrote:
> Can you make it so the menu can be hidden/shown programmatically? Maybe it
> would only appear if the mouse was near it or something (just as an option).
>
The API is only minimal right now, but something like
al_show/hide_menu(display) would work.

However, under OS X (and perhaps some Linux setups) the menu would not
be attached to the window, so that particular use case wouldn't be
cross platform.

--
Matthew Leverton

On 20 Jun 2011, at 15:56 , Elias Pschernig wrote:
> Nice. Will be especially important under OSX since if I remember right
> the MAC Store guidelines require you to have certain menu entries to
> pass validation.

Important to check. Note that we do programmatically create some "standard" menu entries already, which may be enough to satisfy those guidelines (haven't checked though).

> I wonder if that can work under OSX - the menu seems to be per-process
> and not per-window there.

Yes.

> E.g. in XCode with all its separate windows
> the menu stays mostly the same no matter which window is selected. If
> someone implements this for OSX and this really is a problem we probably
> need to tell the user to call al_set_display_menu again in response to
> window-activated messages.

When I did something with generating menus from code (not for Allegro, but could probably be adapted for this) I did figure out how to add menus and menu entries (fairly easy) but I didn't find out how you can remove a menu again. As far as I could tell you can't, or at least not easily. I think you also can't change the order of menus (which is a problem, since we create the "Window" menu when the program starts, but it should be created last in order to show up at the right where it's supposed to).

Anyway, I can look into doing this for OS X (it's really something I would like to add), but not until next week or so at the earliest.

On Mon, Jun 20, 2011 at 6:07 PM, Evert Glebbeek <eglebbk@...> wrote:
> When I did something with generating menus from code (not for Allegro, but could probably be adapted for this) I did figure out how to add menus and menu entries (fairly easy) but I didn't find out how you can remove a menu again. As far as I could tell you can't, or at least not easily.
>
How does the following seem with respect to OS X?

* al_get_supported_menu_types()
  1: application
  2: window (display)
  4: popup

* al_show_menu(ALLEGRO_MENU *menu, ALLEGRO_DISPLAY *display);

If window menus are NOT supported then the first call would always set
the application menu. Subsequent calls to setting display menus would
fail.

Perhaps passing NULL as the display could set the application menu
explicitly, but unless GTK supports both application (e.g., Unity) and
window menus, then I think making the distinction would only hinder
compatibility across platforms as Windows-only and OS X-only people
may not consider the other side.

* al_popup_menu(ALLEGRO_MENU *menu, ALLEGRO_DISPLAY  *display, int x,
int y, int flags);

Shows a context menu at the given location.

* al_hide_menu(ALLEGRO_MENU *menu);

Hides any menu of any type. If problematic, it wouldn't necessarily
need to be supported. (Although the OS specific implementation could
be to delete the menu item in question, and then re-add it if it is
later shown.)

* al_get_menu_event_source(ALLEGRO_MENU *menu)

All events get sent via that source, as opposed from a display source.

> I think you also can't change the order of menus (which is a problem, since we create the "Window" menu when the program starts, but it should be created last in order to show up at the right where it's supposed to).
>
I did a quick search on stackoverflow, and saw code like:

NSMenu* rootMenu = [NSApp mainMenu];
[rootMenu removeItemAtIndex:2];

Is that the type of menu Allegro is currently using? It seemed like it
could be updated programmatically from the various questions I looked
at.

--
Matthew Leverton

On 21 Jun 2011, at 4:22 , Matthew Leverton wrote:
> How does the following seem with respect to OS X?
> 
> * al_get_supported_menu_types()
>  1: application
>  2: window (display)
>  4: popup
> 
> * al_show_menu(ALLEGRO_MENU *menu, ALLEGRO_DISPLAY *display);
> 
> If window menus are NOT supported then the first call would always set
> the application menu. Subsequent calls to setting display menus would
> fail.
> 
> Perhaps passing NULL as the display could set the application menu
> explicitly, but unless GTK supports both application (e.g., Unity) and
> window menus, then I think making the distinction would only hinder
> compatibility across platforms as Windows-only and OS X-only people
> may not consider the other side.

I think it could work, but I find it a bit confusing. That may be because the two ways of doing menus (per-window or per-application) are really very different and trying to catch both in one API ends up being messy one way or the other. I have to admit that in any thoughts I've ever had of doing this, I'd only thought of single-window applications.
Perhaps that's the most common use-case though, so maybe it's fine to optimise for that?

> * al_popup_menu(ALLEGRO_MENU *menu, ALLEGRO_DISPLAY  *display, int x,
> int y, int flags);
> 
> Shows a context menu at the given location.

I think that's fine. I never really looked into context menus very much, but I think the API would fit from what I remember.

> * al_hide_menu(ALLEGRO_MENU *menu);
> 
> Hides any menu of any type. If problematic, it wouldn't necessarily
> need to be supported. (Although the OS specific implementation could
> be to delete the menu item in question, and then re-add it if it is
> later shown.)

Might be a good idea to have it return true/false to indicate success or failure. Even if we intend to eventuall fix that, it helps getting the early implementation done.
Unless it's very easy to do on all platforms, of course.

> I did a quick search on stackoverflow, and saw code like:
> 
> NSMenu* rootMenu = [NSApp mainMenu];
> [rootMenu removeItemAtIndex:2];
> 
> Is that the type of menu Allegro is currently using? It seemed like it
> could be updated programmatically from the various questions I looked
> at.

Yes, it is.
I hadn't thought to try removeItemAtIndex, but with hindsight it makes sense. We can then probably also insert at random places, which is very useful.

Evert

On Sun, Jun 19, 2011 at 3:42 PM, Matthew Leverton <meffer@...> wrote:
> Attached is a sample implementation of native system menus for
> Windows. I put it in the native dialog addon and updated the
> native_file_chooser example. The API is functional, but not complete:
>
I've written up a proposal at:

http://wiki.allegro.cc/index.php?title=Native_Menu_Propsoal

I'll implement it for Windows, which will take care of most of the
dirty work. Linux and OS X would just have to fill in the specific OS
functionality when a menu is created, updated, or deleted.

--
Matthew Leverton

On 06/29/2011 03:41 PM, Matthew Leverton wrote:
> On Sun, Jun 19, 2011 at 3:42 PM, Matthew Leverton <meffer@...> wrote:
>> Attached is a sample implementation of native system menus for
>> Windows. I put it in the native dialog addon and updated the
>> native_file_chooser example. The API is functional, but not complete:
>>
> I've written up a proposal at:
>
> http://wiki.allegro.cc/index.php?title=Native_Menu_Propsoal
>
> I'll implement it for Windows, which will take care of most of the
> dirty work. Linux and OS X would just have to fill in the specific OS
> functionality when a menu is created, updated, or deleted.

Implementation question: if you remove a menu do the existing indicies
remain valid?

m = create_menu();
append_item(m); // has index 0
append_item(m); // index 1
append_item(m); // index 2
remove_item(1);

Does the 3rd item added still have index 2 or is it reshuffled to item 1?

And what exactly are the semantics of insert_item?
a) insert before (thus all existing indicies are invalidated)
b) insert after (invalidate indicies)
c) replace whatever is at the current index

On Wed, Jun 29, 2011 at 4:49 PM, Jon Rafkind <workmin@...> wrote:
> Implementation question: if you remove a menu do the existing indicies
> remain valid?
>
No. But it would be safe to do something like:

al_set_menu_item_flags(menu, al_get_menu_index_by_id(menu, MY_ID), 0);

But generally speaking, you should know what the index is (because you
created the menu). So for simple things, you could just hardcode the
index if you prefer.

I could make it work something like:

#define ALLEGRO_MENU_ID (1 << 31)

al_remove_menu_item(menu, index);
al_remove_menu_item(menu, id | ALLEGRO_MENU_ID);

Or IDs could simply be a required parameter, and then you never work
with indexes.

But it's really a rather simple implementation detail that is easy to
adjust whenever.

> And what exactly are the semantics of insert_item?
>
Insert before that indexed item.

--
Matthew Leverton

you sure about that?

i have 0x6D listed as  MINUS.. also known as  VK_SUBTRACT

VK_DECIMAL  (the dot/delete key)   is  0x6E






On 29/06/2011 7:17 AM, Omar Cornut wrote:
> I tested this on three computers, pressing the "del/dot" key on a keypad
> return keycode 123 to the user which is undefined+16 in Allegro's keycodes.h
>
> The patch for wkeyboard.c is:
>
> -   /* 0x6C */    ALLEGRO_KEY_UNKNOWN+15,  ALLEGRO_KEY_PAD_MINUS,
> ALLEGRO_KEY_UNKNOWN+16,     ALLEGRO_KEY_PAD_SLASH,
>
> +   /* 0x6C */    ALLEGRO_KEY_UNKNOWN+15,  ALLEGRO_KEY_PAD_MINUS,
> ALLEGRO_KEY_PAD_DELETE,     ALLEGRO_KEY_PAD_SLASH,
>
> Regards.
> Omar
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2

On 28.06.2011 23:44, AJ wrote:
>
> you sure about that?
>
> i have 0x6D listed as  MINUS.. also known as  VK_SUBTRACT
>
> VK_DECIMAL  (the dot/delete key)   is  0x6E

I think 6E is where he put it, actually.  ALLEGRO_KEY_PAD_DELETE is the 
wrong name, though.  When num lock is on, it should be 
ALLEGRO_KEY_PAD_DECIMAL or something.  Windows calls it VK_DECIMAL, 
because it's not always a dot.  On my Norwegian keyboard it's a comma. 
Depends on what Allegro does on other platforms, though.

>
>
>
>
>
> On 29/06/2011 7:17 AM, Omar Cornut wrote:
>>  I tested this on three computers, pressing the "del/dot" key on a keypad
>>  return keycode 123 to the user which is undefined+16 in Allegro's keycodes.h
>>
>>  The patch for wkeyboard.c is:
>>
>>  -   /* 0x6C */    ALLEGRO_KEY_UNKNOWN+15,  ALLEGRO_KEY_PAD_MINUS,
>>  ALLEGRO_KEY_UNKNOWN+16,     ALLEGRO_KEY_PAD_SLASH,
>>
>>  +   /* 0x6C */    ALLEGRO_KEY_UNKNOWN+15,  ALLEGRO_KEY_PAD_MINUS,
>>  ALLEGRO_KEY_PAD_DELETE,     ALLEGRO_KEY_PAD_SLASH,
>>
>>  Regards.
>>  Omar
>>
>>  ------------------------------------------------------------------------------
>>  All of the data generated in your IT infrastructure is seriously valuable.
>>  Why? It contains a definitive record of application performance, security
>>  threats, fraudulent activity, and more. Splunk takes this data and makes
>>  sense of it. IT sense. And common sense.
>>  http://p.sf.net/sfu/splunk-d2d-c2
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2

On Fri, Jun 17, 2011 at 12:44 PM, Elias Pschernig
<elias.pschernig@...> wrote:
> Ah, yes, I had misread the wiki page. So the additional change I'd
> request is to have the default be ALLEGRO_CONVERT_BITMAP (i.e. when you
> never ever call al_set_new_display_flags in your thread). Then my
> concerns would be satisfied.
>
> The behavior of using 0 for flags would not change not the behavior
> after the first explicit call to al_set_new_display_flags.
>
I don't think anybody would care if the display option is enabled by
default (because it wouldn't affect anything by itself), but you may
get complaints if the bitmap flags default to ALLEGRO_CONVERT_BITMAP
if al_set_new_bitmap_flags() is never called.

I personally don't care, so it's the others you'd have to convince.

--
Matthew Leverton

On 2011-06-17, Matthew Leverton <meffer@...> wrote:
> On Fri, Jun 17, 2011 at 12:44 PM, Elias Pschernig
> <elias.pschernig@...> wrote:
> > Ah, yes, I had misread the wiki page. So the additional change I'd
> > request is to have the default be ALLEGRO_CONVERT_BITMAP (i.e. when you
> > never ever call al_set_new_display_flags in your thread). Then my
> > concerns would be satisfied.
> >
> > The behavior of using 0 for flags would not change not the behavior
> > after the first explicit call to al_set_new_display_flags.
> >
> I don't think anybody would care if the display option is enabled by
> default (because it wouldn't affect anything by itself), but you may
> get complaints if the bitmap flags default to ALLEGRO_CONVERT_BITMAP
> if al_set_new_bitmap_flags() is never called.
> 
> I personally don't care, so it's the others you'd have to convince.

Fine for me.

Peter

On Sat, 2011-06-25 at 12:10 +1000, Peter Wang wrote:
> On 2011-06-17, Matthew Leverton <meffer@...> wrote:
> > On Fri, Jun 17, 2011 at 12:44 PM, Elias Pschernig
> > <elias.pschernig@...> wrote:
> > > Ah, yes, I had misread the wiki page. So the additional change I'd
> > > request is to have the default be ALLEGRO_CONVERT_BITMAP (i.e. when you
> > > never ever call al_set_new_display_flags in your thread). Then my
> > > concerns would be satisfied.
> > >
> > > The behavior of using 0 for flags would not change not the behavior
> > > after the first explicit call to al_set_new_display_flags.
> > >
> > I don't think anybody would care if the display option is enabled by
> > default (because it wouldn't affect anything by itself), but you may
> > get complaints if the bitmap flags default to ALLEGRO_CONVERT_BITMAP
> > if al_set_new_bitmap_flags() is never called.
> > 
> > I personally don't care, so it's the others you'd have to convince.
> 
> Fine for me.
> 

Committed it. The only test for it is some lines at the beginning of
ex_loading_thread - we probably should expand the unit tests to be able
to test other things than bitmap similarity so results like this or the
string functions would also be in the test results (and could then go
out of the examples folder).

-- 
Elias Pschernig <elias.pschernig@...>

On Tue, Jun 21, 2011 at 11:54 PM, Matthew Leverton <meffer@...> wrote:
> Attached is a patch that adds two functions under Windows that allows
> the user to intercept messages sent to the window.
>
Committed.

--
Matthew Leverton

On June 19, 2011, Trent Gamblin wrote:
> I want to add two very simple functions to the iphone port. These allow you
> to use Game Center in your games and I assume other screen overlay
> thingies like the on screen keyboard. The additions, minus declarations
> are here:
> 
> Index: allegroAppDelegate.m
> ===================================================================
> --- allegroAppDelegate.m	(revision 14796)
> +++ allegroAppDelegate.m	(working copy)
> @@ -18,6 +18,16 @@
>  static volatile bool waiting_for_program_halt = false;
>  static float scale_override = -1.0;
> 
> +UIWindow *al_iphone_get_window(void)
> +{
> +	return [global_delegate window];
> +}
> +
> +UIView *al_iphone_get_view(void)
> +{
> +	return [global_delegate view];
> +}
> +
>  static bool is_ipad(void)
>  {
>  #if (__IPHONE_OS_VERSION_MAX_ALLOWED >= 30200)
> 
> 
> Basically just two accessors. I don't think there's any reason now to
> include them, but before I begin exposing some innards I figured I'd
> check. Elias has more experience with this than me.

If we're talking on screen keyboard support, I think the native dialog addon 
should probably include a function to pop it up on supported platforms (like 
iOS and Android). But other more specific things probably can't be added in 
that way, which would make these accessors useful.

> Trent
> ---------------------------------------------------------------------------
> --- EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev


-- 
Thomas Fjellstrom
tfjellstrom@...

On 2011-06-19, at 9:29 PM, Thomas Fjellstrom wrote:
> If we're talking on screen keyboard support, I think the native dialog addon 
> should probably include a function to pop it up on supported platforms (like 
> iOS and Android). But other more specific things probably can't be added in 
> that way, which would make these accessors useful.

Well I don't plan on adding a keyboard function to native dialogs at the moment,
so at the very least the user could manually access it given these functions. That's
all an assumption, I don't know (but I assume) that using the keyboard on iOS
would work similarly to game center dialogs, or if you would need them at all.

Trent

On Sat, Jun 18, 2011 at 12:10 AM, Matthew Leverton <meffer@...> wrote:
> Attached is a patch to:
>
> * change examples to always use SUGGEST with the display option for
> the number of samples.
> * Fixes a typo in the skater demo.
> * enables multisampling on the speed demo
>
> Any objections?
>

Committed.

--
Matthew Leverton