clean up, typos, etc
This commit is contained in:
parent
a146681a9b
commit
c0b81129e2
26
proposal.txt
26
proposal.txt
|
@ -125,15 +125,16 @@ the maximal "uxn1" header size (assuming all strings are maximum
|
||||||
length and using an icon format of x0a3) would be 5904 bytes. while
|
length and using an icon format of x0a3) would be 5904 bytes. while
|
||||||
this is substantial it is unlikely to push most rom sizes over 64k
|
this is substantial it is unlikely to push most rom sizes over 64k
|
||||||
(the point at which working with them from within varvara becomes
|
(the point at which working with them from within varvara becomes
|
||||||
annoying). since the maximum rom data size is 65280, authors are free
|
annoying). since the maximum rom data size is 65280, authors are
|
||||||
to use up to 255 bytes of metadata while still keeping the total rom
|
guaranteed to be able to use up to 255 bytes of metadata while still
|
||||||
size under 65536.
|
keeping the total rom size under 65536 even if they are using the
|
||||||
|
maximum amount of rom data.
|
||||||
|
|
||||||
TEXT FORMATS
|
TEXT FORMATS
|
||||||
|
|
||||||
uxn isn't likely to ever support unicode very well, so why did i write
|
uxn isn't likely to ever support unicode very well, so why did i write
|
||||||
ASCII/UTF-8 for text formats? my take is that the text in roms is
|
ASCII/UTF-8 for text formats? my take is that the text in roms is
|
||||||
likely to be used both by uxn but also by exeternal systems that
|
likely to be used both by uxn but also by external systems that
|
||||||
probably _can_ handle UTF-8. i expect most authors to stick to the
|
probably _can_ handle UTF-8. i expect most authors to stick to the
|
||||||
ASCII subset that uxn can handle.
|
ASCII subset that uxn can handle.
|
||||||
|
|
||||||
|
@ -144,12 +145,12 @@ we have some alternatives to consider:
|
||||||
(c) mandate another particular encoding (latin-1)
|
(c) mandate another particular encoding (latin-1)
|
||||||
(d) leave the behavior of 8-bit values (0x80 - 0xff) unspecified
|
(d) leave the behavior of 8-bit values (0x80 - 0xff) unspecified
|
||||||
|
|
||||||
i don't think (a) has any advantages of UTF-8 (uxn programs will still
|
i don't think (a) has any advantages over UTF-8 (uxn programs will
|
||||||
need to ignore 8-bit inputs in either case). option (b) sounds like a
|
still need to ignore 8-bit inputs in either case). option (b) sounds
|
||||||
nightmare from within uxn programs and outside varvara UTF-8 is about
|
like a nightmare from within uxn programs and outside varvara UTF-8 is
|
||||||
as general as we really need to be in my opinion. option (c) doesn't
|
about as general as we really need to be (in my opinion). option (c)
|
||||||
feel much better than just limiting ourselves to ASCII (but maybe
|
doesn't feel better than just limiting ourselves to ASCII (but maybe
|
||||||
that's my own cultural bias speaking) and (d) sounds like a nightmare.
|
that's my own cultural bias speaking) and (d) sounds like total chaos.
|
||||||
so my take is that inside varvara only ASCII values are likely to be
|
so my take is that inside varvara only ASCII values are likely to be
|
||||||
well-supported, but for display outside varvara UTF-8 feels like the
|
well-supported, but for display outside varvara UTF-8 feels like the
|
||||||
best option (e.g. allowing author's to write their names correctly).
|
best option (e.g. allowing author's to write their names correctly).
|
||||||
|
@ -168,8 +169,8 @@ strings and icon data and produces a full-featured "uxn1" rom.
|
||||||
|
|
||||||
additionally it would be fairly easy to write tools to extract the
|
additionally it would be fairly easy to write tools to extract the
|
||||||
metadata from roms into other formats that are easy for external tools
|
metadata from roms into other formats that are easy for external tools
|
||||||
to work with (e.g. PNG or BMP for icons, JSON or TXT for metadata,
|
to consume and work with (e.g. PNG or BMP for icons, JSON or TXT for
|
||||||
etc.)
|
metadata, etc.)
|
||||||
|
|
||||||
CONCLUSION
|
CONCLUSION
|
||||||
|
|
||||||
|
@ -180,6 +181,7 @@ dividends as we move forward. among other things, it will:
|
||||||
- display what license or copyright covers a rom
|
- display what license or copyright covers a rom
|
||||||
- let users reliably determine which rom version is newest
|
- let users reliably determine which rom version is newest
|
||||||
- allow launchers to display nice images and names
|
- allow launchers to display nice images and names
|
||||||
|
- make it easier to produce online catalogs of uxn roms
|
||||||
- provide dates, places, and other historical info
|
- provide dates, places, and other historical info
|
||||||
- let authors to write dedications or nice messages
|
- let authors to write dedications or nice messages
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue