Lighting Engine Complete?

Sure seems like it. Got it done in one day!

Now that shadow-culling and day/night cycling is in place, Clarion’s new lighting engine is ready for action.

It allows me to have a virtually unlimited number of shadowed lights at almost no performance cost, which will make environments in the game far better looking. Especially dark dungeons with sparse lighting. The size of the lights are also improved, which frees me from the original annoyance of severely limiting the player’s field of vision in the last version.



Light Up The Night

I’ve got this burning like my veins are filled
with nothing but gasoline.
And with a spark,
it’s gonna be the biggest fire they’ve ever seen.
Cut me down or let me run,
either way it’s all gonna burn…
The only way that they’ll ever learn

Light up the night!



Something like a mouse selector on a tile may seem mundane, but it’s actually pretty complex(or in computer science terms “fun”).

When the game starts, it loads a black&white “tile_mask.png” into memory and converts it into a line of 4,096 bits. Black is 0, white is 1.

When a tile is drawn, it checks the given bitfield at index [ (mouseX-drawX)+(mouseY-drawY)*TILE_WIDTH ] to see if the mouse is on a “white” part of the tile_mask.png, which is, in a sense, placed relative to the tile being drawn. If the bit that’s checked is a 1, the mouse is hovering over that tile, if it’s a 0 or out of bounds, then it’s not.

After the check is performed, a pointer to the selected tile is given to the WORLD object, and can then be used to tell other entities in the game world which MAPTILE object is currently under the mouse cursor.

EDIT: All that stuff you just read up there? It’s STUPID and USELESS.

NEW SOLUTION! I figured out the formula to translate the mouse coordinates into the map’s coords, thus reducing the check to O(1).

I did this by using simple algebra on the code used to draw the tiles, so that I could sort of… “reverse” it to get the coordinate component. It’s rough, but it works.

double selectX,selectY, mX, mY;
mX = MOUSE.x+camX;
mY = MOUSE.y+camY-TILE_H*1.5;

selectY = mX/(TILE_W/2) – (mX/(TILE_W/2) + mY/(TILE_H/2))/2;
selectX = mX/(TILE_W/2) – selectY;

selected_tile = Grid_Tiles.get((int)selectX,(int)selectY);


Ex Why Zee

I got a LOT of work done today as far as reorganizing the objects in the code goes. It’s… cleaner… not sure how to explain. I also delegated the storage of tile data to its own class (in non-jargon, a class is a sort of container for data and functions). So a tile will contain the actors and objects sitting on it, where it needs to be drawn on the screen (without camera offset, but INCLUDING a new drawZ value for height. Nifty!), the tile image it uses, and it also handles its own drawing events and has been integrated into the A* algorithm to allow me to give a movement cost to a tile other than 0(empty) or -1(blocked).

This transfer to allegro 5 broke the thing that allowed me to put a mouse selector onto the isometric map, so I’ll have to fix that later. Hassle.




I completed the translation to allegro 5.

I had to alter the way the tiles are stored in order to take advantage of deferred drawing.

Basically, whenever the game “requests” a tile image, that tile.png is loaded into the game (if it hasn’t been already), given an identifier, and placed onto a 1024×1024 atlas in video memory along with the other previously loaded tile bitmaps. Since the tiles are 64×64, this allows me to use up to 256 tiles at once for efficient drawing that takes advantage of your graphics adapter.

The move to allegro 5 also allows me to load OGG sound/music like I wanted, as well as a variety of other kinds of files.

I need sleep.

Status Update

Right now I’m trying to convert the skeleton of the game to Allegro 5, as opposed to 4.

I WAS attempting to harness hardware acceleration in 4, but it turned out to be a major hassle in such an outdated API. Turns out 5 is far newer, and more suited to my needs.

Should be an easy conversion, the code isn’t very bloated yet.

After this I should be moving on to lighting and animation for the world view.



Hey, it’s actually coming together.


Today, in the Clarion++ framework, I squared away a lot of small things, but one big one was A* pathfinding, a huge component of Clarion’s A.I. and worldgen.

I was up all night debugging my implementation and it’s finally ready for use elsewhere in the game.

Anyway, this is the last of the “really hard things I was afraid of having to do myself because I’m programming this in C++”. From now on, components should fall into place much faster.

This shot was running in-engine. It lets you create blocks and move the yellow square to wherever you click, tracing its path along the way. The path pictured here resolved instantly. Is it my algorithm, or is C++ just that fast?



I’ve been picking at the framework for the revision of Clarion in C++. This involves some lower-level stuff than I’m used to, but it’s working out just fine so far. I should be able to have a very basic world display prototype within a week or two. And later, I’ll have the new guys introduce themselves here. This game is now a team effort. We’ll even have a studio. When all the legal stuff is out of the way, we’ll unveil more details.


I was thinking of translating Clarion into C++. GM is just too slow for me to do the things I WANT to do. And I think I’ve figured out more than enough C++ tricks to actually do this. It would also involve redoing ALL of the graphics, but not necessarily all of the logic. It should be encapsulated well enough to be an easy translation. Of course I would have to rewrite a whole lot of things to work in C++, but it’d be worth it.

If I ported it to C++, I’d improve/add the following:

-Scalable display with proper graphical frames instead of pre-drawn backgrounds for menus.
-Isometric view of the game world with smoother scrolling and movement of objects across tiles (sliding movement as opposed to popping)
-Larger sprites and tiles
-Support for idle animations for tiles/people/monsters/creatures and improved visuals on items as a result. This is possible due to the lack of GM’s ridiculous object overhead and speed problems.
-Finally, the LOS algorithm will work fast enough to be practical and worldgen won’t take five damn minutes.
-Better-implemented code all-around due to having the opportunity to redo it and put in framework features and optimizations I should have put in before.
-Easier tileset modability by simply replacing pictures in the appropriate folders.

Can’t do any of this until I get a new computer, but I’m just throwing that out there as a possibility.