|
|
|
| Allegro 4.9.8 |
|
Peter Wang
Member #23
April 2000
|
Allegro 4.9.8 ("Lesbian House Party") is released. Quote:
Changes from 4.9.7.1 to 4.9.8 (February 2009) The main developers this time were: Thomas Fjellstrom, Trent Gamblin, General: - Lots of bug fixes. File system hooks: - Rationalised file system hook functions. Failure reasons can be retrieved - Enable large file support on 32-bit systems. - Converted the library and addons to use file system hook functions. Path functions: - Added al_path_clone(), al_path_make_canonical(), al_path_make_absolute(), - Made al_path_get_extension() not include the leading "." of the extension, - Add AL_EXENAME_PATH, AL_USER_SETTINGS_PATH, AL_SYSTEM_SETTINGS_PATH enums String routines: - Added a new, dynamically allocating UTF-8 string API. This uses bstrlib - Removed many old Unicode string functions. (Eventually they will all be Config routines: - Clarified behaviour of al_config_add_comment, al_config_set_value with Graphics: - Bug fixes on Windows and Mac OS X for resizing, switching away, setting full - Added an al_get_opengl_texture() convenience function. - Added separate alpha blending. - Added ALLEGRO_PIXEL_FORMAT_ANY. - Honour al_set_new_window_position() in X11 port. - Made the X11 port fail to set a full screen mode if the requested resolution Input: - Added a field to the mouse state struct to indicate the display the mouse is - Made DirectX enumerate all joysticks/gamepads properly by using a device - Fixed a bug in wmouse.c where y was not changed in al_set_mouse_xy. - Support ALLEGRO_EVENT_MOUSE_ENTER/LEAVE_DISPLAY events in Windows. Addons: - Added a primitives addon. - Revamp interface for kcm_audio addon to make simple cases easier. - Added native .wav support and save sample routines to acodec addon. - Added a colors addon. - Added memory file addon and example. TTF addon: - Added al_ttf_get_text_dimensions() function. - Allow specifying the font size more precisely by passing a negative font - Guess the filenames of kerning info for Type1 fonts. Documentation: - Added a new documentation system using Pandoc. Now we can generate HTML, - Added and fixed lots of documentation. Examples: - Added ex_prim, ex_mouse_focus examples. - Made ex_blend2 more comprehensive. - Updated ex_get_path example. - Made ex_ttf accept the TTF file name on the command line. Build system: - Use official CMAKE_BUILD_TYPE method of selecting which build configuration. Removals: - Remove outdated A4 tools. - Remove icodec addon. - SCons build was unmaintained and not working.
|
|
Thomas Fjellstrom
Member #476
June 2000
 |
The X port also has the monitor information api implemented, so you can query how many monitors there are and what size they are. -- |
|
Neil Walker
Member #210
April 2000
 |
Excellent, I'm definitely moving over very soon. btw, the 'string api' mentioned, is this built in or an add-on? I get the impression it's built in but I would have said it isn't core functionality required to do anything useful with Allegro (especially as most people stick with standard ascii character set and use their own anyway (e.g. stl::string) Neil. wii:0356-1384-6687-2022, kart:3308-4806-6002. XBOX:chucklepie |
|
Peter Wang
Member #23
April 2000
|
It's built in. Lots of things internally need strings, e.g. config files, path manipulation. Although we could almost get away with supporting only plain ASCII, it turns out the UTF-8 code adds up to (much) less than 5% of the total string code. We need UTF-8 support for printing strings anyway. BTW, the basic string code is really high quality (we use bstrlib, which deserves all the credit). For example, you can insert a substring of a string into itself and it will work exactly as you expect instead of blowing up. You could even (ab)use the strings as generic, dynamically growing byte arrays since they store NUL bytes just fine.
|
|
Neil Walker
Member #210
April 2000
|
ok, I see where you're going looking at the api documentation and what's an add-on and what's built in. btw, what's the difference between al_load_bitmap and the image addon al_iio_load? they both seem to load bitmaps in various formats, including standard pcx. Neil. wii:0356-1384-6687-2022, kart:3308-4806-6002. XBOX:chucklepie |
|
Thomas Fjellstrom
Member #476
June 2000
|
Quote: btw, what's the difference between al_load_bitmap and the image addon al_iio_load? they both seem to load bitmaps in various formats, including standard pcx. At one point people figured it was a good idea to keep image loading totally separate, but by now I think most/all devs are of the opinion that something like register_bitmap_file_type should be re added, so al_load_bitmap or a function like it can function again with any and all format extensions a user uses. I don't think al_load_bitmap supports ANY format currently. Infact, it seems it's commented out in src/bitmap_new.c. -- |
|
Neil Walker
Member #210
April 2000
|
I just looked (could be looking in the wrong place) at SVN and both seem to be doing their own loading. Seems daft to have multiple methods that do the same thing though in different areas. There's nothing wrong with having all image loading in an add-on library but making it mandatory? Neil. wii:0356-1384-6687-2022, kart:3308-4806-6002. XBOX:chucklepie |
|
Elias
Member #358
May 2000
|
al_iio_load likely will eventually be renamed to al_load_bitmap. -- |
|
Thomas Fjellstrom
Member #476
June 2000
|
Quote: I just looked (could be looking in the wrong place) at SVN and both seem to be doing their own loading. al_load_bitmap is #if 0'ed out. Quote: al_iio_load likely will eventually be renamed to al_load_bitmap. So iio is going to be pulled into the core then? I think it'd be better to just re add al_register_bitmap_file_type, and al_load_bitmap, and have iio register its types. Then other addons can provide more image types later on. And all allegro has in-core is al_register_bitmap_file_type and al_load_bitmap. -- |
|
Elias
Member #358
May 2000
|
I don't think it should be in the core. Just renamed. But I'm all for having an al_register_bitmap_file_type again. -- |
|
Thomas Fjellstrom
Member #476
June 2000
|
Quote: I don't think it should be in the core. Just renamed. al_iio_load hard codes the other iio loader functions -- |
|
Elias
Member #358
May 2000
|
True, but I meant just in general - someone needs to fix it first of course. It shouldn't be hard to replace the hard-coded loaders with an extensible list.. -- |
|
Todd Cope
Member #998
November 2000
 |
Build went smooth. I noticed the ex_prim example program didn't get built, though. Also, I like that the shared libs are built by default now in MinGW. |
|
SiegeLord
Member #7,827
October 2006
 |
Quote: I noticed the ex_prim example program didn't get built, though. Were there errors? It also won't build if you don't have ttf support. Was ex_ttf built for you? "For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18 |
|
Todd Cope
Member #998
November 2000
|
Quote: It also won't build if you don't have ttf support. That explains it. |
|
BigBertus
Member #2,093
March 2002
|
Looks fine. ex_mouse crashes for me, though:
Starting program: E:\prog\all498\allegro\build\examples/ex_mouse.exe
Program received signal SIGSEGV, Segmentation fault.
0x628792ab in mouse_directx_get_state (ret_state=0x22fe60)
at e:/prog/all498/allegro/src/win/wmouse.c:1048
1048 the_mouse.state.display = win_disp->is_mouse_on ? (void*)win_dis
: NULL;
(gdb) backt
#0 0x628792ab in mouse_directx_get_state (ret_state=0x22fe60)
at e:/prog/all498/allegro/src/win/wmouse.c:1048
#1 0x0040151d in _mangled_main ()
at e:/prog/all498/allegro/examples/ex_mouse.c:60
#2 0x6287942b in _WinMain (_main=0x401490, hInst=0x400000, hPrev=0x0,
Cmd=0x241f13 "", nShow=10) at e:/prog/all498/allegro/src/win/wnewsys.c:136
#3 0x0040162e in WinMain (hInst=0x400000, hPrev=0x0, Cmd=0x241f13 "",
nShow=10) at e:/prog/all498/allegro/examples/ex_mouse.c:75
#4 0x004017e8 in main ()
This is the first time I see any Alegro 4.9/5 stuff. So, I wonder if there any plans to support more blending-modes? glBlendFunc(GL_ZERO, GL_SRC_COLOR);
|
|
Thomas Fjellstrom
Member #476
June 2000
|
edit: nm -- |
|
Milan Mimica
Member #3,877
September 2003
 |
