|
|
|
This thread is locked; no one can reply to it.
|
1
2
|
| Allegro 4.9.17 released |
|
Peter Wang
Member #23
April 2000
|
http://sourceforge.net/projects/alleg/files/allegro-unstable/4.9.17/ Quote:
Changes from 4.9.16 to 4.9.17 (February 2010) The main developers this time were: Trent Gamblin, Elias Pschernig, Evert 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 #define ALLEGRO_NO_MAGIC_MAIN disables the #pragma or name mangling, so you Graphics: - Fixed a bug in the OpenGL driver where al_draw_bitmap() wouldn't handle - 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 - 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, - Replaced al_toggle_window_frame function with a new function - al_load_bitmap() and al_convert_mask_to_alpha() no longer reset the current - 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 Primitives addon: - Added support for sub-bitmap textures in OpenGL driver. - Added support for sub-bitmap textures in D3D driver. 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}, - Added al_load_sample_f, al_save_sample_f, al_load_audio_stream_f and the - 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 - Fixed a potential deadlock on destroying audio streams by shutting down the - Comment out PA_SINK_SUSPENDED check, which breaks the PulseAudio driver, at - 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 - 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, 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.
|
|
kenmasters1976
Member #8,794
July 2007
|
Downloading it.
|
|
Dario ff
Member #10,065
August 2008
 |
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"}
TranslatorHack 2010, a human translation chain in a.cc. |
|
Evert
Member #794
November 2000
 |
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). |
|
Arthur Kalliokoski
Second in Command
February 2005
 |
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 They all watch too much MSNBC... they get ideas. |
|
Evert
Member #794
November 2000
|
Arthur Kalliokoski said: 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? Quote: but ex_blend_test crashes Confired on OS X. |
|
Dario ff
Member #10,065
August 2008
|
I've modified ex_ttf to use OpenGL and the problem is fixed. Using Direct3D produces this "clipping". TranslatorHack 2010, a human translation chain in a.cc. |
|
kenmasters1976
Member #8,794
July 2007
|
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.
|
|
Trent Gamblin
Member #261
April 2000
 |
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.
|
|
Dario ff
Member #10,065
August 2008
|
NVidia Geforce 8600 GT DDR2 512 MB. ex_ttf using Direct3D produces that horrible clipping. I don't know about ex_blend_test. It doesn't do anything. Am I supposed to pass some args or something? TranslatorHack 2010, a human translation chain in a.cc. |
|
kenmasters1976
Member #8,794
July 2007
|
Trent Gamblin said: 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.
|
|
Trent Gamblin
Member #261
April 2000
|
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.
|
|
Slartibartfast
Member #8,789
June 2007
 |
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: 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 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? ---- |
|
Trent Gamblin
Member #261
April 2000
|
Static binaries for MinGW and MSVC are up on http://allegro5.org.
|
|
Thomas Fjellstrom
Member #476
June 2000
 |
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. -- |
|
SiegeLord
Member #7,827
October 2006
 |
Quote: 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 "For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18 |
|
Dario ff
Member #10,065
August 2008
|
Cool, Plus DLL solved the problem. The other examples still work as expected. TranslatorHack 2010, a human translation chain in a.cc. |
|
SiegeLord
Member #7,827
October 2006
|
That fix makes no sense, so I haven't committed it yet. Could you try these two .dll's too? Minus2 and Plus2. "For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18 |
|
Dario ff
Member #10,065
August 2008
|
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. TranslatorHack 2010, a human translation chain in a.cc. |
|
SiegeLord
Member #7,827
October 2006
|
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. "For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18 |
|
Dario ff
Member #10,065
August 2008
|
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? TranslatorHack 2010, a human translation chain in a.cc. |
|
SiegeLord
Member #7,827
October 2006
|
Most of the changes are encompassed in the attached diff. "For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18 |
|
ameskitty
Member #11,113
July 2009
|
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. |
|
Kibiz0r
Member #6,203
September 2005
 |
--- |
|
Elias
Member #358
May 2000
|
ameskitty said: 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. -- |
|
|
1
2
|
) installed, so probably this is it?
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?
