Allegro 4.2.0 beta is ready and has been released. This is a beta release for Allegro 4.2.0 that adds features and corrects problems with regard to the 4.0 codebase. It is
API (source) compatible with 4.0.0 on every platform, except for a few minor changes (see docs/html/api.html).
Get it from the files page on sourceforge.

Please download and test this! Report any bugs, incompatibilities, documentation inaccuracies even if they have been reported before: it is very important that these are fixed before 4.2.0 stable is released. Please provide an example programme that demonstrates the problem and if possible help to locate and fix the problem. You can reposrt bugs on the forums, but browsing through a long thread for this is combersome so it would be better to post the problem on the mailing list or the tracker.

I would also like to remind you all of the Allegro demo competition which is still open and encourage everyone to contribute a better demo game!

Some closing remarks: depending on how many problems are reported, there may be more betas after this one. Following the betas there will be at least one release candidate to iron out final problems before full release.

EDIT: I guess we will have a second beta, too many loose ends on the makefile and installation front.

Evert, the Nintendo DS and GameCube versions don't compile with the latest devkitARM (couldn't find <myds.h> and <gclib.h>). I had to go two versions back. The examples run just fine on both systems though - tested on real hardware, not just emulators. Is anyone having any problems building for the PS2, PSP or XBox?

I don't believe you (notice date).

What did I download and compile then?

Evert: make install doesn't work on MinGW (on WinXP)

My point exactly!

On a somewhat more serious but yet completely off-topic note, try not releasing things on April 1 if you can avoid it.

Anyway, good job. I'll check it out later.

Search for "mdhelper" in makefile.all and prepend "misc\" or download the beta again.

allegrogl's example exalpfnt displays broken text when using 4.2.0b

[edit:]
and again, alsa volume fix is not mentioned in changes

Whether or not this is an april fool joke I'd expect some credit for the true color font routines.

Don't be cruel now...

Spellcaster added true colour font support a looong time ago...

Including a nice function that allows you to create gradient true color fonts from mono and bitmap fonts.

You don't think that was a coincidence, do you?

My bad. I'll upload a fixed version in a few moments.

AllegroGL CVS or WIP? Could be a problem with AllegroGL rather than Allegro, but we'll need to look into it.

You're right. It is mentioned in the authors file though.

Sorry, I didn't incorporate that into the library. It is rather specific and probably best in an addon, I think...

If 23 was here the April fool's joke wouldn't have been debunked in the next post. This forum just isn't what it used to be .

About the AGL problem, it should be caused by agl itself. From agl newsletter I found

That's fast. I'm impressed!

I just meant that mentioning me at all would have been a nice thing... I mean, it's based on my True Color routines, isn't it?

Yeah, you're right. Should be added to the AUTHORS and thanks file. I'll do that.

Real-time patching!

Nice. So, is the gradient vertical? Does it support an alpha channel?

Bah, don't bother answering; I'm too excited right now. I just start asking questions... I'll find out for myself.

on here, make was fine, now make install ran mdhelper and started rebuilding everything

Err, what?

That doesn't make sense...

The directory separator shouldn't be an issue... I'm at a loss. MinGW, WinXP.

Did you test it? If you run misc/mdhelper.bat from standard Windows shell, it won't work. At least not on Windows XP. Backslash works fine, though.

I see. There are foreslashes everywhere else, though! Odd.

Is the edit you mentioned above (sorry for not noticing it first; I overlooked the slash distinction) the correct solution or a temporary work-around?

Well, I just sent the following patch to the dev list, as Evert suggested there might be a problem with using slashes under Cygwin. (My original patch had the mdhelper scripts in Allegro's root dir.) I've tested this under standard Windows shell and MSYS.

EDIT: Of course, you'll have to manually apply this, as "cvs up" hasn't given me the "misc" prefixes yet.

EDIT2:

Not to run programs, I bet.

EDIT3:

Sigh, forget about that patch. Windows 9x doesn't support "&". So, then either the mdhelper scripts must be moved to root or, hopefully, there's no problem with slashes and Cygwin.

I see. Thanks for the explanation!

CVS. It is not agl problem -- try to open demofont.dat with grabber.

Thanks, it was me, but this doesn't solve fonts problem. It would be nice to hear someone from AGL team about last 3 patches I sent though.

Ack! I see the problem. Apparently I screwed up when I added the true colour font support. I tested if it worked, but it seems that by unlucky chance I ended up testing it with mono fonts only (which basically means I didn't test it at all).
The fix, which I'm uploading in a moment, is in line 898 of allegro/src/font.c: replace if (bitmap_color_depth(bmp) == 8) with if (bitmap_color_depth(g) == 8) and it should be fine.

Damn, this has to be about the bumpiest release I've ever done

Don't worry. In order to make a giant leap, you have to bend your legs a little.

Yeah, I just made that up and it shows. It also shows that it's waay past my bedtime. Anyway, there was the 4.2 deadline to deal with, and this is still labelled 4.20b, right? Let's get to it and squash bugs!

Wow, the April's fools joke only lasted for two posts

It compiled and installed fine, here. Using MSVC 2003.

I think there is too little time between our 'private test release' and actual release. There should be at least 48 hours.

It was pressure to make it to the shelf on April 1

I think undid most of the damage I did and the current download should compile and work without major show stoppers.

Milan: I had intended to have it finished on Wednesday, but it was not to be. Since everything was fine a few days ago, things worked fine for me and people reported that it worked this morning, I decided I could afford to make the release. Clearly, the problems were with last minute fixes and things I mistested that didn't show up in a cursory run of the test programme or the examples. Should be sorted out now.

I just checked out CVS and had two errors. Apparently the makefile rules for exfont and exsyscur are missing. I just compiled them myself.

Huh? Please double-check that. The rule is there in my local tree, which is synchronized to the CVS tree. Also please check with the source archive on the download page.

Now the "relevant" stuff:

cgames@ryan allegro $ make examples/exfont
make: *** No rule to make target `examples/exfont'.  Stop.
cgames@ryan allegro $ gcc -DHAVE_CONFIG_H -I. -Iinclude -Iinclude/allegro -I./include -I./include/allegro  -I/usr/kde/3.3/include/artsc -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include   -DALLEGRO_LIB_BUILD  -mcpu=pentium -O2 -funroll-loops -ffast-math -fomit-frame-pointer -Wall -Wno-unused  -c ./examples/exfont.c -o obj/unix/exfont.o
cgames@ryan allegro $ gcc -s -Wl,--export-dynamic  -o examples/exfont obj/unix/exfont.o -Llib/unix -lalleg-4.2.0 -lalleg_unsharable -lm
cgames@ryan allegro $ 

Evert, makefile.all is still messed up. Now it's using backslash for the UNIX script, which won't work under MSYS (and neither under Cygwin, I presume).

CGamesPlay: Apparently SourceForge's public servers haven't synchronized with the dev servers yet:

Daniel: great... I probably broke the OSX port at the same time. sigh.
Either we use forward slashes or we use backslashes, in either case it's not going to work in some situations. Doing cd misc; mdhelper; cd .. would still be the best thing to do in my opinion, but as you said DOS really needs commands to be on seperate lines so we probably can't do that. In other words, I'm going to pull the mdhelper scripts from misc into the main directory and release a new beta in a few days or so. In the mean time, we can try to fix some more problems not related to the build system.

Sounds good. BTW, pretty annoying that my patch to use "cd misc; mdhelper" hasn't made it through to the mailing list yet. I sent it almost four hours ago! Of course, the patch is no good for Windows 9x, but I presume that's not the reason it's not on the list yet. Maybe we should consider looking for alternatives to Sourceforge for hosting the mailing lists? This kind of delay happens quite often, doesn't it?

Ugh, the root directory is cluttered. I would suggest moving makefiles into a subdirectory, and project files into another. The root should be clean except with the README, CHANGES, the configure and the fix scripts.

I disagree. I think the root Makefiles/build system files should be in the project root.

[edit]
If you have the Makefile in a subdirectory, you can't simply run "make". You have to run "make -f subdir/Makefile".

The configure script will create a Makefile in the root directory.

A very simple project with a configure script, windows makefile, and vcproject file has these files. Unless you disregard the above two notices, you can't get the root less cluttered than this.

cgames@arena tinparty $ ls
AUTHORS      Makefile.win    config.h       configure.in  mkinstalldirs
COPYING      NEWS            config.h.in    data          src
ChangeLog    README          config.log     depcomp       stamp-h1
INSTALL      TODO            config.status  install-sh    tinparty.dev
Makefile     aclocal.m4      config.sub     libtool       tinparty.sln
Makefile.am  autom4te.cache  configure      ltmain.sh     tinparty.vcproj
Makefile.in  config.guess    configure.bat  missing

20 of those files we because the configure script existed in the directory. You can't lower this number.

The main makefile can/should be in the project root, but I think the platform-specific makefiles can be moved elsewhere.

That is my idea. Let the fix include the subdirectory (of course, modifying all other makefiles). For everyone else it would be clean (fix ...; make). The configure output could be moved into another directory (inside obj/linux, in example).

Attached is a proposed change to the fix.bat for Windows.

It does two things:

1. Changes the --quick parameter to --crlf

2. Changes the --msvcpaths parameter to --disable-8.3

In both cases, the switches have been reversed to default to the opposite behavior. Justification:

1. No one needs to convert from LF to CR/LF if they use the ZIP distribution. The --quick parameter is a nuisance, and is auto-disabled anyway for most of the targets. Furthermore, there is no way to enable it if you are on one of those targets...

2. MSVCDir with spaces is perhaps the #1 problem newbies face when compiling Allegro for MSVC. Even if they know they need to change it, they don't know how. The --msvc-paths switch is a step in the right direction, but it needs to be the default.

It would be nice if those on Windows with MSVC could download the file and test to see if it handles the errors properly.

Update: Corrected new behavior so it only runs under the MSVC targets.

It's a beta. It will have errors. You can't go in forever having pre-beta, pre-pre-beta... eventually you have to dive in. Well done Evert for all your work so far

AFAICS, it isn't broken on OS X (this is revision 1.55 of makefile.all) - or have I got that to come...?

Pete

Hear, hear!

It would be a huge pain to run obj/linux/configure to configure. Every other package on the net has configure in the root. I also don't think the directory is cluttered, as the only things that are ever access from outside the command line are in subdirectories themselves, and those are sorted to the top.

If people are fed up with Sf's mailing lists, I can host MANY on my hosting account. It wouldn't be a problem. I'd even put up a web/download mirror if I had a good domain name to point to it (*.strangesoft.net/*.tomasu.[com|net] don't seem to fit, especially strangesoft.net)

Does 4.2 compile with gcc 2.95? My version doesn't have inttypes.h.

C:\code\allegro>make
Compiling Allegro for MinGW32, optimised. Please wait...
gcc -DALLEGRO_SRC -DALLEGRO_LIB_BUILD -Wall -Wno-unused -mcpu=i586 -O2 funroll
loops -ffast-math  -fomit-frame-pointer -I. -I./include -o obj/mingw32/alleg/all
egro.o -c src/allegro.c
In file included from include/allegro/internal/alconfig.h:64,
                 from include/allegro/base.h:40,
                 from include/allegro.h:25,
                 from src/allegro.c:23:
include/allegro/platform/astdint.h:28: inttypes.h: No such file or directory
make: *** [obj/mingw32/alleg/allegro.o] Error 1

I'd say allegro 4.2 requires GCC 3.+

I have no problems if that is the solution. However, the build process should detect that and tell you nicely if it is the case - considering that (at least most versions of) Allegro 4.1.x compiled with 2.95.

We modem users don't like upgrading unless absolutely necessary.

I'd say it's a bug.

I commented it out in the almngw32.h file and it is compiling away now...

Maybe checking for the GCC major and minor versions?

What is the exact cause of the asmcapa.h error? It can occur when just doing:

make all STATICLINK=1
make installall STATICLINK=1
make veryclean
make all

~~~~~~~

src/poly3d.c:32: obj/mingw32/asmcapa.h: No such file or directory
make[1]: *** [obj/mingw32/alleg/poly3d.o] Error 1
make[1]: Leaving directory `C:/code/allegro'
make: *** [all] Error 2

I know if I delete the folder and try from fresh it works, but there is another way? Doing a make clean and a make veryclean don't help.

I would think echo is failing when make tries to execute mmxtest and ssetest.

OK, I'll bite, is this for real? I am compiling as we speak. This better be real grumble grumble

Run "make depend".

I've got to admit, this has gotten better than the "Allegro 5 Release: Now featufing hardware-accelerated mind control"

A few of the example programs are missing from examples.txt . . . exfont.c and exsyscur.c in particular.

Great job, though, everyone!

I've found that in windowed mode, if the window doesn't gain the focus when created, the mouse doesn't work. The test program shows the problem. It doesn't gain the focus because Kerio pop-ups asking me if I want to allow run the program since it has been modified.

I'm running Windows XP SP2. I don't know for how many time this bug has been there, but Sunny Ball also had it (but now I can confirm it's an allegro bug).

The only way to terminate the program is using the tasklist.

EDIT: Sleep deprivation... You must enable language extensions in order to compile a program with allegro.

Original post:
Hmm, there's a possibly serious bug in the inline functions:

When using VC2003 to compile a pure C program it spits out errors about every single line in the file al386vc.h. It seems it does not recognise any asm directive... Does anyone know if I have to toggle an option to enable inline assembly in VC? I don't remember having to, but then I might be wrong here.

Oscar, the bug has existed for long time now.
just minimize the window, and the mouse control returns.

When compiling on Mac OSX 10.2.8 I got this error.

Compiling Allegro for MacOS X, optimised. Please wait...
make: *** No rule to make target `mach-o/arch.h', needed by `obj/macosx/alleg/pcpu.o'. Stop.

I was wondering if anyone else had gotten this error or if it had been fixed. Or what I might do to fix it.

Try running make depend.

Wow, the 4.2.0 is out and I didn't even know about that: I've been on holidays for 2 weeks and was completely offline. Now I think I have a lot to do to keep up...

Never heard about that one...

It was reported on Jonathan Harbour's forums, but I'm glad to see you can reproduce it with a different version of MacOS X. It hasn't been fixed yet because we don't know what's causing it, but Pete's on it.
Can you provide the steps you took to build and install Allegro?

AJ: do you have any idea what causes the mouse not to work if the programme starts without focus? I would like to know and possibly have this fixed.

Evert, there is another thread at the moment

http://www.allegro.cc/forums/view_thread.php?_id=476898

that seems to have found a fix for the mouse focus @createWindow time issue.

I thought it was totally normal for a window in ms windows to not take
any input(mouse), while it doesn't have the focus.

Maybe i don't know what exactly is the problem here, but isn't it just
necessary to release the mouse when the window loses focus and
reinitialize it (and setting that dinput coop level thing) when the focus
returns?

23 LEFT?!?!?!?!

the problem is, you can launch an allegro app.
then move focus to another app.
allegro will launch its window (without focus).
you dispose of the other app, leaving allegro facing you, clicking the window (which usually activates it) does nothing, no keyb input, no mouse input.

solve: minimize the allegro app, restore it... and focus is gained again.

I had this also today, using 4.1.18. It occurs if the window pops up WITHOUT focus, that is behind another application (which was my debugger). I couldn't get the focus by bringing the window to the foreground, the game would not accept any input, so I had to use the debugger to stop it.

Hmm, the documentation bug thread for 4.1.18 I started here is still there in 420...

Does the window at least change its titlebar to the foreground state
so that the window appears to be activated or does the window not
activate itself at all?

I'm asking because i've taken a look into "wwnd.c"s function
"directx_wnd_proc" and there especially examined the WM_ACTIVATE
message which (seemingly) correctly calls "wdispsw.c"s function
"sys_switch_in" which in turn should activate the mouse and keyboard
stuff.
I couldn't find anything looking odd or wrong (except the thousands of
heavily allegro specific function calls which i didn't have yet the time
to hunt after...).

Is he still working on Allegro?

Not actively, no. He hasn't actually worked on it since before 4.0 was released at any rate.
I wouldn't suggest changing that notice though... I think it's fine the way it is.

Good; That's fine, I just wanted to make sure that it was something that you're aware of...

I'm not too bad at finding documentation bugs... I can find them even when they're not there!

BTW, when did Shawn drop out? curiosity is about to kill me, I just know it

As Evert said, well before 4.0. I think it was around 2000 when he stopped really working on it a lot, but he still was around some times until 2001 or 2002 or so. And I think he also posted once on the A5 list. And he also participated in one of the speedhacks, and at that occasion posted in this forum a bit: http://www.allegro.cc/members/profile-forums.php?id=39

Shawn's last message to the AD mailinglist was on 12th of July 2002 and concerned packfile functions and filters.
I don't know if he's still subscribed to the mailinglist and just lurking a lot.

Should ask Grzegorz.. I think he has access to the subscribers list. Or maybe we have too? Must try..

[Edit:] Heh, no:

So no access for us

[Edit2:] Actually, i can view it here (guess that link should only work for evert): http://sourceforge.net/mail/admin/list_subscribers.php?func=display&list_name=alleg-developers&group_id=5665 And he is not subscribed (at least not public).

Yes, you can check the contents: lists->admin->administer lists->display subscribers list.
Looks like we have quite a few lurkers there, although I've seen some duplicate accounts as well. I didn't know Korval was subscribed too.
I don't see an obvious address belonging to Shawn though... unless it's allegro_dev or allegdev, but I don't think so.

EDIT: Ah, see you found it!

Yes, not easy to find. From the main page, it wants a password which I don't have.

allegro_dev is Vincent I think. And there's the option to subscribe invisible.. but I don't see a reason why someone would use that.

Isn't Vincent allegro_vp or something like that?

Anyway, it's possible Shawn monitors releases now and then but doesn't have time to read the list anymore. Shame, I'm sortof curious about what he has to say about 4.2 and the ideas beyond that (although, I think he knows about those)...

Ah, yes. I remembered that it has "allegro" in it

Well, I remember that quite long comments from him about Allegro 5.0.. hm, found them. I think he based that off all the Allegro 5 proposals which were around at the time, and which we still follow mostly (although we do some things different from what he suggested, apparently http://alleg.sourceforge.net/future/shawns_thoughts.txt

Basically, Shawn stopped at around 3.9.32, which was when gfoot moved the code into CVS. Judging by release dates, that was May 2000. Allegro 4.0 was released December 2001.

"diff files speak louder than a thousand emails"
I've recently passed 2000 posts here... Does that make me as valuable as someone who submitted two diff files?

Just read Shawn's talk about Allegro5 again and found something:

I hope this doesn't apply any more.

Well, yes and no. We've got AllegroGL.

[Edit:] To be more specific, yes, you probably will never want to use Allegro's 2D API to make a 3D game. But no, because apparently we already have AllegroGL, and so you can use Allegro to do the graphics with OpenGL, or even combine with Allegro's API. Allegro 4.3.x won't change anything for that, just probably integrate AllegroGL somewhat better internally.

Is that all of the message? I don't really know what he's talking about there. It almost sounds like he's talking about Allegro's 3D routines, in which case it probably wouldn't be a good idea to make them use hw acceleration, but instead let people use OpenGL directly.

If he's talking about graphics output in general.. then I don't know. In Linux, the preferred nethod for fast graphics would be OpenGL, since going through X puts in a lot of overhead. Under Windows, it'd probably be the same, but don't forget.. DirectDraw was probably still in use when Shawn wrote that. Since DX8, DirectDraw was effectively removed, and Direct3D became DirectGraphics or some such. And if you're going to have a cross-platform graphics API, it'd be best to go with OpenGL instead of OpenGL and Direct3D. Not to say we couldn't have a Direct3D or DX7-based DirectDraw driver, but I don't think the former should be a priority.

I know about AllegroGL, I've used it myself in couple of little test programs. He was talking about allegro's own 3d routines I guess

I think Shawn has changed it's views since then and won't object if allegro is going to use a OpenGL as an alternative for graphics in some later version (4.4?)

OpenGL already is an alternative in 4.0. We won't change that. (The question if AllegroGL should stay an addon or be swallowed is another. I'd tend to say it should stay an addon.)

He was refering to the 2D functionality of Allegro using OpenGL. That would be equivalent to using AllegroGL in Allegro mode, I guess.
For 3D, Shawn actually mentions AllegroGL as a good initiative for doing 3D stuff with Allegro and also for not reinventing the wheel: Allegro does many things well and 3D poorly, but that's ok because OpenGL does 3D just fine and you can easily use the two together. In other words, if there is already a widely used cross-platform library with an API that is so good that we can never hope to come close, then don't do a poor imitation of it but allow the user to use it for what it's good at. The same philosophy would apply to threads and the pthreads library.

For now, I do think that it would make sense to focus on OpenGL as the basis for the cross-platform hardware accelerated driver.
By the way, I agree with pretty much everything Shawn said in that paper.

Just what I thought when reading it.

Somehow I like this quote

I think it'd be best to swallow it, if Bob's alright with that. Setting an OpenGL mode by simply specifying a different driver is quite handy, especially with more games using hardware acceleration these days, we'd want to promote it as a cross-platform API. As well, OpenGL is really the only way to get any hardware acceleration under Linux, since DGA is deprecated (and didn't really offer acceleration beyond direct VRAM access, AFAIK).

The problem is you won't benefit much from OpenGL acceleration when doing 2D graphics. Moreover, things may be even slower.

[edit] Keeping the current API, of course.

Bullshit .

Actually when you simply want to draw a lot of non-blended non-rotated non-lit sprites on memory bitmaps then allegro compiled sprites are allmost as good as OpenGL, especially on older video cards(lots of state changes and huge amount of drawing commands sent to video card). But if you want to do any of these non-thingies then allegro 2d routines will crash and burn heavily compared to OpenGL

OpenGL provides accelerated vram->vram and masked vram->vram blits, hardware scaling, hardware rotating, hardware blending, hardware filtering...

I know, it's just a possibility. If anybody doesn't use any these things then he can use the usual allegro 2d routines and get the same speed.

I would like to see a person who has the power of OpenGL and not use it if it's made relatively simple through Allegro

I think it would be rather cool to use openGL for 2d allegro stuff IF it does provide a performace boost, (GFX_AUTODETECT_OPENGL?) ;-)

edit: but on the other hand I would love much much more to see allegro impliment threading first...

it already utilizes threading.

What would be rather cool is if Allegro could detect OpenGL by passing GFX_AUTODETECT. That would be my prime motivation for merging it with Allegro. If we decide not to do that (and I personally would prefer to, but it's not up to me) then I really want an enhanced build system that also detects and builds plugins as it finds them. Well, I want that anyway.

Hmm... my point of view on this: any threading API Allegro exposes is going to be very limited in scope and rudimentary. Allegro has a private threading API I think, but it isn't something we want to expose. There is also no need to have Allegro present a poor threading API, since a freely available and portable threading API already exists in the form of pthreads.
My point of view is that since pthreads is a good threading API, Allegro doesn't need one, just as it doesn't really need a 3D API because you can already use a good one (OpenGL) alongside Allegro instead.

Allegro should be more thread-safe than it is now internally (although that situation has actually improved quiet a bit lately), but that is a different issue.

Maybe make it GFX_AUTODETECT_OPENGL, so there is a way to tell if something else is preferred (GFX_AUTODETECT tries first non-GL, then GL), or OpenGL is preferred (GFX_AUTODETECT_OPENGL tries first OpenGL, then falls back to something else).

About threading, if we follow a modular principle, then anyone can write a threading addon, and it can be in that user-distribution which includes some addons. Having an easy way for users to get platform independent threading sure would be nice, rather than having them hunt for pthreads themselves. But it need not be in the core Allegro. At least not if we have only like, quite a few, main developers. Although, according to Shawn, there should be at least: 1 dictator, 6 core developers, 6 who are in charge of different areas (probably the same 6).

This is a bit off the subject, but I tried 3 times on 3 different days to download 4.2 by clicking on the link in the original post, and kept getting a "Couldn't read file" error. Now it occurs to me that going directly to that address w/o the allegro frame thing in front might be the problem. Downloading it now.:)

