Ok, this time for sure?

Splendid. That did the trick!

Awesome work. Your sudden inspiration has even inspired me to play with emphatic a little bit.

I need to finisdh some work stuff, and then I hope to do something more. I don't know what yet.

I need to finisdh some work stuff, and then I hope to do something more. I don't know what yet.

Hmm. In the userland arena, I'm not sure there's anything I'm particularly itching for. Most of the empeg things I'd want would be API changes in Hijack to allow for multiple apps to use the display, allow "context switching" between them, etc, a la some of the stuff that was discussed in the Hijack Wishes for 2K3 thread. I don't know if you're much into kernel hacking, but this is #1 on my empeg wish list. There was a lot of good discussion on ways to create a more flexible graphics/input API, but nobody really agreed on one particular way to do it.

Well, gpsapp can always use some love, but it's not clear if atttempting to do anything to gpsapp+roadmap is the right way, or trying to rewrite the display stuff would be better. And then, how to do routing... I was never good with graph theory, unfortuntely.

I was never good with graph theory, unfortuntely

Jan is pretty good in that arena though, isn't he? Does he still have plans to remain active in gpsapp development? I haven't seen him around the BBS much lately.

I don't know if you're much into kernel hacking

I used to a lot of it. I still do it least as much as is necessary to debug OpenAFS, which over the last few days has been a lot due to how lookups works and how we support rewriting part of the path based on the OS you're running (basically).

But part of the reason I've taken up the Mac gauntlet is massive disappointment at what's happened with Linux 2.6. I'm not interested in doing weird stuff so I can have the capability of having groups of processes running with the same unix uid having disjoint, possibly conflicting, groups of authentication credentials. What we did before was really a hack, and it won't work anymore without an even more heinous hack to allow it (Linux has no loadable syscall interface, and changes happened to make it hard to load a syscall anyway). That doesn't bother me. What bothers me is that basically people seem uninterested in either taking any interface offered which will solve the problem, or providing one, or suggestions to what they want, if they don't like what they've seen.

jaharkes did a patch for the issue which consisted of something like 47 lines of changes (add/change/removed lines); Really, having a small blob in the task structure to store presistent data which gets copied on fork/clone doesn't seem like a huge burden. Yet, here we are.

So, I'm basically ignoring the other issues which need to be dealt with before OpenAFS will run on Linux 2.6 (without the missing functionality, but it would still be able to read and write files); Either someone else will deal, or one of my jobs will force me to deal, or I'll blissfully not care.

Hijack, at least, is probably interesting enough to overcome the "I'm bitter at Linux", if I had something to do which might be interesting or useful. But I suspect I'd do poorly at implementing a graphics API. I might try anyhow.

Don't know. Should probably ask, but I suspect he's been busy, and I know I've been busy.

I don't know what yet.

I just thought of something for you to do with your empeg hacking time... vfdlib has bitmap support, but only if you load the bitmaps up in its own format (BITMAP_4BPP, etc.) I asked Richard awhile back to think about adding in libjpg or libpng support such that you can create a vfdlib bitmap from JPG or PNG files. This would be real sweet for a feature I'd like to put into emphatic (scrolling album covers.) How hard do you think that'd be?

Funny you asked. I wonder what I did with the colormap reducer I did when I thought it might be interesting to crop USGS maps to display as background for gpsapp... before proving to myself that 128x32 was simply too small for it to be worthwhile.

So, yeah, that's the thing. How do you allocate a colormap that makes sense? I don't know that I'm clever enough to figure out how to dither without doing something that will be a pig.

Somebody did get the GD library working I believe. Can't quite remember what application it was actually in however.

So, yeah, that's the thing. How do you allocate a colormap that makes sense?

*stares blankly*

I guess I naively thought that the JPG/PNG libs themselves would have options available for color-depth reduction and dithering. But upon further inspection I guess that's not the case. I think the GD graphics library I use in empan takes care of things automagically.

I'm not sure that dithering will even make much of a difference on a 128x32 screen. Maybe just calculating the intensity of each pixel and converting that to the closest "empeg color" would be a good start? So if pixel A is (255, 0, 0) and pixel B is (0, 0, 255) they'd look the same on the empeg display, but probably both be dimmer than a pure white pixel (255, 255, 255). Not sure how beautiful the results would be, but for a first crack at things, I'd try that, and then maybe look into how tough it'd be to add a dithering algorithm.

A few prayer sessions to the Google Gods found me this

