Allegro.cc - Online Community

Allegro.cc Forums » Allegro Development » Alllegro 4.2.0 beta 2 has been released!

This thread is locked; no one can reply to it. rss feed Print
Alllegro 4.2.0 beta 2 has been released!
Evert
Member #794
November 2000
avatar

Allegro 4.2.0 beta 2 is ready and has been released. This is a beta release for Allegro 4.2.0 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).
Get it from the download page on sourceforge.

CHANGES said:

================================================================================
============ Changes from 4.2.0 beta 1 to 4.2.0 beta 2 (April 2005) ============
================================================================================

Daniel Schlyder fixed a problem with the makefile in Windows.

Evert Glebbeek fixed a bug that prevented true colour fonts from working.

Elias Pschernig fixed a bug where the DJGPP version would choke on a missing
variable.

Peter Hull made makedoc retuen in error code if it failed to build the
SciTE documentation.

Peter Wang fixed a problem with compilers that don't have inttypes.h, as
reported by Matthew Leverton.

Evert Glebbeek fixed a problem with incorrect dependencies being generated
for MacOS X.

Tobi Vollebregt fixed a problem in X11 if the XRGBACursor extension was
missing.

Evert Glebbeek made configure use k8 rather than athlon64 as a compiler
switch on AMD64.

Peter Wang and Elias Pschernig added a packfile example.

Michal Molhanec fixed a problem in the MSVC makefile.

Evert Glebbeek removed void pointerarithmetic from the colour converter.

Evert Glebbeek fixed a bug where hardware cursors would stop working.

Elias Pschernig, Andrew Chew fixed and Tobi Vollebregt fixed several problems
with the Windows keyboard driver.

Elias Pschernig fixed bug in unix dependency generation.

Elias Pschernig made the GUI not mess up the hardware cursor.

Elias Pschernig removed pckeys.c and keyconf from the windows port, since
the dinput driver no longer needs pckeys.c nor uses keyboard.dat.

Daniel Schlyder fixed a problem with the -mtune switch on older gcc based
compilers.

Matthew Leverton figured out which versions of Watcom have inttypes.h and
stdint.h.

V Karthik Kumar added a password to the Windows screensaver example.

Cosmetic fixes, example bugfixes and spelling corerctions by Jon Rafkind,
Evert Glebbeek, Peter Wang, StApostol and Elias Pschernig.

This release fixes problems in the previous beta, which was announced in this thread. Please download and test the new release, especially if you had problems with that last beta, and let us know if there are problems. Do not hesitate to report problems even if they have been reported before! Please provide an example programme that demonstrates the problem and if possible help to locate and fix the problem. You can reposrt bugs on the forums, but browsing through a long thread for this is combersome so it would be better to post the problem on the mailing list or the tracker.

I would also like to remind you all again of the Allegro demo competition which is still open and encourage everyone to contribute a better demo game! I'll open up a second thread to make sure I reach everyone.

Thomas Harte
Member #33
April 2000
avatar

I'm busy doing a test Mac OS X build as we speak, having been unable to build 4.2.0 beta 1.

I have no idea if this is a 'new' thing, but does fix.sh really have to convert the line endings of the Windows, BeOS, etc code? I appreciate it is probably on a simple automated 'find and convert' mission but could this not be fixed by someone somewhere? I don't know any shell scripting but I'm going to have a peek inside fix.sh and see if I can't come up with a solution myself...

I also apologise for raising such a trivial issue. No doubt everything else will compile fine.

EDIT: someone really should clear up the ambiguity in docs/build/macosx.txt about whether "sudo make install-framework EMBED=1" and "sudo make install-framework" are alternatives or may complement each other. I've read it as alternatives but it really isn't very clear.

ReyBrujo
Moderator
January 2001
avatar

Hmm... I see datafiles._tx still has over 9 characters. I am guessing it won't build for Watcom DOS. Let's see how it behaves in the other ports.

