d6
/
nxu
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

clean up, typos, etc

This commit is contained in:
~d6 2022-11-11 21:17:46 -05:00
parent a146681a9b
commit c0b81129e2
1 changed files with 14 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
proposal.txt
View File

@ -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
this is substantial it is unlikely to push most rom sizes over 64k
(the point at which working with them from within varvara becomes
annoying). since the maximum rom data size is 65280, authors are free
to use up to 255 bytes of metadata while still keeping the total rom
size under 65536.
annoying). since the maximum rom data size is 65280, authors are
guaranteed to be able to use up to 255 bytes of metadata while still
keeping the total rom size under 65536 even if they are using the
maximum amount of rom data.
TEXT FORMATS
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
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
ASCII subset that uxn can handle.
@ -144,12 +145,12 @@ we have some alternatives to consider:
(c) mandate another particular encoding (latin-1)
(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
need to ignore 8-bit inputs in either case). option (b) sounds like a
nightmare from within uxn programs and outside varvara UTF-8 is about
as general as we really need to be in my opinion. option (c) doesn't
feel much better than just limiting ourselves to ASCII (but maybe
that's my own cultural bias speaking) and (d) sounds like a nightmare.
i don't think (a) has any advantages over UTF-8 (uxn programs will
still need to ignore 8-bit inputs in either case). option (b) sounds
like a nightmare from within uxn programs and outside varvara UTF-8 is
about as general as we really need to be (in my opinion). option (c)
doesn't feel better than just limiting ourselves to ASCII (but maybe
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
well-supported, but for display outside varvara UTF-8 feels like the
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
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,
etc.)
to consume and work with (e.g. PNG or BMP for icons, JSON or TXT for
metadata, etc.)
CONCLUSION
@ -180,6 +181,7 @@ dividends as we move forward. among other things, it will:
- display what license or copyright covers a rom
- let users reliably determine which rom version is newest
- 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
- let authors to write dedications or nice messages