http://thorkildsen.no/faqsys/docs/dither.c

Any help?

Somebody did get the GD library working I believe. Can't quite remember what application it was actually in however.

I can't take credit for making it work, but I did use it in 3 of my apps. I was trying to avoid using GD in emphatic because it's a real dog performance-wise.

I'll have to find whatever provides the px_ functions because I think px_wgrey and px_rgrey at least are things I'd want. Also, have you displayed the whole palette on the empeg? You can display more than 4 colors but iirc not many more than 4 were useful.

Is ~4 shades of "grey" going to be useful for displaying an album cover?

Also, have you displayed the whole palette on the empeg? You can display more than 4 colors but iirc not many more than 4 were useful.

From what I understand, while the display itself supports more than 4 shades, Hijack's sreenbuf is just 2048 bytes, so > 4 shades can't be represented. I think the stuff Toby does in the visuals involves straight assembly to the display which allows more "shades." And from what I've seen, other shades wouldn't be very useful due to too much flickering.

Is ~4 shades of "grey" going to be useful for displaying an album cover?

I think if it scrolled through the album cover vertically, yes. I did a few with empan and they were recognizable, though obviously not photorealistic. To give you an idea of what to expect, if you have emphatic installed, bring up its menu and hold down the knob while the "On" menu item is selected for a couple seconds, and let go. You'll see the emphatic "easter egg" which will show some credits and then scroll an image from the Simpsons. That's about the level of detail I'd expect for album covers.

Okay, that easter egg is TOO COOL.

From what I understand, while the display itself supports more than 4 shades, Hijack's sreenbuf is just 2048 bytes, so > 4 shades can't be represented. I think the stuff Toby does in the visuals involves straight assembly to the display which allows more "shades."

I don't remember seeing any kernel mechanism that would allow him to do so - 3 shades + black appears to be it.

Umm... 128 (width) * 32 (height) * 4bpp = 2048 bytes * 8...

The EMPEG_DISPLAY_WRITE_PALETTE ioctl can select the 4th palette which is a 1 to 1 mapping. Most of the values don't work very well though.

It's 4bpp, not 4Bpp.

That is: 128 * 32 * 0.5B = 2048B

Edit: On second thought, I think I don't understand what you're saying. Where does the *8 come from?

The display buffer is 2048 bytes and 8 bits per byte so you get 16384 bits in total.
height x width x bits_per_pixel = 128 x 32 x 4 = 16384 bits as well

Umm... 128 (width) * 32 (height) * 4bpp = 2048 bytes * 8...

I echo Bitt's sentiments. What are you trying to say? Your math confirms what I was saying, which is that it only supports 4-bit color depth.

Edit: I am officially an idiot. 4bpp = 16 shades. I need more coffee.

It's two pixels packed into each byte in the screen buffer. Which means each pixel is 4 bits. This can represent 16 different values not just 4.
Normally the kernel driver will remap it so that it's only 4 distinct values but if you use the EMPEG_DISPLAY_WRITE_PALETTE ioctl then you can get all 16 "colours" on the display.

then you can get all 16 "colours" on the display.

Yep. But as I said before (trying to appear intelligent after screwing up the math so poorly) the other shades are pretty much worthless everywhere except in the visuals (where flicker can be considered "part of the effect.")

Toby did time dithering as well to increase the number of effective intensities. [edit]Hugo said that John tried out the shades again and found one more was okay. It's not used however.[/edit]

And I think somebody did retry the entire range of possible intensities and found that 1 or 2 of them weren't that bad actually.

Hmm. I'd be interested in seeing that.

I had a program somewhere which just did a 'test pattern' of 16 bands of color. It would be easy to write again, which is good, since I may have tossed it.

I had a program somewhere which just did a 'test pattern' of 16 bands of color. It would be easy to write again, which is good, since I may have tossed it.

Well, regardless of whether it's 2bpp or 4bpp, I'd love to see JPG/PNG format in vfdlib.

Do you have a Central?

I'm thinking of porting parts of Hijack to the Rio Central's kernel in hope of opening up that platform somewhat. Initially, just kftpd.c from the Hijack sources.

Problem is, I don't have a Rio Central. So if somebody else wanted to take over this mini-project..

Cheers

No Central. The thought of getting one has crossed my mind, but I suspect I shouldn't flush any money until the oil spill cleanup is done, since I don't know how much of that the insurance will cover (they did cover 100% minus the deductable of the tank, oil, and oil dry removal the night of the incident).