View Single Post
Old 03-26-2012, 07:47 AM   #18
hawhill
Wizard
hawhill ought to be getting tired of karma fortunes by now.hawhill ought to be getting tired of karma fortunes by now.hawhill ought to be getting tired of karma fortunes by now.hawhill ought to be getting tired of karma fortunes by now.hawhill ought to be getting tired of karma fortunes by now.hawhill ought to be getting tired of karma fortunes by now.hawhill ought to be getting tired of karma fortunes by now.hawhill ought to be getting tired of karma fortunes by now.hawhill ought to be getting tired of karma fortunes by now.hawhill ought to be getting tired of karma fortunes by now.hawhill ought to be getting tired of karma fortunes by now.
 
hawhill's Avatar
 
Posts: 1,379
Karma: 2155307
Join Date: Nov 2010
Location: Goettingen, Germany
Device: Kindle Paperwhite, Kobo Mini
Well, thanks a lot for the friendly feedback so far.

As geekmaster already mentioned: This application will eat your battery fast. On the one hand, constantly updating the display is expensive in terms of power. And then the CPU is running at 90-100%, too. Although the CPU is very efficient, this will eat battery, too.

I did not really intend to present this as a useful application. However, it was evolved far enough to justify publishing it - it's a nice show case. And I was reading about raster image interpolation and doing experiments with it. So I implemented a simple, 4bpp-optimized ordered dither - and thought of a use case. I played with gnuboy before, so I knew its code structure which is easily extensible.

What I also didn't mention before: It should do not only GameBoy ROMs, but also GameBoy Color (GBC) ones. Well, don't expect color to show up on your e-ink screen :-)

inameiname: regarding your first question: The current implementation is highly optimized in some regards. E.g., each GameBoy pixel is exactly doubled in both dimensions (2x2 e-ink pixels represent one GB pixel). It is somewhat harder to settle on fractional multiplication here since this would introduce some multiplication/division operands that are really slow on our CPU. Doing 3x3 pixels might be an option, the problem however is that the 4bpp framebuffer needs a very clever algorithm for that in order to deal with the "half bytes" that represent a pixel. Using only even factors (as opposed to odd numbers) is just much easier. That said, I have an algorithm in mind that would always look at two source pixels and create a factor-6 dither out of them. That would increase the resulting display to 480x432. Going to a 4x4 factor, the screen wouldn't be big enough. We would get a width of 640px, where the K3 only has 600px. Also, the update speed would suffer a lot.

As for the second question: There are lots of NES emus out there. However, the harder part is to find one that isn't optimized specifically for i386. I played once with InfoNES, it's not all that good in terms of compatibility, though. And most NES emulators are very timing critical, e.g. sync'ing on VRefresh and stuff like that. That's not going to work so well on e-ink.

What I thought about and would like to see, however, is a ScummVM port :-)
hawhill is offline   Reply With Quote