Allegro.cc - Online Community

Allegro.cc Forums » Allegro Development » Allegro 4.1.17 WIP

This thread is locked; no one can reply to it. rss feed Print
 1   2 
Allegro 4.1.17 WIP
Evert
Member #794
November 2000
avatar

Allegro 4.1.17 WIP has been released. Get it from the Allegro SoureForge
page at [url http://sourceforge.net/projects/alleg/]. Also see http://alleg.sourceforge.net/.

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 said:

=======================================================================
============ Changes from 4.1.16 to 4.1.17 (December 2004) ============
=======================================================================

Sven Sandberg fixed a few problems with the sprite rotation code.

Sven Sandberg optimized blitting between different colour depths.

Evert Glebbeek added support for the use of native window manager cursors.

Chris Robinson made install_allegro() check if the library version matches
the version of the headerfiles installed.

Peter Wang fixed some problems with rest() on UNIX systems.

Evert Glebbeek added an is_windowed_mode() function.

Elias Pschernig added the scancode_to_name function.

Elias Pschernig made rest use usleep() on MacOSX.

Chris Robinson fixed the incorrect use of -export-dynamic on UNIX

Elias Pschernig, Chris Robinson and Peter Wang fixed XOR mode leaving
droppings in X11.

Elias Pschernig fixed several dependency issues.

James Lohr fixed a problem with mouse acceleration in fullscreen modes under
Windows.

Peter Wang fixed a problem in the TGA loader.

Lennart Steinke contributed keyboard layout detection code for Windows.

Peter Wang fixed a bug that caused Allegro to crash if it failed to
initialize.

Peter Wang fixed a deadlock related to X vsync emulation.

Daniel Schlyder fixed make uninstall with mingw make.

Elias Pschernig fixed QNX issue of not including utimer.c

Angelo Mottola fixed compilation problems on BeOS and fixed the detection
of VRAM.

Evert Glebbeek fixed compilation problems on *BSD.

Elias Pschernig made the X11 window hidden in GFX_TEXT mode.

Peter Wang removed remapping of numpad keys when NumLock was off in Linux

David A. Capello made override_config_file also be used for writing to the
config file.

Julien Cugniere added an X11 message box for allegro_message under X11.

Vitaliy Chetverikov a small bug in the GUI where the return value of
MSG_IDLE was ignored.

Peter Wang made several improvements to the examples.

Grzegorz Adam Hankiewicz made a lot of improvements to the documentation.

Elias Pschernig made make-install not build examples.

Peter Wang fixed several instances of symbols not declared static that should
have been.

Elias Pschernig replaced the X11 keyboard driver with a new XIM driver.

Peter Wang fixed a problem with Linux headers and Allegro headers both
declaring KEY_ constants, as pointed out by David A. Capello.

Elias Pschernig fixed X11 async reply in DGA2 mode detection due to missing
XLOCK/XUNLOCK

Peter Wang fixed problems in ex3buf, which was trying to lock symbols which
had been removed.

Elias Pschernig cleaned up grabber/dat documentation.

Daniel Schlyder added ALLEGRO_LIB_BUILD flag for gcc variants not using
configure.

Elias Pschernig fixed bugs in matrix_to_quat and get_align_matrix.

Evert Glebbeek fixed a problem with the X11 port when
ALLEGRO_MULTITHREADED was not defined.

Matthew Leverton added support for a fourth mouse button to the Windows port.

Michal Molhanec added a faq section about the giftware license.

Elias Pschernig added the license disclaimer to the docs.

Evert Glebbeek added missing vtable entries for AllegroGL, as requested by
Robert Ohannessian.

Dustin Dettmer spotted a typo in save_bitmap.

Sam Hocevar removed deprecated use of init_read_test, test_byte_read, etc.

Peter Wang fixed a bug in the Windows keyboard driver.

This WIP should be reasonably close to what 4.2.0 is going to look like. There are a few things still left to do, but by all means, do test it and report how it works or doesn't work for you!

Richard Phipps
Member #1,632
November 2001
avatar

gnolam
Member #2,030
March 2002
avatar

CHANGES said:

Lennart Steinke contributed keyboard layout detection code for Windows.

Allegro Manual: Keyboard routines said:

On some platforms (like DOS and Windows), Allegro requires the user to specify the language of the keyboard mapping because it is impossible to obtain this information from the OS, otherwise the default US keyboard mapping will be used.

Feels like that passage should be changed then :)

