likely two stages, depending on how efficient the first one is
stage 1:
- no more Selectables
- using ImDrawList to draw the pattern
- perhaps even bypassing that and directly firing quads at the draw queue
stage 2:
- using textures and tiles to draw the pattern
this introduces several major changes to Furnace. I hope this message explains everything.
**File Format Changes**
a new song info header (`INF2`) has been introduced, which:
- cleans up the mess I made when adding sub-songs to Furnace
- allows better forward compatibility and extensibility
- uses 16-bit chip IDs
- moves compatibility flags to another block and is stored as a DivConfig
- stores channel count in the file, allowing chips with dynamic channel count (e.g. Namco 163)
a new sub-song data block has been introduced as well.
check out papers/format.md for information.
**Furnace Changes**
TimeBase ("Divider" in the UI) has been REMOVED. it was a DefleMask leftover.
to compensate, the speeds are now 16-bit. older songs will have their speeds converted, but this may fail if you use grooves or change speed mid-song.
dynamic channel count support has been added. the following chips are currently supported:
- Namco 163 (1-8 channels)
- ES5506 (5-32 channels)
- Generic PCM DAC (1-128 channels, with software mixing!)
channel colors have been added (thanks Eknous!).
SegaPCM (compatible 5-channel mode) and Neo Geo CD have been REMOVED. when loading previous files, including .dmf ones, these will have compatible SegaPCM and Neo Geo CD chips converted to normal SegaPCM and YM2610 respectively.
their channel count remains unaltered though. you can fix this by going into the chip manager and clicking the button next to "irregular channel count" in each chip config section.
**Code Changes**
a couple refactors have been made for the sake of code cleanliness and depending less on DivEngine...
=> Chip Channel Count
two new values, adjacent to the channel count, have been added to DivSysDef.
these specify the minimum and maximum channel count for a chip.
if your chip doesn't require dynamic channels, feel free to set these to the channel count.
for example, here's an old definition:
```
sysDefs[DIV_SYSTEM_NES]=new DivSysDef(
_("NES (Ricoh 2A03)"), NULL, 0x06, 0x06, 5 /* channel count*/, false, true, 0x161, false, (1U<<DIV_SAMPLE_DEPTH_1BIT_DPCM)|(1U<<DIV_SAMPLE_DEPTH_8BIT), 0, 0,
...
```
and here's how it looks now:
```
sysDefs[DIV_SYSTEM_NES]=new DivSysDef(
_("NES (Ricoh 2A03)"), NULL, 0x06, 0x06, 5 /* nominal channel count*/, 5 /* min channels */, 5 /* max channels */,
false, true, 0x161, false, (1U<<DIV_SAMPLE_DEPTH_1BIT_DPCM)|(1U<<DIV_SAMPLE_DEPTH_8BIT), 0, 0,
...
```
=> New Channel Definition
a new way to define chip channels has been introduced, replacing the old one.
it looks cleaner and is more flexible (even supporting dynamic channel count).
it works by defining a function in the chip definition, which returns a DivChanDef with channel information (name, short name, type and instrument type(s)).
alternatively, a list can be provided in the DivChanDefFunc() constructor, in the event channels differ greatly and/or the number of channels is small.
for example, if your chip's channel definition code looked like this:
```
{_("Pulse 1"), _("Pulse 2"), _("Triangle"), _("Noise"), _("DPCM")}, // names
{"S1", "S2", "TR", "NO", "DMC"}, // short names
{DIV_CH_PULSE, DIV_CH_PULSE, DIV_CH_WAVE, DIV_CH_NOISE, DIV_CH_PCM}, // types
{DIV_INS_NES, DIV_INS_NES, DIV_INS_NES, DIV_INS_NES, DIV_INS_NES}, // ins types
{DIV_INS_NULL, DIV_INS_NULL, DIV_INS_NULL, DIV_INS_NULL, DIV_INS_AMIGA}, // secondary ins types
```
now they look like this:
```
DivChanDefFunc({
DivChanDef(_("Pulse 1") , "S1" , DIV_CH_PULSE, DIV_INS_NES),
DivChanDef(_("Pulse 2") , "S2" , DIV_CH_PULSE, DIV_INS_NES),
DivChanDef(_("Triangle"), "TR" , DIV_CH_WAVE , DIV_INS_NES),
DivChanDef(_("Noise") , "NO" , DIV_CH_NOISE, DIV_INS_NES),
DivChanDef(_("DPCM") , "DMC", DIV_CH_PCM , DIV_INS_NES, DIV_INS_AMIGA)
}),
```
some helper templates, such as stockChanDef and simpleChanDef also exist, which automatically map channel names and types regardless of count.
this is useful if all your channels happen to be named "Channel 1", "Channel 2" and so on, while sharing the same type and instrument type (this is the case for many sampler chips).
if you've been working on a custom chip, make sure to adapt your chip definitions.
=> More Chip Definition Changes
the DivSystem enum is now in src/engine/sysDef.h
channel definitions are cached in the DivSong.
=> Reducing Dependency on DivEngine
many functions have been moved away from DivEngine where possible. these include:
- recalcChans() (now on DivSong)
- chans, sysOfChan, dispatchOfChan, dispatchChanOfChan and dispatchFirstChan have been moved to DivSong as well.
- asset dir storage/modification/check finctions (now on src/engine/assetDir.cpp)
- DivEngine::getSystemDef() is now a static function, so it can be called without a DivEngine (engine still has to initialize systems first!)
IMPORTANT: hasLoadedSomething is no longer set in recalcChans() because it is part of DivEngine. if you have import code, MAKE SURE TO SET hasLoadedSomething TO true AFTER SWITCHING THE SONG (song=ds).
=> Dynamic Channel Count
a new array called systemChans[] has been added to DivSong, allowing you to define the number of channels for each chip.
if you change this, make sure to call recalcChans() afterwards.
if you use dispatchChanOfChan[], treat `-1` as "no channel". this is set when the channel count is higher than the chip's maximum.
if you're working on import code, and are certain you won't use dynamic channel count, call DivSong::initDefaultSystemChans() before recalcChans(). this will set up default channel counts for you.
otherwise, set systemChans[] appropriately.
