Allegro game programming library

Andrei Ellman wrote:
> 
> The second version using makefile.helper does not work if using MSVC6, 
> as msvchelp.c does not get called. Either use the version of the patch 
> that I've attatched (a modified version of the first version of your 
> patch), or update fix.bat so that msvchelp.c is called regardless of 
> which MSVC version is being used (and update the docs to reflect this).

Bah, I just applied this patch. IMO there is no much point unuglyfing 
the 4.2 branch build system as long as it works.
And making --msvcpaths default wouldn't work if the user doesn't have 
win32-api installed onto cygwin/mingw.


-- 
Milan Mimica
http://sparklet.sf.net

Milan Mimica wrote:
> Andrei Ellman wrote:
>> The second version using makefile.helper does not work if using MSVC6, 
>> as msvchelp.c does not get called. Either use the version of the patch 
>> that I've attatched (a modified version of the first version of your 
>> patch), or update fix.bat so that msvchelp.c is called regardless of 
>> which MSVC version is being used (and update the docs to reflect this).
> 
> Yeah really, why not making --msvcpaths default for all MSVC targets? We 
> can relax DOS 8.3 format restrictions for paths since we have msvchelp. 
> There must be a catch I'm affraid

I agree. Using the msvchelp.c for all MSVC builds is a good idea, 
because then, it simplifies the install instructions - just let fix.bat 
do it's thing, and not worry about spaces in the MSVCDir. fix.bat would 
have to be modified to set the MSVCDir variable to MSVC6's MSVCDIR if 
VCINSTALLDIR is not found. We might also want to remove the 'msvc' 
target from from fix.sh while we're at it.


> Bah, I just applied this patch. IMO there is no much point unuglyfing 
> the 4.2 branch build system as long as it works.

Has the MSVC makefile for 4.3 forked off from the one for 4.2 yet? If 
not, we can easilly apply the fixes to both. makefile.vc in 4.2.1 is 
already broken if using the current version of Cygwin's make, so we 
might as well un-uglify the build-system while we're at it.


> And making --msvcpaths default wouldn't work if the user doesn't have 
> win32-api installed onto cygwin/mingw.

Ermm... don't we already need win32-api to be able to build the Allegro 
windows build?


And while I'm here, as well as fixing the 'cygpath' for MSVC, do we also 
need to do the same for the Borland C makefile and other Windows compilers?


AE.

Andrei Ellman wrote:
> 
> Has the MSVC makefile for 4.3 forked off from the one for 4.2 yet? If 
> not, we can easilly apply the fixes to both. makefile.vc in 4.2.1 is 
> already broken if using the current version of Cygwin's make, so we 
> might as well un-uglify the build-system while we're at it.

We use scons in 4.3. I don't know if makefiles are going to be dropped 
completely. If not then we should unuglify it.

> Ermm... don't we already need win32-api to be able to build the Allegro 
> windows build?

No. If you are using mingw to build allegro with MSVC, you don't need 
mingw win32-api package. msvchelp, runner and co. are built using gcc.

> 
> And while I'm here, as well as fixing the 'cygpath' for MSVC, do we also 
> need to do the same for the Borland C makefile and other Windows compilers?

I assume Borland C makefile is broken for ages because no one uses it.


-- 
Milan Mimica
http://sparklet.sf.net

Milan Mimica napsal(a):
> Yeah really, why not making --msvcpaths default for all MSVC targets?

because it won't work with DJGPP/Cygwin without w32api

> I assume Borland C makefile is broken for ages because no one uses it.

it should work fine using Mingw or DJGPP GNU tools

Andrei Ellman napsal(a):
>> And making --msvcpaths default wouldn't work if the user doesn't have 
>> win32-api installed onto cygwin/mingw.
> 
> Ermm... don't we already need win32-api to be able to build the Allegro 
> windows build?

note that we are speaking actually about MSVC build, just using Cygwin
GNU tools

-----------------------------------

To make msvcpaths default I see two solutions:

-- build msvchelp.c using MSVC - I have no idea why it isn't already
    done this way
-- use msvchelp rewritten in VBscript - much faster, not
    much tested, needs WSH (IIRC part of Windows since w2000,
    may require installation for w9x)
    available at: http://st.vse.cz/~xmolm04/msvchelp.vbs.zip


-- 
Regards,
      Michal

ICQ# 175762750

Michal Molhanec wrote:
> 
> To make msvcpaths default I see two solutions:
> 
> -- build msvchelp.c using MSVC - I have no idea why it isn't already
>     done this way

I like this one more.

> -- use msvchelp rewritten in VBscript - much faster, not
>     much tested, needs WSH (IIRC part of Windows since w2000,
>     may require installation for w9x)
>     available at: http://st.vse.cz/~xmolm04/msvchelp.vbs.zip

Speed is not an issue.
Some users may have WSH disabled for security reasons. I think even 
anti-virus apps might complain.
But I have nothing particular against this either, I just prefer the 
above idea.


-- 
Milan Mimica
http://sparklet.sf.net