[EDIT]
It seems like scancode_to_name() is broken, unless I'm using it wrong :P
With regular readkey() and scancode_to_name() the only name I get is "(null)", and with ureadkey() (the docs don't say which of them apply) I get completely nonsensical mappings.

--
Move to the Democratic People's Republic of Vivendi Universal (formerly known as Sweden) - officially democracy- and privacy-free since 2008-06-18!

Evert
Member #794
November 2000
avatar

Quote:

Feels like that passage should be changed then :)

Indeed. Thanks for spotting that. :)

Quote:

It seems like scancode_to_name() is broken, unless I'm using it wrong :P
With regular readkey() and scancode_to_name() the only name I get is "(null)"

Hmm... just to make sure, you did use scancode_to_name(readkey()>>8)? That's how I think it should work. Best to ask Elias to make sure...
It's also possible that the function doesn't yet work in Windows... but I'm not sure about that.

Elias
Member #358
May 2000

It should work. And yes, it works with the scancode, so readkey() >> 8. Actually, just run exkeys, the names it displays to the right come from scancode_to_name. If they all says (null), than that needs to be fixed.

[Edit:]
To make this clear, the reason why I think scancode_to_name was needed is, if you have some game, and want keyboard controls to be user configurable. So, what you would do is, let the user select a control, and ask to press the desired key. You can now either use readkey/ureadkey, but then you can't use keys like Left-control or Right-control. Or, you can use key[], but then you don't know what name to display for a key. The KEY_* constants are not accurate, e.g. KEY_TILDE doesn't exist on many keyboard layouts. This is exactly what scancode_to_name is for. It tries to name a key, e.g. scancode_to_name(KEY_F1) will return "F1", and scancode_to_name(KEY_TILDE) should return whatever the OS thinks is the name of the corresponding key.

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

gnolam
Member #2,030
March 2002
avatar

My bad. I forgot that readkey doesn't return the scancode but instead a value containing both the scancode and the ASCII value :)

Oh well, I blame it on being in a hurry when testing it...

--
Move to the Democratic People's Republic of Vivendi Universal (formerly known as Sweden) - officially democracy- and privacy-free since 2008-06-18!

deps
Member #3,858
September 2003
avatar

