I've dusted off all the dust from the Accidental/Golem3D stuff and I've been doing some tinkering. I realized quite some time ago that there really is no fundamental difference between all the various simple 2-dimensional and 3D-ish maps I've been playing with outside of the view, so I abstracted out viewpoint and camera information away from the map representation. Before, a map was fixed as a simple top-down tilemap, or an isometric map, or a 3D map with perspective viewed from top down, or viewed from an isometric-ish angle, etc... Much duplicated code and functionality.
I've split away the viewpoint stuff into separate classes that work in conjunction with a map. A map is just a map: a 2D grid of data. The viewpoint stuff deals with rendering chunks of a map from the appropriate camera angle and projection settings. Any type of map can be viewed through any configuration of viewpoint. Although, of course, in the case of some styles, such as a bog-standard isometric, viewing it from any other viewpoint than isometric looks peculiar.
These are some views of the same simple tile map from a 3d perspective, orthogonal top down, and isometric (2:1) viewpoint:
Same map, just a slight reconfiguration of the viewpoint between each screenshot. Only the Simple Tilemap type has been fully fixed for the new system, but the soon-to-be available map types are the Simple Tilemap, Elevated Terrain (with terrain blending), and Generic Geometry (for arbitrary 3D meshes, objects, characters, etc...) that were, in Accidental, combined up with all the viewpoint code into a cluttery mess. Now, you can just treat a map as a map, and let the viewpoint worry about drawing it.
It's mostly a cleanup issue, and it does simplify the maps themselves enormously. It does add some interesting capabilities, allowing different camera views to draw to different viewport's on the screen. Having a perspective close-up view on one part of the screen and a long-range top down on another part makes for easier visualization while tinkering with the map generation.
I've also pretty much written libnoise out of the project. It is a very nice library, and served well to inspire the construction of my own, but in the end I wanted to support a bit more options on the back-end. I've begun writing my own (mostly completed, just needs some tweaking) library, constructed similarly to libnoise, but which allows several more generator types, as well as the ability to specify the behind-the-scenes noise generator used for a given generator module. Types are value noise(noise values determined at each integral coordinate location), gradient noise (the original Perlin algorithm), and simplex noise (Perlin's newer type of gradient noise). You can also specify whether a generator module should use the 1D, 2D or 3D versions of each of those types of noise, and can specify the interpolation (linear, Hermite, or quintic) that should be used between the noise values.
This has the benefit that you can tweak particular modules for speed where sacrifices can be made in noise quality, etc... The module interface specifies noise functions in 3 dimensions, but if a particular module is always going to be used to fill a 2D buffer, then using a 2D noise function on the backend can drastically speed performance, especially when many generators are used in conjunction. Since the Accidental Engine isn't in the business of constructing whole planets, then falling back on 2D noise functions is often the way to go.
Also, the different noise types and interpolation types provide noise functions with different basic characteristics. Any function/interpolation combination can be used with any of the multi-octave fractal types (multifractal, ridged multifractal, hybrid multifractal, fbm, turbulence, etc...) to produce a wide variety of results.
I do need to do some cleanup. The backend specification stuff grew a bit unruly, turning into a mass of #defines that I need to tidy up into enumerations. I should also put it all in a namespace at some point, but eventually I'll probably post the library. The backend noise functions are inspired by libnoise in their organization, but rely on the reference noise generators given by Perlin for gradient and simplex noise, with some modifications to the coordinate hashing and gradient lookup tables. I also need to fix the 'magic numbers' that attempt to correct the output of the fractal generators so that they fall into the range of [-1,1] as the rest of the library expects. Kind of tough, actually, since octave count and base noise function can really play hell with the output result range. EDIT: The turbulence fractal at the top of this post was created by applying the output of a ridged multifractal and a billow noise multifractal generator to the inputs of a generator that draws a unit-sized sphere. Both the turbulence supplies had an octave count of 4. The ridged fractal perturbed the x coordinate, the billowy fractal perturbed the y coordinate, and the base noise function for each generator was quintic-interpolated 3D simplex noise.
Accidental is slowly growing into a Lua application powered by C++ extension modules. All the logic and input handling, GUI, etc... has moved into Lua files. Modules are provided that can setup and takedown an SDL/OpenGL window, and a wrapper for SDL has been provided to assist with input handling, but all the logic now is done from Lua, either from the command-line or from a GUI console when visualization mode is enabled. Things that are performance critical, such as rendering, are implemented as modules callable from Lua. It has really tidied up things, since I've been able to integrate a lot of the little stand-alone Lua-based tools I was using before (image processors, data-file processors, etc... all the little things you accumulate over time) with the main application for easier access and integration. I can fire up the application and do some mockups and image manipulation, render the output of noise functions, etc... from the Command Line, or I can enter visualization mode and fiddle with maps, textures, and other pretty colors. Pretty neat, and a lot more flexible, plus I still have good performance. (Although, it does take a bit of a hit by putting the main loop in Lua. Not bad, but noticeable.)
Anyway, that's what I've been up to. More to follow, hopefully.
