[Book]The Little Prince

The Little Prince

The classic children’s book in Pokitto form.
Text only as the original images are not in the Public Domain.

Download: TheLittlePrince.bin (90.8 KB) | TheLittlePrince-AAFont.bin (83.6 KB)

  • Up: Jump to start of the book
  • Down: Jump to last page read
  • A: Next page
  • B: Save bookmark
8 Likes

Ohhh, beautiful <3 My favorite PD book is Flatland, can we do that too? :slight_smile:

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.

4 Likes

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. :thinking:

1 Like

Store it in RAM then?

EDIT: But that actually takes up flash too, right? Sorry :slight_smile:

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)

image

This one is with 16 color palette only:

image

EDIT:

According to my magnifying glass Pokitto display is vertical BGR.

EDIT:

Which is best?

Why not store the text on the SD card and just read it off a page or two at a time?

(Also this source code has no licence…)

1 Like

Hmmm…probably because it’s in Java and Java don’t have SD functionality right now?:stuck_out_tongue:

Then this is an excellent excuse to add SD support.

Either that or just port it to C++ while it’s still a small (1 page) program.
A few functions are mostly inline C++ anyway.

2 Likes

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.

Interesting idea, this could be an option.

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.

1 Like

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:

Looking at that I get the feeling that @spinal’s idea would result in much clearer text. The obvious trade-off being more frequent line-breaks.


Scope. This is “[Book]The Little Prince” and putting everything in flash works well enough.

As for the lack of a licence, there isn’t much source code either. I didn’t think anyone would be interested in licensing a snippet.

1 Like

90 degrees rotated seems to look much better, but I only have cell phone so the photo is bad:

you can try with this (only look at the bottom text, the above ones are messed up):

firmware.bin (83.5 KB)

1 Like

Much better.

2 Likes

BTW reminds me of this 1 pixel wide font, just a curiosity:

2 Likes

One good thing about fixed width: you don’t have to worry about keming (i.e. bad kerning).

Someone could, but regretably I get the feeling nobody will.

That’s fair enough, but ‘Flatland’ has crept in now too.
Before you know it you’ll have 50 books, each on a separate .bin.

Scope has a habit of growing. Make sure to preempt it at the first sign of growth.

Without a licence we literally don’t have permission to modify it,
the amount of code being used doesn’t change that fact.

If in doubt, label it MIT or CC0 and let people do with it as they please.

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.

1 Like

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.

The idea of a book on pokitto is rather cool, though imagine a pokitto reader, e ink screen about the size of an original iPhone or droid eris, , ,

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.