Keen to try it! Unfortunately remembered that I had forgotten that Allegro 5.0 doesn't work on OS X Yosemite. Will have to get the git version built and installed.
Pete

Just a little note for the OP about distributing software. It's a good idea to always include a root-level directory in archives so that when extracted the files don't end up littering the destination directory. You seem to have done that, but "src - beta 2 release" is a terrible name. Also, discourage spaces in filenames. They're a pain to code with, and they add no actual value.

Instead, it would have been better to use filenames like this:

invincible-countermeasure-beta2-src.zip
`-* invincible-countermeasure-beta2/

My girlfriend and I are not feeling well so she's waiting for me to get back to the couch to watch more House, but I aim to try building and testing this out. Looks good.

Append:

= 11. Whisper♫bambams@sephiroth:~/src/invincible-countermeasure-beta2$ LD_LIBRARY_PATH=/usr/local/lib ./a.out 
Invincible Countermeasure
Copyright 2014-2015 Linley Henzell
Version: beta 2

This is free software and comes with no warranty (see licence.txt).
For instructions, read manual.htm.
To configure screen resolution etc, edit init.txt.

Have fun!


Failed to open init.txt. Starting with default settings.
Could not load sample file (data/sound/blip.wav). Sound disabled.
Error:failed to load font file (data/images/fwss_font.bmp)

Apparently the source distribution is lacking all of the resources? And the license? And configuration and everything? I would also include those files in the source unless there's some reason you can't (e.g., licensing). Generally, the source should contain everything needed to build and run it (except for third party files, particularly when their license is incompatible).

Append:

Looks like the game is GPL v3 so maybe later I'll create my own source distribution and upload it so it's easier for others.

Gideon: Yes, the window on the right is part of the game - it's the built-in IDE. It is a programming game, after all.

Peter: Excellent! Good to see it compiles.

bamccaig: You're right, I didn't put that distribution together very well. I've renamed the source zip and updated it with the things you've suggested.

It's come on a really long way since beta1, looking really good now!

I've made a OS X binary if you want it. Let me know. By the way it builds fine with Allegro 5.1.

Pete

[edit] ic-beta2-OSX.dmg

I went ahead and created a GitHub repository for the UNIX package at https://github.com/bambams/invincible-countermeasure/. It appears to be forked from Linley's repository. For completeness I'll include another revised version here.

Latest changes:

• I added libm to the Makefile LIBS per Erethar's report for Arch.

• I renamed license.txt to the more standard COPYING.

• I created a README* for the UNIX release branch explaining the project to the best of my ability.

* Linley, that included adding a copyright notice of "Copyright (C) 2014, 2015 Linley Henzell". Please let me know if there are any errors or changes you wish me to make and I'll fix it. Also feel free to incorporate my branch or use any of my work on this release into your own repository or code (or not, no worries).

Peter: Thanks, I've uploaded the OSX binary to sourceforge.

bamccaig: Actually I opened that github repository before I realised that github was a bit more involved than what I needed. The repository you've set up looks good - I'll see if I can work out how to use some of your work for the next release (as you've probably worked out, I don't know very much about releasing software!).

Audric: Thanks for your comments.

1) I think I may have made a mistake by designing the game's graphics for my largish monitor, because it doesn't really work on smaller sizes like 1024x768. I'll look into how difficult it will be to implement a zoom feature (unfortunately, although the graphics are vector-based I wrote the display code with an Allegro 4 indexed colour mentality that doesn't accommodate scaling very well).

2) I'm not sure why the enemies don't appear on your mini-map, though. They should definitely be there; maybe the dots aren't bright enough to show on monitors with lower brightness settings. Does this happen on the tutorials as well as the missions, where the enemies use different colours?

3) The map doesn't start with landmarks, but does kind of get them as battles take place. But I do plan to make the background more varied at smoe point.

The RTS controls are pretty basic, but this is mostly because players can redefine them completely by rewriting the operator program (this is op_basic.c in the src or mission directory, which compiles in the game's own compiler). In fact the last couple of missions feature enemies that work on the flag-based principle you mentioned, although this may not be obvious to the player.

bamccaig: what did you do about file locations for Linux? The beta2 has the exe, resources, settings file and mission progress file all under the same directory, which isn't conventional for OS X/Linux. I used al_get_standard_path() to put the init.txt and msn.dat into ALLEGRO_USER_SETTINGS_PATH.

Pete

I didn't want to make any source changes since I didn't really know how the game works. The Git repository should document everything that I did, but I'm not certain. I began the work before I thought to track it with a Git repository.

Basically, I renamed the binaries directory to media since it seems to basically hold run-time files. The launcher script just changes into the media directory so that relative paths work as expected. At least, they seemed to for a basic test of starting a mission. I can't guarantee that there are no path-based bugs.

I moved source files into a new src/ directory and header files into a new include/ directory and created a Makefile and make/ directory with helpers. Predominantly, the changes I made just clean up the root directory so you can see an entire directory listing in a few lines, and added a Makefile that builds and generates a launcher script. The Makefile isn't intended to install the program anywhere because I wasn't sure how the game's compiler or interpreter works.

I avoided doing anything to the binaries directory because I couldn't be sure how it would break the game. Patches welcome if you can come up with a better way to organize it. I haven't really taken the time to play it yet, or to familiarize myself with the code. I'm really intrigued though that the game itself involves C code. I would like to come up with a way to install the game system-wide so that all users of the system could play without interfering with each other or duplicating more than is needed. I expected this would require source changes so I avoided it.

If we can figure out how to install it system-wide and shared by all users then we could even package it up for some popular distros. Either now or when a "stable" release is done. I bet that would help Linley with getting it used by more people.

Append:

I don't know if it's a bug in Allegro, the game, or LXDE, but with the game running in full-screen if I open the "Load File" dialog it doesn't appear. Nothing appears to have happened. I have to switch virtual consoles back and forth before I see it. If it affects all Linux users then it should certainly be fixed.

Thanks for trying to fix up the directory structure! My approach to this is pretty much stuck in the DOS era, unfortunately.

If you're concerned about the compiler or interpreter generating temporary files or using other system resources, they don't do anything like that. The ways that the game loads and saves files are:
- loading the init.txt configuration file at startup
- loading the font and title bitmaps and the sound .wav files at startup
- loading and saving the msn.dat mission progress file at various points
- loading source code files from the missions directory when the player starts a mission (these source files are not meant to be changed either by the game or by the user)
- loading and saving other source code files, gamefiles, turnfiles and saved games at the user's direction

Out of those things, it's really only the init.txt and msn.dat files that might need to be kept separate for different users. Players choose where to store their own source files, saved games etc, and can put them in their own directory if they want.

That's not good. Unfortunately I suspect it's some kind of bug or incompatibility in Allegro, because the game uses Allegro's native file dialogue functions in a pretty straightforward way. I had a similar problem in Windows using true fullscreen which I fixed by using a fullscreen window instead.

If there isn't a fix for Allegro it may be that the only solution is to change the init.txt file to use a window with a resolution similar to your monitor's resolution.

That's strange. Does it happen if you press escape at any other time?

Yes, this is probably what's happening. The native dialogues block the game's execution so it can't refresh the display or anything else. I think there's a way to avoid this by opening the dialogues in a separate thread, but that would be quite complicated and probably error-prone.

Any of the menu screens, but not in the actual game.

OK, I have seen it on linux now if I attempt to close the window with the 'X' in the top right.
I'll see if I can figure it out!

[edit]: In close_window_box the program goes into a tight loop, drawing the dialog and calling al_flip_display When double buffering is used, the rest of the screen is not touched and therefore oscillates between the last two frames. Depending on how different they were you'll see more or less flicker. AFAICS it does happen during the game, too, if you try to exit while your processes are moving across the screen you'll see them wobble back a forth a tiny bit.

To solve this, is there a function that will redraw the rest of the screen appropriately (i.e. menus or gameplay)? If not, the backbuffer could be copied to a temp bitmap and used for the background for each frame. Or, is there a clever Allegro way to do that, which I'm not aware of!?

bamccaig: I'm using 5.0.10. I think his problem is that he's not using the correct linker options to link to the allegro library or the maths library. If the libraries weren't installed at all he wouldn't have been able to compile anything.

He posted a similar question at the other repository I set up for the game,
here, which suggests that he might not be using your makefile. Other than that, I'm not really sure what could be going wrong.

Peter: It would be great if you could implement the directory fix using _get_standard_path. I'm not sure how directories work in multi-user environments and I'd probably get it wrong.

I have the issue you describe with the game responding to mouse controls when the window isn't in the foreground, but it's never really bothered me so I haven't fixed it. I think it should be fixable by detecting the ALLEGRO_EVENT_DISPLAY_SWITCH_IN and ALLEGRO_EVENT_DISPLAY_SWITCH_OUT events; I'll look into this.

I haven't been able to reproduce the flickering problem with close_window_box(), or even the slight wobbling effect you describe. This is probably something to do with differences in the way different OSes or video card drivers treat double buffering.

One solution may be to uncomment the line:
al_set_target_bitmap(al_get_backbuffer(display));
at the end of the while loop in close_window_box(). I'm actually not sure why I commented that out.

If that doesn't work, I'll look into making it possible to call the standard display routines from close_window_box(), which isn't really possible now. You could try also uncommenting the line:
al_clear_to_color(colours.base [COL_BLUE] [SHADE_LOW]);
at the start of the loop, which at least should stop the flickering.