Allegro game programming library

David Capello wrote:
> Hello Andrei, here I attached a patch which fix this bug. It's for
> "keyboard.c". Some one should test it on Linux, but I don't think that
> it'll cause a problem in any platform.

The patch works for the startup problem (caps, scroll, num locks not 
being registered at program start), but there's still the problem of 
shift not being registered when numlock is on and a numpad number is 
pressed. Also, I tried it on Linux and found a new problem: The lock 
keys are registered even after they have been toggled off.

2007/10/28, Trent Gamblin <trentg@...>:
> but there's still the problem of shift not being registered
> when numlock is on and a numpad number is
> pressed.
> [...]

Yes, to fix that error I was thinking that maybe we could use
the same as in "key[]". E.g.: when key[KEY_RSHIFT]
or key[KEY_LSHIFT] are pressed we activate the KB_SHIFT_FLAG
in "key_shifts".

We should add some code in "handle_key_press" and
"handle_key_release" (wkeybd.c) to update the "_key_shifts"
(with this we don't need GetAsyncKeyState anymore).

On Thu, 2007-10-25 at 21:58 +1000, Peter Wang wrote:
> Hi,
> 
> I was a bit surprised to see that al_acknowledge_resize() does not take
> an argument.  In a multi-window program, if you don't set the current
> display before acknowledging a resize event, that's a bug, and an easy
> one to make.  So I think al_acknowledge_resize should take the display
> as a parameter.
> 
> It's a little inconsistent with the other functions, but it's also
> special as the program is not in control of which display is being
> resized.

Agreed. I basically didn't consider multi-window programs much when
thinking about the API (and with a single window no problem can occure)
as likely 99% of uses will be single-window, and multi-window users
should be aware of the al_set_current_display function anyway. But
"al_acknowledge_resize(event.display.source)" instead of
"al_acknowledge_resize()" isn't bad enough in a single-window app not to
change this case.

-- 
Elias Pschernig <elias@...>

Peter Wang wrote:
> Hi,
> 
> I was a bit surprised to see that al_acknowledge_resize() does not take
> an argument.  In a multi-window program, if you don't set the current
> display before acknowledging a resize event, that's a bug, and an easy
> one to make.  So I think al_acknowledge_resize should take the display
> as a parameter.

Fixed in SVN.

On Sun, 2007-10-21 at 03:10 -0600, Thomas Fjellstrom wrote:
> > It would be easy to add a sign conversion pass to Allegro's mixer as
> > well of course. Basically, in
> > https://alleg.svn.sourceforge.net/svnroot/alleg/allegro/branches/4.3.10plus
> >/src/unix/alsa9.c provide another copy of alsa_mix which has an extra loop
> > over the
> > sample buffer and converts to unsigned. On driver initialization, it
> > could be decided if the normal function or the one with conversion
> > (slightly slower) should be used. E.g. the jack driver always does a
> > conversion like that since it only understands signed data.
> >
> 
> Really? I find it really odd that a sound server, thats meant to pipe and mix 
> many sound streams and formats can only handle signed data.. Just seems wrong 
> to me. :o
> 

Yes, it's because it only supports 32-bit (and 64-bit I think) float
samples and nothing else - at least from what I remember when writing
the driver. Their goal was not to support different formats, but to have
as low latency as possible (e.g. the docs even disallow calling
pthread_mutex_lock inside the mixer callback - even though I simply call
_mix_some_samples which does that and it still seems to work).

-- 
Elias Pschernig <elias@...>

On Sun, 2007-10-21 at 12:57 +0200, Elias Pschernig wrote:
> > Really? I find it really odd that a sound server, thats meant to pipe and mix 
> > many sound streams and formats can only handle signed data.. Just seems wrong 
> > to me. :o
> > 
> 
> Yes, it's because it only supports 32-bit (and 64-bit I think) float
> samples and nothing else - at least from what I remember when writing
> the driver. Their goal was not to support different formats, but to have
> as low latency as possible (e.g. the docs even disallow calling
> pthread_mutex_lock inside the mixer callback - even though I simply call
> _mix_some_samples which does that and it still seems to work).

Hm, looking again at alsa9.c, there's this line:

alsa_signed = 0;

Probably changing it to:

alsa_signed = 1;

makes the alsa driver use signed.. so the portaudio problem should be
easy to fix, instead of hardcoding alsa_signed, we'd just need to figure
out how to detect what alsa supports.

-- 
Elias Pschernig <elias@...>

On Sun October 21 2007, Elias Pschernig wrote:
> On Sun, 2007-10-21 at 03:10 -0600, Thomas Fjellstrom wrote:
> > > It would be easy to add a sign conversion pass to Allegro's mixer as
> > > well of course. Basically, in
> > > https://alleg.svn.sourceforge.net/svnroot/alleg/allegro/branches/4.3.10
> > >plus /src/unix/alsa9.c provide another copy of alsa_mix which has an
> > > extra loop over the
> > > sample buffer and converts to unsigned. On driver initialization, it
> > > could be decided if the normal function or the one with conversion
> > > (slightly slower) should be used. E.g. the jack driver always does a
> > > conversion like that since it only understands signed data.
> >
> > Really? I find it really odd that a sound server, thats meant to pipe and
> > mix many sound streams and formats can only handle signed data.. Just
> > seems wrong to me. :o
>
> Yes, it's because it only supports 32-bit (and 64-bit I think) float
> samples and nothing else - at least from what I remember when writing
> the driver. Their goal was not to support different formats, but to have
> as low latency as possible (e.g. the docs even disallow calling
> pthread_mutex_lock inside the mixer callback - even though I simply call
> _mix_some_samples which does that and it still seems to work).

I still don't get the point of that, force everything else to mix to it? so 
the mixing is bottle necked in the clients instead?

> --
> Elias Pschernig <elias@...>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/



-- 
Thomas Fjellstrom
tfjellstrom@...

>
> I still don't get the point of that, force everything else to mix to it? so
> the mixing is bottle necked in the clients instead?
>

My guess is, high quality sound apps have to use floating point anyway
as they absolutely must avoid any internal clipping, and for others
the int->float conversion of the buffer is not a bottleneck. E.g. I
can't notice any difference here between using Alsa directly or
routing it through Jack with Allegro, neither in lag nor CPU use.

On Tue October 23 2007, Elias Pschernig wrote:
> > I still don't get the point of that, force everything else to mix to it?
> > so the mixing is bottle necked in the clients instead?
>
> My guess is, high quality sound apps have to use floating point anyway
> as they absolutely must avoid any internal clipping, and for others
> the int->float conversion of the buffer is not a bottleneck. E.g. I
> can't notice any difference here between using Alsa directly or
> routing it through Jack with Allegro, neither in lag nor CPU use.

High quality? Its aiming to replace esd, you hardly need to target high end 
anything :P

But get enough stuff going, and that int->float conversion may become an 
issue, especially in apps that do it inefficiently. Why make all apps do it, 
possibly very wrong, when its easy enough to include a converter in the sound 
server itself, and have it guaranteed to be the best possible solution?

> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/



-- 
Thomas Fjellstrom
tfjellstrom@...

On Tue, 2007-10-23 at 19:09 -0600, Thomas Fjellstrom wrote:
> On Tue October 23 2007, Elias Pschernig wrote:
> > > I still don't get the point of that, force everything else to mix to it?
> > > so the mixing is bottle necked in the clients instead?
> >
> > My guess is, high quality sound apps have to use floating point anyway
> > as they absolutely must avoid any internal clipping, and for others
> > the int->float conversion of the buffer is not a bottleneck. E.g. I
> > can't notice any difference here between using Alsa directly or
> > routing it through Jack with Allegro, neither in lag nor CPU use.
> 
> High quality? Its aiming to replace esd, you hardly need to target high end 
> anything :P
> 
> But get enough stuff going, and that int->float conversion may become an 
> issue, especially in apps that do it inefficiently. Why make all apps do it, 
> possibly very wrong, when its easy enough to include a converter in the sound 
> server itself, and have it guaranteed to be the best possible solution?
> 

I think portaudio is the one who aims to replace ESD, not Jack:
http://jackaudio.org/

The main design goal of Jack was lowest possible latency (their FAQ says
none at all "When we say none, we mean absolutely zero."). And using
32-bit floats for all data means it's easy to route them between
different applications without ever losing quality or having to do
conversions (only applications themselves may need to convert if they
use a different format, like Allegro).

-- 
Elias Pschernig <elias@...>

> complete compatibility layer doesn't seem technically worthwhile any
> longer,

Oh? Why and in what sense not?

> and mentioning the year 2002 and  
> AllegroPro in an article named "future"..). The roadmap on the wiki
> (currently down) has more accurate info on current and future
> development, and also can be easily updated. So, any objections to
> simply removing this "Future" page?

