ahem yes, the problems of not properly checking return results even where I've code leaf functions to at least partly cope.
There is also the problem of not properly supporting multiple platforms. The code as written expects all data files to be in the same directory as the executable on Windows/Linux because here in my OS X application bundle ghetto I didn't really put a lot of thought into it. My IDE copies all the data files into the Resources part of the bundle and Allegro autimatically switches there, so I've just been stupid not thinking about the unholy mess that will create on other OSs.
Beyond that, I have no idea why manually adding folder names into the source doesn't work.
In my defence, it is only a work in progress technology demo.
One shouldn't hardcode the number of bitmaps.
In this case it is more acceptable than usual - the bitmaps are all different views of the same object, designed to allow the display a "3d" object using sprites, as in Doom or Mario Kart 64. I know that such an idea is very old fashioned and low tech, but it fits the mood.
Incidentally, I'm still slowly working on my game that will use this engine. Having abandoned a "realistic feel" as a time consuming dead end - even though it means admitting that almost everyone else was right and I was wrong - I've been working this week on a course editor. I haven't been posting because it is SDL based. It is SDL based because I consider a resizeable window (i.e. one where the user can drag expand it to their desired proportions) to be immeasurably useful for this sort of thing. In addition the event based structure of SDL makes it much easier to do very low processing cost and low FPS tools that don't become unresponsive. The editor limits itself to 10fps if possible, waking early if an input event occurs giving it about 3% CPU usage on my quite old machine. I'm imagining a scenario where it is used simultaneously with a running copy of the game for proper driving tests.
A couple of screenshots:
This is the initial screen of the editor. I've gone for an Outrun style branching track (branches as I plan them are a quite trivial engine modification), and on this screen the editor selects which route they will edit. A quite boring first screen. Selected route is saved from one session to the next so you usually don't spend too long here.
The main editor screen. Most of it is obvious. A tilemap has been adopted for the road surface so that lanes and lane sizes can dynamically change, etc. I've just chopped up 23's original textures to make the tiles, which hasn't worked too badly.
The main tile map section currently allows the map to be painted and objects to be placed. Corner editing will eventually go in there too, probably just through placing and rotating arrows as markers, with an eye on the not yet implemented 3d preview in the bottom right to get the curvature you want.
The "floor tiles" and "objects" bits are just palettes for selecting things to paint onto the main screen.
At the time of capture, the user is doing a copy/paste style operation. The bit highlighted in white is the copy source, the section being highlighted in purple is where that row will be duplicated.
At the top is the elevation editor. It uses quadratic Beziers much as before but now has a much more user friendly chop operation. The blue lines at the top match the blue lines in the tile area to help with orientation.
Development has been temporarily halted (about two days now) because I made a logical flaw in my planning. Of course with a tilemap it becomes important to preserve arc length, i.e. total road surface distance. I've decided to stick with Beziers and just implement that as a hard constraint, although I considered a more physical approach that would have made the elevation graph act a bit like a piece of string. I decided that would make it too hard to maintain continuity (in the mathematical sense) using the string idea and was too busy to code today.
I expect I'll be back on an art beg within a few weeks, but I want to put together a basic playable first stage even if quite art deficient as otherwise I can't see why people should believe that things have moved on since the last big thread.
Back in the day, I traced the asm code for a cout on a 286, after 40 minutes, my eyes watered, my head hurt, I decided not to use C++ anymore. Now, once in awhile, I find some code to do something in C++ and I try to understand it. I can't imagine why ppl would think a constructor is better than some straightforward initialization on entry, my brain recoils in horror... Oh well, to each his own.
With my investigations of Aqua lately, I've become persuaded that Objective-C is actually a really good language, especially as it can be mixed with C and C++ in the same source files. The conceptual idea of messages rather than functions which is implemented through runtime binding to prevent messy overhead is cool, especially as it eliminates the fragile base class problem about 1,000,000 times more neatly than COM or any other method I've seen.
As for while(n--), it's just my favoured type of loop. In the olden days it was recommended as the most efficient loop as the compare to zero and hence the branch decision is obtained "for free". That won't make any odds any more, but it is just the thing I automatically reach for now.