|
Alllegro 4.2.0 beta 2 has been released! |
Evert
Member #794
November 2000
|
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 CHANGES said:
================================================================================ 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 Peter Hull made makedoc retuen in error code if it failed to build the Peter Wang fixed a problem with compilers that don't have inttypes.h, as Evert Glebbeek fixed a problem with incorrect dependencies being generated Tobi Vollebregt fixed a problem in X11 if the XRGBACursor extension was Evert Glebbeek made configure use k8 rather than athlon64 as a compiler 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 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 Daniel Schlyder fixed a problem with the -mtune switch on older gcc based Matthew Leverton figured out which versions of Watcom have inttypes.h and V Karthik Kumar added a password to the Windows screensaver example. Cosmetic fixes, example bugfixes and spelling corerctions by Jon Rafkind, 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
|
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. [My site] [Tetrominoes] |
ReyBrujo
Moderator
January 2001
|
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. -- |
Carrus85
Member #2,633
August 2002
|
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
|
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 -- |
Thomas Harte
Member #33
April 2000
|
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! [My site] [Tetrominoes] |
Matthew Leverton
Supreme Loser
January 1999
|
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
|
CHANGES said: spelling corerctions
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
|
Isn't there some utility you can make to go through and modify the timestamp on the files so make doesn't get confused Usually IIRC gcc would throw a clock skew detected. I'm thinking a small utility could be whipped up rather quickly. ___________________________________ |
Evert
Member #794
November 2000
|
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. 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
|
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? 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
|
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.. -- |
ReyBrujo
Moderator
January 2001
|
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. -- |
Evert
Member #794
November 2000
|
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
|
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? -- |
Daniel Schlyder
Member #257
April 2000
|
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 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. |
ReyBrujo
Moderator
January 2001
|
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
-- |
Daniel Schlyder
Member #257
April 2000
|
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
|
I was trying to build only the optimized library fix mingw32 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) [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
|
|
|