It's about time I finally dug into those ramp tiles. I had been putting it off for a while, but I suddenly decided I'd take a crack at it and here we are. There are still a few things I could add to it, but overall it's working quite well.

In order to implement ramp tiles I needed the ability to query the alpha value of a given pixel in a texture. My method of ramp tiles uses a pixel-perfect detection method to allow for any shape of ramp (as opposed to only simply 45 degree slopes). It took me a little while to finally wrap my head around what was required to do this on a texture in OpenGL, but eventually I made my way through the unfamiliar territory. One detriment to pulling out pixel values for the RGBA components from a GL texture that is already pushed onto the card is that it's slow. Trying to do that several hundreds of times in a logic loop is a bad idea. To prevent major slowdown when querying pixel information I implemented a caching system where you can decide whether you want to retain the pixel buffer data for future use or not. If you retain the data, get pixel operation speeds are increased dramatically. The pixel getting function is all smart and figures out whether you've already done a pixel operation and retained the data or not and will choose the fastest operation possible if one exists according to how it was invoked (retain vs no retain).

With pixel-getting capabilities in the bag, ramped tiles were finally a go. The core functionality was easy to pin down. The real problem areas were the edge cases, like ramps that meet with full solid tiles and making the animation look smooth when walking down a ramp. A classic problem regarding ramped tiles that aren't specialized in terms of angle is that when the character moves "down" the ramp they move outward a little bit, and then when there are a void below them they begin their "falling" animation and fall into the space. Rinse and repeat as you go down the ramp. In reality, it should look very smooth and as the player walks down the ramp the animation is "stuck" to the walking/running animation, yet the player still moves in y position without triggering the falling status. My method for working around this is pretty simple: if you're not directly blocked, not falling, and are physically blocked half a tile's worth of space below you, don't perform the falling operation and instead just move downward.

As for deficiencies: any ramp tile that has a solid column of pixels that are the height/width of a tile are impassable at that point. This sort of makes sense, as if you have a solid ramp tile you do not want to be able to just "fly" right through it. This means that if you want a ramp to gradually raise up to a normal tile height, it must be drawn in such a way that it actually raises up to the tile height minus one, or else it will be impassable. This means that if a ramp should raise up to a normal tile hight and actually connect as one large ramp, the ramp tile must be adjacent to a normal "non ramp" tile.

Throughout this whole explanation of the ramp tiles I realize I made it seem like ramps and regular tiles are treated differently from one another. On the contrary, regular tiles are simply a special type of ramp: and entire solid ramp that completely blocks the player. The tiles are treated the same and there isn't special code to tell whether you're on a rampified tile or not. The code simply checks where the player should be according to while tiles are surrounding them and moves him/her accordingly.

It was about time I went back and did some major code refactoring and cleanup. It turns out I had let me list of TODO comments grow to an incredibly large amount. After the switch from Allegro to my new wrapper library a lot of stuff got left up in the air--especially things like the allegro_message functionality. I was using allegro_message for almost all of my error reporting. Unfortunately, my custom library didn't offer that functionality off the bat while I was doing the code conversion. This meant that a lot of the error reporting was actually just commented out to see if I could simply get the engine running or not.

Instead of throwing a dialog box to the user while they're playing the game, I opted for writing to a log about whatever errors or strange out of memory errors might occur. Long story short, all of the allegro_messages had to be replace with logging. While it took a while, it removed almost 90% of the TODOs. There were a few minor changes regarding other things that I was fleshing out while bringing my library up to speed, but aren't really so significant they warrant specific mention.

Overall I touched a good portion of my entire codebase. It feels good to be "clean," for now.

Just doing a little cleanup with the site design, if you hadn't already noticed. I spent forever tinkering around with banner/logo concepts until I decided to just write one out "by hand" as a last effort. It turns out that this style actually looked the best and fit loomsoft pretty well. There you have it. A not so long story made incredibly super-short!