Florian Bueren said:
at e:/prog/all498/allegro/src/win/wmouse.c:1048
I think the whole input mechanism on Windows is still broken. I've tried to fix it but I failed at even understanding it. This specific error could be fixed by replacing the offending line with
-- |
|
Don Freeman
Member #5,110
October 2004
 |
The mouse_cursors example program does not update the cursor, unless you leave the window and come back and the ex_mouse just dies on mine...actually just keeps running in the background and I have to kill it. Running Windows Server 2008. I love the primitives addon! That is friggin sweet with the textured and lit shapes! Would be easy to do some real time lighting with those!:D Will there be support for the chm docs later? I kind of liked those...;) Also, the demo program compiles fine...just dies on run though. I've moved the executable around to see if it was just missing the data files, but still just dies. Something for the newer guys later: If you don't have the DirectX SDK listed on the very top of the include and library directories option in Visual Studio...you WILL get errors such as undefined reference to _IID_DirectInput8 and such. Took me a minute to figure out, but was confusing at first. Also, will there be an updated grabber? Maybe with the Ma5king GUI lib and maybe some LUA sprinkled in for fun?!? Hint hint...::) Great job guys...Looks pretty awesome! I think I'll start to port over now before I get too tangled up with the old Allegro API in my current project.8-) Edit: -- |
|
Elias
Member #358
May 2000
|
Quote:
So, I wonder if there any plans to support more blending-modes? glBlendFunc(GL_ZERO, GL_SRC_COLOR); No, that's what OpenGL is for. It would be rather pointless for us to provide all the OpenGL blending modes, and then maybe also support for compiling fragment shaders. OTOH, if someone feels like making an addon for it... -- |
|
BigBertus
Member #2,093
March 2002
|
Quote: No, that's what OpenGL is for. It would be rather pointless for us to provide all the OpenGL blending modes, and then maybe also support for compiling fragment shaders. OTOH, if someone feels like making an addon for it...
Well, I thought it'd be cool to be able to use them with Direct3D ... indirectly, without using Direct3D |
|
Neil Walker
Member #210
April 2000
|
Probably repeating the above, but what if you are in directx mode or auto mode and you don't know what mode you are in? you don't provide access functions to dx in the same way as opengl, or do you? (not that I know directx at all...) Neil. wii:0356-1384-6687-2022, kart:3308-4806-6002. XBOX:chucklepie |
|
Trent Gamblin
Member #261
April 2000
 |
There are access function for directx al_d3d_get_device(ALLEGRO_DISPLAY *display); al_d3d_get_system_texture(ALLEGRO_BITMAP *bitmap); al_d3d_get_video_texture(ALLEGRO_BITMAP *bitmap); ...
|
|
Elias
Member #358
May 2000
|
They are rather useless though, as they only work under Windows. -- |
|
Thomas Fjellstrom
Member #476
June 2000
|
Quote: They are rather useless though, as they only work under Windows. Watch out, trentg might label you as a Stallman clone if you say anything that might even remotely put windows, or developing windows specific code in a bad light. -- |
|
|
|
Not that useful for a nice extensible library.