It refuses to compile for me. :(

...other stuff here, but no errors or warnings.

gcc -DALLEGRO_SRC -DALLEGRO_LIB_BUILD -Wall -Wno-unused -mcpu=pentium -O2 -funro
ll-loops -ffast-math  -fomit-frame-pointer -I. -I./include -o obj/mingw32/alleg/
wkeybd.o -c src/win/wkeybd.c
src/win/wkeybd.c: In function `key_dinput_handle_scancode':
src/win/wkeybd.c:174: `DIK_PAUSE' undeclared (first use in this function)
src/win/wkeybd.c:174: (Each undeclared identifier is reported only once
src/win/wkeybd.c:174: for each function it appears in.)
make: *** [obj/mingw32/alleg/wkeybd.o] Error 1

gcc -v says it is gcc version 3.2.3 (mingw special 20030504-1)
make -v is GNU Make 3.80

---
Layers are good, all good things have layers, like onions. Good things also stink. - Trezker
I now have a page and a blog!

ReyBrujo
Moderator
January 2001
avatar

Compiles for me without problem, so no idea. You have MINGDIR set, and run fix mingw32 before building, right? Just guessing, it works here.

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

deps
Member #3,858
September 2003
avatar

Yes, mingdir is set, and I did run fix mingw32. Haven't had problems compiling allegro for a long time. I also completley removed the old directory, 4.1.16, before I unzipped the new one.

edit: all the other files are compiled without problems, it's just this one that complains.

Edit again:
And when i try to compile it, I do as i always do:

fix mingw32
make
(and here i would run make install, if it wasn't for the error)

---
Layers are good, all good things have layers, like onions. Good things also stink. - Trezker
I now have a page and a blog!

ReyBrujo
Moderator
January 2001
avatar

The definition is in dinput.h. Do you have the DX headers (I guess so, check that file to see if you find that definition there)?

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

deps
Member #3,858
September 2003
avatar

No, it wasn't in d:\mingw\include\dinput.h
So i guess i should redownload the dx headers from alleg.sf.net then? I will try that.

edit: looks like i used the dx80 headers before. Will try dx70 now

---
Layers are good, all good things have layers, like onions. Good things also stink. - Trezker
I now have a page and a blog!

ReyBrujo
Moderator
January 2001
avatar

Try downloading the headers for DX 8. I think there is a link at a.cc to those minimun headers as well.

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

deps
Member #3,858
September 2003
avatar

No, i had dx8 before. I am using dx 7 now and it compiles. Thanks for the help. :)

---
Layers are good, all good things have layers, like onions. Good things also stink. - Trezker
I now have a page and a blog!

Fabiano Lopes
Member #3,024
December 2002
avatar

Any reason for avoiding a proper makefile.mgw update?

Compiling Allegro for MinGW32, optimised. Please wait...
gcc -DALLEGRO_SRC -DALLEGRO_LIB_BUILD -Wall -Wno-unused -mcpu=pentium -O2 -funro
ll-loops -ffast-math  -fomit-frame-pointer -I. -I./include -o obj/mingw32/alleg/
allegro.o -c src/allegro.c
`-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.

Chris Katko
Member #1,881
January 2002
avatar

I must say, this is quite lovely. :) Allegro has been spending almost all of its time on bug fixes making it pretty stable.

-----sig:
“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs
"Political Correctness is fascism disguised as manners" --George Carlin

ReyBrujo
Moderator
January 2001
avatar

Fabiano, which compiler you are using? I would guess GCC 3.4 or something like that. I used 3.2 and compiled without warnings.

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

Gideon Weems
Member #3,925
October 2003

Rock. Is it just me, or are there a lot of good fixes/additions with this one?

Fabiano Lopes
Member #3,024
December 2002
avatar

gcc (GCC) 3.4.2 (mingw-special)
Copyright (C) 2004 Free Software Foundation, Inc.

Also, it seems the "-mtune=i686" issue is gone. ;)
I loved that mouse-fix too! (windows version)

EDIT: nope, unfortunately. It still crashes in windowed mode (not on fullscreen though).

Evert
Member #794
November 2000
avatar

Quote:

Any reason for avoiding a proper makefile.mgw update?

Yes, no one uses Windows so these things tend to go (mostly) unnoticed... ok, I remember that you did point it out.
At the moment, I think changing the flag is not worth it, as it would break older versions of the compiler. For the future, it's something that we should look into though.

Quote:

Is it just me, or are there a lot of good fixes/additions with this one?

There are quite a few, yes. Part of the reason is that we really want to get Allegro ready for 4.2 so that work can focus on rebuilding the API.

Jeff Houck
Member #5,287
December 2004
avatar

If anyone is interested, here are the library versions I'm using to compile 4.1.17 under msys and mingw without any problems:

MSYS-1.0.10
MinGW-3.1.0-1
msysDTK-1.0.1
msys-libtool-1.5
w32api-3.1
binutils-2.15.91
mingw-runtime-3.5
mingw-utils-0.3

after those are installed I updated the compiler:
gcc-core-3.4.2-20040916
gcc-g++-3.4.2-20040916

DO NOT UPDATE THE AUTOCONF (2.5.9) AND AUTOMAKE (1.8.2) PACKAGES FOR MINGW. THEY ARE BROKEN!>:( I had a lot of problems on another project until I found out from some other users these updated libs are really broken. Even though Allegro doesn't use them, it's better not to install them anyway.

I use Dev-C++ 4.9.9.1 without the integrated mingw option and the DX8_mgw headers from the Allegro site.

Thomas Fjellstrom
Member #476
June 2000
avatar

Quote:

Rock. Is it just me, or are there a lot of good fixes/additions with this one?

Its not just you ;) wait for 4.3.* muahaha. Though there (IIRC) WILL be api breakages in 4.3.*.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Kitty Cat
Member #2,815
October 2002
avatar

Quote:

Though there (IIRC) WILL be api breakages in 4.3.*.

I think 4.2->4.4 will be light enough that there won't. But I can't say for 100% certain.

--
"Do not meddle in the affairs of cats, for they are subtle and will pee on your computer." -- Bruce Graham

Jeremy McCleese
Member #5,241
November 2004
avatar

I'm loving it. ®

Something that isn't made too clear about building Allegro from source:

If you plan on compiling it for MSVC, you of course must use gnu make to do so, but many people use MinGW, while building Allegro requires CR/LF formatting. The tool to do this, UTOD, isn't distributed with MinGW. It's DJGPP.

Just something to ponder for documentation purposes.

r30y162part2

gnolam
Member #2,030
March 2002
avatar

Quote:

The tool to do this, UTOD, isn't distributed with MinGW

Something wrong with unix2dos.exe?

And in any case, what are you saying has to be converted for MinGW? ???

--
Move to the Democratic People's Republic of Vivendi Universal (formerly known as Sweden) - officially democracy- and privacy-free since 2008-06-18!

Gideon Weems
Member #3,925
October 2003

I thought the make process did that automatically (LF -> CR/LF when fix.bat was run for "ming32")? Either that or the .zip distribution has CR/LF formatting?

 1   2 


Go to: