Update to v106r2 release.
byuu says:
Changelog:
- Super Famicom: added support for loading manifests without embedded
mapping information¹
- genius: initial commit
- various Makefile cleanups
¹: so the idea here is to try and aim for a stable manifest format,
and to allow direct transposition of icarus/genius database entries into
manifest files. The exact mechanics of how this is going to work is
currently in flux, but we'll get there.
For right now, `Super Famicom.sys` gains `boards.bml`, which is the raw
database from my board-editor tool, and higan itself tries to load
`boards.bml`, match an entry to game/board from the game's `manifest.bml`
file, and then transform it into the format currently used by higan. It
does this only when the game's `manifest.bml` file lacks a board node.
When such a board node exists, it works as previous versions of higan
did.
The only incompatible change right now is information/title is now
located at game/label. I may transition window title display to just use
the filenames instead.
Longer term, some thought is going to need to go into the format of the
`boards.bml` database itself, and at which point in the process I should
be transforming things.
Give it time, we'll refine this into something nicer.
2018-02-01 08:20:37 +00:00
|
|
|
#pragma once
|
|
|
|
|
2018-09-02 14:06:41 +00:00
|
|
|
//required bytes: ceil(bits / log2(base))
|
|
|
|
//base57 => 128=22, 256=44, 512=88
|
|
|
|
//base62 => 128=22, 256=43, 512=86
|
|
|
|
//base64 => 128=22, 256=43, 512=86
|
|
|
|
|
Update to v106r2 release.
byuu says:
Changelog:
- Super Famicom: added support for loading manifests without embedded
mapping information¹
- genius: initial commit
- various Makefile cleanups
¹: so the idea here is to try and aim for a stable manifest format,
and to allow direct transposition of icarus/genius database entries into
manifest files. The exact mechanics of how this is going to work is
currently in flux, but we'll get there.
For right now, `Super Famicom.sys` gains `boards.bml`, which is the raw
database from my board-editor tool, and higan itself tries to load
`boards.bml`, match an entry to game/board from the game's `manifest.bml`
file, and then transform it into the format currently used by higan. It
does this only when the game's `manifest.bml` file lacks a board node.
When such a board node exists, it works as previous versions of higan
did.
The only incompatible change right now is information/title is now
located at game/label. I may transition window title display to just use
the filenames instead.
Longer term, some thought is going to need to go into the format of the
`boards.bml` database itself, and at which point in the process I should
be transforming things.
Give it time, we'll refine this into something nicer.
2018-02-01 08:20:37 +00:00
|
|
|
#include <nall/arithmetic.hpp>
|
|
|
|
|
2019-01-16 00:46:42 +00:00
|
|
|
namespace nall::Encode {
|
Update to v106r2 release.
byuu says:
Changelog:
- Super Famicom: added support for loading manifests without embedded
mapping information¹
- genius: initial commit
- various Makefile cleanups
¹: so the idea here is to try and aim for a stable manifest format,
and to allow direct transposition of icarus/genius database entries into
manifest files. The exact mechanics of how this is going to work is
currently in flux, but we'll get there.
For right now, `Super Famicom.sys` gains `boards.bml`, which is the raw
database from my board-editor tool, and higan itself tries to load
`boards.bml`, match an entry to game/board from the game's `manifest.bml`
file, and then transform it into the format currently used by higan. It
does this only when the game's `manifest.bml` file lacks a board node.
When such a board node exists, it works as previous versions of higan
did.
The only incompatible change right now is information/title is now
located at game/label. I may transition window title display to just use
the filenames instead.
Longer term, some thought is going to need to go into the format of the
`boards.bml` database itself, and at which point in the process I should
be transforming things.
Give it time, we'll refine this into something nicer.
2018-02-01 08:20:37 +00:00
|
|
|
|
|
|
|
template<uint Bits, typename T> inline auto Base(T value) -> string {
|
|
|
|
static const string format =
|
|
|
|
Bits == 2 ? "01"
|
|
|
|
: Bits == 8 ? "01234567"
|
|
|
|
: Bits == 10 ? "0123456789"
|
|
|
|
: Bits == 16 ? "0123456789abcdef"
|
|
|
|
: Bits == 32 ? "0123456789abcdefghijklmnopqrstuv"
|
|
|
|
: Bits == 34 ? "023456789abcdefghijkmnopqrstuvwxyz" //1l
|
|
|
|
: Bits == 36 ? "0123456789abcdefghijklmnopqrstuvwxyz"
|
|
|
|
: Bits == 57 ? "23456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz" //01IOl
|
|
|
|
: Bits == 62 ? "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"
|
|
|
|
: Bits == 64 ? "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz{}"
|
|
|
|
: Bits == 85 ? "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz!#$%()+,-.:;=@[]^_`{|}~" //\ "&'*/<>?
|
|
|
|
: "";
|
|
|
|
static const uint size = ceil(sizeof(T) * 8 / log2(Bits));
|
|
|
|
|
|
|
|
string result;
|
|
|
|
result.resize(size);
|
|
|
|
char* data = result.get() + size;
|
|
|
|
for(auto byte : result) {
|
|
|
|
*--data = format[value % Bits];
|
|
|
|
value /= Bits;
|
|
|
|
}
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
2019-01-16 00:46:42 +00:00
|
|
|
}
|