Yes it is, get it here.
Have fun!

Yay! First order of business: Port it to Linux.

Can you make the data easy to download to? It compiled fine on linux, except for the DIGI_DIRECTX stuff, but I dont want to have to boot into windows to get the data.

Yeah, the .exe installer isn't Zip compatable (some are), so getting the data on a linux platform requires Windows access.

But yeah, it compiles and runs fine, if the window specific DIGI_ drivers are removed, and the .ini is changed to use the DIGI_AUTODETECT option.

My patch to make Alex 4 compile in UNIX is attached. It will map the sound_device=2/3 from the ini file to OSS and ALSA respectively, while retaining the ability to compile the source for Windows.
Tested under SuSE Linux 8.0.

The game itself seems to run properly (though I've only played it briefly), but sometimes segfaults on exit. GDB traces the crash to allegro_exit(). I haven't investigated further yet.

EDIT: I'm dumb!! I posted at the same time Matthew did, which looks somewhat funny.

Allright, I've included the data in the download now.

Thanks.

Hey Johan,

Do you use DJGPP ?

Last time I checked he used MSVC. There's no excuse for using DJGPP in Windows, and Peitz knows this.

I haven't used DJGPP for ages. I've been using MSVC for the last few years at least. (But! I'm about to move to mingw soon.)

What? I thought you said you were NOT going to move to MinGW.

I'm allowed to change my mind, am I not? I got it working last night, with windres and all. Now I just need to learn how to make makefiles.

Cool!
If you want, I could whip up a makefile for Alex 4 that allows it to compile for DOS, Windows (MinGW) and Linux simultaneously as an example...?

Yes please.

Excellent choise, really. I use it too .
MSVC is too heavy and messy for me
DJGPP is for DOS - that says it all. I stopped using it as soon as I found out about MinGW .

I just use a compile.bat file, and I run it through EditPlus from which I edit the code and manage the project and run everything. It's almost like an IDE. The output is easy to handle too .

What I would want you to fix in this source is the warnings that I always get from MinGW .
I already told you in the FLD forum, I think:

: main.c:1292: warning: suggest parentheses around && within ||
(if ((mode == 1 && (keypressed() || is_fire(&ctrl) || is_jump(&ctrl))) || my_counter > 200) {
: main.c:2152: warning: type defaults to `int' in declaration of `camera_type'
(I.E. use static int, not static)
: map.c:412:57: warning: multi-line comment
(// 45 degree slope \)
: shooter.c:376: warning: int format, long unsigned int arg (arg 3)
((int)(s_var.show_score))
And plenty more "No newline at end of file"s.

And that whole slopes code should either be fixed or removed. I would prefer if it was fixed

Oh, well, I understand you're done working on it .

Better idea: change the "%d" or "%i" or whatever it is to "%lu".

goes off to download it

Umm ... I have a confession to make. I changed the meaning of dumb_resampling_quality for DUMB v0.9.2. So the information in the config file isn't quite accurate.

It's not a real problem though. The variable now ranges from 0 to 2, and if you set it higher it'll just act as if you'd set it to 2.

Very nice game. It should keep me occupied for a while

[EDIT] Psst, Matthew, delete your post since I edited out the stuff it was in reply to. Then I'll have two posts together! jÄää~

Ah, that's smart .

Say, how does the compiler recognizes what I want, after all, the rest of the varialbes are passed to the argument list - it's not supposed to be of a certain format. It doesn't know what is expected unless it checks what I passed in the char *format.

It does. It's a GCC extension.

And if you want GCC to check calls to your own printf or scanf-style functions, you can. Look up 'function attributes' in the GCC docs.

Johan, I'm going to try and compile it for Mac OSX (lillo rules ). If I manage it, will you have space on your website?

Pete

Peter: already done, with some little endianess-related fixes to the code

Now if only Johan could ungarble the packfile password he used for datafiles (cool idea to use a garbled password in the code, so it's not so easy to spot it by quickly analyzing the exe), I'd easily extract the egg sprite and use it as program icon...

Sorry for spoiling the fun, most of you probably want to get the passwords themselves (it's a challenge ), but I will anyway...
Ungarble the password? It's easy, find packfile_password, you see the parameter it recieves is init_string.
init_string is defined to be "[YhJPJKUSY`0-'\"7 ", but it's ungarbled using the function garble_string:

// garbles a string using a key
void garble_string(char *str, int key) {
  int i;
  int len_i = strlen(str);
  for(i = 0; i < len_i; i ++) {
    str<i> ^= (key+i);
  }
}

And it is called by: garble_string(init_string, 53);

So just run this proggy and it'll be fine:

Yes I will, alex is hosted on sourceforge, no problemo.

Did you manage to get it to work? I thought it would be near impossible since I saved the struct right off the bat.

I have attached an egg for you to boot.

How did I know you would? No worries though, the password says it all.

If anyone has any other ports that works I'll gladly accept them.

Um... Johan, MaxOS may not be able to use ico files.

Well in that case, here's one in pcx.

Try PNG.

X-G did you forget to eat your dried frog pills today?

Indeed, the only way to make me appear sane is make me so insane I think I'm sane.

Johan: it was actually easy. Luckly you put all your map loading/saving code into the same file... The problem was when you load/save the Tmap struct: it has some int fields that get screwed up as on disk they're in little endian format, and if you read the whole struct with fread() as you did, on memory it'll be in inverted byte order.
For the actual map you also used fread() of a struct, but that struct (Tmappos) only has byte fields, so no endianess issues arise and there was no need to fix.
So the only fix I made was to load/save the fields of the Tmap struct one by one - I used the Allegro packfile routines, that feature pack_igetl() which was helpful in this case.

I'm attaching the diff to map.c in case someone else is interested (it should not harm other ports)

About the icon: MacOSX accepts bitmaps of size 16x16, 32x32, 48x48 or 128x128. It'd be helpful if the icon is in an Allegro supported image format...

That's the PCX file he posted

Beaten to the punch again

Here's my screenshot, though.

lillo: I added a function 'fix_tmap' to swap certain bytes after the map has been loaded (and it is a no-op on little-endian systems.)

Pete

Cool Peter

Have you noticed some lags during game though? If I run the game fullscreen or at 4x windowed, it lags a bit... Guess because of speed issues or stretch_blit(). Johan, what about using a faster routine? 2x and 4x are special cases and you could use ints to blit 2 or 4 pixels at a time... Yes, normally stretch_blit() is fast, but that's expecially true on x86 hardware, where it uses on-the-fly asm code generation of the stretcher inner loop. On non-x86 CPUs though, stretch_blit falls back on using a more generic C routine, which as is generic, isn't particularly fast as a dedicated 2x or 4x C blitter would be.

One last thing Johan: I'd like to contribute the binary for OSX, but I don't know what files to include apart from the exe/data. Don't ask me to see what the Win32 binary holds, as it's a Win32 installer and I can't handle it under OSX...

It just needs the data/*.dat files and alex4.ini afaik.

I made an icon from the 16x16 Alex sprite - but the Mac ruined Johan's retro-blocky-pixel look by antialiasing it!

Pete

FBlend even has an optimized function for 2x blits - check it out some day.

Ok, I made the optimized 2x and 4x stretchers, and now it works better (few lagging in 4x windowed mode, no lag in 4x fullscreen).

I'm attaching a diff with all the modifications I made to the code as found currently on the FLD site. Apart from the new blitters you'll find that:

- if NO_YIELD is #defined at compile time, yield_timeslice() is not called anywhere in the sources (this reduces lag: under some platforms yield_timeslice() translates into a usleep(msecs) where msecs is not always 0 on all platforms)

- Working directory is not set up if under OSX: Allegro under OSX already sets it at startup depending if the exe is inside an app bundle or not (Mac users should understand)

Yes please.
The windows installer extracts files and folders found here: http://allegator.sourceforge.net/alex4_all/
If you could make the mac-app do the same (with the manual and everything, I'd be delighted.