Milan Mimica wrote:
> Andrei Ellman wrote:
>   
>> Has the MSVC makefile for 4.3 forked off from the one for 4.2 yet? If 
>> not, we can easilly apply the fixes to both. makefile.vc in 4.2.1 is 
>> already broken if using the current version of Cygwin's make, so we 
>> might as well un-uglify the build-system while we're at it.
>>     
>
> We use scons in 4.3. I don't know if makefiles are going to be dropped 
> completely. If not then we should unuglify it.
>   
just a nitpick, both scons and cmake will be supported for 4.3. Me and 
elias will support scons I guess Peter Wang and others will support 
cmake. I think all parties would like to drop makefiles and use at least 
cmake or scons.

Milan Mimica napsal(a):
> Michal Molhanec wrote:
>> To make msvcpaths default I see two solutions:
>>
>> -- build msvchelp.c using MSVC - I have no idea why it isn't already
>>     done this way
> 
> I like this one more.

yes, probably the least problematic

in that case, can you test the attached patch ?


-- 
Regards,
      Michal

ICQ# 175762750

Michal Molhanec wrote:
> 
> in that case, can you test the attached patch ?
> 

The patch works but doesn't do much in sense of makefile.vc simplification.

Mine patch (attached) upgrades your changes in fix.bat so that MSVCDir 
is always set in "makefile" file. This way makefile.vc can rely on 
MSVCDir being declared and no need to test for MSVCDIR and VCINSTALLDIR. 
It simplifies makefile.vc.

Docs still need to be updated.


-- 
Milan Mimica
http://sparklet.sf.net

Milan Mimica napsal(a):
> The patch works but doesn't do much in sense of makefile.vc simplification.

OK

> Mine patch (attached) upgrades your changes in fix.bat so that MSVCDir 
> is always set in "makefile" file. This way makefile.vc can rely on 
> MSVCDir being declared and no need to test for MSVCDIR and VCINSTALLDIR. 
> It simplifies makefile.vc.
> 
> Docs still need to be updated.

