Allegro 4.9.8 ("Lesbian House Party") is released.

The X port also has the monitor information api implemented, so you can query how many monitors there are and what size they are.

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)

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.

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.

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.

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?

al_iio_load likely will eventually be renamed to al_load_bitmap.

al_load_bitmap is #if 0'ed out.

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.

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.

al_iio_load hard codes the other iio loader functions Not that useful for a nice extensible library.

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..

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.

Were there errors? It also won't build if you don't have ttf support. Was ex_ttf built for you?

That explains it.

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?
For example something like

glBlendFunc(GL_ZERO, GL_SRC_COLOR);

edit: nm

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
the_mouse.state.display = win_disp ? (win_disp->is_mouse_on ? (void*)win_disp : NULL) : NULL;
but that's not supposed to happen in a well written code and there's probably other places where the same problem can occur.

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:
Love the title: Allegro 4.9.8 ("Lesbian House Party");D Can't wait to see what the actual version 5 will be code named!8-) "Picolo's Curse" or such...:o

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
All those people with bad/broken/... GL drivers... who would potentially play 2D-games with cool blending effects

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...)

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);
...

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.

I just checked this release, code and docs, great work!
the A5 WIP looks promising.

Let's tease Elias: I think it's normal, for some D3D functions, to only work under windows :-)

Heh. I just want that most A5 programs written under Windows will run equally under Linux and OSX. If there is a reason to have Windows-specific features, then I don't have anything against that. Just experience with A4 shows that people used Windows specific stuff all the time for no good reason. So with A5, we should not encourage the same by advertising any platform specific functions. The same goes the other way around, Linux or OSX specific functions should not be normally used. Unless it makes sense of course, if you make a high quality game it may be worth the time to do things differently for platforms, so it's good if Allegro 5 allows doing so.

OpenGL is a different matter. We simply can't provide all the same functionality OpenGL (or DirectX) provide in Allegro, even though it all is useful for games. It has been done in projects like Ogre or Wine maybe, but those are huge compared to Allegro. And OpenGL already is cross-platform and usually works under Windows, so I don't see a big problem to use it whenever the Allegro API isn't enough.

I agree 100%. I also think that by extension, this implies that requiring OpenGL for some (common?) tasks isn't quite "platform-neutral" enough, despite OpenGL working fine in Windows. It feels a bit like saying "but you can run X11 applications on a Mac too, so we don't need a native OS X port, the X11 port will do fine" (the X11 port doesn't work on OS X, by the way, it would be good if it did though).
I don't think we should go out of our way to wrap all of OpenGL, but some wrapping (blending?) might be in order, with the added bonus that it'd also work with D3D (don't bother with software for the time being). Now, I have a feeling this has been discussed before, and it may not be as easy as I'm making it out to be.

The problem is with Windows users may (will) want to use D3D for whatever reason - which means they'll have to write platform specific code. If we can wrap that, so much the better.

Indeed. Which is why I'd be in favor of supporting more blending modes, and things like shaders and whatnot. Make it so even fairly complex Allegro 5 games can use completely platform neutral code, including no direct GL.

4.9.8 binaries are on allegro5.org.

I'm also in favor of it from a user view, I just don't think it's realistic to expect we will get developers to implement it. Also, if we add support for shaders, there wouldn't be much need for the fixed blending modes - we would just have some example shaders doing what the fixed ones do. Not sure about the memory functions - if Mesa supports shaders, we likely could require it, or another free library, if one exists.

So, any volunteers for adding support for pixel shaders?

A portable pixel shader library is a huge undertaking. They already exist. Why not just let the user choose one of the existing ones?

Ah! Now that is a wholly different issue. We probably could use an extra pair of hands there. I currently lack the knowledge it would take to help out with something like that (as in, I've never done anything similar with OpenGL).

Ok.

Hehe... these days I think of something else when I see "mesa". Interesting how that works (no, I'm sure that one does not support shaders of any kind).

That would also work. Some kind of simple interface between said libs, and allegro (so you don't end up having to call d3d or gl specific functions yourself) would be nice though.

I really only gave "shaders" as an example of something we may want to support in a platform neutral way. I'm sick and tired, so I can't recall anything else

Perhaps I'm getting mixed up with how the display flags work, I saw:

ALLEGRO_OPENGL - require the driver to provide an initialized opengl context after returning successfully
ALLEGRO_DIRECT3D - require the driver to do rendering with Direct3D and provide a Direct3D device

And figured that to get hardware acceleration (or however the library implements the functions) you had to specify one of them (or both for a random choice) and got software everything if you didn't.

There is no software driver, at least not yet. On windows, direct3d is the default, on other systems, opengl is the default, and the only.

And this is exactly why we need something to offer people using the default setup.

Shader add-on based on one of said libs? I'm for it.

Nope. The point is to get hardware acceleration by default.

Well, if they need more functionality than Allegro can provide, they have to use either DirectX or OpenGL (or another library) - nothing we can do about it. But OpenGL is the best choice since it works (is supposed to work) everywhere already.

Best get a move on then, I was searching for some stuff on opengl performance and near the top of the search list was this, dates just a few months ago at gamedev.net. Be warned, it'll have you spitting blood

I would say that's the way to go. I've got too many projects on the go right now to take this one though.

The "macro hack" reminds me, what about removing END_OF_MAIN from Allegro 5? I sent a patch to the mailing list to do so some time ago, but got no conclusive comments. That patch doesn't change any functionality, just instead of having

int main()
{
}
END_OF_MAIN()

you would then have:

int allegro_main()
{
}

This was originally suggested by Peter Hull, and I think it is much less hackish, no macros at all involved.

How many months? This is relevant, because A5 has matured considerably over the past few months.

Not really. It probably is becoming time to spread "A5" news a bit beyond these boards though.

Sure. Which is why we need an extra pair of hands.
Now that SiegeLord is done with his primitives addon, maybe he can do this one? Preferably before the next WIP?

I guess. Let's just be very clear that it can't be that the user could write "int main()" without doing anything special on other platforms and have it work.
Although, we could stick an (optional) "#define main allegro_main" in there.
Personally I'll gladly settle for something that lets me write plain "int main(void|int, char**)" without doing anything special, while at the same time allowing the user to disable any "main hijacking" transparently.
In short:
Have main/allegro_main "just work" without tweaking on Windows and *nix (ie, maybe have #define allegro_main main).
Have a "real" main living in "liballegromain.a" on OS X that gets linked in, call "allegro_main" in user code, which the user secretly created by "#define main allegro_main". This can be easily disabled by not linking "liballegromain.a" and not doing the "#define".
This way, the user can (normally) write either "main" or "allegro_main" and have either of those work reliably, but still disable it easily if they need to get rid of it (when using Allegro along some other library that needs to have access to main).
That's my personal preference though.
There was something else I wanted to say, but I forget. I need to rush for morning coffee meeting anyway.

I'm thinking into installing Allegro 4.9.8 and give it a try (that announcement in the main page really got me).

5. http://www.gamedev.net/community/forums/topic.asp?topic_id=509165

October then, at the beginning of the current more regular release schedule.
As I said, it's been maturing a lot since then (obviously most of the work was done before that time).

I wouldn't worry about it. GD has been full of misinformation about Allegro ever since version 4 was released. In library-vs-library threads, somebody always makes the claim that it's an "old DOS blitting library" as to imply that it's useless to the person asking the question—even when it's obvious that the person doesn't even have the skills to reach the limits of QBASIC.

Would anyone be willing to try my binaries to see if you have trouble with the audio? The ex_saw works fine and I get sound, but the demo doesn't load and such. It seems something is amiss with the kcm_audio addon, but I don't know...Everything else seems to be fine.

Libs
Error from demo:

/*
Keyboard driver installed.
Error loading sample (null)
Failed to load demo\data\sfx\big_explosion.ogg
Error loading resources.
Error in initialization.
*/

I checked...the sample is there and plays fine in media player classic.
This is my cmake cache.
Is openAL required, even under Windows? If so, that might be the problem. I am not using it as you can see above in the cmake cache. I was under the impression that it would default to DirectSound under Windows.::)

As always,
Thanks guys!8-)

I believe the demo requires the ogg library. OpenAL is not needed under Windows.

I am building it. Feedback soon !

This would be ideal for Allegro#'s API, as I can't make a partial class across two assemblies, so instead of the elegant Bitmap.Load(), you get the ugly ImageIO.LoadBitmap().

I'm able to reconcile saving bitmaps with extension methods, though, so you at least get the myBitmap.Save() either way.

Just a thought on allegro#

Why not make it xna ready? as in give an 'allegro' style front-end but what you write at the back end is xna rather than directx.

Because what would be written at the back end would be XNA rather than DirectX.

Because the back end is neither. It dispatches straight into the Allegro DLL you provide. (or build as part of Allegro#'s build process) All Allegro# does is provide a .NET-style API and manage the ugly bits, of which there are many.

It would be cool to have an Allegro+XNA wrapper library, but that's another project entirely. (actually, one which I have sort of started on the side...) Besides, I've been careful so far to keep it as cross-platform as C# can be and XNA would destroy that.

I'm sure Shawn H. would appreciate the irony, though.

Was Just wondering What does XNA smell like ? I'm asking cause i really don't wanna get too close to anything near Redmond;D

Ah, I thought this was a port not a re-bind. But I guess a port of xna to look like allegro would be about as popular as Microsoft J#

Then again, I'd try it...

Shawn Hargreaves is involved with it, so it's probably not too bad.

[edit: and don't ask who that is, or you may be considered unworthy of being in these forums.. ]

Ogg works under windows, it's something in your configuration. If you're using MinGW, you can get fully built libraries with all dependencies from allegro5.org. If you want MSVC binaries I'll make time to make some.

That's strange. I've looked at the source and I can't figure how it could print (null) there and the actual filename later. You should debug it.

I just uploaded binaries for msvc. Direct link:

click me

"Elias: Shawn Hargreaves is involved with it, so it's probably not too bad."

Aha !... Traitor ! (just kiddin )

The only first-party API I know that has been designed from the ground up for a modern, high-level language. So, pretty nice.

Thanks Trent! I'll try these out. I figured it has to be something with my setup, but I can't find it...:-/

Ok...now I just get an exception. I'll try to manually compile the demo (with a new project) to see if that helps. I'd use ming, but I'm now sure how you setup the environment, like the include and lib directories. Any help in that regard? If so, I'll just use ming to make my windows versions.::)

That is what I thought as well. I actually did do a debug on it before...it gives a couple of threads that return 1 instead of 0, but they have just funny names like ~2acda and such...don't know for sure what thread is dying.::)

Thanks for those helping.8-)

RelWithDebInfo is probably not suitable for debugging. Try running cmake with -DCMAKE_BUILD_TYPE=Debug option.

Thanks...Ok, now this is driving me nuts! I had to copy my directx stuff into my compilers lib and include directories. Ok, so far so good. deleted my allegro directory, started fresh with cmake. Still good to go. Compile everything, no errors. Run the demo, I've got sound...then I realize WTF?!? No video! So I think, hummmm, lets try one of the examples, a simple example. I fire up the ex_bitmap example. No video! WTF?! The ex_membmp works, as do the openGL stuff. Could this just be a video driver issue? I am using NVidia on this box, I'll boot up the lappy and try with my ATI later. The way the programs with directx seem to run, it appears to be a driver issue, and not something with allegro.:-/

These are the examples that do not give video, or are buggy (Just for reference if someone else has the same or similar issues):
ex_bitmap.exe - black screen
ex_bitmap_target.exe - blue screen (not the bsod)
ex_blend.exe - gray screen
ex_d3d.exe - black screen
ex_expose.exe - black screen with (looks like) inlaid gray/silver border
ex_fs_resize.exe - orange/brown screen first, then with switch I get a picture of mysha with a purplish color with black lines running up and down
ex_joystick_events.exe - cream color screen
ex_keyboard_focus.exe - red screen
ex_lockbitmap.exe - black screen
ex_mouse.exe - dies
ex_mouse_events.exe - cream color screen
ex_ttf.exe - white screen
ex_winfull.exe - dies (or at least does nothing)
ex_bitmap_flip.exe - black screen
ex_color.exe - dies
ex_disable_screensaver.exe - black screen
ex_font.exe - black screen
ex_icon.exe - black screen, but icon does change
ex_keyboard_events.exe - white screen
ex_lines.exe - gray screen
ex_lockscreen.exe - black fading to white from top left to lower right
ex_mouse_cursor.exe - gray screen
ex_mouse_focus.exe - black when offscreen with mouse, red when on screen with mouse
ex_noframe.exe - black screen (no border)
ex_prim.exe - black screen
ex_resize.exe - white screen
ex_scale.exe - black screen

Here are the Visual Studio 9 2008 Standard Version binaries and includes for others to play with.::)

Has anyone tried the Windows Server 2003 Standard? That is what I was using this for. I remember I had issues with an older game saying it can't find some directx files...even though dxdiag finds them just fine. I figured it was just the game...it was old. If so, then please let me know of any issues you may have had. Thanks.

Edit:
Ok. It is definitely a driver issue. It works perfectly on my laptop. I think it has something to do with Windows Server 2003 and DirectX. It just doesn't work right...or at least not on my box. I guess I'll have to figure something else out for my other box...:-/

Great job guys!
Thanks8-)

Seems to be a D3D vs OpenGL issue.

You need two monitors for that (one will do full screen, the other will show a window).

That's what they are supposed to do.

On that topic...

• the examples really need to be organized into sub folders

• the ex_* prefix on all of them is annoying

• some of them are kind of lame... e.g., output to a console even though it is never seen in MSVC

• the demo is huge

Not our fault MSVC is lame

Question:
Has anyone else here had DirectX troubles in Windows Server 2003?

Comments:

Lame or not, I can get a LOT more work done with it than anything on Linux. KDevelop likes to act pretty retarded a lot. There have been times when I had to delete the project files just to get it to do something correctly...and it was NOT my fault. Eclipse takes FOREVER to load, and CodeBlocks has changed way to much for me to use anymore without really investing time in it. I would rather just deal with the issues of Visual Studio...at least I know what most of them are.:P

To Evert:
Yeah, I was more just commenting on the ones jacked up by my drivers on my other box. They indeed work correctly with good drivers.;D

Also, I hate how cmake does not pick up my include and lib environment variables correctly. I have all of the required libs in those variables...the only thing I should have to do is select what version of those libs to use...like truetype and such. I have rarely seen it delete the def files, so that I would have to replace it from a backup. That is annoying. Only happened twice though that I remember.

Plus, if we are using the IDE (Visual Studio and others I would imagine) then why hard code the directories in the program's build options? We would most likely have those directories saved in our IDE's search path anyway. If nothing else, an option would be nice.:-/

Edit:
Fitting that during the Lesbian House Party release, I get post number 69!;D8-)

Of course none of that has to do with it not showing console output anywhere.

The ex_ prefixes stay, so it is completely obvious what is being discussed. I don't want users reporting bugs in "the mouse example" -- which one?

Some of the examples are lame and unobvious what they do.

Well neither did yours if you want to be technical! You can compile the examples to use the console just like in Linux.:P If the console window disappears before you get to read the message...then that is a problem with Windows, but not a fatal flaw. You could easily add a wait for key event so the user has time to read it before it disappears.8-)

Also, asking again...will there be support for chm help files later???? (Keeps fingers crossed)

I know nothing about chm files. If you can find some way to produce them from the HTML files we could do that.

Just a matter of documenting them, I'd imagine.

I know the 4.2/4.3 versions of Allegro had support for chm files, I guess from the latex format? So, if that is the case...it should be easy to do maybe? I could probably do it by hand, but I've never done any work with the hhc command line tools.

Edit:
Also, we need a getting started section in the docs. Like how to get a basic program up and running with the new API. I know the examples are there...but something like this should be in the docs. It shouldn't really take up THAT much room.::) I've gotten so used to the old API...I have to forget what I knew about Allegro and start over. Are we gonna get an updated grabber utility later? It would be nice to see it work with Masking lib (from the Monday project...aka Miran) and be able to throw down some oggs and pngs into a datafile.8-)

