Allegro 4.9.9 is available.
EDIT: Allegro 4.9.9.1 is available.
Changes from 4.9.9 to 4.9.9.1 (March 2009)
==========================================
- Made it compile and work with MSVC and MinGW 3.4.5.
- Enabled SSE instruction set in MSVC.
- Fixed X11 XIM keyboard input (partially?).
- Fall back on the reference (software) rasterizer in D3D.
Changes from 4.9.8 to 4.9.9 (March 2009)
========================================
The main developers this time were: Trent Gamblin, Evert Glebbeek, Milan
Mimica, Elias Pschernig, Paul Suntsov, Peter Wang. Other contributions
from: Todd Cope, Angelo Mottola, Trezker.
Graphics:
- Added display options API and scoring, based on AllegroGL, for finer
control over display creation.
- Added API to query possible display formats (implemented on X, Mac OS X).
- Changed the bitmap locking mechanism. The caller can choose a pixel
format.
- Added support for multisampling.
- Simplified the semantics of al_update_display_region().
- Optimised software blitting routines.
- Optimised al_map_rgb/al_map_rgba.
- Replaced al_draw_rectangle() and al_draw_line() from core library with
al_draw_rectangle_ex() and al_draw_line_ex() from the primitives addon.
- Implemented al_wait_for_vsync() everywhere except WGL.
- Fixed problems with sub-bitmaps with the OpenGL driver.
- Fixed bugs in software scaled/rotated blit routines.
- Added a new pixel format ALLEGRO_PIXEL_FORMAT_ABGR_F32.
Removed ALLEGRO_PIXEL_FORMAT_ANY_15_WITH_ALPHA,
ALLEGRO_PIXEL_FORMAT_ANY_24_WITH_ALPHA.
- Added support for creating OpenGL 3.0 contexts (untested; only WGL/GLX for
now). Relevant display flags are ALLEGRO_OPENGL_3_0 and
ALLEGRO_OPENGL_FORWARD_COMPATIBLE.
- Allow disabling any OpenGL extensions from allegro.cfg to
test alternative rendering paths.
- Fixed problem with windows only activating on title bar clicks (Windows).
- Fixed a minimize/restore bug in D3D (with the help of Christopher Bludau).
Input:
- Implemented al_set_mouse_xy under X11.
- Added ALLEGRO_EVENT_MOUSE_WARPED event for al_set_mouse_xy().
Path routines:
- Made al_path_get_drive/filename return the empty string instead of NULL
if the drive or filename is missing.
- Changed al_path_set_extension/al_path_get_extension to include the leading
dot.
- Made al_path_get_extension(), al_path_get_basename(), al_path_to_string()
return pointers to internal strings.
Unicode:
- Changed type of ALLEGRO_USTR; now you should use pointers to ALLEGRO_USTRs.
- Added UTF-16 conversion routines.
Other core:
- Added ALLEGRO_GET_EVENT_TYPE for constructing integers for event type IDs.
- Renamed configuration function names to conform to conventions.
- Removed public MIN/MAX/ABS/MID/SGN/CLAMP/TRUE/FALSE macros.
- Replaced AL_PI by ALLEGRO_PI and documented it as part of public API.
Audio addons:
- Added stream seeking and stream start/end loop points.
- Add panning support for kcm_audio (stereo only).
Font addons:
- Made al_font_grab_font_from_bitmap() accept code point ranges.
- Made font routines use new UTF-8 routines; lifted some arbitrary limits.
- Fixed artefacts in bitmap font and TTF rendering.
Image I/O addon:
- Made the capability to load/save images from/to ALLEGRO_FS_ENTRYs public.
- Added missing locking to .png save function.
Other addons:
- Added native_dialog addon, with file selector dialogs.
- Fixed many bugs in the primitives addon.
- Made hsv/hsl color functions accept angles outside the 0..360° range.
- Fixed a bug in al_color_name_to_rgb.
Examples:
- New programs: ex_audio_props, ex_blend_bench, ex_blend_test, ex_blit,
ex_clip, ex_draw, ex_font_justify, ex_gl_depth, ex_logo, ex_multisample,
ex_native_filechooser, ex_path_test, ex_rotate, ex_stream_seek, ex_vsync,
ex_warp_mouse.
(ex_draw demonstrated known bugs currently.)
- Updated programs: ex_joystick_events, ex_monitorinfo ex_pixelformat,
ex_scale, ex_subbitmap.
Build system:
- Added pkg-config support. .pc files are generated and installed on Unix.
- Allowed gcc to generate SSE instructions on x86 by default. For Pentium 2
(or lower) compatibility you must uncheck a CMake option before building
Allegro.
Other:
- Many other bug fixes.
I am downloading it !
Edit:
I catch that error when compiling:
D:\Documents and Settings\Administrateur\Bureau\allegro-4.9.9\allegro\src\wind3d_disp.cpp: In function `bool _al_d3d_init_display()':
D:\Documents and Settings\Administrateur\Bureau\allegro-4.9.9\allegro\src\wind3d_disp.cpp:816: error: `D3D9b_SDK_VERSION' was not declared in this scope
D:\Documents and Settings\Administrateur\Bureau\allegro-4.9.9\allegro\src\wind3d_disp.cpp:816: warning: unused variable 'D3D9b_SDK_VERSION'
mingw32-make[2]: *** [CMakeFiles/allegro.dir/src/win/d3d_disp.cpp.obj] Error 1
mingw32-make[1]: *** [CMakeFiles/allegro.dir/all] Error 2
mingw32-make: *** [all] Error 2
Edit 2: Nevermind. I was just in need of the new dx9 package for mingw.
Edit 3:
Now come the real bug:
D:\Documents and Settings\Administrateur\Bureau\allegro-4.9.9\allegro\build\demo>gdb demo.exe
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32"...
(gdb) run
Starting program: D:\Documents and Settings\Administrateur\Bureau\allegro-4.9.9\allegro\build\demo/demo.exe
[New thread 2012.0x214]
[New thread 2012.0x6d4]
Program received signal SIGSEGV, Segmentation fault.
0x6b69117e in al_set_new_display_option (option=22, value=0, importance=1)
at D:/Documents and Settings/Administrateur/Bureau/allegro-4.9.9/allegro/src/display_settings.c:36
36 extras->required |= 1 << option;
(gdb) p extras
$1 = (ALLEGRO_EXTRA_DISPLAY_SETTINGS *) 0x0
(gdb) p extras -> required
Cannot access memory at address 0x0
Edit 3:
A little bit of research later, it seems that _al_get_new_display_settings() can return 0 without it to be an error. As 'extras' is unchecked, it's segfaulting.
I'm having a problem with stopping a stream.
This property only works if I call it before attaching to voice.
al_set_stream_bool(work_sound_stream, ALLEGRO_AUDIOPROP_PLAYING, false);
Now come the real bug:
Which gcc version?
Elias: gcc version 3.4.5 (mingw-vista special r3) , but it's not the static build. The demo & examples need their dlls to work fine.
Can you try with 4.x?
[edit:]
For example 4.3.0: http://sourceforge.net/project/showfiles.php?group_id=2435
It's still important to fix it for 3.x of course - just would be good to know if it's just an outdated compiler causing the problem or something else.
Just let me save my current mingw directory, install a fresh new TDM build, freshen up the whole thing and I will tell you.
Edit:
Working fine for my problem with gcc version 4.3.3 (4.3.3-tdm-1 mingw32).
Can't it come from the static DWORD tls_index; at tls.c line 78 not being initalized correctly with gcc 3 series ? -> Edit: NO !
I will try to add a call to GetLastError (which is preconized by the msnd about TlsGetValue returning 0) and tell you what is going on.
Nice. I'm downloading it.
No codename this time?.
I got the exact same problem as GullRaDriel here using the same compiler version he did. I am now upgrading to mingw 4.x
Unfortunately, like 4.9.7, 4.9.9 doesn't build with MSVC. We might have to release a 4.9.9.1 in a few days to fix that and the demo bug (which BTW works with GCC 4.2.1 for me).
I'm uploading MinGW binaries of 4.9.9 to http://allegro5.org as I type this.
I'm uploading MinGW binaries of 4.9.9 to http://allegro5.org as I type this.
Awesome. Thanks!
And the 4.9.9 release is awesome too! Good work guys!
I got the exact same problem as GullRaDriel here using the same compiler version he did. I am now upgrading to mingw 4.x
Same problem here. Same gcc version.
Too bad. I was really looking forward to try it.
The demo started off as a game on my website, so you could grab a binary there if you just want to try it: http://nooskewl.com/index.php?option=com_content&task=view&id=14&Itemid=26
Uses an old version of 4.9 so it may not work as well as the 4.9.9 demo would.
Trezker: thanks for reporting, will investigate. It does work if you attach the stream to a mixer, and the mixer to the voice.
I've made a quick fix. Don't know if it's correct or not, but now the examples are working with gcc 3.4.5.
[EDIT:] Programs using OpenGL keep crashing, but at least I can try 4.9.9 using Direct3D.
[EDIT 3:] Duh!... nevermind about EDIT 2... now I get what it's doing...
See updated original post.
4.9.9.1 binaries for Windows can be found at http://allegro5.org. Note that the version number was bumped to 4.9.10 but these are not 4.9.10 binaries, they're 4.9.9.1.
Thanks for fixing it
Note that the version number was bumped to 4.9.10
That's true if you built it from SVN, but if you built it from the release it would still say 4.9.9.
I built from svn after checking out tag 4.9.9.1.
Yes, the tag will have the wrong version number. The release is correct though.
I'll consider changing the release procedure next time around.
Programs using OpenGL keep crashing on my machine with 4.9.9.1. I have an old integrated Intel graphics card.
Anyone else with integrated Intel card having this problem?.
So around when Allegro 5 will be released?
When it's done.
Programs using OpenGL keep crashing on my machine with 4.9.9.1. I have an old integrated Intel graphics card.
Show your bo log file.
If no one else is having this problem then maybe it's an issue with my drivers or something and not worth for the devs to bother. But in case it's useful...
I tried to use the binary pack at allegro5.org but it doesn't include the debug versions, so I had to build them on my machine to get a log file. However, this is all I get on the allegro.log file for either the ex_glext or ex_opengl examples:
ALLEGRO_SYSTEM_INTERFACE created. al-winput INFO: Input thread started. Render-to-texture: 1
This is what I get with gdb:
(gdb) run Starting program: C:\allegro\allegro-4.9.9.1\build\examples/ex_opengl.exe [New thread 2072.0xe04] [New thread 2072.0xc78] [New thread 2072.0x804] warning: WGL Message:System Error: (13):wglGetPixelFormatAttribARB: WGLERR_INVAL ID_DATA Program received signal SIGSEGV, Segmentation fault. 0x00000000 in ?? () (gdb) backtrace #0 0x00000000 in ?? () #1 0x69b294f1 in get_pixel_formats_count_ext (dc=0x34010665) at C:/allegro/allegro-4.9.9.1/src/win/wgl_disp.c:247 #2 0x69b2a6dd in get_available_pixel_formats_ext (count=0x22fcfc) at C:/allegro/allegro-4.9.9.1/src/win/wgl_disp.c:753 #3 0x69b2ab96 in select_pixel_format (d=0x3f6000, dc=0x9c011aa2) at C:/allegro/allegro-4.9.9.1/src/win/wgl_disp.c:879 #4 0x69b2ae6a in create_display_internals (wgl_disp=0x3f6000) at C:/allegro/allegro-4.9.9.1/src/win/wgl_disp.c:959 #5 0x69b2b1fa in wgl_create_display (w=640, h=480) at C:/allegro/allegro-4.9.9.1/src/win/wgl_disp.c:1054 #6 0x69ad3268 in al_create_display (w=640, h=480) at C:/allegro/allegro-4.9.9.1/src/display_new.c:59 #7 0x0040197d in _mangled_main () at C:/allegro/allegro-4.9.9.1/examples/ex_opengl.c:130 #8 0x69afeb68 in _WinMain (_main=0x401920, hInst=0x400000, hPrev=0x0, Cmd=0x241f16 "", nShow=10) at C:/allegro/allegro-4.9.9.1/src/win/wnewsys.c:136 #9 0x00401a6e in WinMain (hInst=0x400000, hPrev=0x0, Cmd=0x241f16 "", nShow=10) at C:/allegro/allegro-4.9.9.1/examples/ex_opengl.c:164 #10 0x00401e61 in main () (gdb) quit
Don't know if this is related to the problem kenmasters1976 described.
I have one of these things lying around and I wanted to make it usefull again with a little allegro app.
But the app refused to start, no matter what resolution I set.
It supposed to have a Lynx 3DM+ graphics chip.
When setting
al_set_new_display_flags(ALLEGRO_OPENGL);
al_create_display returns NULL.
When setting
al_set_new_display_flags(ALLEGRO_DIRECT3D);
the application just crashes.
I wasn't able to compile allegro myself yet, so I'm using the binarys from allegro5. Since these are in releae mode no log file is created.
Maybe if someone could provide debug binarys (windows mingw or msvc) I could provide a log file.
What is strange is that al_create_display doesn't return null when direct3d is forced but the application just crashes.
If the device I have there is too exceptional and you don't plan on making allegro work with it just say so
If Allegro crashes when used correctly then that's a bug we need to fix.
Something to do with D3D not being completely de-initialized after trying one mode maybe... if the first mode it tries fails, it explodes. I will look into it.
Not sure that device will support D3D9 but it might. Never heard of the gfx chipset though.
cmake ended with a complain about OpenGL:
CMake Error at CMakeLists.txt:485 (message): X11 support currently requires OpenGL support.
As far as I know, I got OpenGL support. What should I install?
(Edited: Nevermind, I had a conflict here. Apparently in Ubuntu the Nvidia drivers come with their own set of OpenGL libraries and headers. Commands to get them on: sudo apt-get install freeglut3-dev libgl1-mesa-dev libglu1-mesa-dev libglut3-dev mesa-common-dev xlibmesa-gl-dev).
Other than that, compiled fine. Cannot get it to generate the info or the PDF documentation, I am guessing just turning WANT_DOCS_PDF and WANT_DOCS_INFO is not enough. I reconfigured, but somehow it is not applying the changes (as in, it is not creating them).
You need pandoc 1.1 for info docs, and pdflatex for PDFs. Note that the info docs are slightly out of whack (sections being chapters; easily fixed but just hasn't been done).
An error message for missing binaries should be useful in those cases.
Does someone have a static pandoc 1.2 binary btw?
Ubuntu/Debian only has 0.46 and my attempts to compile 1.1 and 1.2 failed. It first wanted three dependencies, things called "parsec", "utf8-string" and "zip-archive". Neither of them exists in Debian. So I tried compiling them. But to get them some strange tool named "cabal" seemed necessary. Installing that requires "hugs" instead of "ghc"... but "ghc" seems necessary for an earlier step... so basically it seems impossible. (The Debian/Ubuntu maintainers likely have the same problem and therefore it's still at 0.46 there.)
[edit] Got the dependencies to compile somehow (and only parsec 1.2 and not parsec 1.3 will work). Why they think something like "cabal" is a good idea I'll never understand - letting me get the dependencies without it would have made this much easier :/
[quote]
When it's done.
[/quote]
Which is when? I don't want a fixed date, just a Month approximation, for example, in 10 to 15 months etc.
I think it should be done this year, maybe by summer.
But you shouldn't underestimate the final details, the ones we know of are just the tip of the iceberg. So we shouldn't be surprised if it drags on into next year, unless the devs want to make a KDE like .0 release.
Which is when?
When it's done.
I don't want a fixed date, just a Month approximation, for example, in 10 to 15 months etc.
Sorry, no.
I could make a guess, but I don't want to make an estimate like that. When we're close to bringing out RC1, you'll hear about it.
It's getting there and it shouldn't be too long now, if we can keep momentum going.
Maybe you're missing a trick with Allegro 5 and you should do what the big boys do by missing a few numbers. Allegro 7 has a nice look about it.
What logic would you use to go 1 to 4 then to 7?
What logic would you use to go 1 to 4 then to 7?
Other than being frivolous and not serious, 5 is tainted as being the telepathic April fool version, 6 is two short of the devil, but 7 on the other hand looks nice.
Visual C++ missed out 3 - and skipped from 6 to 2002 , Navigator missed out 5, etc.
kenmasters1976: It does look like a driver issue. As you may know, allegro programs read some settings out of allegro.cfg, and there should be one in the package. Under section [graphics] there is an option named "config_selection". Try setting it to "old".
You can just create a text file containing only:
[graphics] config_selection=old
This will turn off all the fancy stuff during al_create_display().
You can just create a text file containing only:
For me that didn't change anything on the oqo
Christopher: Your OpenGL works just fine It returns NULL. I guess you don't have OpenGL 1.2.
Visual C++ missed out 3 - and skipped from 6 to 2002 , Navigator missed out 5, etc.
With the 2002 part, then it applies to Windows, they skipped NT 5 and went to 2000... oh wait... what about Windows 7?
The logic with Visual Studio skipping up to 6 was so that MS could have all the products be the same version number. Something in the Visual Studio line didn't skip numbers, and it was at 6.0 when the skip happened. So your MSVC part is moot (Note Visual J++ jumped from 1.1 to 6 at the time BTW)
Navigator 5... I saw a Navigator 5 once...
I guess you don't have OpenGL 1.2.
EDIT: Since I don't really have a clue what this graphicchip is I probably won't find drivers for it (and probably they will not have opengl support )
Btw, with allegro 4.9.8 direct3d is not creating a display as well but is returning NULL.
Maybe that helps finding the bug.
What could be the problem that direct3d isn't able to create a display?
Does that mean the graphicscard doesn't support 1.2 or do I have to install something?
I don't know. There might be other restrictions as well.
For me your suggestion about config_selection worked. Now the examples using OpenGL run fine. Thanks.
But... now there's another problem, this time with the primitives addon. I have this simple program:
It crashes on the call to al_draw_line(). Again, it only crashes when using OpenGL. Disabling the extensions in allegro.cfg didn't help.
Heres the contents of the allegro.log file:
ALLEGRO_SYSTEM_INTERFACE created. al-winput INFO: Input thread started. Render-to-texture: 1 al-wmouse INFO: mouse handler starts wgl-win INFO: select_pixel_format(): Forcing OLD visual selection method. wgl-win INFO: get_available_pixel_formats_old(): Got 42 visuals. -- wgl-win INFO: Decoding visual no. 1... wgl-win INFO: Decoding: wgl-win INFO: Accelarated: yes wgl-win INFO: Single-buffer: yes wgl-win INFO: Swap method: undefined wgl-win INFO: Color format: r8 g8 b8 a8, 32 bit wgl-win INFO: Depth buffer: 0 bits wgl-win INFO: Sample buffers: no wgl-win INFO: Samples: 0 display_settings INFO: Single Buffer requirement not met. -- ... ... -- wgl-win INFO: Decoding visual no. 42... wgl-win INFO: Decoding: wgl-win INFO: Not RGBA mode wgl-win INFO: get_available_pixel_formats_ext(): 7 visuals are good enough. wgl-win INFO: select_pixel_format(): Chose visual no. 2 wgl-win INFO: Accelarated: yes wgl-win INFO: Single-buffer: no wgl-win INFO: Swap method: undefined wgl-win INFO: Color format: r8 g8 b8 a8, 32 bit wgl-win INFO: Depth buffer: 0 bits wgl-win INFO: Sample buffers: no wgl-win INFO: Samples: 0 al-ext INFO: OpenGL Extensions: al-ext INFO: GL_ARB_multitexture al-ext INFO: GL_ARB_texture_border_clamp al-ext INFO: GL_ARB_texture_compression al-ext INFO: GL_ARB_texture_cube_map al-ext INFO: GL_ARB_texture_env_add al-ext INFO: GL_ARB_texture_env_combine al-ext INFO: GL_ARB_texture_env_dot3 al-ext INFO: GL_ARB_texture_env_crossbar al-ext INFO: GL_ARB_transpose_matrix al-ext INFO: GL_EXT_abgr al-ext INFO: GL_EXT_bgra al-ext INFO: GL_EXT_blend_color al-ext INFO: GL_EXT_blend_func_separate al-ext INFO: GL_EXT_blend_minmax al-ext INFO: GL_EXT_blend_subtract al-ext INFO: GL_EXT_clip_volume_hint al-ext INFO: GL_EXT_compiled_vertex_array al-ext INFO: GL_EXT_cull_vertex al-ext INFO: GL_EXT_fog_coord al-ext INFO: GL_EXT_packed_pixels al-ext INFO: GL_EXT_packed_pixels_12 al-ext INFO: GL_EXT_rescale_normal al-ext INFO: GL_EXT_secondary_color al-ext INFO: GL_EXT_separate_specular_color al-ext INFO: GL_EXT_stencil_wrap al-ext INFO: GL_EXT_texture_compression_s3tc al-ext INFO: GL_EXT_texture_env_add al-ext INFO: GL_EXT_texture_env_combine al-ext INFO: GL_EXT_texture_filter_anisotropic al-ext INFO: GL_3DFX_texture_compression_FXT1 al-ext INFO: GL_IBM_texture_mirrored_repeat al-ext INFO: GL_NV_texgen_reflection al-ext INFO: GL_WIN_swap_hint glDrawRangeElements successfully loaded glTexImage3D successfully loaded glTexSubImage3D successfully loaded glCopyTexSubImage3D successfully loaded glActiveTexture successfully loaded glClientActiveTexture successfully loaded glMultiTexCoord1d successfully loaded glMultiTexCoord1dv successfully loaded glMultiTexCoord1f successfully loaded glMultiTexCoord1fv successfully loaded glMultiTexCoord1i successfully loaded glMultiTexCoord1iv successfully loaded glMultiTexCoord1s successfully loaded glMultiTexCoord1sv successfully loaded glMultiTexCoord2d successfully loaded glMultiTexCoord2dv successfully loaded glMultiTexCoord2f successfully loaded glMultiTexCoord2fv successfully loaded glMultiTexCoord2i successfully loaded glMultiTexCoord2iv successfully loaded glMultiTexCoord2s successfully loaded glMultiTexCoord2sv successfully loaded glMultiTexCoord3d successfully loaded glMultiTexCoord3dv successfully loaded glMultiTexCoord3f successfully loaded glMultiTexCoord3fv successfully loaded glMultiTexCoord3i successfully loaded glMultiTexCoord3iv successfully loaded glMultiTexCoord3s successfully loaded glMultiTexCoord3sv successfully loaded glMultiTexCoord4d successfully loaded glMultiTexCoord4dv successfully loaded glMultiTexCoord4f successfully loaded glMultiTexCoord4fv successfully loaded glMultiTexCoord4i successfully loaded glMultiTexCoord4iv successfully loaded glMultiTexCoord4s successfully loaded glMultiTexCoord4sv successfully loaded glLoadTransposeMatrixf successfully loaded glLoadTransposeMatrixd successfully loaded glMultTransposeMatrixf successfully loaded glMultTransposeMatrixd successfully loaded glSampleCoverage successfully loaded glCompressedTexImage3D successfully loaded glCompressedTexImage2D successfully loaded glCompressedTexImage1D successfully loaded glCompressedTexSubImage3D successfully loaded glCompressedTexSubImage2D successfully loaded glCompressedTexSubImage1D successfully loaded glGetCompressedTexImage successfully loaded glActiveTextureARB successfully loaded glClientActiveTextureARB successfully loaded glMultiTexCoord1dARB successfully loaded glMultiTexCoord1dvARB successfully loaded glMultiTexCoord1fARB successfully loaded glMultiTexCoord1fvARB successfully loaded glMultiTexCoord1iARB successfully loaded glMultiTexCoord1ivARB successfully loaded glMultiTexCoord1sARB successfully loaded glMultiTexCoord1svARB successfully loaded glMultiTexCoord2dARB successfully loaded glMultiTexCoord2dvARB successfully loaded glMultiTexCoord2fARB successfully loaded glMultiTexCoord2fvARB successfully loaded glMultiTexCoord2iARB successfully loaded glMultiTexCoord2ivARB successfully loaded glMultiTexCoord2sARB successfully loaded glMultiTexCoord2svARB successfully loaded glMultiTexCoord3dARB successfully loaded glMultiTexCoord3dvARB successfully loaded glMultiTexCoord3fARB successfully loaded glMultiTexCoord3fvARB successfully loaded glMultiTexCoord3iARB successfully loaded glMultiTexCoord3ivARB successfully loaded glMultiTexCoord3sARB successfully loaded glMultiTexCoord3svARB successfully loaded glMultiTexCoord4dARB successfully loaded glMultiTexCoord4dvARB successfully loaded glMultiTexCoord4fARB successfully loaded glMultiTexCoord4fvARB successfully loaded glMultiTexCoord4iARB successfully loaded glMultiTexCoord4ivARB successfully loaded glMultiTexCoord4sARB successfully loaded glMultiTexCoord4svARB successfully loaded glLoadTransposeMatrixfARB successfully loaded glLoadTransposeMatrixdARB successfully loaded glMultTransposeMatrixfARB successfully loaded glMultTransposeMatrixdARB successfully loaded glCompressedTexImage3DARB successfully loaded glCompressedTexImage2DARB successfully loaded glCompressedTexImage1DARB successfully loaded glCompressedTexSubImage3DARB successfully loaded glCompressedTexSubImage2DARB successfully loaded glCompressedTexSubImage1DARB successfully loaded glGetCompressedTexImageARB successfully loaded glBlendColorEXT successfully loaded glBlendEquationEXT successfully loaded glLockArraysEXT successfully loaded glUnlockArraysEXT successfully loaded glCullParameterdvEXT successfully loaded glCullParameterfvEXT successfully loaded glSecondaryColor3bEXT successfully loaded glSecondaryColor3bvEXT successfully loaded glSecondaryColor3dEXT successfully loaded glSecondaryColor3dvEXT successfully loaded glSecondaryColor3fEXT successfully loaded glSecondaryColor3fvEXT successfully loaded glSecondaryColor3iEXT successfully loaded glSecondaryColor3ivEXT successfully loaded glSecondaryColor3sEXT successfully loaded glSecondaryColor3svEXT successfully loaded glSecondaryColor3ubEXT successfully loaded glSecondaryColor3ubvEXT successfully loaded glSecondaryColor3uiEXT successfully loaded glSecondaryColor3uivEXT successfully loaded glSecondaryColor3usEXT successfully loaded glSecondaryColor3usvEXT successfully loaded glSecondaryColorPointerEXT successfully loaded glFogCoordfEXT successfully loaded glFogCoordfvEXT successfully loaded glFogCoorddEXT successfully loaded glFogCoorddvEXT successfully loaded glFogCoordPointerEXT successfully loaded glBlendFuncSeparateEXT successfully loaded wglCreateBufferRegionARB successfully loaded wglDeleteBufferRegionARB successfully loaded wglSaveBufferRegionARB successfully loaded wglRestoreBufferRegionARB successfully loaded wglGetExtensionsStringARB successfully loaded wglGetPixelFormatAttribivARB successfully loaded wglGetPixelFormatAttribfvARB successfully loaded wglChoosePixelFormatARB successfully loaded wglMakeContextCurrentARB successfully loaded wglGetCurrentReadDCARB successfully loaded wglCreatePbufferARB successfully loaded wglGetPbufferDCARB successfully loaded wglReleasePbufferDCARB successfully loaded wglDestroyPbufferARB successfully loaded wglQueryPbufferARB successfully loaded wglSwapIntervalEXT successfully loaded wglGetSwapIntervalEXT successfully loaded al-ext INFO: GL_ARB_texture_non_power_of_two found in [opengl_disabled_extensions]. al-ext INFO: GL_EXT_framebuffer_object found in [opengl_disabled_extensions]. Packed Pixels formats available al-ext INFO: Use of non-power-of-two textures disabled. al-ext INFO: Use of FBO to draw to textures disabled. ogl_display: Format 9 used for backbuffer. wgl-win INFO: OpenGL Version: 1.3.0 - Build 4.13.01.3069 wgl-win INFO: Vendor: Intel wgl-win INFO: Renderer: Intel Brookdale-G
I removed part of it (the Decoding visual part) to make the post shorter but I can post it again if needed.
And here's gdb's output:
(gdb) run Starting program: C:\allegro.cc/Allegro5_Test4991.exe [New thread 2940.0xf0] (no debugging symbols found) (no debugging symbols found) [New thread 2940.0xcfc] [New thread 2940.0x49c] [New thread 2940.0x754] Program received signal SIGSEGV, Segmentation fault. 0x00000000 in ?? () (gdb) backtrace #0 0x00000000 in ?? () #1 0x6ce87396 in setup_blending () at C:/allegro/allegro-4.9.9.1/addons/primitives/prim_opengl.c:42 #2 0x6ce87591 in draw_soft_vbuff (texture=0x0, vbuff=0x3f6818, start=0, end=4, type=5) at C:/allegro/allegro-4.9.9.1/addons/primitives/prim_opengl.c:93 #3 0x6ce87945 in _al_draw_prim_opengl (texture=0x0, vbuff=0x3f6818, start=0, end=4, type=5) at C:/allegro/allegro-4.9.9.1/addons/primitives/prim_opengl.c:205 #4 0x6ce898a0 in al_draw_prim (vbuff=0x3f6818, texture=0x0, start=0, end=4, type=5) at C:/allegro/allegro-4.9.9.1/addons/primitives/primitives.c:96 #5 0x6ce8145b in al_draw_line (x1=-5, y1=-5, x2=0, y2=0, color= {r = 0.5, g = 1, b = 1, a = 1}, thickness=2) at C:/allegro/allegro-4.9.9.1/addons/primitives/high_primitives.c:116 #6 0x00401508 in _mangled_main () #7 0x69afeb68 in _WinMain (_main=0x4012e0, hInst=0x400000, hPrev=0x0, Cmd=0x241f1f "", nShow=10) at C:/allegro/allegro-4.9.9.1/src/win/wnewsys.c:136 #8 0x00401577 in WinMain@16 () #9 0x004018a1 in main () (gdb) quit
What logic would you use to go 1 to 4 then to 7?
What are you talking about, there was an Allegro 1, 2, 3, and 4. I came into the scene with 3.1 a decade ago.
I meant 1 through 4. And I came into Allegro with 3.1(0?) as well
kenmasters1976: Thanks, it's a bug. glBlendFuncSeparate is inctruduced in OpenGL 1.4.
I could make a guess, but I don't want to make an estimate like that. When we're close to bringing out RC1, you'll hear about it.
It's getting there and it shouldn't be too long now, if we can keep momentum going.
That's ok, even this tip is useful.
No compression (similar to 4.2 datafiles) on this version?
No compression (similar to 4.2 datafiles) on this version?
Eventually it'll have zip file support. As well as zlib support for compressing entire files. But right now theres no support for anything like allegro4's DATAFILEs.
I keep trying to learn the new API. Now I'm checking the examples using the IIO addon. I don't know why but all of them run incredibly slow on my machine (due to the bitmap drawing routines, it seems). I tried to change the created display on ex_bitmap and ex_bitmap_flip to use OpenGL to see how fast they run but they both crash on the call to al_draw_bitmap(). I'm using Allegro 4.9.9.1.
It seems that the problem is in the creation of display bitmaps when using OpenGL, 'cause if I change the following lines in ex_bitmap:
bitmap = al_clone_bitmap(membitmap); if (!bitmap) bitmap = membitmap;
to this, the program no longer crashes:
bitmap = membitmap;
gdb's output for both examples is almost the same:
Program received signal SIGSEGV, Segmentation fault. 0x00000000 in ?? () (gdb) bt #0 0x00000000 in ?? () #1 0x69b26d74 in draw_quad (bitmap=<incomplete type>, sx=0, sy=0, sw=320, sh=200, cx=0, cy=0, dx=0, dy=0, dw=320, dh=200, xscale=1, yscale=1, angle=0, flags=0) at C:/allegro/allegro-4.9.9.1/src/opengl/ogl_bitmap.c:118 #2 0x69b271bd in ogl_draw_bitmap (bitmap=<incomplete type>, x=0, y=0, flags=0) at C:/allegro/allegro-4.9.9.1/src/opengl/ogl_bitmap.c:202 #3 0x69ac1bd7 in al_draw_bitmap (bitmap=0x3f6c18, dx=0, dy=0, flags=0) at C:/allegro/allegro-4.9.9.1/src/bitmap_new.c:278 #4 0x00401477 in _mangled_main () #5 0x69afeb68 in _WinMain (_main=0x4012e0, hInst=0x400000, hPrev=0x0, Cmd=0x241f18 "", nShow=10) at C:/allegro/allegro-4.9.9.1/src/win/wnewsys.c:136 #6 0x00401539 in WinMain@16 () #7 0x00401881 in main () (gdb) quit
Hope it's useful to the devs.
Also, any explanation on why bitmap drawing routines are so slow on my machine?.
Thanks.
Probably trying to call glBlendFuncSeparate() when the feature is not available. Fixed in SVN already.
Just built r12036 and yes, OpenGL works great there. I tried a simplified version of ex_bitmap with a frame counter and I get around 200 fps using OpenGL (200 fps is great on my machine, I think).
Thanks.
Unfortunately, like 4.9.7, 4.9.9 doesn't build with MSVC. We might have to release a 4.9.9.1 in a few days to fix that and the demo bug (which BTW works with GCC 4.2.1 for me).
I don't know if it's the same problem, but I had a slight issue building 4.9.9.1 on Visual Studio 2008: after generating the solution/project files with CMake, nearly all of the projects failed because "dxguid.lib" could not be found -- I had to add the DirectX SDK library path to all of the projects' settings before it would build. This was after already specifying the DX SDK libs path to CMake when generating the solution, FWIW.
Also, one question: are there any plans to add the default font back into the font addon? It's really annoying having to include a font file and load it for every project, no matter how tiny. It was really nice in Allegro 4 being able to just slap in the default "font" if I just wanted text on the screen and didn't particularly care how it looked, and I'm really feeling its absence.
Also also, is there a reason that the font bitmap background color is bright, violent yellow? It's not a big deal I guess, but just looking at it hurts my eyes...
If the reason is "to hurt Allegro users' eyes," then I guess I could understand that... at least it would be a reason...
Also also, is there a reason that the font bitmap background color is bright, violent yellow? It's not a big deal I guess, but just looking at it hurts my eyes...
Its BECAUSE it hurts people's eyes that its used. Its a very uncommon color, so it was picked to be a reserved color. At least thats why it was picked for a4.
Well, true, but Magic Purple hurts a little bit less than the yellow... Any particular reason that wasn't used?
Magic Pink is also used. The Yellow is for the background around the chars, the pink is used for the char's actual bg, since it's treated as translucent.
Or at least I think thats how it went
Magic Pink is also used. The Yellow is for the background around the chars, the pink is used for the char's actual bg, since it's treated as translucent.
Or at least I think thats how it went
No. The character background uses actual transparency. I think we should use the color at 0/0 instead of yellow. Then you can use whatever you like.
And I also think we should add back a builtin bitmap font - there are cases where it is nice to have, e.g. debug messages before your truetype fonts are loaded
I have a port of A4's default font to A5. It even overloads the font vtable so it can use the same data format as A4 (ie, you can just use it without having to do anything special). The only issue is performance is atrocious, but that could be remedied by actually doing the conversion to an A5 bitmap font automatically the first time the font is used.
Or just add a function that will convert the data to a proper A5 font. Maybe that's easiest.
I just changed the addon in SVN so you can now use any color as background instead of yellow.