--
RB
光子「あたしただ…奪う側に回ろうと思っただけよ」
Mitsuko's last words, Battle Royale

Carrus85
Member #2,633
August 2002
avatar

Quick question: Would anyone happen to have an explaination why running the setup program and clicking "test" would case the setup program to minimize (MS Windows)?

For some strange reason, I seem unable to get allegro to properly output MIDI data. The setup program, no matter what MIDI driver I set it to, refuses to output any form of MIDI. After I get home from school I'm going to try running some tests to see if I can pinpoint what exactly is going on. Just thought I should ask here before I get too far into troubleshooting something that may or may not be a well documented issue in some piece of documentation that I have no access to.

The potential hardware culprit is an integrated soundcard on a HP Laptop, the appropriate linux driver for the sound card is the intel_8x0 driver set (IIRC). Lets see, what else... Ah, the windows hardware resources panel identifies it as a "Soundmax Integrated Audio Device." It also happens to be integrated on a nForce 3 motherboard.

I'm going to see if I can reproduce the problem later. Any comments?

EDIT: This is a confirmed problem on my end with Beta 1 at least. It will several hours before I will have time to troubleshoot this further... No earlier than 3:00 PM Mountain Daylight Time.

EDIT2: I will setup and run the same procedure to see if it is reproducable in Beta 2. Maybe one of the bugfixes above caught the problem. I'll also see if the problem exists in any of the previous versions, like the stable 4.03 branch. Sorry that I can't be of assistance any earlier, I'm busy finishing up some final papers for my classes... >:(

ReyBrujo
Moderator
January 2001
avatar

Hmm... ok, this is... wierd. I am leaving for work, but with MinGW (GCC 3.2.3), I did make all, and make compiled the optimized, then the debug, then the profile, then the optimized again (!). Then I did make installall, and compiled the optimized again(!!).

Something is broken somewhere I am guessing. Will see if it happens at work as well with 3.2.

(Edited: Installed the optimized, and now compiling the debugging version again (!!!)).

(Edited 2: Installed the debugging, and compiling the profiling version again (!!!!)).

(Edited 3: Hmm... make 3.79 told me the makefile.dep had changed time in the future. 3.80 didn't say a thing. I will compile again later to see if that happens again. I am guessing 3.80 didn't use the dep because of that. That is what happens when you download the packet as soon as it was released in a eastern country ;)

--
RB
光子「あたしただ…奪う側に回ろうと思っただけよ」
Mitsuko's last words, Battle Royale

Thomas Harte
Member #33
April 2000
avatar

Just one major OS X problem to report!

Having successfully completed make, sudo make install and sudo make install-framework EMBED=1, I get an error at sudo make install-template. Specifically:

Toms-Computer:/Programming Libraries/allegro-4.2.0 thomasharte$ sudo make install-template
install: d: No such file or directory
make: *** [/Library/Application Support/Apple/Developer Tools/Project Templates/Application/Allegro Application] Error 71

So close!

Matthew Leverton
Supreme Loser
January 1999
avatar

Quote:

That is what happens when you download the packet as soon as it was released in a eastern country

On the first beta, I was getting odd problems (due to timezones) where a "make install" was recompiling everything after a "make".

Perhaps when Allegro 4.2 is released, it should be announced publically the day after it is posted? This will prevent some initial panic of "it doesn't work!"...

Rampage
Member #3,035
December 2002
avatar

CHANGES said:

spelling corerctions

;D

Quote:

Perhaps when Allegro 4.2 is released, it should be announced publically the day after it is posted? This will prevent some initial panic of "it doesn't work!"...

And how would the developers know that something doesn't work?

-R

Steve Terry
Member #1,989
March 2002
avatar

Isn't there some utility you can make to go through and modify the timestamp on the files so make doesn't get confused :P Usually IIRC gcc would throw a clock skew detected. I'm thinking a small utility could be whipped up rather quickly.

