|
Allegro 4.1.14 |
Matthew Leverton
Supreme Loser
January 1999
|
From Eric Botcazou on AD: Allegro 4.1.14 is available at: [url http://sourceforge.net/projects/alleg] This release is a Work-In-Progress release that adds features and corrects problems with regard to the 4.0 codebase. It is API (source) compatible with 4.0.0 on every platform, except for a few minor changes (see docs/html/api.html). ==================================================================== ============ Changes from 4.1.13 to 4.1.14 (April 2004) ============ ==================================================================== Elias Pschernig added a missing install dependency on Linux. Elias Pschernig fixed a couple of problems in dat2c. Angelo Mottola polished the MacOS X package builder script. Elias Pschernig added a Jack sound driver to the Unix port. Henrik Stokseth added support for debugging with DMalloc under Unix. Eric Botcazou fixed detection of the ALSA 1.0 MIDI driver. Eric Botcazou fixed compilation with --enable-color8=no under Unix. Angelo Mottola made it possible to link against the Allegro framework with the allegro-config script under MacOS X. Angelo Mottola changed the dynamic lib install name to major.minor to preserve binary compatibility under MacOS X. Angelo Mottola fixed a bug in fixbundle with 32bpp icons and alpha channel under MacOS X. Eric Botcazou improved the cross-compilation support on Linux. Eric Botcazou restored the compensation code for end-of-frame in the FLI player. Daniel Schlyder fixed potentially unsafe constructs in the Windows code. |
CGamesPlay
Member #2,559
July 2002
|
Jees... Did that merit another release? What "unsafe constructs"? -- Ryan Patterson - <http://cgamesplay.com/> |
Kitty Cat
Member #2,815
October 2002
|
Quote: Jees... Did that merit another release? Not IMO. I don't even know why it was since there's still a few things waiting to be done. There's new mixer code waiting to be put in, as well as an Allegro-DX mixer patch that improves conformance, as well as a patch for DIGMID to reduce CPU usage. And too, there was an identified joystick "bug" that nobody's commented on (on AD), as well as talk on how to better handle mouse input in Windows. Some of us were hoping 4.1.14 would've been the last WIP before 4.2, but I doubt it will be if the aforementioned things are still going to be worked on. -- |
Evert
Member #794
November 2000
|
Improved MacOS X support justifies the new release, IMO. As was discussed on the mailinglist, there's no problem in putting out WIPs a little more often than has been the case of late. That said, Allegro 4.2 should be released relatively soon. The stable 4.0 branch does not offer native MacOS X support, which in itself would justify 4.2. As there are other issues to fix (eg, thread safety) too, it may take a little longer. |
X-G
Member #856
December 2000
|
In the spirit of improving things often and quickly, I don't see why this release is a bad idea ... if something useful has been added, publish it, even if it's not much. It's not like we can run out of version numbers or anything. -- |
Richard Phipps
Member #1,632
November 2001
|
We should be grateful that people are still working on improving Allegro. And in their free time too.. Good job everyone who worked on this release! |
Stuart Moore
Member #1,809
January 2002
|
Indeed. It's good for people to be working on this. But I have a problem with the latest version... SUSE 9.0Pro (which means ALSA 0.9.x). GCC 3.3.1 (default compiler with the distro). Configured, compiled, installed. BUT... none of the Allegro programs work. They all shut down with Signal #6. Any ideas? -- |
Chris Katko
Member #1,881
January 2002
|
I don't mind it... But this isn't really much a minor release if you compare the stuff done on this to the stuff done between 4.1.12 and 4.1.13 or some other version. As Kitty Cat said, I don't see why they didn't wait a bit longer and throw some more stuff in. If you need a distro released every month, get the CVS snapshot. -----sig: |
Elias
Member #358
May 2000
|
As Evert said, this release is mostly for the MacOS X port. Quote: SUSE 9.0Pro (which means ALSA 0.9.x). GCC 3.3.1 (default compiler with the distro). Configured, compiled, installed. BUT... none of the Allegro programs work. They all shut down with Signal #6. Any ideas? Can you try if 4.1.13 works? -- |
Stuart Moore
Member #1,809
January 2002
|
Allegro 4.1.13 had the same results as 4.1.14 - i.e., it crashed out with a signal #6. -- |
Elias
Member #358
May 2000
|
Does it say anything else? And what is the ouput of "make info"? Also, could you try a debug build, for example like this: cd allegro ./configure --enable-dbgprog make make install Then run some example in gdb, e.g.: gdb examples/ex12bit Then when it aborts again, enter "bt", and post the output here. -- |
Stuart Moore
Member #1,809
January 2002
|
Ah, how about this... grabber: rawmidi.c:306: snd_rawmidi_open: Assertion `(inputp || outputp) && name' failed. ...any use? -- |
Evert
Member #794
November 2000
|
Interesting. Most of my programs use such a config file, which is why I didn't notice the problem earlier. Also using SuSE 9.0, with updates and patches from a week or two ago. |
Elias
Member #358
May 2000
|
Hm, I don't have Alsa midi here, so that could explain why I don't get this. Can you try reconfiguring with: ./configure --disable-alsamidi make make install And see if it fixes it? And then someone will have to look up that function in the Alsa docs.. I say Tomasu since he wrote the driver -- |
Stuart Moore
Member #1,809
January 2002
|
Disabling ALSA MIDI seems to make it work again, Elias. Grabber starts without any problem. It also plays MIDI files (thanks to OSS). -- |
Elias
Member #358
May 2000
|
Ok, thanks for reporting this and testing - I guess it can be fixed now. It seems like the ALSA function you quoted doesn't like the parameters it gets by Allegro - and therefore aborts the program. -- |
Evert
Member #794
November 2000
|
Allegro's defaults must be screwed up. I'll try a rebuild later on and see what Allegro uses as default values and what is actually written to the config file (which, as I said, does work). |
Elias
Member #358
May 2000
|
Finally had a look at the ALSA docs, and the problem seems to be the name parameter - it must not be 0. The attached patch should fix it, can't test it myself though right now. I'm also sending it to [AD]. -- |
|