No, allegro 4 has its own documentation format and converter, it directly supported chm's source format.

Speaking of the documentation, perhaps we can use something like this to improve the usability of the docs? We'd just need to coax pandoc to produce the function name -> url pairings and then add a bit of code to make that selection actually work.

Cool! As you know, I was looking for something like that. It's even got a compatible licence.

Pandoc doesn't need to do anything. We can produce function -> URL pairings with a little script. If I do that, could you give me the code to make it do something? (I haven't actually checked the code yet, maybe it's not hard.)

EDIT: this page describes converting DocBook to CHM. Pandoc can generate DocBook so that could be a way to go. There seems to be some tools around to convert other formats to CHM, so other intermediate formats may also be viable: OpenDocument, RTF, Texinfo.

I am bored with the "Warning: .drectve `/DEFAULTLIB:"uuid.lib" /DEFAULTLIB:"uuid.lib" ' unrecognized" message between each target.

Also, no example is currently working there. I am checking my memory because I feel like my ddr is going mad

Get better DirectX libraries for Mingw. The ones from Trent's site are a bit broken. Where to get any others I wouldn't know though

Can you include some of the examples then I'll see whether the fault happens on mine?

Also, as a side issue your attachment name is too large so it truncates the name, including the .zip extension.

If you're getting those defaultlib warnings, you're compiling static with MinGW. If you're compiling static with MinGW, it means you must have gcc version 4.2.1 or greater or none of the examples will work.

It seems to work, just was playing with a test site. I'll make a Python script to generate pairings from html_refs and try to wire into the cmake build.

I don't know all that much javascript, I mostly just wanted to highlight that site for someone who knew more... but I can see if I can learn enough javascript to do something with that today.

EDIT: Nevermind, Elias already put it in. Check it out at http://docs.liballeg.org.

Excellent!

I noticed a few issues:

- if you type "color", the popup is a little bit too narrow, so that the scrollbar overlaps with the text. Actually the popup keeps changing width, which is bit annoying.

- if the search box is near bottom of the page, the popup will be cut off. Can we do something about that?

- keyboard repeats don't work. Again, I don't know if this is something that can be fixed.

- maybe get rid of the underlines, which look ugly with underscores.

I guess all we can do is change the "Public"and "Styles" parameters at the top here, or we find someone who understands the Javascript and modifies it:

https://alleg.svn.sourceforge.net/svnroot/alleg/allegro/branches/4.9/docs/src/autosuggest.js

I need some help. I'm trying to build 4.9.8, but it stops at this point:

I know you have answered a lot of questions about the build process before, so I'm sorry for this.

Use this: http://trent.gamblin.ca/dx/dx9mgw.zip

Thanks, I didn't it came from that (didn't search too)

Ok, as I am now sure of the quality of my memory (a full night benchmark has given no negative result) I will upgrade my gcc and give it a new try. I was wanting to try STATIC, but I didn't remember to check my gcc version.

I didn't have the problem before cause I was only trying the dynamic library version.

Edit:
Some links that some of you can like:
Gcc for Windows (gcw) is yet another attempt to port gcc to Win32 platform. The major difference from MinGw and Cygwin is maximum possible acceptance of Microsoft Visual C++ source code and intended binary compatibility with Microsoft Visual C++.

MinGW: A native Windows port of the GNU Compiler Collection (GCC), with freely distributable import libraries and header files for building native Windows applications; includes extensions to the MSVC runtime to support C99 functionality.

The TDM-GCC builds are unofficial replacements for the official MinGW releases of GCC binaries. TDM-GCC was previously recommended for experimentation purposes only, but constant use in day-to-day development and a total download count of over 40,000 have proven the TDM-GCC releases to be at least as usable as the most recent official MinGW GCC release.

I am currently trying the TDM's build.

Quick question...I know there is a way to create a window without a border, but can we create a window that is not just a square...like a circle or other shape, using the alpha channel or "magic pink" color for transparency? And if so, does the OS only give the app notifications over these "visible" portions? It would be an awesome thing to have.8-)

Edit:
Also, here is my new logo for this version:
http://www.allegro.cc/files/attachment/597761

Patches are welcome. I definitely would like to see support for having the alpha-channel of the framebuffer work - likely it just needs a flag somewhere. I don't have compositing enabled in my X11, so I can't test it, but once I upgrade X11 I'll add this. About system events, we could have a function to ignore a mouse click and ask the window manager to pass it on, shouldn't be hard.

Thanks Matthew, I'm downloading it now.

Ok...I've updated the manual to reflect this current release.::)

Thanks for that link Matthew.

I'll take a look to see how complicated that will actually be later. I just had to spend half my day yesterday getting my box back together for development. Stupid Windows Server 2003 somehow just decided to say fuck my DirectX stuff. Oh well...I finally got Windows Server 2008 working on this box. Yeah!:D I can't wait to experiment with that compiz stuff in Linux...that looks fucking sweet!:o

Here is an updated package with all of the required stuff for proper Visual Studio 9 2008 development of Allegro 4.9.8 projects. I've tested this all and everything works just fine. There is a dll folder in that archive, just put those in windows/system32 or wherever you are running said project and everything will be good to go. Enjoy.8-)

I was having this error while building:

So, while waiting for the dx9mgw.zip download provided by Matthew Leverton to finish, I had this idea and went and replaced D3D9b_SDK_VERSION with D3D_SDK_VERSION (which is defined in the default DirectX headers of MinGW), and now everything builds succesfully (with the exception of the ex_d3d.cpp example).

What nasty side affects can arise from building it this way?. I'm only building the basic lib (no addons right now). Can it affect when building the addons?.

Also, is it normal that the examples doesn't recover the focus when you click inside the window?. Instead, I have to click on the title bar.

I don't know if that is intended or not...but it happens for me as well (Windows Server 2008 (Vista)).

I'm not sure what else was changed in the dx9mgw.zip, but if you are having errors still without trying it...I would rebuild using the zip specified.

Sorry, I didn't see your post.:o I have no issues with the attachment name in firefox. Try this instead. Also, I've attached the examples here.

I see wmouse.c got a fix for al_set_mouse_xy, but when will you fix it in xmousenu.c?
I kinda need it now.

"We accept patches."

At the very least, we also accept bug reports in SF, so at least we don't forget about this and fix it ourselves when we get the chance to.

No worries, I fixed it myself.
First time I fix something in the allegro source.
It's not a patch, but since I only changed the one function you can just paste over the old version.

Or you can give me svn commit access, username Trezker on sourceforge.

You forgot to emit an event.

X takes care of that for me.

If you do use this function, however, it generates events just as if the user had instantaneously moved the pointer from one position to another.

Here's my test code. If I remove that if, it gets really jerky.

A diff would be appreciated in the future, even when just posting here. It makes it a lot easier to tell whats been changed.

if you have a regular svn checkout, svn can give you a valid diff. svn diff should be enough to give a diff of any changes.

Alright, I've tinkered a bit more. I noticed some flaws.
The mouse was jerking a little bit, so I added the event trent wanted.
I think it helps a bit, but it's still jerking a bit when I move the mouse slow.

Anyway, this time I attach a diff.

I think its jerking because you're injecting an event AND X is injecting an event. I really don't think thats the way to go about doing things. Are you sure you need to inject an event into allegro's queue? If all else fails, maybe theres a way to tell X to move the cursor without injecting its own event? That way you can and all should be well.

Well, I think it jerked more when I didn't inject the event.
But I'm not sure, the difference is not quite clear.

It could also have something to do with my computer. It's jerking the mouse all the time, even when I'm not running allegro. Maybe I should reboot.

Do you have an example which shows the jerking? A short example program demonstrating al_set_mouse_xy would be quite useful (and maybe would help find the cause of the problem)...

[Edit:] Btw., I'm really amazed how well the "we accept patches" seems to work these days

It only works for certain kinds of people in a certain mood, with certain small problems

I get that if flash, firefox, or konqueror are somehow flooding X with commands. Even if it looks like theres very little CPU use, sometimes it causes jerky mouse input and especially jerky window resizing and whatnot. Try closing some apps.

Why do programs using the new API not get the focus unless their title bars are clicked (or of course brought into focus with alt-tab)?:o Is this an issue only under Windows? I have not tried under Linux yet.

Another issue with the mouse...when changing the cursor, it does not take effect unless the cursor leaves the window and then returns.:o WTF? Is this a Windows only issue? Any workaround for that????

I've also noticed that pressing the caps lock key in the keyboard example crashes under the 4.9.9 version...don't know what has changed. Seems something with the keyboard code has changed, because other programs compiled with it crash when different keys are pressed.:-/

Some annoyances: the al_draw_arc and al_draw_ellipse (and others I imagine) piss me off to no end! They ask for position variables, but they do not start there, at least not drawing...I want to be able to use: al_draw_arc(10,10,0,3.14,c) and get an arc starting AT 10,10 (the drawing...not the center point). I am trying to use it for drawing rounded rectangles, but it is hard...because I have to account for the center point, the radius, etc. and sometimes they seem off by one pixel because of rounding errors.:-/

Any since we are on that subject, why not a rounded rect function? I am willing to add one if you would like.::) I am debating on how to handle the 'roundness' of the corners though. Any suggestions on that? I would ultimately like to have the function parameter such as:

al_draw_rounded_rect(float sx, float sy, float w, float h, ALLEGRO_COLOR c, float roundness, int thickness = 0 );

Check the primitives addon, if its not there, ask SiegeLord about it, its his baby.

I actually have an arc function that draws unfilled arcs using Allegro or OpenGL that takes a starting and ending position, and fills in the gaps. At least I did, I may not have it anymore

We didn't think people would want their windows focussed, and if they did, they'd give them focus themselves.
It made sense at the time.

Probably, but this is the first I've heard of it. There was a problem with the OS X port that required a click in the window after it was resized before it would take keyboard input again, that's the only thing I've seen that comes close to what you describe (but that was due to a buggy implementation of window resizing and has been fixed).

Again, possibly. There's a quirk in Windows where the cursor doesn't update unless you move the mouse (which usually results in warping the mouse to its present location), but this doesn't sound like the same problem.

A fix would be better, I think.

Congratulations. You just volunteered to do it.

Probably the length of the circle arc in radians: pi/2 for a quarter circle, 0 for a single pixel (a corner that isn't rounded). You'll need to calculate the centre and radius of the circle and the intersection point between the circle and the rectangle.

So I change it, and then people start complaining that the position variables do not refer to the center of the arc. Either way you do it, it's going to annoy half of the people using that function.

No harm in adding one, I guess. Although it takes like 6 lines to do it in the current API.

EDIT: Well, a little bit more... heh. This motivates me to alter how the al_calculate_* functions work.

It's not in the 4.9.8/4.9.9 versions. I don't care to make it.:D Any suggestions on the roundness aspect? I think it should be somewhere between a normal rect and could degrade down to an ellipse.::) How do I make the allegro.def file needed to compile the 4.9.9 version as a dll? I can use dumpbin to get all of the mangled function names, but...have you ever tried to manually edit the output of that?!:o I started, but gave up after the first 1500 lines.:-/ I am just going to use 4.9.8 until that little issue gets straighten out.::)

Edit:
SiegeLord: Yeah...I see what you mean. I am just being a whinny ass today.;D Thanks for all of your hard work everyone!:D

Roundness will be the radius of the circle bevel. This is how it's always done.

So basically, just attach four arcs to four lines...and voila, a rounded rect is born.8-) Of course, one would have to take the line thickness into account.

Yeah, more or less. A little bit more work for the filled rounded rectangle, but the idea is the same.

I'll see what I can come up with then. I'll post it here later and someone could possibly add it to the primitives later if they so desire.8-)

I made a minimal test program for al_set_mouse_xy and tested with and without sending my own event.

With my event, I get the jump to the target coordinates, immediately followed by an event with dx = 0, dy = 0. This is probably because I do the_mouse.state.x = x; the_mouse.state.y = y; So the event from X doesn't change the position.

Without my event, there's only the 0, 0 event.

If I remove the_mouse.state.x = x; the_mouse.state.y = y; I get the correct event from X. But my "complex" program gets totally chaotic, the cursor jumps away from the center of the screen instead of to he center as it should.
On a closer inspection it appears to be making a feedback loop and it doesn't help to ignore events where the mouse position equals the set position.

Here's my small test program.

Ok, as promised. Here is the function I came up with (the al_draw_arc does NOT seem to take neg values correctly for the second angle like it says in the docs::)): You can simple skip the thickness value, as it will default to 0 (hairline).

///////////////////////////////////////////////////////////////////////////////
// Prototype:
void al_draw_rounded_rect( float x, float y, float w, float h, float roundness,
                           ALLEGRO_COLOR c,
         int thickness = 0 );
///////////////////////////////////////////////////////////////////////////////

This could use some optimization, but meh...it works.:P

Docs are for the SVN version where that bug was fixed . Thanks though... will put it in someday soon.

Still have to work out a filled rounded rect...maybe using circles instead of arcs. That should work.8-)

I didn't check your patch, but check how A4 does it. After warping we have to ignore some events.

BTW, how are you accounting for multiple windows? Again, I didn't check the patch. I assume it's relative to the current display.

Whats the 3D api going to look like? It would be nice to have some cool 3D fluff in the 2D api. Like maybe a simple z setting during blit, or being able to tilt/wobble the screen.

OpenGL.

Some nice candy would be beneficial in primarily two ways: The games made would actually use them and it would be great for the PR of Allegro itself.

It wouldn't be out of place in an addon. We accept patches

Here is the al_draw_filled_rounded_rect function:

void al_draw_filled_rounded_rect( float x, float y, float w, float h, float r,
                                  ALLEGRO_COLOR c, int t )
{
  ///////////////////////////////////////////////////////////////////////////
  al_draw_filled_rectangle(x+r,y,(x+w)-r,(y+h),c);
  al_draw_filled_rectangle(x,y+r,(x+w),(y+h)-r,c);
  al_draw_filled_circle(x+r,y+r,r,c);                 // top left
  al_draw_filled_circle((x+w)-r,y+r,r,c);             // top right
  al_draw_filled_circle(x+r,(y+h)-r,r,c);             // bottom left
  al_draw_filled_circle((x+w)-r,(y+h)-r,r,c);         // bottom right
  ///////////////////////////////////////////////////////////////////////////
}
///////////////////////////////////////////////////////////////////////////////

Again, needs to be optimized like the unfilled version, but it works.8-)

Edit:
Is there no easy way to set the text color besides using the blender? If not, is this not slow????

Just make a function like this:

void text_color(float r, float g, float b) {
    al_set_blender(ALLEGRO_ALPHA, ALLEGRO_INVERSE_ALPHA,
        al_map_rgb_f(r, g, b));
}

And then in the rest of your code do this:

text_color(1, 0, 0);
al_font_textprintf(font, x, y, "This is red.");
text_color(0, 1, 0);
al_font_textprintf(font, x, y, "This is green.");

Might be worth adding such a function to the font addon actually - but I'm not sure.

How so? I'd say it's a much faster method than the real-time pixel-by-pixel recoloring used in A4...

You have to reset the blender though...I found that out after setting the font color that way, my images got 'colorized' as well.:-/

That is, until you happen to turn on blending . Well, no worries, I'll implement it later on.

It already exists in an unimplemented state, so, basically like it looks like now

Or did you not notice that al_set_vbuff_pos takes x, y and z?

Yeah...I noticed that with the filled version. I guess it is because of the overlap of the rectangles on the circles. I could probably fix it...but if you will implement it later on, I'll just wait.::) If you make a version, do you plan to keep the same layout and drawing style (The rounded rect will NOT exceed a normal rect)? That would be awesome if so, this way I could just switch my code later to use yours without having to modify that layout of all of my drawings and such.:D