I couldn't resist implementing multiple background support. To be honest, a lot of the framework for being able to deal with the ability to add an arbitrary amount of "something" to a given map is pretty solid. Throwing together the multiple background support was really like taking the exit handling code and modifying it to be background specific. That said, pulling it all together took a lot longer than I had originally anticipated. The original scheme was implemented to only support a single background, so a lot of restructuring was needed to encapsulate the concept of a "background", rather than leave everything scattered around in various variables floating on the map object. Now, a map background is its own class. The nice thing about this is if I decide to allow for scrollable foregrounds, I can easily extend and abstract out the background class to offer this capability.

In any case, multiple background support is awesome. It's very cool to see various backgrounds all scrolling on their own according to the attributes that you set in the editor. Even with fake images that don't really go together, it's easy to see that there is now the potential for a very high sense of depth to the maps that will comprise the game. I can't wait to get some serious looking backgrounds and take it for a test run.

So, I decided to bite the bullet and implement the whole gamut of stuff I was describing earlier. The backgrounds now tile themselves and scroll accordingly. It was a bit of a pain to take into account all of the edge cases, but in the end I think it will pay off in flexibility to the game's engine. What was interesting, though, was that my first approach at handling scrolling was incorrect. My initial thought was to keep track of how much the camera had moved and draw the background offsets according to those changes. This led to some miscalculations, however, as the amount the screen moved couldn't always be captured correctly: you can't know where it's going to move before it does, so there was a bit of lag involved and the background was shifting itself out of view even though you could move the character around in the same spot over and over again.

A much easier solution was to simply calculate where the background should draw itself given the camera's current position. This was an incredible savings of processing time. Instead of doing all sorts of calculations and keeping track of deltas, I can simply generate the backgrounds absolute coordinates in a single line of code (one for both x/y coordinates). After that calculation, there is some extra positioning required due to how I've set up my background tiling code. The background "offsets" (from upper left corner) must always be within the range of 0 < x < background tile width and 0 < y < background tile height, where the tile width/height is the chosen background display width/height. Such a calculation to place the absolute coordinates within a single "background tile" is fairly straightfoward, though. I really like this new approach I've taken. It's clean and concise!

With background scrolling and tiling taken care of, the next step is to determine whether I really want the ability to have multiple backgrounds to be able to layer on top of one another. This is another one of those features that will make the engine pretty flexible. I'll most likely end up doing it, but mostly because I can already think of at least one scenario in which I would find it to be useful.

Since I haven't done much with the background code in a few days, I've been thinking about my decision regarding the ability to effectively use any portion of a valid texture as a background that is automatically tiled and wrapped. Since I'm writing this engine mostly for my own purposes, right now I only need to care about myself as a "user". For the most part, I don't anticipate having any need for a background that I want to have automatically tiled. If anything, what I'll be using every time is a background that's actually larger than the screen. Even so, I can't help but feel like if I take the easy route out and throw away the work involved with tiling (which is really just a test of patience and handling lots of edge cases) is a bad idea. I might as well make the engine as flexible as possible from the get-go, right?

If that's the case then I should make backgrounds tileable and in addition to that implement the ability to place an arbitrary number of backgrounds on a map, each with their own scrolling properties. Ah yes. Instead of choosing an easier route, I'm actually just pushing toward making more work for myself!

With backgrounds I had the initial thought that the user should be able to decide whether it wraps horizontally, vertically, both, or neither. I'm beginning to think this was an incorrect assumption and design. What would be drawn in the place of the background if there is no wrapping to take place? Nothing? That doesn't make very much sense at all, unless the plan is to use the background for some floating style object. If that is the case, then, there is another problem: the background will always start drawing from the upper left corner of the screen, as opposed to some other position. While it might make a little sense to be able to create some sort of object background, I think it would make more sense to use tiles in the game to do such a thing -- or some specific object that isn't a background image itself, but is rather some kind of "background object" with adjustable movement speeds.

I think the method of background implementation I'm leaning toward is the "always wrap" mode; the image will wrap around on itself when it scrolls out of view. In addition, it tiles itself to fill in the screen if the selected portion of the background texture image is smaller than the game's resolution size. For starters, I'll probably go with this method as I do not anticipate using background textures that would not require wrapping in at least one direction. The fact that wrap needs to occur (aside from tilling) can be dictated mostly by the background's scroll speed, anyway. If the background isn't scrolling in some direction, and it's always at least the size of the game's dimensions, then there will never even be a need for "wrapping."

In any case, design thoughts aside, the ability to now select which portion of a texture you want to be used as the background image is now implemented. You simply left click to place the upper left bound, and right click to place the bottom right bound. All the fancy bound checking is done to ensure you don't pick some texture region that is totally bogus. The more difficult/time-consuming part is going to be the auto-tiling of the texture to the screen.

Background scrolling is now implemented properly. Wrapping is still unfinished for reasons I will discuss later. The background scrolling is set up in such a fashion that it can scroll in either the same direction that the map is "moving", or in the opposite direction. Furthermore, the amount of scroll that occurs is also customizable. This allows for great versatility in what backgrounds can do. Couple this with the potential for being able to display multiple backgrounds and you have all sorts of scrolling and pseudo-3D capabilities in your hands. The map can scroll both left and right, and up and down. The support for changing these values is also already intact in the editor. Now, about that background wrapping...

Due to the fact that I'm using an OpenGL backend for displaying textures, I'm stuck with the limitation of having to use power-of-two dimensioned textures. This is obviously not really that great if you want to use a background image that isn't a power-of-two dimension. Currently, there is no way to tell the engine that you only want to use a sub-portion of a texture as the actual "full" background image for a map. This kind of functionality needs to come first before any automatic texture wrapping occurs to compensate for the fact that backgrounds can scroll. Being able to set the sub-texture that will be drawn as a background is going to require a decent amount of work in the editor code to be at least somewhat user friendly. I'm currently running out of key combinations to control things!

When it comes down to it, I know I'll come up with some solution that's workable. Right now I think the solution will be to make a sort of sub-texture grabbing mode where only the background image is displayed and you can select the region you want to be the background image. The only problem this poses is for backgrounds that are larger than the screen size. How are you going to select a sub-region on a texture then? To solve that I think I'll allow the background image to be scrollable, and the user can simply pinpoint two locations on the texture that will make up the background: the upper left corner, and the bottom right corner. Clicking the area you desire will place the markers, and then the user could nudge them into the pixel-perfect location using the keyboard. I think it sounds relatively workable. It's a pretty big chunk of functionality to implement, but doing things this way would make background selection incredibly versatile.

It's another one of those "it's been way too long since I've last updated" posts! Honestly, I didn't really go anywhere--I simply haven't been updating with the progress I've been making. This is mostly because I've been doing some research into art and spriting. While I haven't started my hand at getting more practice in my pixeling skills, I have been asking around for guidance and the like. Of course, if worse comes to worst, I'll go scouting around for an actual pixel-artist. Even so, if it comes to that I will have at least increased my pixeling skill on some level, right?

Aside from sulking around the 'net due to my inability to pixel like a master, I've been doing a little bit of coding here and there. I've made some updates to my minimap system whereby it won't simply draw pink squares anymore. Now there are two textures that I draw each "block" of the minimap from. When you pop open the minimap it will display either the "unvisited" or the "visited" portion of those textures for each block you have visited. This will allow me to do fancy things like make a highly stylized map that doesn't look so grid-like in its completed state.

On top of that, I've also begun working on the ability to assign a background image to any given map. The plan is to have the background image auto repeat on either x or y axis, as well as scroll dependent on the player's movement. This will add the wonderful effect of parallax scrolling to the game's engine. So far the design only allows for a single background to be placed. I may be extending this to allow multiple backgrounds, but for now a single one will do. As of this writing, you can currently select the background only. There isn't any automatic scrolling, neither the ability to set or select the parameters of scrolling and texture wrapping.

Another nicety I'd like to put into the engine after background capabilities is the ability to have non square tiles, or in layman's terms: ramps. I've already discussed this before, but I still haven't actually implemented it. I mentioned a method that I had used before for a tile engine I wrote a while back. While this method would work in my current engine, it would definitely lead to memory wasteage due to implementation details. Hopefully I'll be able to work out some unique and more efficient way of doing ramp tiles.