___________________________________
[ Facebook ]
Microsoft is not the Borg collective. The Borg collective has got proper networking. - planetspace.de
Bill Gates is in fact Shawn Hargreaves' ßî+çh. - Gideon Weems

Evert
Member #794
November 2000
avatar

Actually, I think it's supposed to be so that the timestamp and timezone are stored in the archive and updated when it is unpacked.
Maybe that requires additional setup on the user's system though...

EDIT:

Quote:

Perhaps when Allegro 4.2 is released, it should be announced publically the day after it is posted?

Makes sense. I think it would be pre-released internally for developers first anyway.

Quote:

Having successfully completed make, sudo make install and sudo make install-framework EMBED=1, I get an error at sudo make install-template.

Hmm... no idea. Can you try running `make depend' before make? The problems with the first beta were solved by doing that. Just a random guess though.

Quote:

I see datafiles._tx still has over 9 characters. I am guessing it won't build for Watcom DOS.

Ouch... missed that one. Should be easy to fix though.

EDIT2: As a general warning, and probably something I should have pointed out before although it is somewhat obvious: do not yet distribute Windows programmes the depend on alleg42.dll. There can be some mild breakage due to changes and fixes between beta 1 and beta 2 and eventual release.

Matthew Leverton
Supreme Loser
January 1999
avatar

Quote:

And how would the developers know that something doesn't work?

I'm only referring to problems that timezones cause. I know that when unzipping a recent Allegro build (I'm six hours off UTC) under Windows that strange things happen. Once the time of my system > the time of the release, everything is fine. It just gives a bad first impression to someone who doesn't understand what's going on.

Peter Hull
Member #1,136
March 2001

changes.txt said:

makedoc retuen in error code

Double-dutch? :P ;)

As I understand it, the normal framework and the embedded framework are alternatives.

Pete

Avenger
Member #4,550
April 2004

Why are there timezone troubles in the first place???

Mika Halttunen
Member #760
November 2000
avatar

The expackf.c reads " Allegr" instead of "Allegro" during one of the tests. Nothing major, I know but still :)

---------------------------------------------
.:MHGames | @mhgames_ :.

Peter Wang
Member #23
April 2000

Oh that's a bug then. Guess nobody tested expackf.c with DOS line endings so far :)

Elias
Member #358
May 2000

Argh. I guess we could just place something in the first line for the seek test.. or do something like in your original..

--
"Either help out or stop whining" - Evert

ReyBrujo
Moderator
January 2001
avatar

Avenger said:

Why are there timezone troubles in the first place

Someone creates the package and uploads it from Japan (example), where it is currently 6:00 PM (example) o'clock, and makes an announcement. I get the notification, and download it half an hour later at 6:30 PM. However, my local time is 6:30 AM. When I uncompress the packet, the date and time for each file will be touched at 6:00 PM, that is, a future date.

Some versions of make will warn that the files have a future modification date and stop the process for you to check. Others seem just to work with them, but will rebuild the files everytime because the original files will always look as if they were modified (make checks if the source is newer than the object files, since the sources were made at 18:00 and I am at 6:30, the program will think I modified the files again at 18:00 and thus the object files need to be rebuilt).

Hope that helps understanding.

--
RB
光子「あたしただ…奪う側に回ろうと思っただけよ」
Mitsuko's last words, Battle Royale

Evert
Member #794
November 2000
avatar

Actually, the timestamp on the files in the source archive seems to be their last modification time... so I'm not sure what's going on. At any rate, unzip could (potentially) check the timezone and adjust for that. I could be wrong, but I think tar does.

ReyBrujo
Moderator
January 2001
avatar

It is possible, this was one of the first times I downloaded the zip instead of the tar file. Maybe when generating the zip package the developer should move his clock backwards a day and touch all the files?

--
RB
光子「あたしただ…奪う側に回ろうと思っただけよ」
Mitsuko's last words, Battle Royale

Daniel Schlyder
Member #257
April 2000
avatar

I don't think you have to move the clock back a day, doesn't touch accept a timestamp argument?

EDIT Yup, sure does:

-d, --date=STRING parse STRING and use it instead of current time

Fiddler
Member #5,385
January 2005

On building the optimized dll with mingw32 (gcc 3.4.2) I get three warnings:

Warning: .drectve `%.*s' unrecognized
Warning: .drectve `%.*s' unrecognized
Warning: .drectve `%.*s' unrecognized

