Please be patient if I take too long to reply any questions, as it's going to be very hard to get free time, working at a limited pace until February.
A few friends and me have been writing & arranging a fully documented cross-platform engine, for the MD, 32x and SCD consoles, including Mode 1 and the full 32xCD combination, all written in Assembly. Meant to be found useful and "versatile" enough, its main goal is to keep it free and open from a legal viewpoint, so anyone could use it for Any purposes-
In simpler words, your same code could run in any of these platforms, unless you take a more complex route and program for a dedicated target with its extra features.
Technically, Build time is driven through GNU Make, under a "Build Objects / Link them" scheme. Uses open-source VASM and VLINK tools to assemble the Z80 and 68k code, plus a custom checksum generator and CD image builder. Each Makefile.[TARGET] file produces its output by fitting the Object files however does "best" (that's relative) to the Target; can automatically link objects from a previous build meant for a different Target, and for each SCD file (speeding up build process) even! The latter point should count, only as long as there's no VDP-related code in said Object files, though (more on that later).
Optimization Priority: CPU > ROM > RAM
Some (planned) key features, these may change at any time:
- 32x PWM driver on SH2
- Stereo Output
- Pan control
- Vol control
- Z80-based version
- Not sure about a 68k-based version?
- "Corner Pin" support
- Scaling & Rotation support
- DMA-based sprites list (for anything that doesn't require any of the above)
- "Basic" 3D support (Using flat color texture, no lighting) (Besides need to investigate a lot yet, may and up using ".blend to custom" format converter or similar method))
- SCD ISO-9660 library, V2 or Joliet (whatever turns best, need to investigate)
- SCD builds shall run core engine from 12MHz SubCPU
- > The other way could be optional (?)
Here I'm showing the first inmediate drawback about SubCPU support: There's no direct way to communicate to VDP, and it's necessary to send the command to MainCPU; either "inmediately", or to its VInt-based queue, however necessary. This is why the commands and data is sent through macros: It would build differently if the target was SCD.
With some help from Mercury's Sonic Physics Guide, a first "ideal" release would include a character with Sonic's physics, a few other objects to play with, and a scroll engine capable of drawing in individual 16x16 blocks and 128x128 chunks (made from 16x16 blocks) modes. It will be up to you to replace it with a Sonic the hedgehog's spritesheet and make a fangame upon it, or create something new.
This project is still taking shape, so any comments would be appreciated. For you, is any of this a good idea in the first place?
Please excuse any ignorance from mine part, especially regarding terminology, but, isn't the intention what counts?
A few things to note:
- It's the first time I try an arragement where files aren't directly attached to the "ROM tree"
- I'm beginning from the MD alone's implementation