My thoughts about the voxel mapper shifted around towards unifying all my tools projects. Will it be implemented? We'll see! It should all be within an order-of-magnitude of possibility, though - just a matter of development time.
VX-32: fantasy console/engine, in the spirit of PICO-8, but designed more around pushing modern hardware with brute-force, easy-to-use techniques and an extremely integrated toolchain with a large number of presets. Hard limits aren't the focus, but we're aiming for 4-8 megabyte ROMs.
Desktop toolchain - we have a "ROM builder" that functions as an IDE. Open-protocol service to automatically store, share, synchronize games - accounts, registration, etc. This is not a web or mobile-focused project, so it'll use native code. Language not yet settled.
Rendering: stb_voxel_render.h as the basis, in mode 0 or mode 1. Fez-like 8x8x8 "trile" system used as the building block for maps; texturing and vheight also applied to lend additional shape and detail to trilemaps. Tools build around trile system. Goal is something like the uniformity and low memory consumption of graphics data on NES et al., just with additional dimensions. Detailed, smaller, static maps rather than rote emulation of big Minecraft landscapes and malleability. Voxel sprites, effects rendered as additional trile passes - rotation and alignment is freeform. Particles? Sprites? TBD
Ampliscape becomes the canonical sound engine: Reformulation from "game-like" tool into a more fully-formed DAW-like environment. Synthesizer redesigned around a flexible sampler system "Amplisynth". 64 voices assignable to 16 stereo mixgroups - voice allocation is automated. 16/48khz sample playback with panning, loop points and release. one multi-mode VA filter per voice. (Same filter I currently have in Ampliscape's synth.) 8-stage envelopes with loops. some undetermined FX chain per mixgroup. Ampliscape acts as the toolchain to generate sequences, apply procedural effects, trigger sounds, etc.
Built-in ROM containing default textures, triles, and sound samples, including an ASCII font, character and environment art, various bread-and-butter sounds and synth patches. Goal is never to feel reliant on importing data from elsewhere in order to finish a project and to have a distinctive base aesthetic.
Scripting focus for actual game code - to be "virtual console" like it shouldn't be necessary to dig into the engine, although some method of escaping and taking control of the engine and toolchain will exist for the brave and foolish. Entity management, collision data, camera, etc. - built in but designed for scripting control.
Target for higher-level game tools - e.g. walkthrough sim maker, shmup maker, etc.