These appear just after running the dllwarp for liballeg.a . The build is nonetheless completed correctly and the resulting library is working. I dont know if these appear on the other configurations.

Also, some preliminary testing shows that the new beta ate ~70 fps from my game (300->230 fps), on both the optimised and debuging libs for both msvc7.1 and mingw32. I'll have to test some more though to see what causes this.

The Open Toolkit: a game development library for .Net/Mono.
http://www.opentk.com

ReyBrujo
Moderator
January 2001
avatar

Compiled fine with the free Microsoft Visual Studio 2003 Toolkit, full DirectX 9 SDK from April 2005, and the Platform SDK for Windows XP SP2.

Two problems, though. One is that MSVCRT.lib isn't available (though I just copied it from the .NET Framework SDK v1.1, but there are ways of getting it without having to download the full framework). The other is that the setup I had lacks lib.exe. I tried the solution given here (creating a lib batch file that calls <i>link lib), but didn't work. However, changing in the MSVC makefile from lib to <i>link lib worked.

I tried the makefile.vc modification with MSVC6, and it worked for both dynamically and statically linked. I suggest patching the makefile to prevent problems if someone else uses the free tools:

--- makefile.vc	Sun Apr 10 14:17:14 2005 UTC
+++ makefile.vc	Thu Apr 21 20:14:40 2005 UTC
@@ -134,7 +134,7 @@
    MSVC_CL = $(MSVCDIR_U)/bin/cl
 endif
 MSVC_LINK = $(MSVCDIR_U)/bin/link
-MSVC_LIB = $(MSVCDIR_U)/bin/lib
+MSVC_LIB = $(MSVCDIR_U)/bin/link /lib
 MSVC_RC = rc
 

--
RB
光子「あたしただ…奪う側に回ろうと思っただけよ」
Mitsuko's last words, Battle Royale

Daniel Schlyder
Member #257
April 2000
avatar

Quote:

On building the optimized dll with mingw32 (gcc 3.4.2) I get three warnings:

I don't get these using TARGET_ARCH_EXCL=i586. Probably because I'm using the binutils candidate package released in January.

Marco Radaelli
Member #3,028
December 2002
avatar

I was trying to build only the optimized library

fix mingw32
mingw32-make uninstall
mingw32-make clean
mingw32-make

It waits too much (I think) on this line:

gcc -O -Wall -Wno-unused  -I. -I./include -o obj/mingw32/asmdef.exe src/i386/asm
def.c
obj/mingw32/asmdef.exe obj/mingw32/asmdef.inc

(and there's no CPU utilization)

gcc (GCC) 3.4.2 (mingw-special)
GNU Make 3.80
Windows XP SP1
Amd Athlon-64 3200+

[edit]

ReyBrujo said:

The other is that the setup I had lacks lib.exe.

It should be under Platform_SDK_Dir\Bin\Win64. Anyway I'd like if it could be replaced by your suggested makefile modification

[edit2]

While waiting for the make process on the latest version, I completely recompiled the 4.1.18 version :-/

[edit3] A useless comment, but why does it die so horribly if I do mingw32-make uninstall twice? If I do mingw32-make clean twice it simply says "Nothing to be done for 'clean'"

[edit4] I can't explain it, but today it worked perfectly. I redone the whole compilation process and it finished correctly both times :)

Gideon Weems
Member #3,925
October 2003

beta_testers++;

Installation was a breeze on WinXP using MinGW, DEBUGMODE=1.



Go to: