Allegro 4.1.18 WIP has been released! Get it from the Allegro SoureForge
page at [url http://sourceforge.net/projects/alleg/].

This release is a Work-In-Progress release 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).

If all goes as planned, this is the final release in the Allegro 4.1 WIP series and the final release before 4.2.0 RC1. So please go and test everything in this release, try to break it and find bugs that need to be fixed!
There are known issues with Allegro on multi-processor machines that are not yet fixed in this version, but must be for final 4.2.

EDIT: anyone think I should post this on Jonathan Harbour's forum too?

Woohoohoo!

Now then, what has been changed with the mouse acceleration?

See the posts by Elias in this thread: [url http://www.allegro.cc/forums/view_thread.php?_id=452248]. That's the current status of mouse acceleration in Windows.

Aww chucks. And I just submitted a fix to my sligthly broken patch

Should've held on to RC status for 5 more minutes

So does this mean that 4.1.18 has James Lohr's patch working? Or another varient?

Richard: It means it has the patch that Elias posted about posting in the thread I linked to, which is an improvement over James' original patch. It seems that James has made another improvement since then though, but he has yet to release what it is

gnolam: Yeah, I just saw it... it's a shame, but having to rebuild and zipup the release several times over is quite painful too... then again, who's going to notice if the problem only shows up in Windows 95?

Too many patches!

Well, I'll have to try 4.1.18 at some point..

Oh well... guess there's a reason it's called the unstable branch

This one sounds great! Does it mean that someone can write a RAM loader, finally? Or the load_* functions still use allegro's packfile implementation always?

But SS2 detection code was already there, even in 4.0

SSE code was in 4.0, I don't remember SSE2. And will have to switch the mirror, the one I use (umn) is timing out

Nope, it was in 4.0. Look at the screenshot attached from the config program of my tetris clone. The CPU info comes from allegro, and it detects SS2.

It is other, but SF has no separate field for that. See here for license questions:

Yes. There's also load_bmp_pf() and similar function that load files from an already opened packfile, so all you have to do is provide VTABLE functions for reading from memory.
That said, while Peter added the functions and VTABLE, there is no real documentation yet, so you'll have to figure out how to use it by looking at the source. I'd recommend starting with allegro/include/allegro/file.h for the definition of the VTABLE.

Hmm... in that case I remembered incorrectly what he added. I know it was three things, one of which was SSE3 and the other was 64 bit detection... I'll look it up.

Was the mouse problem with AllegroGL introduced in Allegro 4.1.16 fixed?

Was the exact cause of it already identified? I was meaning to boot into windows and try.. but didn't get around to yet.

As far as I know, no it hasn't.

As far as I'm concerned I would have been even more happy to see my MSVC7.1 workspace being included. Or did I miss something to see it included?

No, because I don't know what's causing it. I asked Julien to revert some of the changes that I thought might have caused it, and it didn't fix the problem... obviously something that needs investigation.

EDIT:

I don't recall seeing a finished version for it...? Can you send it to me through e-mail?

Oops, so I really missed that. I had posted one, and that's it, but I'll send you my current version this evening, tested with 4.1.18 then. Sorry.

Aah! You misspelled my name! A curse on you all unto the seventh generation!

... seriously, I didn't expect that to be in there at all.

Hmmm... My game (and the grabber) both crash upon exit if they're run in windowed mode. Windows XP SP2, 4.1.18.

Shit.. Just got installed 4.1.17.. and there is newer allready available. I hate making them all the time all over again.

I think that's ok, considering there are a couple of syntactically challenged sentences in the changelog

[EDIT]
Sourceforge finally let me download 4.1.18, and it seems I can't compile it:

XP SP1, pristine (except for the DirectX headers) MinGW 3.2.0 RC3. But it seems version independent - didn't work on my old 3.1.0.1 either.

Does the obj/mingw32 directory actually exist (it should)?
EDIT: that entry should read font loading routines... I type too fast sometimes...

Maybe it is executing it from the wrong path?

(OT: By the way, just noticed 7-Zip shows the original user and group in the tar.gz file )

Yep...

But is it really supposed to go in obj/mingw32 and not obj/mingw32/alleg or something like that?

i added CPU_IA64 CPU_SSE3 CPU_AMD64 detection.
so the changlog text is wrong.. big deal!

Yes, it goes in obj/mingw32, because no matter if you are building the release, profiling or debug libraries, the detection is always the same.

Go to allegro directory, and type echo #define ALLEGRO_GENERATED_BY_MAKEFILE_TST > obj\mingw32\asmcapa.h

Yep, works if I do it by hand...

After that it can continue to compile past that part, only to choke and die a bit later:

gcc -Wall -Wno-unused -I. -I./include -x assembler-with-cpp -o obj/mingw32/alleg
/asmlock.o -c src/win/asmlock.s
windres --include-dir include -O coff -o obj/mingw32/alleg/dllver.o -i src/win/d
llver.rc
gcc: src/win/dllver.rc: No such file or directory
gcc: warning: `-x c' after last input file has no effect
gcc: no input files
windres: no resources
make: *** [obj/mingw32/alleg/dllver.o] Error 1

Does that file exist? (Again, it should... it does in my local installation at any rate, which may not say much as that's a UNIX installation, but still... the contents of the archive should be the same).

Interesting:
When I build 4.1.18 with TARGET_ARCH_COMPAT=i686 all the programs crash upon exit when run in windowed mode. I built Allegro using i586 and everything works.

I'm using GCC 3.4.2 (mingw)

Not that it helps you, but the Zip archive compiled cleanly for me using MinGW GCC 3.4.2. I have downloaded the individual MinGW packages though, not the installer, but I don't see why that would matter. Maybe your uncompressor messed up the Allegro archive?

And again, it does.
And if I type the line manually with an absolute path it works... until the next .rc... and the next .rc... and so on.

[EDIT]
Found the problem. I have "cd c:\" in my autorun for the Windows console. Apparently, make is borked somehow and spawns new instances of cmd.exe over and over again instead of running the commands directly, thus changing the working directory...

"autorun"? You mean shortcut? If so, you can set 'Start in' under Properties -> Shortcut to "c:\" instead.

Ugh, yes, makes seems to spawn a new command, which cd's back. Remove that autocommand and try make clean and build again from scratch. And turn off the antivirus for the windres problem. Might help.

No, I mean in my autorun.

HKEY_LOCAL_MACHINE->SOFTWARE->Microsoft->Command Processor->Autorun

The "start in" property of shortcuts only apply to (no surprise here) shortcuts, so when starting the console manually you'll still end up in c:\blah\foo\bar\annoyinglylongpath\somewhereyoudon'twanttobe\ ... unless you add a CD command to the console autorun.

Aha, ok, cool. I didn't know of that registry key. There's additional benefits to using a shortcut though, like being able to change appearance. I've placed a customised console shortcut on Quick Launch. I keep forgetting how bad the default is.

The manual isn't in tatula.demon, when it will be updated?

I just installed SUSE 9.2 64 bit version and decided to give Allegro 4.1.18 a try. The library compiles fine, but it fails when compiling the demo:

gcc -DHAVE_CONFIG_H -I. -Iinclude -Iinclude/allegro -I./include -I./include/allegro  -DALLEGRO_USE_C -DALLEGRO_LIB_BUILD   -O2 -funroll-loops -ffast-math -fomit-frame-pointer -Wall -Wno-unused  -c ./demo/demo.c -o obj/unix/demo.o
gcc -s -Wl,--export-dynamic  -o demo/demo obj/unix/demo.o -Llib/unix -lalleg-4.1.18 -lalleg_unsharable -lm
lib/unix/liballeg-4.1.18.so: undefined reference to `_colorconv_rgb_scale_5x35'
lib/unix/liballeg-4.1.18.so: undefined reference to `_colorconv_indexed_palette'
lib/unix/liballeg-4.1.18.so: undefined reference to `_colorconv_rgb_map'
collect2: ld devolvió el estado de salida 1
make: *** [demo/demo] Error 1

[edit]
The same happens when I try to compile any allegro program. Maybe it's a problem with th C only version of the library?

So now I've updated and compiled everything on MSVC7.1, and here is the new vcproj-file with the new files included.

Edit: Urgs. Something seems to be missing, I'll correct that...

Edit: Evert, I can't find the implementation of the functions gui_get_screen() and gui_set_screen(), where are they supposed to be? It's strange, I could build everything from the makefiles, but using the workspace these symbols are missing, and using text search I can't find them.

That's odd... it's indeed possible that it's a problem with the C version of the library. Peter is working on (has) a patch that makes Allegro work better on 64 bit CPUs, but it hasn't been applied yet. You may want to check with him if he's aware of possible problems.

Uhm... where?

Lines 960 and 970 from src/gui.c.

There are no known problems with the patch, but some threading problems seem to show up more on AMD64 than x86 (or at least, on a gentoo box vs a slackware box). The patch itself should be applied fairly soon.

I don't know why you're getting undefined references to the colorconv stuff though. Try make depend first.

BTW, make forking itself over and over is the normal way make operates.

Something has gone wrong, my local gui.c was not properly copied or something. Now it works and builds fine, so here's the vcproj-file.

That didn't work I tried with make depend and then make clean. Allegro 1.1.17 works, though.

[edit]
I deleted the full allegro folder and started from scratch and now it works I don't know why it didn't work the first time

[edit 2]
But now X11 fullscreen doesn't work (it did with 1.1.17).

Perhaps all Allegro docs/build/* docs should begin with a big big warning that you should delete all previous Allegro versions completely, including a search for alleg through all your hard drive. About half of "Allegro doesn't work" problems result from the previous version pieces remaining here and there.

I installed it on a clean linux. There weren't old allegro versions anywhere (SUSE, at least the 64 bit version, doesn't include allegro).

tobing, can you please provide some more info to allow this project file to be used properly.

a directory listing, showing the file tree required.. as currently the project file alone does not help you figure out where to put everything.

also some notes about the environment you used to make this project file.

apologies if all this info is in the above posts, i am requesting that you organize it into a single package.

can you also tell me if you still have to go to the command line to generate the asm files?

Sorry, I missed out the details.

The project file has to be put into the allegro directory, top level (where the makefiles are). Nothing else is required. To use the project file, first build for MSVC using the makefile. After that the project file can be included in any solution and used to rebuild the allegro library. All output files are put where the usual make also puts them, but the solution file automatically adds the output libraries to the linker statement, so it's not necessary to add the allegro libraries to the game project in the linker options.

Would this be sufficient? If not, please let me know...

thank you, it is most helpful.

i thing leaves me wondering. what was the purpose of having a msvc project for allegro ?
as building it still requires the commandline.
is there any chance the project could be used to build allegro without having to go to command line ?

The use is to have a simple means to debug into allegro functions, to apply analysis tools form within the MS IDE, and to apply changes to the source code, compile them and continue work. That way it is MUCH simpler than doing things on the command line.

The reason I didn't try to build the libraries from scratch, using only the MSVC workspace. The make from scratch also build the runner.exe (I don't know if that would be necessary), and also creates some header file(s) - I didn't go into all detail here. The point is, it would require one project file for each intermediate target, and that would make it more complicate to include all that stuff into one's game workspace.

I'm having problems rendering a windowed video bitmap with the MSVC build of 4.1.18, under Windows...

Basically, I create 2 video bitmaps, one a back buffer and one a screen buffer. After I call show_video_bitmap() and start updating, the window doesn't update unless I drag it around with the mouse. This example worked previously with 4.0.3, but I experienced the same problem with 4.1.17.

Colour depth is 16-bit (though changing it makes no difference). Switching to memory bitmaps works fine.

Hmm... can you reproduce the problem with Allegro's exupdate example?
If not, can you send me your test program so that I can check this out?

I just tried exupdate, and the problem doesn't show up. However, there's no video double-buffered mode, so maybe that's the problem. Anyway, attached is a project that exhibits the symptoms.

EDIT: Later...

For fun, I tried page flipping, and it works:

  if(is_video_buffer)
  {
    BITMAP *temp;
    temp=screen_buffer;
    screen_buffer=back_buffer;
    back_buffer=temp;
    show_video_bitmap(screen_buffer);
  }

Seems that the problem is with double buffering:

  blit(back_buffer, screen_buffer, 0, 0, 0, 0, SCREEN_W, SCREEN_H);

Have you checked that the GFX_HW_VRAM bit in gfx_capabiliteis is set?
Anyway, I'll see if I can reproduce the problem with the programme you atatched.

Yes, gfx_capabilities&GFX_HW_VRAM_BLIT is true.

I've modified the allegro 4.1.17 sources and recompiled it to add some features, I will upgrade it to 4.1.18.

But, how can I submit my modifications?

Post here (start a new thread), or send them to the mailing list if you think they're worth including (and if they still can be).
What sort of enhancements did you make?

(Hmm... still need to check the problem Paul posted about too )

About Paul's problem, I didn't find time to test as well - but out of wild speculations, it may be a problem with the way allegro creates a directx flipping chain out of the bitmaps. And directx may not be happy with blitting one surface onto another in the same flipping chain. (And a better solution to blitting one vram page to another would be to allow disabling of vsync and then use normal page flipping. Not sure I'll find time to add this to the directx port though - but we should think about such things for the new gfx api..)