But it does not expose threading for us to use... Eh, I figure yes you can download other libraries to work with allegro for things like threading, networking, opengl, etc, but I usually have a hard time getting them to make, it's always a wild goose chase "Oh by the way for this library to build it needs these other 10 libraries," and for each dependant lib it's almost the same... I rather like how smoothe the allegro build usually is, and it would be neat if I could distribute the source code to linux/whateverOS users and say "Oh... all you need is allegro" anyway, that's just me being lazy I guess...

Speaking of allegro's build, 4.2.0 doesn't build right under DJGPP... it complains about midi.c 1537, I tried redirecting the output to a dump file but it would only dump the successful things to the dump file and the rest went to the screen so that's kind of useless, basically it said that midi_timer_frequency was undeclared, I commented the line out since I don't plan to use any of the midi functions on my graphics only test (this is on a p100 running dos 7.1)

pthreads is fairly self-contained. It doesn't take more than dowloading the procompiled libraries in Windows and installing them along with the headerfiles.
UNIX systems usually have it installed anyway.

Already fixed in CVS.

Why should it?

If Windows had done proper POSIX support (pthreads is POSIX-standard), this wouldn't be an issue. But Windows had to break standards (surprised?) and make its own. Even if pthreads weren't standard when Windows' threads were made, they still could've supplied some sort of built-in compatibility.

After working on AllegroGL for the last few years, I have to agree with Shawn. It really wasn't that much of a good idea. Large parts of AGL are overly complex and unwieldy to work around various GPU's limitations or odd behaviors.

Allegro's API also doesn't map all that well to OpenGL.

Is this also true for the new API? Wasn't that designed a bit with OpenGL in mind? Like, having full support for alpha bitmaps in the Allegro API should make it easy to just have the bitmap it in a texture and then draw a quad for rotated_scaled_tinted_alpha_blit(). Also, the new DISPLAY design will completely get rid of all the ugly screen hacks, and so on. So at least, with the new API, I hope it will be much better than with the current.

And then, of course using Allegro's API won't be as efficient as directly using OpenGL. But I don't think this should matter for what the Allegro API does (blitting and some basic graphics primitives).

This confuses me. If it's not good enough for anybody to really use, then... why have two threading systems in the same application? Why not just use pthreads for Allegro?

I-I want to hurt you...

I'll ignore the second statement because it's obviously false in almost every scenario. The first part irritates me though.

With every single game that I have ever worked on, I have felt cramped by Allegro's graphics. It's performance is horrible when it comes to any kind of blending. Which is an extremely powerful artistic tool.

This is somewhat off-topic, yes, but it leads into my question: "Why not have an OpenGL driver for Allegro?"

Could you explain how? Unless you're refering to using extra functionality of OpenGL (like the whole draw_rotated_trans_lit_mirrored_superimposed_sprite() thing, but solutions to that were voiced).

For 3-D, use AGL, OGL, D3D, or whatever you fancy. Allegro doesn't need to be a wrapper for a real library, I'm well aware of that. But I'm talking about 2-D acceleration.

If you haven't realized yet, developers are really reluctant to add extra dependencies to the base Allegro system.

I know. But duplicate code seems like such a waste.

I think that means Allegro builds upon the existing threading system (pthreads for Unix/Linux, and whatever Windows uses), for its own internal uses.

I believe that microsoft just calls it threading, anyway, in DOS it uses software interupts... it would really be desirable, IMHO, to use pthreads because then we can expect the same behavior on multiple platforms also...

Cross-platform user programs might benefit from using only pthreads, but Allegro won't. The Windows-specific part of Allegro needs to access Windows-only APIs anyway (by definition) thus we can use Windows threading primitives there. Using an emulation of pthreads for that would be pure overhead.

..and the reason to not expose the internal API also for user programs is that user programs can as well use pthreads and then have a proper API, since for them, clean design and an easy to use API is more important than the overhead.

Allegro's internal threading AOU only would be a too-small-to-be-useful subset, only the things that are needed internally (mostly if not only locks so far). But then, there's no real strong reason to not expose this API at some point.. just since pthreads can be used, that is always the better solution.

I'm not actively subscribed, but I browse the forums here, and the maillist archives on Sourceforge, every now and then.

As a matter of principle, I hate the idea of obfusticating email addresses, but I get so much spam at my old talula.demon.co.uk address that I just can't be bothered to use it any more. I have a hotmail address that I check pretty regularly, though: concat("shawn", "hargreaves", at, "hotmail.com");

Hi Shawn! I hope we're not messing up your baby :-)

Wow, Shawn himself. me gasps in awe

O_o Shawn dropping by... I was taken by surprise

Let's have a look at his profile...
Ranks #248 among active members with 73 posts at an average of 0.04 posts per day.
Latest post:

1. re: Next DX == God? - 2002-10-08 17:51

Do you lack gmail, or are you just hiding it from the public?

/me thinks this thread is gonna be offtopic now, talking about teh Shawn!

Yeah, we can give you a couple of invitations for you to subscribe them to the lists, if anything.

I don't think you can really call Allegro a baby anymore: it seems pretty much full-grown :-)

All looks good to me, anyway! It's really cool for me to see regular releases, bugfixes, etc, carrying on for so many years...

I just never bothered to set one up: Hotmail works well enough for what I use it for, and it's a pain to keep changing address all the time!

For the Allegro 5 release, I'd like to see a release party somewhere in the world.
Someone should also build the Allegro console that Grudge had plans for.

Hi, Shawn! Thanks for Allegro; it's loved by all of us. Any words of wisdom while you're here? (Or have you already left?)

hey shawn! I've never seen you before. I love allegro, thanks man.

Hello Shawn!:D

Compiled the 4.2 with the mingw 3.4.1 (? the one that has one massive installer) on win98. Everything compiled fine, but when I tried the example programs, I couldn't exit with ESC, control-alt-end, or control-alt-del. I had to alt-tab back to the desktop and do control-alt-delete to get the task manager thing to kill them.

It turns out that the examples using "if( (readkey() >> 8) == KEY_ESC)" were always getting 0 instead of a ascii value in the low byte, looking at the source, readkey calls ureadkey, which never returns anything but zero. The key_table[] and scancodes still work as they should. I didn't dig any farther than that.

Since you guys didn't mention this problem I'll assume it's win98's fault
(obsolete enough not to bother with? like dos?)

If I recall correctly, this happens because of the new keyboard driver under Windows. I guess some more tweakling is needed.

If you can, try the latest CVS, there were some problems with the keyboard fixed in it.

building 4.2.0 beta - make builds halfway then chokes on the tests:

gcc -s -Wl,--export-dynamic -o tools/textconv obj/unix/textconv.o -Llib/unix -l alleg-4.2.0 -lalleg_unsharable -lm
make: *** No rule to make target `tests/cpptest', needed by `programs'. Stop.

Is this an error on my part or do I need to edit the makefile...?

Hey Shawn! (post_count++;). And now for some serious stuff: How long do you think the beta will last? I hate having to recompile libraries over and over again.

Hey Shawn, thank you very much for putting so much effort on the library so we can use it

/me joins Elias.
It's a nice idea that you're peeking over our shoulder from time to time

You certainly shouldn't have to edit the makefile. What steps did you follow to configure Allegro?
What system are you using?
Do you have C++ support enabled?
What is your gcc version number?

I'm not Shawn, but I think I am in a better position to answer than he is anyway
There are several issues with the beta that have (hopefully) been fixed now, so expect a new beta release later this week.
If there are no issues after that and there has been some more doc/example/tools tuning, expect RC1 in a few weeks (unless real life issues intervene and it takes slightly longer). Depending on issues that pop up then, it will go to RC2 or release hopefully not too long after.
Hope for end of May, June. I hope that's a realistic target.

Well, that question wasn't directed at him, though I would love to have my question answered by such a great man Not that you aren't great, too
End of May sounds wonderful!

How long will the beta last? 'tis a good question but I'm afraid I have no clue :-)

Likewise I can't really take credit for anything along the lines of hard work, as I haven't been doing any of that at all for so many years!

I think any credit has to go firmly to all the people who are still working hard on getting new version out: great job, guys!

Thank you for Allegro, Shawn. Alot of us (including me) learned how to program by hacking around with your Allegro

Hi there Shawn!

I used Allegro in my second program I made in C/C++. The first one was HelloWorld. I guess I have to thank you for such great library, without it I probably wouldn't be half the programmer I am now.

Are you saying that you've been sitting on your arse being lazy since you left Allegro dev???

Well, not entirely :-)

I haven't done any significant open source work for a LONG time though...

You should work on that, pester your boss to release some of thier games

Huh, we wouldn't understand the source anyway.
(That's a compliment on your prowess btw..)

I would think a few are still interested in that XBox port

I think you'd be surprised how boring the source of most commercial games would be. Big, messy, lots of specialised stuff to do with odd corner cases, and by the time anything is actually shipped, so hacked about that any cool stuff lying at the core of it is buried so deep that you'd never find it without advice from the people that wrote it in the first place :-)

Also there isn't much use having loads of code for embedded platforms that you can't actually compile and run it on. PS2 rendering code is really really dull and hard to read, even for people who've worked on the PS2 for years!

Tools, though, are a different matter. A surprising amount of the time on most good games is actually spent on the editing tools, data convert process, etc, rather than the game engine itself. Much better to do the clever stuff in your level converter, where it can run overnight and have gigabytes of swapspace to chew through, then keep the gameside render code nice and simple.

I'd love to be allowed to release some of the tools I've developed over the last few years, but it's unlikely I'll ever be able to, company politics being what it is. We've made some very cool stuff, though: ask Grzegorz about it if he ever shows up here...

Hello Shawn, nice to see you here from time to time

Thanks for having started the Allegro library and I take the occasion to thank all the people who are currenlty working on it and making it better from release to release.

Great work

I think I got my new incoherent Happy Birthday message. "Hey Shawn!"

As always. But if it's just a wrapper for the XDK... (meaning it needs it, and it does), then there isn't much incentive to using it. I mean, if you've got a legit XDK, then you probably don't need Allegro (unless you want to port an Allegro game for some strange reason) and if you don't, you can't use it.

Now an OpenXDK port (assuming OpenXDK ever has worthwhile progress), would be great. But my Xbox is more of a paper-weight these days anyway, so I'm not dying for such a thing.

Icy Tower on XBox, who wants?

I assume, this is not the Grzegorz who runs the Allegro website..

I never properly ported Allegro to Xbox, and never used it for anything: just got a couple of the graphics examples running one day when I was bored.

It's not at all a sensible thing to do, because Allegro is a CPU based software bitmap API, while the Xbox is a hardware polygon processor. It's not really very smart to use the Xbox just as a 600 mhz Pentium box, ignoring all the dedicated pixel shader hardware!

Same one... I worked with him for just over a year (he wrote a huge chunk of the UI for our latest art tool), but he recently moved back to Spain...

Wow, never knew he was working with you. And he still found the time to manage the website. Btw., since Grzegorz seems to be a big Python fan - is that also the language used for such tools?

We use Python for various little throwaway utilities, but the bulk of the toolset is C++, using Qt for the UI, and a lot of STL stuff. When you're dealing with half a million tri meshes, memory efficiency and performance are really important! Plus it makes life easier if you can easily share libs between game code and tools.

Hey Shawn, really nice to see you here.

p.s. : wonder when is Shawn's birthday

August 23, 1975.

One day after Steve Terry's.

It must be my lucky day. I always wanted Shawn to post in a thread started by me. Well this is the next best thing. Cool!!! . Shawn do not forget to drop by on 23rd August.

Heheh. Pradeepto, you have a birthday fetish.

Merry Christmas, Shawn!

Well, happy every freakin holiday there is and a couple more...
Shawn, unless you've been lurking as crazy you have probably missed hundreds of holiday threads.

hi,

i've been trying out some of the examples, but i've found that two (there might be more) of them don't exit when the esc key is pressed. The following line won't work on ex3d.c:

if((readkey && 0xFF) == 27)
break;

i don't understand why this doesn't work, but then again im not an ascii expert i pressed esc and it won't exit, which is weird because those 2 lines are used in 4.0.3's version, and that works fine. this also happens with exkeys.c.

using dev-c++ 4.9.9.2 with gcc 3.4.2, running Win98.
graphics mode used was DirectDraw accel 640x480 16bpp

thanks, dthompson

The beta 1 keyboard driver has problems (as in, bugs) in Windows 98.
Beta 2 should be available shortly though.

Are you sure that these lines read EXACTLY as you posted?

Because it doesn't really make much sense to me, && ought to be &.

Like this:

if((readkey & 0xFF) == 27)
  break;

edit:
And I'm not sure if readkey is a function or not. If it is, there are the () missing.

Like this:

if((readkey() & 0xFF) == 27)
  break;

edit 2:
Yes, it is a function. So go with the second sample, ignore the first one. I'll leave it for archiving purposes

Hope that resolves the error.

thanks evert, looking forward to it

also will there be a do_circlefill function?

i'll try that new piece of code, thanks

No. There will be no new features until 4.3.0 is released.

Thread closed - beta 2 is out.