Attached. Somebody should rewrite it in English. And somebody with 
working Cygwin should check the part about fix.sh (for me Cygwin make 
always stops with
makefile.vc:308: *** target pattern contains no `%'.  Stop. )

-- 
Regards,
     Michal

ICQ# 175762750

Michal Molhanec wrote:
> 
> Attached. Somebody should rewrite it in English.

? Looks fine to me.

> And somebody with 
> working Cygwin should check the part about fix.sh (for me Cygwin make 
> always stops with
> makefile.vc:308: *** target pattern contains no `%'.  Stop. )

export ALLEGRO_USE_CYGWIN=1
That's what the thread was about originally :)
Oh, we should mention that in the build docs.


-- 
Milan Mimica
http://sparklet.sf.net

Milan Mimica napsal(a):
> Michal Molhanec wrote:
>> And somebody with 
>> working Cygwin should check the part about fix.sh (for me Cygwin make 
>> always stops with
>> makefile.vc:308: *** target pattern contains no `%'.  Stop. )
> 
> export ALLEGRO_USE_CYGWIN=1
> That's what the thread was about originally :)

:-) ok, now it works
I'm attaching small fix.bat patch fixing some problems
I'm also attaching patch to makefile.vc which fixes some problem for 
MSVC 8 + automatically detects Cygwin and sets ALLEGRO_USE_CYGWIN

Btw something produces message
Invalid switch - "msvc".
(already the unpatched 4.2.1 so it's not fault of my patch)

> Oh, we should mention that in the build docs.

other thing is that fix.sh no longer works. does it mean that cygwin 
users will have to use fix.bat?

Also Andrei Ellman wrote:
> We might also want to remove the 'msvc' 
> target from from fix.sh while we're at it.

-- 
Regards,
     Michal

ICQ# 175762750

On 2006-12-28, Andrei Ellman <ae-a-alleg@...> wrote:
> Hi,
> 
> I've noticed that whenever I switch out of an Allegro app using the 
> CTRL-ALT-DEL combination and then press the task-manager button, my 
> allegro app continues to run in the background (the app's cpu-usage is 
> 99% and when I switch back in, the app looks like it's been running 
> continuously).

Does the program get the WM_ACTIVATE message in this case? (line ~259 in
src/win/wwnd.c)

Peter

On Tuesday 26 December 2006 14:40, Milan Mimica wrote:
> Chris Robinson wrote:
> > I really need to figure out how hardware mixing works. Not so much
> > the 'playing multiple voices at once' part, but the re-channeling,
> > panning, resampling etc parts. Allegro's software mixers do it in a nice
> > (IMO) way, but I need to figure out how to do it through the various
> > backends capable of hardware mixing so the API can work with it.
>
> Maybe if you could add vtable entries (to AL_AUDIO_DRIVER?) for these
> functions I could try to do something. Maybe :)

I suppose I can add extra functions for it. The problem is mainly with the 
current ALSA driver, as that allocates a new output connection for every 
Allegro voice (so, if you allocate a mono voice, it gives mono output). In 
that way it differs from the OpenAL driver, which creates a new source on the 
output that was selected at driver initialization and does actual mixing for 
them. That allows you to take a mono voice and pan it around if you're 
outputting on 2+ channels (unlike the ALSA driver which only combines voice 
output and doesn't allow that because the mono voice is outputting on a mono 
channel). IMO, the OpenAL driver is the preferrable method, but doing that 
would remove ALSA's multiple hardware voice capabilities.

I'll also need to change some of the struct's non-voice functions to take a 
unique value so a single driver can be instantiated multiple times. Unless 
you don't think that particular ability is important?

Chris Robinson wrote:
> 
> I suppose I can add extra functions for it. The problem is mainly with the 
> current ALSA driver, as that allocates a new output connection for every 
> Allegro voice (so, if you allocate a mono voice, it gives mono output). In 
> that way it differs from the OpenAL driver, which creates a new source on the 
> output that was selected at driver initialization and does actual mixing for 
> them. That allows you to take a mono voice and pan it around if you're 
> outputting on 2+ channels (unlike the ALSA driver which only combines voice 
> output and doesn't allow that because the mono voice is outputting on a mono 
> channel). IMO, the OpenAL driver is the preferrable method, but doing that 
> would remove ALSA's multiple hardware voice capabilities.

OK, I see now that there is a lot of work to be done on alsa driver. It 
will probably get rewritten one more time. We need to use some of these 
functions to to make the voice settings independent on the driver output 
settings: http://www.alsa-project.org/alsa-doc/alsa-lib/pcm_plugins.html
and a config file has to be constructed at runtime with these:
http://www.alsa-project.org/alsa-doc/alsa-lib/group___config.html

And I don't like that spawning a new thread per voice thing.

> I'll also need to change some of the struct's non-voice functions to take a 
> unique value so a single driver can be instantiated multiple times. Unless 
> you don't think that particular ability is important?

Dunno. I don't see any use of that with all this mixer stuff.


-- 
Milan Mimica
http://sparklet.sf.net

On Wed, 2006-12-27 at 00:28 +0100, Grzegorz Adam Hankiewicz wrote:
> On 2006-05-27, Grzegorz Adam Hankiewicz <gradha@...>
> wrote:
> > The problem is packf_open, using uconvert_toascii() (at least
> > under unix). [...]
> >
> > PD2: I really hope I making a stupid mistake in the test case,
> > I don't want to fix this mess.
> 
> Well, I guess I'm a little bit late. The changes made so far to the Unix
> code are not really a solution (I get "libc encoding is unknown"). Even
> if that worked, what do we do about other platforms?
> 
> The problem is that the whole cross-platform solution is sort of a
> nightmare really. I was going to write an email, but it ended up being
> too big with examples, so I'm attaching it all.
> 
> Rather than start commiting changes like crazy we need to think of the
> correct solution before acting.  For the tar.bz2 impaired, it should be
> available for some time at:
> 
>   http://gradha.sdf-eu.org/unicode_bug.zip, 11964 bytes.
> 
> Lets start the snowball. Happy holidays.

Just out of interest, if you set your locale to UTF8, the tests will
work on your system, right?

-- 
Elias Pschernig

On 2006-12-27, Elias Pschernig <elias@...> wrote:
> Just out of interest, if you set your locale to UTF8, the tests will
> work on your system, right?

Sure. I can compile with U_UTF8, launch an xterm with -u8, create a few
files with latin1 characters and run the test, then it all works, since
Allegro is converting from utf8 utf8, this is, it is not converting
anything at all, and then we have exactly the situation of 4.0.x, where
setting U_ASCII would effectively make strings go straight from/to the
OS without conversion and my latin1 test would work.

With the changes to utf8 in 4.2.x the situation is more likely to go
unnoticed, since possibly most new linux installations use utf8, but it
is just still wrong.

On Wed, 2006-12-27 at 00:39 +0100, Grzegorz Adam Hankiewicz wrote:
> On 2006-09-19, Ryan Patterson <cgamesplay@...> wrote:
> > Attached is my allegro.log. Apparently Allegro doesn't like multimedia keys.
> 
> Extract from allegro.log:
> 
> 	al-xkey ERROR: You have more keys reported by X than Allegro's maximum of 127 keys. Please send a bug report.
> 	al-xkey INFO: Key 233 missing: XF86Go NULL NULL NULL NULL NULL - assigned to 0.
> 
> Do we just expand the array?

Not so easy, because e.g. keyboard_lowlevel_callback expects only 7-bit
codes. We could make a keyboard_lowlevel_callback_ex though. Then
increase KEY_MAX (making sure to not touch any KEY_* constants). That
way I believe it even would stay binary compatible.

I'm inclined to just keep the 127 keys limitation though for 4.2, should
not be such a big issue. (Maybe reword the log message.)

In 4.3, there's a similar issue with AL_KBDSTATE.. but in fact, I will
propose a different keyboard state API for 4.3 (which allows checking
how many times a key has been pressed since the last call - much more
useful for a game than an on/off state which is highly dependent on
timing issues). But not important right now.

-- 
Elias Pschernig