Not from me, no.

Evert

On 10/23/07, Evert Glebbeek <eglebbk@...> wrote:
> > complete compatibility layer doesn't seem technically worthwhile any
> > longer,
>
> Oh? Why and in what sense not?

It's just a lot of work. Currently, we have a compatibility layer
where all A4 calls render to a special memory buffer, and then that
buffer updates to the screen - that defeats the purpose though as it
is inherently slower than just using A4 directly.

So I think, with the GFX API almost finished now (just a lack of
drivers, only Windows-Direct3D and a quite basic Linux-GLX-1.4 for
now), it's best to next work on sound (compatibility to all the old
voice functions also would be some work here I guess), filesystem and
maybe config APIs and not spend time on compatibility. After that, we
basically have A5 (Trent already wrote two A5 games, so things do look
good) - and I wouldn't want to delay the official A5 release by a year
or so just to get the compatibility layer in.

> It's just a lot of work.

Well, sure. Never assumed it'd not involve work!

> Currently, we have a compatibility layer
> where all A4 calls render to a special memory buffer, and then that
> buffer updates to the screen - that defeats the purpose though as it
> is inherently slower than just using A4 directly.

True, but it doesn't have to be perfect. In my mind, the first  
purpose of the compatibility layer is to compile existing code. It  
doesn't need to take full advantage of the new capabilities in the  
first release.
There even need not be any guarentee that a function call that  
succeeds in Allegro 4 needs to succeed in vanilla 5.0 (split_screen 
(), scroll_screen() or whatever they're called being prime examples  
of somewhat obsolete functions that could just fail and that probably  
no one will miss anyway).

> maybe config APIs and not spend time on compatibility. After that, we
> basically have A5 (Trent already wrote two A5 games, so things do look
> good) - and I wouldn't want to delay the official A5 release by a year
> or so just to get the compatibility layer in.

Well, no, it shouldn't take a year, no. But I do think it would be  
good to have the compatibility layer in the release labelled as  
'5.0'. Even after 'A5' is basically done we'd have to go through a  
sequence of WIP/beta/RC.

Evert

On Tue, 23 Oct 2007 13:12:16 +0300, Evert Glebbeek <eglebbk@...> wrote:

>> It's just a lot of work.
>
> Well, sure. Never assumed it'd not involve work!
>
>> Currently, we have a compatibility layer
>> where all A4 calls render to a special memory buffer, and then that
>> buffer updates to the screen - that defeats the purpose though as it
>> is inherently slower than just using A4 directly.
>
> True, but it doesn't have to be perfect. In my mind, the first
> purpose of the compatibility layer is to compile existing code. It
> doesn't need to take full advantage of the new capabilities in the
> first release.
> There even need not be any guarentee that a function call that
> succeeds in Allegro 4 needs to succeed in vanilla 5.0 (split_screen
> (), scroll_screen() or whatever they're called being prime examples
> of somewhat obsolete functions that could just fail and that probably
> no one will miss anyway).
>
>> maybe config APIs and not spend time on compatibility. After that, we
>> basically have A5 (Trent already wrote two A5 games, so things do look
>> good) - and I wouldn't want to delay the official A5 release by a year
>> or so just to get the compatibility layer in.
>
> Well, no, it shouldn't take a year, no. But I do think it would be
> good to have the compatibility layer in the release labelled as
> '5.0'. Even after 'A5' is basically done we'd have to go through a
> sequence of WIP/beta/RC.
>
> Evert
>

Just throwing an idea, but the compatibility layer doesn't *have* to be  
the job of the Allegro developers. If there is a real need for one, users  
can step up and write an add-on library.

Just make it very clear that A5 won't be compatible with A4 well in  
advance of the release, to give A4 users the chance to a) either update  
their projects or b) write the compatibility layer. An announcement in  
a.cc would be a good idea, as soon as the new API gets semi-stable.

Elias Pschernig wrote:
> I committed it (to the 4.3.10plus branch), but changed the
> word "internal" to "linked". 

Isn't this going to be in the forthcoming 4.2.3 release as well?

AE.

On Sun, 2007-10-21 at 18:35 +0200, Andrei Ellman wrote:
> Elias Pschernig wrote:
> > I committed it (to the 4.3.10plus branch), but changed the
> > word "internal" to "linked". 
> 
> Isn't this going to be in the forthcoming 4.2.3 release as well?
> 

Not sure.. I thought 4.2.2 was the last 4.2 (except that no_asm thing).

-- 
Elias Pschernig <elias@...>

Elias Pschernig wrote:
> On Sun, 2007-10-21 at 18:35 +0200, Andrei Ellman wrote:
>> Elias Pschernig wrote:
>>> I committed it (to the 4.3.10plus branch), but changed the
>>> word "internal" to "linked". 
>> Isn't this going to be in the forthcoming 4.2.3 release as well?
>>
> 
> Not sure.. I thought 4.2.2 was the last 4.2 (except that no_asm thing).


If we're going to release a 4.2.3 to fix the no_asm thing, we might as 
well include this as well. For that matter, we should include the 
wkeybd.c patch (that improves the key_shifts situation considerably) and 
any other fixes that have cropped up since 4.2.2 was released.

AE.

> > Not sure.. I thought 4.2.2 was the last 4.2 (except that no_asm thing).

Well, the last one planned, sure. However, if we're going to do a bugfix 
4.2.3 release anyway, there's no reason not to include the other fixes we 
have as well - although I suppose that technically this isn't a bugfix.

> If we're going to release a 4.2.3 to fix the no_asm thing, we might as 
> well include this as well. For that matter, we should include the 
> wkeybd.c patch (that improves the key_shifts situation considerably) and 
> any other fixes that have cropped up since 4.2.2 was released.

As long as they apply cleanly to 4.2 SVN I agree. It shouldn't be too much 
work though, since that will detract from 4.3/4.9 development.
One thing I saw mentioned on ACC that should be fixed has to do with axes 
on gamepades being miscounted in Windows. I think there was a similar 
problem on the Mac where it was fixed, so someone with Windows should 
maybe take a look at this.

Evert