http://sourceforge.net/projects/alleg/files/allegro-unstable/4.9.17/
Changes from 4.9.16 to 4.9.17 (February 2010)
=============================================
The main developers this time were: Trent Gamblin, Elias Pschernig, Evert
Glebbeek, Paul Suntsov, Peter Wang.
Core:
- Removed END_OF_MAIN() everywhere.
For MSVC, we pass a linker option through a #pragma.
On Mac OS X, we rename main() and call it from a real main() function in the
allegro-main addon. The prototype for main() for C++ applications should be
"int main(int, char **)", or the code will not compile on OS X. For C,
either of the normal ANSI forms is fine.
#define ALLEGRO_NO_MAGIC_MAIN disables the #pragma or name mangling, so you
can write a WinMain() or use al_run_main() yourself.
Graphics:
- Fixed a bug in the OpenGL driver where al_draw_bitmap() wouldn't handle
blitting from the back buffer.
- Changing the blending color now works with deferred drawing (Todd Cope).
- Avoid some problems with window resizing in Windows/D3D.
- Added al_get_d3d_texture_position.
- Fixed bug under X11 where al_create_display() would always use the display
options from the first al_create_display() call.
- Properly implemented osx_get_opengl_pixelformat_attributes().
- Fixed automatic detection of colour depth on OS X.
- Fixed al_get_num_display_modes() on Mac OS X 10.6.
- Removed al_get_num_display_formats, al_get_display_format_option,
al_set_new_display_format functions as they can't be implemented on
OSX/iPhone/GPX ports (and were awkward to use).
- Replaced al_toggle_window_frame function with a new function
al_toggle_display_flags.
- al_load_bitmap() and al_convert_mask_to_alpha() no longer reset the current
transformation.
- Add a minimize button to all non-resizable windows on Windows.
- The wgl display switch-in/out vtable entries were swapped (Milan Mimica).
Input:
- Some keycodes were out of order in src/win/wkeyboard.c
- Fixed mouse range after resizing window on Windows.
- Fixed (or worked around) a joystick axis detection problem on Mac OS X.
- Change timer counts from 'long' to 'int64_t'.
File I/O:
- Remove `ret_success' arguments from al_fread32be/le.
allegro-main addon:
- Added an "allegro-main" addon to hold the main() function that is required
on Mac OS X. This way the user can opt out of it.
Primitives addon:
- Added support for sub-bitmap textures in OpenGL driver.
- Added support for sub-bitmap textures in D3D driver.
Made D3D sub-bitmaps work better with user D3D code.
Audio addons:
- Changed the _stream suffix to _f in the audio loading functions.
- Added the stream versions of loading functions for wav, ogg and flac.
- Rename audio I/O functions to al_load_{format}, al_save_{format},
al_load_{format}_f and al_save_{format}_f.
- Added al_load_sample_f, al_save_sample_f, al_load_audio_stream_f and the
related functions.
- Fixed a bug where al_save_sample was improperly handling the extension.
- al_drain_audio_stream would hang on an audio stream in the 'playing' state
(the default) which wasn't attached to anything.
- Fixed a potential deadlock on destroying audio streams by shutting down the
audio driver.
- Comment out PA_SINK_SUSPENDED check, which breaks the PulseAudio driver, at
least on Ubuntu 9.10.
- Replace unnecessary uses of `long' in audio interfaces.
Image addons:
- Fixed return values of al_save_bmp_f and al_save_pcx_f being ignored.
- Changed the _stream suffix to _f in the image loading functions.
TTF addon:
- Drawing TTF fonts no longer resets the current transformation.
Build system:
- Add the CMake option FLAC_STATIC, required when using MSVC with a static
FLAC library.
- Link with zlib if linking with PhysicsFS is not enough.
- Updated iPhone project files.
Documentation:
- Many documentation updates.
Examples:
- ex_display_options: Added mouse support, query current display settings,
display error if a mode can't be set.
Bindings:
- Made the Python wrapper work under OSX.
- Added a CMake option to build the Python wrapper.
- Added al_run_main() mainly to support the Python wrapper on OSX.
Downloading it.
What the hell happened to ex_ttf.exe?
{"name":"600489","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/1\/9\/1926aaf51d5769265f6b96a62885234d.jpg","w":632,"h":955,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/1\/9\/1926aaf51d5769265f6b96a62885234d"}
It looks like either the clipping or the rendering is off by one pixel (you can see the difference at the right side of the O in "Allegro" or at the base of the A).
The ex_ttf looks fine to me in Linux (no clipping of the o and the small green text is well formed) but ex_blend_test crashes
gdb) run
Starting program: /home/prog/allegro-4.9.17/build/examples/ex_blend_test
[Thread debugging using libthread_db enabled]
[New Thread 0xb64d87e0 (LWP 11018)]
[New Thread 0xb64d7b90 (LWP 11021)]
OK OK
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb64d87e0 (LWP 11018)]
al_transform_coordinates (trans=0x140, x=0xb7f5b6e0, y=0xb7f5b6e4)
at /home/prog/allegro-4.9.17/src/transformations.c:214
214 *x = t * trans->m[0][0] + *y * trans->m[1][0] + trans->m[3][0];
(gdb)
I haven't fiddled with all of them yet
The ex_ttf looks fine to me in Linux (no clipping of the o and the small green text is well formed)
It's fine on OS X too. I wonder if it's a D3D vs OpenGL problem?
but ex_blend_test crashes
Confired on OS X.
I've modified ex_ttf to use OpenGL and the problem is fixed. Using Direct3D produces this "clipping".
Curiously, ex_ttf looks fine with the default settings on my machine (Windows XP, old Intel graphics). ex_blend_test crashes, too.
[EDIT:] It seems that calling al_load_font() before creating the display causes the program to crash. Maybe it's supposed to be called after the display is created (it's not in the documentation), but it didn't crash on 4.9.16. Can't tell for sure if it was present in the 4.9.17 SVN revisions, though.
ex_ttf looks fine here, only tested on vmware fusion with nvidia... any pattern for those who it doesn't work for? Ie what are you graphics cards?
ken: That's a bug.. just not sure what is the bug: 1) If you load a font/bitmap before creating a display, should you have to use ALLEGRO_MEMORY_BITMAP? or 2) should Allegro do that itself if there is no display.
In this example you'd want to load the font after creating the display anyway, because you don't want a memory font.
NVidia Geforce 8600 GT DDR2 512 MB.
Windows XP SP3.
ex_ttf using Direct3D produces that horrible clipping.
ex_ttf using OpenGL displays correctly.
I don't know about ex_blend_test. It doesn't do anything. Am I supposed to pass some args or something?
In this example you'd want to load the font after creating the display anyway, because you don't want a memory font.
Thanks, I'll keep that in mind.
Seems like the problem with ex_ttf is related to the global use of transforms. The transform application in D3D was being offset by 0.5 pixels, but that's already done for bitmap drawing, so drawing was being done starting at the center of a pixel instead of the top left corner. What I think the solution is is to offset primitive drawing in the direct3d functions by -0.5 pixels... I'm not sure how well that is going to work though. SiegeLord will have to answer that question. For now there's a patch attached to this post that fixes the problem.
So what am I doing wrong? :S
[ 31%] Building C object addons/audio/CMakeFiles/allegro_audio.dir/pulseaudio.c.o /home/aviv/Documents/Programming/4917/allegro/addons/audio/pulseaudio.c: In function ‘sink_info_cb’: /home/aviv/Documents/Programming/4917/allegro/addons/audio/pulseaudio.c:49: error: ‘pa_sink_state_t’ undeclared (first use in this function) /home/aviv/Documents/Programming/4917/allegro/addons/audio/pulseaudio.c:49: error: (Each undeclared identifier is reported only once /home/aviv/Documents/Programming/4917/allegro/addons/audio/pulseaudio.c:49: error: for each function it appears in.) /home/aviv/Documents/Programming/4917/allegro/addons/audio/pulseaudio.c:49: error: ‘ret’ undeclared (first use in this function) /home/aviv/Documents/Programming/4917/allegro/addons/audio/pulseaudio.c:51: error: ‘pa_sink_info’ has no member named ‘state’ /home/aviv/Documents/Programming/4917/allegro/addons/audio/pulseaudio.c: In function ‘pulseaudio_open’: /home/aviv/Documents/Programming/4917/allegro/addons/audio/pulseaudio.c:93: error: ‘pa_sink_state_t’ undeclared (first use in this function) /home/aviv/Documents/Programming/4917/allegro/addons/audio/pulseaudio.c:93: error: expected ‘;’ before ‘state’ /home/aviv/Documents/Programming/4917/allegro/addons/audio/pulseaudio.c:95: error: ‘state’ undeclared (first use in this function) make[2]: *** [addons/audio/CMakeFiles/allegro_audio.dir/pulseaudio.c.o] Error 1 make[1]: *** [addons/audio/CMakeFiles/allegro_audio.dir/all] Error 2 make: *** [all] Error 2
EDIT:
(ran cmake with WANT_PULSEAUDIO and no WANT_OSS or WANT_ALSA, then make gave me this (after everything before being successful))
Ubunutu 9.04
EDIT2: According to the internet the required struct is only defined in PulseAudio since 0.9.15, and according to my package manager I have version 0.9.14 (the latest 
) installed, so probably this is it?
EDIT3: Interesting! If you remember my previous Audio Troubles thread, I recompiled with ALSA (and no OSS or PulseAudio) and got crappy sound. Curiously enough, I still get crappy sound in all of the audio example except ex_stream_seek, what could be causing this?
Static binaries for MinGW and MSVC are up on http://allegro5.org.
Curiously enough, I still get crappy sound in all of the audio example except ex_stream_seek, what could be causing this?
PulseAudio being crappy.
What the <censored> happened to ex_ttf.exe?
Well, I'm back from my little vacation and I can't reproduce this bug... :-\ Can any of those that have this bug also compile Allegro from source? If not, try these .dll's and see if they work (obviously remove the suffixes). They might only work for MinGW people, or maybe for nobody at all 
Cool, Plus DLL solved the problem. The other examples still work as expected. 
Minus didn't change anything though. Did you commit these fixes to the SVN yet? Or would you mind sending me the changes so I can build it myself?
Both Minus2 and Plus2 dlls fixed the problem. I'm sure the problem isn't with my build, since the previous minus dll you attached yesterday didn't fix the problem.
Those last two dll's do something different (and something more sane, actually, hah). Can someone who didn't have this bug use those last two dll's and see what happens? If it doesn't break things for those people I'll commit the changes to SVN.
As soon as a friend connects I'll send him the ex_ttf to test.
What did you change SiegeLord? You removed the 0.5f offset from d3d_bmp?
Most of the changes are encompassed in the attached diff.
I've been debugging for a bit and think I found the problem with using TTF fonts when the display hasn't been created. I do that when I load a font in another thread just so I can use the text width functions (which I think should be usable without a display).
The transformations part of the API doesn't do any checks for a NULL display (which makes sense - you wouldn't be using transforms unless there was a display), so when the TTF addon calls the transformation functions in render_glyph without checking for a NULL display, a memory error is generated and the program crashes.
The attached diff adds a NULL display check to the TTF addon before saving the current transformation.
Although I'm not sure if this fixes kenmasters1976's issue - I was still able to load fonts just fine, I just couldn't call any function using render_glyph.
which makes sense - you wouldn't be using transforms unless there was a display
Unless you are drawing to a memory bitmap.
We solved the same issue for blending by moving it out of the display and put into thread local storage - which is a bit hackish as conceptually, transforms and blending belong to the display. So not sure yet what to do about transforms.
Can someone who didn't have this bug use those last two dll's and see what happens? If it doesn't break things for those people I'll commit the changes to SVN.
Both dll's give a correct output for ex_ttf on my machine.
Great, thanks. The changes are now in the SVN.
Slartibartfast said:
Curiously enough, I still get crappy sound in all of the audio example except ex_stream_seek, what could be causing this?
PulseAudio being crappy.
Well, the "curiously enough" part refers to ex_stream_seek working fine. And would PulseAudio being crappy matter if I'm using alsa? (seeing as how I couldn't even get PulseAudio support compiled :S)
Edit: forgot to say good job for your work on Allegro
When you use PulseAudio it takes over all sound. That is in a recent Ubuntu, even if you use Alsa, it is routed through PA. You can check it by clicking the PA volume icon. It will have a volume slider for each application currently playing sounds, including those using Alsa - for those it says something like "ALSA plug-in [application name]" instead of just "application name".
It also seems possible to fix the lag issue application-wise. For example in LMMS, I can choose alsa, pulseaudio and SDL for sound output.
If I select Alsa, LMMS simply crashes. Apparently it uses Alsa in a way which does only work with real ALSA, and not the pulseaudio ALSA emulation.
If I select pulseaudio, it works, but the sound is delayed by half to a full second. Makes it completely unusable of course.
If I select SDL, it works perfectly. No noticeable delay, and no audio noise even with the smallest possible buffer size. But it still is routed through PA - seems the SDL devs managed to make their audio API somehow trick PA into dropping it's forced half-second delay. Question is just how did they do it.
Just wanted to say thanks to the Allegro devs, everything is worked as expected after solving the little problem with the d3d clipping. Everything's working great so far.
When you use PulseAudio it takes over all sound. That is in a recent Ubuntu, even if you use Alsa, it is routed through PA.
Oh, okay. Lame.
If I select SDL, it works perfectly. No noticeable delay, and no audio noise even with the smallest possible buffer size. But it still is routed through PA - seems the SDL devs managed to make their audio API somehow trick PA into dropping it's forced half-second delay. Question is just how did they do it.
Considering how in my case, all sound examples fail to produce proper sound except for ex_stream_seek, maybe there is some hidden solution to that problem in the case of ex_stream_seek?
<edit>
Never mind.. my problem was just that I didn't realise allegro 4.9 required a different directX sdk to allegro 4.4. I downloaded this and it fixed the problem. (I'm just leaving my original message in case it helps someone else)
</edit>
I just downloaded the latest version of the 4.9 branch on svn. It had compile errors, so I reverted to version 12922 (for which the comment was "bumped to 4.9.17", so I assume it's the version you're talking about here) - but that had the same errors.
Here's a copy-paste of the first few compile problems:
C:\Programming\allegro5\src\win\wjoydxnu.c: In function `joystick_dinput_acquire': C:\Programming\allegro5\src\win\wjoydxnu.c:271: warning: implicit declaration of function `IDirectInputDevice8_Acquire' C:\Programming\allegro5\src\win\wjoydxnu.c: In function `_al_win_joystick_dinput_unacquire': C:\Programming\allegro5\src\win\wjoydxnu.c:292: warning: implicit declaration of function `IDirectInputDevice8_Unacquire' C:\Programming\allegro5\src\win\wjoydxnu.c: In function `_al_win_joystick_dinput_grab': C:\Programming\allegro5\src\win\wjoydxnu.c:318: warning: implicit declaration of function `IDirectInputDevice8_SetCooperativeLevel' C:\Programming\allegro5\src\win\wjoydxnu.c: In function `joystick_enum_callback': C:\Programming\allegro5\src\win\wjoydxnu.c:582: warning: implicit declaration of function `IDirectInput8_CreateDevice' C:\Programming\allegro5\src\win\wjoydxnu.c:587: warning: implicit declaration of function `IDirectInputDevice8_QueryInterface' C:\Programming\allegro5\src\win\wjoydxnu.c:587: error: `IID_IDirectInputDevice8' undeclared (first use in this function)
Any hints as to what I'm doing wrong? I'd prefer to be able to use the most up-to-date code, but maybe I should just download the non-svn version. (?)
Where's the API for Allegro 5, anyway? All the examples I find are out of date and I don't see any docs online except for the same API as on the site here ...
Search for "Allegro 4.9 manual":
That works, thanks
There's a link to the A5 API (the page Matthew posted) on Allegro's homepage (under "API"): http://alleg.sourceforge.net/api.html