Ohhh, beautiful <3 My favorite PD book is Flatland, can we do that too?
What are the technical details please? Did you use text compression? Is there a source? I was thinking about a book reader too, perhaps with options to change font, colors etc. (could be compile time options). Would be awesome with font antialiasing – I wonder what subpixel antialiasing would look like on Pokitto (what is the subpixel order of the LCD?).
There is a CC0 font Aileron that could be used to render the antialiased font for Pokitto.
Here’s the FemtoIDE project, along with a Flatlander.bin: TextReader.zip (411.2 KB)
I do very simple text compression that gets about a 50% ratio and doesn’t need much code to decompress. It’s all in the zip.
Edit: subpixel antialiasing would probably look really bad on the Pokitto, since the pixels are so big. For regular anti-aliasing we could use a bitmap font and a grayscale palette. That would take up more flash space, though.
EDIT: But that actually takes up flash too, right? Sorry
The native size is okay no? Anyway I’d like to see it at least. Let me see, this is super exciting.
Here is a quick image that could be used to test how it looks (the above font: normal AA, light AA, RGB horizontal, RGB vertical – you can use ftview to render these): (wrong subpixel order)
This one is with 16 color palette only:
EDIT:
According to my magnifying glass Pokitto display is vertical BGR.
I think the bottom one looks best, but as the subpixels are vertically stacked it would work better if the screen was rotated since it’s really the horizontal clarity that is needed most in text.
I am now split on whether the font should be fixed width or not – it’s not so readable, but some books, e.g. plain text versions of books on Porject Gutenberg, have ASCII art image approximations, which need fixed width. Perhaps that could be an option too.
BTW reading text from SD can be done with my Pokipad – the length of text is limited by RAM, but I think someone could relatively easily edit the code to read individual pages from SD (just add offset when loading the text from SD to RAM), or to read from flash. Or you can have portions of the text (e.g. chapters) split into multiple files.
While Aileron looks much nicer than the fonts we’re currently using, I was under the impression that it was a bit too blurry, so I decided to give it a closer look:
That’s how it’s meant to be I think, same as with the GB emulator.
I think a very short snippet could be non-copyrightable, but it’s not clear how short is short, I wouldn’t use such code without a license. So I agree with @Pharap , a license/waiver would be great – the worst that can happen is that it will be redundant.
In that case I have to question the premise.
Instead of flashing a new .bin to switch between books,
I think it would be better to just have a ‘book reader’ program that could load lots of different books.
Think of it as being equivalent to having a .pdf reader to read multiple .pdf files instead of each .pdf being a separate executable.
The Game Boy games are a different matter because they’re intended to be fast executables and it wouldn’t be practical to load them over SD card because of the technical constraints.
I wouldn’t like to bet on it without more knowledge of the relevant laws.
Precisely.
Not to mention that if someone were to modify it to a point where it actually is a non-trivial amount of code then it would save them the problem of deciding whether they have the right to put a licence on it and/or copyright it.
That’s an option of course, each one has pros and cons (works without SD, is limited by flash, etc.). But I personally like the other way – instead of pdfs + a reader you can think of it as a “book engine”. I like that you could have self-contained executable books in a single file precustomized to fit each book’s mood etc., without the unnecessary reading from SD – of course you could customize the book to your needs by recompiling it with custom settings etc.
I was thinking this through yesterday and I’d like to make it a multiplatform engine that would allow creating these small books on all consoles and others platforms (that’s also why I want to avoid reading files). This is my vision:
Have a repo with a template file (let’s say main.txt) for the engine.
Have different files implementing each platforms specifics, e.g. platform_pokitto.h, platform_arduboy.h – these implement the main loop, function to set pixels, specify display resolution, implement functions to get key states, optionally save a bookmark etc.
Have a python script that takes the book plain text, platform, settings etc., that creates a single compilable book.c. The script would take the engine template, merge it with the platform specific code and add the book data (it could try to compress the text, preprocess it, format it in some way etc.)
That’s kind of a bigger project tho, so I don’t know if I want to get it started, but I think it would be nice to have this.
What exactly is wrong with reading from SD card?
It’s not a limited or uncommon resource.
Near enough everybody has an SD card and people would just be using the SD card to flash the books onto their Pokitto anyway, why not save them the trouble of flashing?
That’s going to multiply the workload by the number of platforms you want to support.
Besides which, instead of doing that you’d be better off coming up with some kind of API that exposes the features of each platform you want to support in a unified way.
That way you could write the API and its implementations just once and then anything you want to port to multiple platforms you just rewrite to target that API.
But as this is the Pokitto forum, that sort of thing is almost certainly out of scope here.
It’s bloat, requires extra code/drivers and requires this type of memory be present, which also comes with its own set of issues, bugs and effort. As I say, I don’t object to anyone doing it, but I like the philosophy of not using what is not necessary, in the spirit of suckless programs (which e.g. avoid reading config files by having config as part of source code).
This is completely untrue, platform specific code is very thin, I am already doing this in my unannounced project, it works great.