I was thinking that if the bevel radius is 0, then the output is identical to al_draw_{filled_}rectangle, so I guess, yes I am planning on that.

The titlebar thing is a bug, I swear it worked with 4.9.8 (haven't checked again) but even though there were no changes to the windows window handling code, you can't click on the client area to focus a window. I've looked at it a bit but haven't found the problem.

I was thinking of using the al_calculate_arc and using a ALLEGRO_VBUFFER to draw the shape with al_draw_prim...maybe even be able to pass in a texture to it as well, since al_draw_prim allows a texture...but hey, whatever works for you.::)

Is there any built in anti-aliasing functions for the primitives? That would be awesome as well!:D

Trent: No, it is broken in the 4.9.8 version. That is what I am using right now. I can't get a dynamic version of 4.9.9 to compile for visual studio yet...

That's probably how it'll be done.

No high level primitive routines have texture support for one simple reason, there is no unique way to do it. Do you want a rotated/scaled texture or whatnot? For circles, do you want a radial texture mapping, or a rectangular one? Etc etc. I just figured that if you want textures, you go into the source, copy the implementation, and set the uv coordinates to your liking yourself.

There is multi-sampling support in A4.9.8 that supposedly antialiases the entire screen. So far it looked like crud to me, but that's probably because my card is bad.

Do you know the name of it, or is it on by default? I do not see it in the docs.:-/

The program that uses it is called ex_multisample. Maybe I am mistaken and it was added after 4.9.8...

I was thinking about looking into the place where mouse axes events are processed, it seems likely that's where something gets fucked up.

As for multiple displays, I'm not really thinking about that yet. I'm just using current display. With the API being as it is now, I think you can only support jumping within one display. Though I'm not sure. I'll have a look at it. I think people might want to be able to jump between displays, even if it's a stretch I'll bet in the future some guy will be wondering about it.

But for the time being, I think you could use the patch I attached back there. At least you can move the mouse at all, even if it's buggy and might not work on multiple displays.

At some point someone WILL make a game that can span monitors. Having the mouse move between displays is rather important, regardless of where the actual allegro Display is placed. Hopefully the underlying window manager will do most of the work.

Actually, I think it makes sense if x and y in al_set_mouse_xy() refer to the current display. I don't think there's any other sane way for the function to behave, so supporting multiple displays shouldn't be hard at all if that function works correctly.
Or do I misunderstand what you mean by "As for multiple displays, I'm not really thinking about that yet. I'm just using current display."?

Well, the x warp function takes a parameter of a type called window, but the docs don't link to this mysterious type and I don't feel like looking for it.
That's why I'm using the relative position warp, and that will not work with jumping between displays. Or maybe it can be done, but I would still need to figure out where to get some additional variables...

The code in allegro 4.2 that skips some events was really crazy. It made no sense to me. But I'm trying to skip some events after a warp now to see if I can make that work. So far it's not looking good...

On another note, I'd like to know how to skip building the examples when I build allegro.

In windowed mode I don't think we can even try to say that windows pretend to be beside each other... any XWarp wouldn't move the cursor directly to the next window unless it was directly beside it.

That is, the only time moving the mouse should go from one display to another is if the displays are right next to each other. Anything else would be complicated to implement

I fixed it, the jerky thing and event skipping.

Now, it skips up to one motion event after warp.
I also added an if to avoid sending 0,0 delta events which also occur after a warp.

The multi display issue is still open. I only have one display sitting on my desk so I don't feel like taking care of that feature.

So, it's all smooth now. The attached diff is made against the same revision as the other one.

EDIT: Hmm, I got two attachments, I thought I deleted the first one...
Well the bigger one is the right one. It has the if that skips the 0,0 delta event.

I currently use 4.9.8 and it doesn't work correctly here too.
When I start a allegro window I can only give it focus by clicking on the title.

Once I alt tabbed AWAY from the allegro window I can give focus by clicking inside the window. Regardless how it looses the focus. alt tabing away once fixes the problem for the lifespan of the window.

Maybe this helps to track down the bug.

I am confused as to how that can happen at all. The WM shouldn't be affected by Allegro doing anything.. Any window should get focus when you click on the title bar (not nesesarily the client area, that could be ignored). Though I suppose if our win32 event handling handles NC (non client) area clicks, and handles that case wrong, it might do it, but why the hell would we handle NC area events at all?

Did you misunderstand my post or did anyone else say that clikcing on the title doesn't work?

For me clikcing on the title always works.
But clicking inside the window only gives focus after I alt tabbed away from the allegro window.

I'm not sure now. I thought someone did. No it seems I'm just not reading properly nm.

Are these problems with Allegro windows showing up specifically in one version of Windows? Or does it show up in all of them?

It must have something to do with the code that was added to detect mouse enter/leave events. I'll try to look at it today.

[edit]
It should be fixed in SVN now.

Can you try the attached patch? It adds a modified version of your patch as well as your example to current SVN. Just recompile then run ex_mouse_warp to test.

I removed all the mouse skipping stuff as it makes no difference here - I assume it will have to be added back. However, we should describe in more detail how exactly it behaves "weird" without the skipping, and maybe we can figure out which X11 versions show that behavior and only do the skipping for those.

Your patch works actually. I'm not getting any jerking.

Ah, very nice. Committed it to SVN, thanks a lot.

I get random crashes when using:

ALLEGRO_MOUSE_STATE msestate;
al_get_mouse_state(&msestate);

The program dies, and then I debug and it breaks on al_get_mouse_state, saying that msestate is invalid. I've looked at the examples and I am just doing the same thing as they are. I don't get it.??? It doesn't happen every time, and that is what is frustrating. I think that something in the mouse code is screwy...but I'm not sure. I am using Windows Server 2008 (Vista) if that helps anyone. I can run it a few times before I get the crash...sometimes it just crashes right away. Actually, the ex_mouse example does the same thing. Maybe there is something wrong with the mouse driver code on windows?!:o

I've attached the full project (code, data, and a Windows executable). This is just a learning exercise for the new API before I use it to work on my WarLand project.8-)

Edit: (This is under the 4.9.8 API)

Edit 2: I think I've fixed the issue. Here is the other post. Maybe someone could fix this in the source somewhere?!:D
Spoke to soon.:'(

I'm experiencing problems with the mouse (seemingly) in ex_expose. It is failing assertions that mouse_directx_installed != 0, even though the mouse has been installed. Kind of seems like a memory bug.

With the changes made by Milan Mimica here, my mouse problems (that I've noticed anyway) are gone...that AND it fixes the issue where windows didn't get the focus unless their title bars where clicked.:D

Nah, Trent fixed that.

set_mouse_xy is borked.
I just did a new fresh checkout from svn and the big jumpy behaviour was back.

I attach a diff of ex_warp_mouse.
When I hold the right mouse button and move around at moderate speeds the pointer jumps away hundreds of pixels.

EDIT:
I added a check that compares the next event from x with the event that should come.
X does send a motion event right after the warp. But it doesn't match.

EDIT2:
However, when I warp on click I do get an event right away with correct values.
Also, the warp on move is correct sometimes. But when it's wrong I can't figure out where those values could come from.

Well, it makes sense - we were using XWarpPointer in relative mode. Assume the mouse is at x=200 and you want to move it to x=100 on each movement event. Now the user twice moves it to the right for one pixel. The event queue will contain the two events:

mouse event(x=201,dx=1), mouse event(x=202,dx=1)

In response to those two events, ex_warp_mouse sends these commands to the X11 server:

XWarpPointer(-101), XWarpPointer(-102)

So because the user moved the mouse two pixel to the right, we asked X11 to move the pointer 203 pixel to the left. Of course instead of getting to x=100 as intended, we were overshooting that and moved out of the window

The attached patch fixes it here.

Yeah, it's working.

Actually, depending on what you want to use this for, it's still not perfect. If you look at the mouse positions relative to (width/2, height/2), they won't always correspond to the user movement of the mouse. If you do something like make a game with infinite mouse movement but call al_set_mouse_xy(width/2, height/2), it will again have jerky movement. I proposed a solution for it on the mailing list.

Heh, so now we're discussing this in two places

I think the public could voice their opinion in the matter.

The current solution in the mailing list is a special event when the mouse is set with a warp. So you get ALLEGRO_EVENT_MOUSE_AXES and ALLEGRO_EVENT_MOUSE_WARPED.

I don't think I like this. I'd rather see the ALLEGRO_EVENT_MOUSE_AXES event have a flag event.mouse.warped you can check.

Yes, so don't cross-post.

Anyway, I'll just quote the reply I sent in the mailing list:

There is no functional difference to checking a flag, except that the code is cleaner because we don't need to hack in a flag to indicate special behavior. Another way to think of this is that an event that needs a flag to indicate that it's different from other events of the same name should be a different event.

I wasn't the one moving this discussion over to the mailing list. You guys are the ones cross posting.

So, different event it is.

Does the demo in SVN work for anybody currently? At least here it seems that it is failing due to sound problems:

I boiled the problem down to line 144 in Misc.cpp: It seems that calling

voice = al_create_voice(44100, ALLEGRO_AUDIO_DEPTH_INT16, ALLEGRO_CHANNEL_CONF_2);

fails, because voice is NULL afterwards.
Is this a known problem, or just a configuration mistake of mine?

What is al_install_audio(ALLEGRO_AUDIO_DRIVER_AUTODETECT) returning?

You need to force a different sound driver via allegro.cfg (see this file in the 4.9 root folder for the options and format). The 'autodetection' of audio driver is at fault here, I think. It crashes similarly to me, but as soon as I force it to something other than the default (I don't remember the details) it works fine.

How do you calculate how many points you will need for al_calculate_arc?

Edit:
I was started to find there is not flood fill?!:o That has GOT to be one of the most basic pieces of a solid primitives addon. I use a lot of the low level drawing stuff to make my own GUI and other graphics. I'm sure I could get away with using al_draw_prim, but a flood fill would be SO much easier...at least for the lazy ones like me.::)

Look at high_primitives.c, it shows how to estimate the number of points in an arc/circle etc.

Flood fill is a tough one... there is no way that it can be made fast... the hardware 'accelerated' version of it would be unbearably slow. Honestly, I'd say it'd better be placed in an 'image editing' addon which can have that and blur and whatnot in it. Any people have other opinions?

Hi!

Matthew, al_install_sound() returns 0 - both for ALSA and OSS.
SiegeLord, thanks for your advice - changing the sound driver to OSS worked. However, seeing that the ALSA driver fails is a bit disturbing.

By the way, great demo! Who made it?

That would be me. The space ship (I think) was drawn by Micah Crow (who is awol) and the music I got from some royalty free music site.

It would be nice if he could draw asteroids in the same style as well. They look kinda flat, and the ship has this nice 3d effect.

Maybe someone else could do it.

Trent: You make Allegro sound like a military camp...

That was... random.

It's what it is...

I'm still waiting for the hidden..."Welcome to Allegro..."

Is there a way to get the HWND for the current app using the current API...as in, not having to call FindWindow(className,windowName); ? I was thinking of adding some special Windows code like in the old API, any suggestions as to how I should go about that? Probably just look at the old API and see how it exposes the Windows API on a Windows system. I know some people didn't want special OS calls to be part of the new API, but sometimes it's needed.

I've been meaning to extract that sample and put it in the example data directory. Good that you remind me.

I don't know enough about the Windows port to say one way or the other whether this is possible or not, although I suppose it must be (come to think of it, look at the file picker addon in SVN, I think it has code for doing that). What is it that you want to do exactly? There may be a way to do what you want to do without having to use Windows-specific functions, or maybe it is something for which we should provide a platform neutral interface.

As with breaking the API between different releases, I'm in the "no unless" camp on this. If at all possible, a platform-neutral wrapper is the way to go for me.

I am using GetForegroundWindow() for now. It returns the HWND for the window which currently has input focus.

I'm with Evert. If what you actually want can be done in a platform neutral way we should do that before extending the api for OS specific stuff like this.

Much like theres a File Dialog addon now.

Mainly I ask, because I was looking to add the clipboard functions (Windows for now, others could provide a Linux/Mac version)...but I need to do some OS specific stuff. I do not plan to expose any Windows specific code ideally, but I need to gain that access in my functions.

An HWND and a Window or Display or whatever X11 uses are pretty different. There is a way to get the HWND of a display if you're using direct3d, but it would be better if it was, if not cross platform, cross driver (meaning available with opengl in windows too).

Sure, ok. Definitely have a look at the file selector addon, it needs to do something similar on Windows, I think.

So what?
You have some data structure that represents a window and that you pass around but never actually need to do anything with yourself, right? The only thing you care about is that the functions you want to pass it to know what to do with it.
Anyway, not to get into that discussion: if you need to write platform specific code (eg, in an addon), you need to write platform specific code. If we can wrap it in a platform neutral package, so much the better.

The ALLEGRO_DISPLAY essentially already is that data structure.

HWND *al_get_display_hwnd(ALLEGRO_DISPLAY *d);

Something like that for each platform is all that is needed. (Same thing A4 does.)

This inspired the military camp comment:

If he was saying what I think he was saying, he was thinking something more like:

void *al_get_display_oshandle(ALLEGRO_DISPLAY *);

One function covers all platforms, you just have to cast.

But what I was thinking was more along the lines that it shouldn't be a public function. If such a funtion is needed, look at what it is needed for first, and try to support THAT in a cross platform manner.

I'd make it return an ALLEGRO_OS_DISPLAY_HANDLE or something like that, but yes, that's the idea.

Oh, absolutely.
I was thinking along the lines of a cross-platform wrapper that you can pass the cross-platform OS handle to, but I realised after posting about it that there's no need for something like that: Allegro internally knows what the OS handle on the current display is, so there would never be a good reason to specify it manually in that case.

At first, I was thinking of having it part of the system driver. Then there could be an added function to call, such as al_get_display_handle( ALLEGRO_SYSTEM_DRIVER *driver ). Maybe that is not the correct way to go, but that was my main idea.

Yeah...that was my thinking. I'm not sure how Linux or Mac handles clipboard data, but my goal was to expose something like this to the end user:

ALLEGRO_CLIPBOARD_DATA * al_get_clipboard_data( ALLEGRO_CLIPBOARD_DATA_TYPE
                                                type );
bool al_set_clipboard_data( ALLEGRO_CLIPBOARD_DATA *data,
                            ALLEGRO_CLIPBOARD_DATA_TYPE type );

Obviously, I would plan this out better, but that is the jest of my idea. All of the cross platform stuff would ideally be handled internally by the library.

Also, I was thinking that maybe we could have OS specific stuff exposed by including the OS specific headers, like the old API. If you need/want Windows specific stuff for some obscure reason, then just include <allegro5/winalleg.h> or such. I don't really want to limit the functionality of the library just for the sake of argument...especially if that functionality is indeed there in the lib, just not exposed to the user (as in the case of the HWND). In the end, we have to make the distinction that the end user should 'do the right thing'.

Edit:
On the note of a clipboard addon, what would you like to see in it? I was thinking of text, graphics, sound, and user defined types. There are a shit ton of different types in Windows, but those are the most basic. Any suggestions/ideas?::)

Now I'm just confused. What good is ALLEGRO_OS_DISPLAY_HANDLE? What functions would receive it? It never would be an Allegro function. It would always be a platform dependent function.

What are you suggesting?

#ifdef WINDOWS
#define ALLEGRO_OS_DISPLAY_HANDLE HWND
#else
#define ALLEGRO_OS_DISPLAY_HANDLE FOO
#endif

ALLEGRO_OS_DISPLAY_HANDLE *hndl = al_get_display_oshandle();
ShowWindow(hndl, SW_RESTORE);

or

struct ALLEGRO_OS_DISPLAY_HANDLE {
}

ALLEGRO_OS_DISPLAY_HANDLE hndl = al_get_display_oshandle();
ShowWindow(hndl.hwnd, SW_RESTORE);

or

typedef void * ALLEGRO_OS_DISPLAY_HANDLE;

ALLEGRO_OS_DISPLAY_HANDLE hndl = al_get_display_oshandle();
ShowWindow(hndl, SW_RESTORE);

I just don't see any point to introducing a special Allegro type when we know the only purpose is for it to be used with a platform dependent function.

That doesn't work, because there can be multiple displays.

That's also what I would prefer. As Matthew said, something like ALLEGRO_OS_DISPLAY_HANDLE would be entirely useless.

I think a function to just retrieve and set text would be a good start, once we have that people can start implementing it for different platforms.

I also can see the usefulness of pictures. But I think it should be separate pair of functions. The pictures would be converted to/from Allegro format.

All other types likely should be OS specific functions - trying to wrap too much into a cross-platform function will only make it hard to use.

If it was an Allegro type, I would do as you posted:

#ifdef WINDOWS
#define ALLEGRO_OS_DISPLAY_HANDLE HWND
#else
#define ALLEGRO_OS_DISPLAY_HANDLE FOO
#endif
ALLEGRO_OS_DISPLAY_HANDLE *hndl = al_get_display_oshandle()

That would be more readable than casting everywhere.

Using the following, you would still have to cast somewhere in the code:

typedef void * ALLEGRO_OS_DISPLAY_HANDLE;

ALLEGRO_OS_DISPLAY_HANDLE hndl = al_get_display_oshandle()
ShowWindow((HWND)hndl, SW_RESTORE);

I'm not sure about the other systems, do they all have the same kind of functionality...a 'handle' to a window?!???

Edit:
You beat me...;D

I don't think it will be too hard to add sound and graphics in a cross platform way. It shouldn't make a difference to the end user, the way I was going to expose the functionality. I had planned to have functions to convert an ALLEGRO_CLIPBOARD_DATA object to the various Allegro types...ALLEGRO_BITMAP and ALLEGRO_SAMPLE so ideally, that should not be a big deal to the user.

You surprise me. You just failed basic reading. Just re-read what I said above:

So no, there would never be any point in having a function like that.

Check allegro5/addons/native_dialog/win_dialog.c. It does the following, which I suppose from the code and comments to be similar to what you need:

[...]
#include "allegro5/platform/aintwin.h"
[...]
void al_show_native_file_dialog(ALLEGRO_NATIVE_FILE_DIALOG *fd)
{
   OPENFILENAME ofn;
   ALLEGRO_DISPLAY_WIN *display;
[...]
   display = (ALLEGRO_DISPLAY_WIN*)al_get_current_display();
   ofn.hwndOwner = display->window;

This is the proper way to do it (at the moment): if you need the platform specific information, you include the header that defines the platform-specific data structures (which are derived from Allegro's public platform-neutral data structures), cast it and then access the fields you need.

Aside and note to self: the OS X port doesn't allow you to do the same for its displays at the moment because the ALLEGRO_DISPLAY_OSX_WIN struct, which should maybe lose the _WIN, is in a different file (src/macosx/osxgl.m). That should possibly change.

EDIT: I forgot to say:

Don't make things too complicated (personally, I don't like seeing yet-another-datatype). I would just add functions to grab text/bitmap/sample from the clipboard and to place them there.

Well, I don't know. I'd like if I can just do:

al_set_clipboard_text("abc");
ALLEGRO_USTR *text = al_get_clipboard_text();

Will be hard enough getting that implemented for the 3 platforms.

For pictures, I'd like something like:

al_set_clipboard_bitmap(screenshot);

Of course, if there really is use for going the way of ALLEGRO_CLIPBOARD_DATA, I won't oppose it. Can you give an example where I could do something with that I couldn't with the simple functions? I only see how it would be useful in Windows-specific code - but for that just make a Windows-specific function.

Your post was confusing to me, because the first half plainly says you want the al_get_display_oshandle() function and the second half says you do not want some function referenced by pronouns and quotes with no citations.

But it seems we all agree now that neither al_get_display_oshandle() nor a special data type is needed.

I think the only reason would be to support custom data formats.. but then we could do this instead:

al_set_clipboard_data(char *type, void *data);

where type is a mime type or something similar (I think most systems use mime types for clipboard data, but I'm not 100% sure about that).

edit:

Indeed, I didn't think far enough to realize the same thing. Any code that wants to access the handles, can do so if they grab the OS specific display type.

Thanks Evert! That looks good.8-)

The main reason for adding the ALLEGRO_CLIPBOARD_DATA type was for easier cross platform programming....a layer of abstraction that the end user would not have to know about or deal with. Should there maybe be an ALLEGRO_CLIPBOARD object that has a vtable that would point to the OS specific functions for the different ops, such as loading/saving text/graphics?

The type isn't needed. Just a set of functions that can set or get ALLEGRO types.

You can implement it that way, but its nothing you need to export.

Ok...that sounds cool with me. <heads to evil lair to begin work.>8-)

I agree with Elias here. I think a few functions like this are all we need:

al_set_clipboard_text(char *text);
al_set_clipboard_bitmap(ALLEGRO_BITMAP *bmp);
al_set_clipboard_data(char *type, void *data);

That would work well with Windows, at least. (Custom clipboard types are just specified by strings that you register in the registry.)

Ah. Well, no, that was only meant as an explanation of what I meant before.

Yes.

I'd follow the approach of the file selector addon: just have different files for each platform and compile the proper one in. You really only need a vtable if you think you might have different drivers for the same functionality on one platform.

Thats what I was thinking.

For X11, if we want to support the classic middle-click selection, we'll have to tap into Allegro's X11 events handler:

http://tronche.com/gui/x/xlib/events/client-communication/selection.html

It works in a kinda stupid way, whenever you paste something, X11 sends an event to the window with the current selection asking it for the data.

Apparently in KDE and Gnome there also is a normal, non-stupid clipboard with persistent data (so the selection won't be gone when you close the window like with the X11 one) - haven't found out yet how to access it though. Maybe we only should support the normal clipboard and not the middle-click one.. but from example code I've seen so far both are entangled somehow :/

I have an early version for getting text, in Windows anyway.

a5_clipboard.h:

a5_clipboard_win.c:

Do you think I should add an option to limit the amount of text that is returned?
I still haven't figured how to get unicode text (like from character map) to show up correctly...even using ALLEGRO_USTR. Any suggestions?

Windows unicode is likely UCS-2, or UTF-16 (whatever), allegro deals in UTF-8, you may have to use uconvert (if peter kept it around) to convert to utf8.

Arbitrary limits are evil, so no, you shouldn't. But who is responsible for freeing the pointer returned by al_get_clipboard_text? If it's a static buffer that changes the next time GetClipboardData/GlobalLock are called, you should strdup it.

It should work AFAIK if you use a char * pointing to a UTF8 encoded string. Doesn't that work for you? Have you checked the encoding?

Ok...I'll look at it later. Thanks for the comments.:D

Demo not working for me (VS 2009). It stops when trying to load the sound file "big_explosion.ogg", although the file is in the proper place.

Do you have OGG vorbis support compiled in? You need libogg and libvorbis for that.

I don't think so. Is it a prerequisite for Allegro 5? or is it only for the demo?

Its a prerequisite for the demo, and any sound playing example you want to be able to load ogg.

Ok, libogg and libvorbis downloaded, compiled and installed.

What now? how do I add support for it for the demo? or is it automatic?

EDIT:

The code that fails is this one:

/* Function: al_load_sample
 */
ALLEGRO_SAMPLE *al_load_sample(const char *filename)
{
   const char *ext;

   ASSERT(filename);

   ext = strrchr(filename, '.');
   if (ext == NULL)
      return NULL;

The filename is "c:\dev\allegro-4.9.8\demo\data\sfx\big_explosion.ogg".

The function strrchr returns null, and therefore the sample can not be loaded.

You re ran cmake for allegro, and re compiled it right?

It can't return NULL in that case, it'll find the last . and return that. You must be mistaken on what is actually going on there.

Nope. I am about to do that again.

EDIT:

Bleh, I built libvorbis but cmake can't find it, although I added the correct paths...it's late, and I am tired of the the command line already. The command line sucks. No demo for me...

Which Addons doesn't require any external libraries?. Right now I have only built the core Allegro lib and the Primitives addon, but I'm thinking into building the rest.

I was wondering if I could get some people to test this for me. I've noticed different behavior on two different machines, both with the same OS (Windows Server 2008). I am guessing this is a driver issue, maybe ATI Vs. nVidia . The main problem is that my ATI driver (at least in my mind so far) is causing this to fail when loading the Terrain.png file. I can not seem to get debug info from it either. The debugger says that there are no symbols for it...allegro was compiled with debug options as well as the program, so I assume that it is a failure in one of the other modules, perhaps something from DirectX. I can switch the Terrain.png to be a grid of 10x10 tiles and it works. It is almost as if it is running out of memory, but that can't be...I have over a gig in each machine and plenty of free memory. I am thinking it has something to do with texture memory and the way the two (nVidia and ATI) handle that. I am just trying to figure what the main deal is here. I've also noticed that on my ATI system, the drawing functions look different as well. The drawing functions look fine in other programs I've made between both systems, so that is weird. It is the exact same program, but the al_draw_rounded_rect looks different on both systems. It looks correct on my nVidia card, but the rounded rects look slightly scewed. If you decide to test this for me, please let me know what system (OS and version) and what kind of video card type and video memory your system has. Note: this was tested with Allegro-4.9.8, so that is why I am posting it here. I want to see if this is a bug with Allegro, or something with ATI or nVidia drivers.

Here is the Visual Studio 2008 project files, source code, and data needed.
Here is the 10x10 tile grid file that worked on the ATI system. If you would, please rename the original Terrain.png and put this to data/gfx/terrain.png in the programs search path. Please test with both versions and let me know if one worked and not the other, or if both worked/failed for you as well.

For those who do test it, spacebar pops up the terrain to 'select' (enter tile brush selection mode) and esc exits the program. When in 'select' mode, arrow keys move the selection cursor around, enter selects a tile brush, and esc exits that mode.

Thanks guys.:-*

Edit:
Here is a compiled version for Windows (using Visual Studio 2008).

The standard no screen shot, no download...so here ya go:
Main screen:
http://www.allegro.cc/files/attachment/598032
Tile brush select mode:
http://www.allegro.cc/files/attachment/598033

Um, yea, I'll test when I feel like downloading the dlls

Anyone?! I want to see if this is something with the way the new API deals with hardware calls, or if it is a driver issue...and if it can be fixed. Maybe this could be addressed in the FAQ or other area.::)

Can you statically link everything or point me in the direction of the allegro dlls? I've got the depencies from here http://www.allegro.cc/forums/thread/599504/798701#target

But they only include non-allegro stuff.

allegro5.org has binaries.

What's the... purpose of http://allegro5.org ?
The FAQ doesn't seem to be working, and there's no about page.
What do you get for creating an account?

Right now its purpose is news on Allegro 5 and Binaries. We (trent and I) don't really have much news to post...

Later on it will probably just be turned into an alias for liballeg.org once allegro 5 is released.

The FAQ seems to be working fine though. Its just that there are no questions

Trent registered liballeg.org and allegro5.org.

I think it would be best if we made those the official addresses. "alleg.sf.net" ties us to SF (probably Allegro's web hosting will never change to anything else - but still no reason to have it as official address). Right now the "official" address is still talula.something.really.long.nobody.can.remember - which is kinda stupid.

Yeah I like allegro5.org, has a good solid feel to it.
The design of it right now really looks like a place where you should be able to find all the resources you need with just one or two clicks. But I don't think you do quite yet, basically because some things people need haven't been written yet.

The program crashes on my machine and I don't have some of the needed addons installed to try and build it myself on MinGW. Sorry.

If anyone wants to work on the FAQ or any other areas of allegro5.org let me know. I can handle the binary releases.

Right I've got 28 dlls in my folder now! I remember the days when you could ship an exe and a dat

Anyway, as soon as I start the program I get an exception. Here is my directory folder in case I've missed something:

a5_acodec-4.9.8.dll
a5_color-4.9.8.dll
a5_font-4.9.8.dll
a5_iio-4.9.8.dll
a5_memfile-4.9.8.dll
a5_primitives-4.9.8.dll
a5_ttf-4.9.8.dll
allegro-4.9.8.dll
freetype6.dll
jpeg62.dll
kcm_audio-4.9.8.dll
libFLAC++.dll
libFLAC.dll
libpng12.dll
librle3.dll
libsndfile-1.dll
MapEditorEnhanced.exe
ogg.dll
ogg_d.dll
tmp.txt
vorbis.dll
vorbisenc.dll
vorbisenc_d.dll
vorbisfile.dll
vorbisfile_d.dll
vorbis_d.dll
zlib1.dll

I wasn't able to run the program either.

Ok...thanks to those willing to try. What are your video cards (ATI,nVidia,Intel)? Also, if you would, can you try with this file? Just place it in the data/gfx folder. It's weird, but it works for my other box that didn't work before.:o

Edit:
The executable was created using Visual Studio 2008, so you may need the run times for that. If you already have Visual Studio 2008, then I guess you don't have to worry.::)

Thanks again to all those willing to give it a go.:D

Also, here are the libs/dlls/includes I used for development.::)

There could be something funky with your build of Allegro that doesn't work with the allegro5.org dlls. IIRC, not having the runtime actually should come up with an error along those lines.

When I tested, it was with a nVidia card. 6600GT AGP (It's a PCI Express card retro fitted to AGP actually, including GDDR3 ram, which no current AGP has now...)

Yeah, it SHOULD give you an error like 'This program has used the c-runtime incorrectly' or something.

I don't think so, but I guess it could be possible. I've included the development stuff above.

I wonder if it has something to do with integrated cards. My laptop is of course integrated, but my desktop is not. The desktop works fine.::) It does work with the new version of Terrain.png I posted above, so please see if it does for you as well.:D

It didn't work with the files in the binary pack at allegro5.org, but it worked with the ones in your attachment.

It worked (painfully slow on my machine) with the 10x10 terrain grid, but not with the original one. I have a crappy old integrated Intel graphics card.

I have VS2008 and I run vista so I don't need the additional MS files. Are you checking all the return values on startup?

You mentioned gfx folder? All you sent in the original was a single exe. Do you need the gfx and if so, why aren't you checking the files exist?

btw, shouldn't this strain of messages be moved to another thread?

That is strange...I'll have to take a look at THAT one. The only thing I could imagine is they use a different version of libpng or something.

How fast is your computer ken? I'd like to know what kind of hit to my user base to expect using the new API.::)

Edit:

They are in the original post, but it includes the source and project files as well. I just included the bin for those not wanting to compile it.::)

Yeah, maybe this should be in a new thread...;D

I have a pretty old machine. It's a Celeron CPU @ 1.70 GHz with an Intel 82845G/GL Graphics Controller.

ok, i've downloaded your source. You aren't checking a single return value so I have no idea where it is failing.

I am checking for an invalid image loaded using al_iio_load in LoadTiledImage:

unsigned int LoadTiledImage( const char *fileName, unsigned int borderSize,
           unsigned int tileWidth, unsigned int tileHeight,
           ImageVector &dest )
{
//  ...
  ALLEGRO_BITMAP *tmp = al_iio_load(fileName);
  if ( !tmp )
    return 0;

The actual line of code that dies is al_iio_load. It doesn't even get to the if (!tmp) line. I've checked the all of the return values during my debug session before posting my question here. I've even commented out parts of the program to narrow the offending section down. My conclusion was the call to al_iio_load. As soon as that function is called...blammo. It dies using the original Terrain.png file. What dies is not anything that is from Allegro or my program directly. It seems to be coming from the graphics driver dll functions, probably in a DirectX call somewhere. I can only get assembly output for that section as well...even with debug options on for Allegro and my program. If no one else is interested in this, then please just disregard my question(s) in this regard. I am going to assume that this is something of an issue with various graphics card drivers and will program around this. The developers do not seem to be that interested anyway....:-/ I'll try to keep an eye on future issues others may have and see if this is something in common with others, or just something of a fluke.???