#171198 - 18/07/2003 06:10
Fixing vfdlib for v3.00
|
addict
Registered: 14/11/2000
Posts: 474
Loc: The Hague, the Netherlands
|
Are there any volunteers for fixing vfdlib on v3.00?
It does not seem the original author, Richard Kirkby
is on this board.
The rendering of text using this library does not seem to work
anymore with the fonts supplied with v3.00-alpha3.
As a workaround one could probably copy the old fonts
to a separate location and use those, but this is tedious.
Pim
|
|
Top
|
|
|
|
|
#171199 - 18/07/2003 06:48
Re: Fixing vfdlib for v3.00
[Re: pim]
|
carpal tunnel
Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
|
Richard hasn't posted since February (his BBS name is kirkis) but he's always been good about responding to emails. I spoke with Tony F. yesterday about this font issue and said that if the Empeg guys could provide me with the specs for the new font format, I could give it a go.
|
|
Top
|
|
|
|
|
#171200 - 18/07/2003 08:53
Re: Fixing vfdlib for v3.00
[Re: pim]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31575
Loc: Seattle, WA
|
Yeah, I suspect that what happened is that 3.0 has revamped the font files to use unicode, so if you re-use the player fonts in VFDlib, the 3.0 fonts won't work. The solution would be, as you said, to upgrade VFDlib to support both possible font sets and autodetect which is present. We need only to know the spec for the new font files, and I've already placed a request for this with The Guys. They're pretty busy with some Real Life deadlines right at the moment, so I wouldn't expect a reply immediately.
There's no chance that someone could simply look at the new font files and reverse-engineer the spec, is there? Maybe it's as simple as "the file format is the same, you just have a larger unicode index instead of an 8-bit index"?
|
|
Top
|
|
|
|
|
#171201 - 18/07/2003 09:02
Re: Fixing vfdlib for v3.00
[Re: tfabris]
|
carpal tunnel
Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
|
There's no chance that someone could simply look at the new font files and reverse-engineer the spec, is there? Maybe it's as simple as "the file format is the same, you just have a larger unicode index instead of an 8-bit index"? Possible, but more difficult, and if the team isn't in a hurry to release 3.0, I'm not in a hurry to fix vfdlib for 3.0.  I'd rather have a spec in front of me than count on Doing the Right Thing with reverse engineering. Or at least someone with a blue nickname to say exactly what you just said about a larger unicode index.
|
|
Top
|
|
|
|
|
#171202 - 18/07/2003 09:16
Re: Fixing vfdlib for v3.00
[Re: tonyc]
|
addict
Registered: 14/11/2000
Posts: 474
Loc: The Hague, the Netherlands
|
If I recall correctly, the new fonts are smaller. So they might
be encoded more efficiently, while supporting larger character
sets at the same time.
According to this thread, the character sets haven't grown, though.
Pim
|
|
Top
|
|
|
|
|
#171203 - 18/07/2003 09:56
Re: Fixing vfdlib for v3.00
[Re: pim]
|
carpal tunnel
Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
|
Your analysis would seem to be correct about new fonts being more efficiently encoded:
17588 large.bf
15626 large.bf.new
9272 medium.bf
8502 medium.bf.new
6500 small.bf
6102 small.bf.new
My guess is that efficiency comes at the expense of ease in decoding, but I'm sure it's not rocket science.
|
|
Top
|
|
|
|
|
#171204 - 18/07/2003 13:14
Re: Fixing vfdlib for v3.00
[Re: tfabris]
|
carpal tunnel
Registered: 24/01/2002
Posts: 3937
Loc: Providence, RI
|
There's no chance that someone could simply look at the new font files and reverse-engineer the spec, is there? Maybe it's as simple as "the file format is the same, you just have a larger unicode index instead of an 8-bit index"?
I'm sure there's a chance it could be done, but I bet most of the people who could do it are either busy or insufficiently special.
|
|
Top
|
|
|
|
|
#171205 - 20/07/2003 08:58
Re: Fixing vfdlib for v3.00
[Re: Daria]
|
carpal tunnel
Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
|
Well, I'm not the best reverse-engineer on the planet, but I can find no obvious file format for the new files. If anyone else wants to try, be my guest, but unless someone can get me a format spec (or the old spec and tell me what the differences are) I won't be the one patching vfdlib.
|
|
Top
|
|
|
|
|
#171206 - 20/07/2003 10:28
Re: Fixing vfdlib for v3.00
[Re: tonyc]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31575
Loc: Seattle, WA
|
Cool, thanks for trying.
And by the way, I sent Tony *just* the font files, not a full copy of 3.0.
|
|
Top
|
|
|
|
|
#171207 - 20/07/2003 11:28
Re: Fixing vfdlib for v3.00
[Re: tfabris]
|
carpal tunnel
Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
|
And by the way, I sent Tony *just* the font files, not a full copy of 3.0. Rub it in why don't you.
|
|
Top
|
|
|
|
|
#171208 - 20/07/2003 14:16
Re: Fixing vfdlib for v3.00
[Re: tfabris]
|
carpal tunnel
Registered: 21/05/1999
Posts: 5335
Loc: Cambridge UK
|
This is a bad week to ask for, well, pretty much anything - but hopefully next week I can dig out the font spec. I also don't mind if someone sends 3.0 to Tony for app fixing purposes.
Rob
|
|
Top
|
|
|
|
|
#171210 - 21/07/2003 18:01
Re: Fixing vfdlib for v3.00
[Re: pim]
|
new poster
Registered: 17/03/2002
Posts: 21
|
Hi Guys,
I'm still around but have zero time to devote to empeg development. I couldn't even begin to try fixing the problem without v3.00 anyways.
If someone is kind enough to take on the task of doing the fix I'd be happy to put it into a new vfdlib release.
Richard
--
|
|
Top
|
|
|
|
|
#171212 - 18/09/2003 21:21
Re: Fixed vfdlib for v3.00
[Re: Daria]
|
carpal tunnel
Registered: 24/01/2002
Posts: 3937
Loc: Providence, RI
|
And actually, in fairness, it's not done. I'm still trying to figure out what the deal with the last 32 characters is.
|
|
Top
|
|
|
|
|
#171213 - 18/09/2003 21:51
Re: Fixed vfdlib for v3.00
[Re: Daria]
|
carpal tunnel
Registered: 24/01/2002
Posts: 3937
Loc: Providence, RI
|
In order for this to make sense, see previous patch.
unk2 is an offset. At that offset appears to be a table, which appears to be a pair of char for each entry. I'm not sure what the purpose is, since it appears the first char in the pair counts up from 0, and the other is always 0.
At least, looking at 13pixel.bf and large.bf both seem to indicate this.
Hm. Looking at 13pixelnumeric.bf, I guess the table is actually one which tells us at what offset to fill in the character.
Ok, a little more coding...
|
|
Top
|
|
|
|
|
#171214 - 18/09/2003 21:55
Re: Fixed vfdlib for v3.00
[Re: Daria]
|
carpal tunnel
Registered: 24/01/2002
Posts: 3937
Loc: Providence, RI
|
Hm. No, I understand now. Finished fix shortly.
|
|
Top
|
|
|
|
|
#171215 - 18/09/2003 22:31
Fixed better vfdlib for v3.00
[Re: Daria]
|
carpal tunnel
Registered: 24/01/2002
Posts: 3937
Loc: Providence, RI
|
Ok, this one should deal correctly with the packing. It appears to work with the v2 and the v3 fonts I have. It's not clear I have all the v3 fonts.
Attachments
178789-vfdlib.diff2 (111 downloads)
|
|
Top
|
|
|
|
|
#171216 - 19/09/2003 05:39
Re: Fixed vfdlib for v3.00
[Re: Daria]
|
addict
Registered: 14/11/2000
Posts: 474
Loc: The Hague, the Netherlands
|
Hey that's great! Unfortunately I won't be able to try it out, as I'm just packing for a short holiday trip to the US (Chicago & New Orleans). I will certainly make a new build of my vfdlib-enabled rsync port when I return.
Thanks,
Pim
|
|
Top
|
|
|
|
|
#171217 - 19/09/2003 08:37
Re: Fixed vfdlib for v3.00
[Re: pim]
|
carpal tunnel
Registered: 24/01/2002
Posts: 3937
Loc: Providence, RI
|
Actually, I was lying in bed thinking about it, and there are still 2 bugs. I'll try to get a corrected patch out before I leave for Ohio.
|
|
Top
|
|
|
|
|
#171218 - 19/09/2003 08:40
Re: Fixed vfdlib for v3.00
[Re: Daria]
|
carpal tunnel
Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
|
Actually, I was lying in bed thinking about it, and there are still 2 bugs. I'll try to get a corrected patch out before I leave for Ohio. Great stuff! I had planned to restart emphatic development soon so I'll give this a shot once you've got the bugs worked out.
|
|
Top
|
|
|
|
|
#171219 - 19/09/2003 08:42
Re: Fixed vfdlib for v3.00
[Re: tonyc]
|
carpal tunnel
Registered: 24/01/2002
Posts: 3937
Loc: Providence, RI
|
One is easy. free(cOffset); before the font register routine returns.
The other should also be easy, I'm testing it now.
|
|
Top
|
|
|
|
|
#171220 - 19/09/2003 08:44
Fixed vfdlib for v3.00 ter
[Re: Daria]
|
carpal tunnel
Registered: 24/01/2002
Posts: 3937
Loc: Providence, RI
|
This one won't write into random memory it shouldn't when it finds a character that shouldn't be mapped.
Attachments
178817-vfdlib.diff3 (93 downloads)
|
|
Top
|
|
|
|
|
#171221 - 19/09/2003 12:29
Re: Fixed vfdlib for v3.00
[Re: pim]
|
veteran
Registered: 01/10/2001
Posts: 1307
Loc: Amsterdam, The Netherlands
|
In reply to:
I'm just packing for a short holiday trip to the US (Chicago & New Orleans)
New Orleans OK, but holiday in chicago?
|
|
Top
|
|
|
|
|
#171222 - 19/09/2003 12:44
Re: Fixed vfdlib for v3.00
[Re: julf]
|
carpal tunnel
Registered: 25/12/2000
Posts: 16706
Loc: Raleigh, NC US
|
From what I hear, it's a toddlin' town.
_________________________
Bitt Faulk
|
|
Top
|
|
|
|
|
#171223 - 19/09/2003 12:56
Re: Fixed vfdlib for v3.00
[Re: wfaulk]
|
old hand
Registered: 01/05/2003
Posts: 768
Loc: Ada, Oklahoma
|
I saw a man, he danced with his wife.
_________________________
-Michael West
|
|
Top
|
|
|
|
|
#171224 - 23/09/2003 18:41
Re: Fixed vfdlib for v3.00 ter
[Re: Daria]
|
carpal tunnel
Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
|
Okay, vfdlib (as written) doesn't seem to be working for me with 3.0 fonts. Here's where vfdlib_registerFont bombs out:
if (bfHeader.version == 2) {
fseek(fp, bfHeader2.offset, SEEK_SET);
if (fread(cOffset, sizeof(CharOff), totalChars, fp) < totalChars) {
fclose(fp);
return -1;
}
}
.
I threw in some debug and the fread() call seems to be reading 115 chars, and totalChars seems to always be 200.
I tried having it continue on regardless of what fread() returns, and after everything loads up, this is what I get in emphatic:
The characters all seem to be formed properly (individually) but the character map seems out of place... Watching lyrics scroll by looks pretty funny.
Any idea what's up? I'm using small.bf, medium.bf, and large.bf (the 3.0 versions.)
|
|
Top
|
|
|
|
|
#171225 - 23/09/2003 20:20
Re: Fixed vfdlib for v3.00 ter
[Re: tonyc]
|
carpal tunnel
Registered: 24/01/2002
Posts: 3937
Loc: Providence, RI
|
I'll look later. Maybe when I cleaned it up I broke something.
|
|
Top
|
|
|
|
|
#171226 - 23/09/2003 20:42
Re: Fixed vfdlib for v3.00 ter
[Re: tonyc]
|
carpal tunnel
Registered: 24/01/2002
Posts: 3937
Loc: Providence, RI
|
Oh, sh*t.
It works when I run gpsapp_host on a PC, and fails in the way you describe on an empeg I dropped the fonts on.
|
|
Top
|
|
|
|
|
#171227 - 23/09/2003 20:50
Re: Fixed vfdlib for v3.00 ter
[Re: Daria]
|
carpal tunnel
Registered: 24/01/2002
Posts: 3937
Loc: Providence, RI
|
Ok, I know why, and given what I was thinking earlier today it makes sense. It's not a table of 2 chars, it's a list of shorts, so presumably it is some encoding supporting more than 256 characters.
|
|
Top
|
|
|
|
|
#171228 - 23/09/2003 20:53
Fixed vfdlib for v3.00 final try?
[Re: Daria]
|
carpal tunnel
Registered: 24/01/2002
Posts: 3937
Loc: Providence, RI
|
Ok, this time for sure?
Attachments
179371-diff (94 downloads)
|
|
Top
|
|
|
|
|
#171229 - 23/09/2003 22:26
Re: Fixed vfdlib for v3.00 final try?
[Re: Daria]
|
carpal tunnel
Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
|
Splendid. That did the trick!
Awesome work. Your sudden inspiration has even inspired me to play with emphatic a little bit.
|
|
Top
|
|
|
|
|
#171230 - 23/09/2003 22:30
Re: Fixed vfdlib for v3.00 final try?
[Re: tonyc]
|
carpal tunnel
Registered: 24/01/2002
Posts: 3937
Loc: Providence, RI
|
I need to finisdh some work stuff, and then I hope to do something more. I don't know what yet.
|
|
Top
|
|
|
|
|
#171231 - 24/09/2003 09:59
Re: Fixed vfdlib for v3.00 final try?
[Re: Daria]
|
carpal tunnel
Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
|
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.
|
|
Top
|
|
|
|
|
#171232 - 24/09/2003 10:14
Re: Fixed vfdlib for v3.00 final try?
[Re: tonyc]
|
carpal tunnel
Registered: 24/01/2002
Posts: 3937
Loc: Providence, RI
|
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.
|
|
Top
|
|
|
|
|
#171233 - 24/09/2003 10:20
Re: Fixed vfdlib for v3.00 final try?
[Re: Daria]
|
carpal tunnel
Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
|
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.
|
|
Top
|
|
|
|
|
#171234 - 24/09/2003 10:27
Re: Fixed vfdlib for v3.00 final try?
[Re: tonyc]
|
carpal tunnel
Registered: 24/01/2002
Posts: 3937
Loc: Providence, RI
|
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.
|
|
Top
|
|
|
|
|
#171235 - 24/09/2003 10:50
Re: Fixed vfdlib for v3.00 final try?
[Re: tonyc]
|
carpal tunnel
Registered: 24/01/2002
Posts: 3937
Loc: Providence, RI
|
Don't know. Should probably ask, but I suspect he's been busy, and I know I've been busy.
|
|
Top
|
|
|
|
|
#171236 - 25/09/2003 18:04
Re: Fixed vfdlib for v3.00 final try?
[Re: Daria]
|
carpal tunnel
Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
|
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?
|
|
Top
|
|
|
|
|
#171237 - 25/09/2003 21:13
Re: Fixed vfdlib for v3.00 final try?
[Re: tonyc]
|
carpal tunnel
Registered: 24/01/2002
Posts: 3937
Loc: Providence, RI
|
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.
|
|
Top
|
|
|
|
|
#171238 - 26/09/2003 07:18
Re: Fixed vfdlib for v3.00 final try?
[Re: tonyc]
|
carpal tunnel
Registered: 24/12/2001
Posts: 5528
|
Somebody did get the GD library working I believe. Can't quite remember what application it was actually in however.
|
|
Top
|
|
|
|
|
#171239 - 26/09/2003 07:34
Re: Fixed vfdlib for v3.00 final try?
[Re: Daria]
|
carpal tunnel
Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
|
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?
|
|
Top
|
|
|
|
|
#171240 - 26/09/2003 07:39
Re: Fixed vfdlib for v3.00 final try?
[Re: tman]
|
carpal tunnel
Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
|
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.
|
|
Top
|
|
|
|
|
#171241 - 26/09/2003 09:33
Re: Fixed vfdlib for v3.00 final try?
[Re: tonyc]
|
carpal tunnel
Registered: 24/01/2002
Posts: 3937
Loc: Providence, RI
|
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?
|
|
Top
|
|
|
|
|
#171242 - 26/09/2003 10:22
Re: Fixed vfdlib for v3.00 final try?
[Re: Daria]
|
carpal tunnel
Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
|
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.
|
|
Top
|
|
|
|
|
#171244 - 26/09/2003 10:47
Re: Fixed vfdlib for v3.00 final try?
[Re: tonyc]
|
Carpal Tunnel
Registered: 08/02/2002
Posts: 3411
|
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.
_________________________
Mk2a 60GB Blue. Serial 030102962
sig.mp3: File Format not Valid.
|
|
Top
|
|
|
|
|
#171245 - 26/09/2003 11:09
Re: Fixed vfdlib for v3.00 final try?
[Re: tonyc]
|
carpal tunnel
Registered: 24/12/2001
Posts: 5528
|
Umm... 128 (width) * 32 (height) * 4bpp = 2048 bytes * 8...
|
|
Top
|
|
|
|
|
#171246 - 26/09/2003 11:11
Re: Fixed vfdlib for v3.00 final try?
[Re: genixia]
|
carpal tunnel
Registered: 24/12/2001
Posts: 5528
|
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.
|
|
Top
|
|
|
|
|
#171247 - 26/09/2003 11:12
Re: Fixed vfdlib for v3.00 final try?
[Re: tman]
|
carpal tunnel
Registered: 25/12/2000
Posts: 16706
Loc: Raleigh, NC US
|
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?
Edited by wfaulk (26/09/2003 11:14)
_________________________
Bitt Faulk
|
|
Top
|
|
|
|
|
#171248 - 26/09/2003 11:16
Re: Fixed vfdlib for v3.00 final try?
[Re: wfaulk]
|
carpal tunnel
Registered: 24/12/2001
Posts: 5528
|
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
|
|
Top
|
|
|
|
|
#171249 - 26/09/2003 11:16
Re: Fixed vfdlib for v3.00 final try?
[Re: tman]
|
carpal tunnel
Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
|
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.
|
|
Top
|
|
|
|
|
#171250 - 26/09/2003 11:22
Re: Fixed vfdlib for v3.00 final try?
[Re: tonyc]
|
carpal tunnel
Registered: 24/12/2001
Posts: 5528
|
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.
|
|
Top
|
|
|
|
|
#171251 - 26/09/2003 11:26
Re: Fixed vfdlib for v3.00 final try?
[Re: tman]
|
carpal tunnel
Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
|
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.")
|
|
Top
|
|
|
|
|
#171252 - 26/09/2003 11:29
Re: Fixed vfdlib for v3.00 final try?
[Re: tonyc]
|
carpal tunnel
Registered: 24/12/2001
Posts: 5528
|
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]
|
|
Top
|
|
|
|
|
#171253 - 26/09/2003 11:31
Re: Fixed vfdlib for v3.00 final try?
[Re: tman]
|
carpal tunnel
Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
|
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.
|
|
Top
|
|
|
|
|
#171254 - 26/09/2003 12:53
Re: Fixed vfdlib for v3.00 final try?
[Re: tman]
|
carpal tunnel
Registered: 24/01/2002
Posts: 3937
Loc: Providence, RI
|
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.
|
|
Top
|
|
|
|
|
#171255 - 26/09/2003 13:24
Re: Fixed vfdlib for v3.00 final try?
[Re: Daria]
|
carpal tunnel
Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
|
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.
|
|
Top
|
|
|
|
|
#171256 - 27/09/2003 06:08
Re: Fixed vfdlib for v3.00 final try?
[Re: Daria]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14483
Loc: Canada
|
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
|
|
Top
|
|
|
|
|
#171257 - 27/09/2003 09:46
Re: Fixed vfdlib for v3.00 final try?
[Re: mlord]
|
carpal tunnel
Registered: 24/01/2002
Posts: 3937
Loc: Providence, RI
|
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).
|
|
Top
|
|
|
|
|
#171258 - 15/10/2003 14:19
Re: Fixed vfdlib for v3.00 ter *DELETED*
[Re: Daria]
|
old hand
Registered: 09/01/2002
Posts: 702
Loc: Tacoma,WA
|
Post deleted by siberia37
|
|
Top
|
|
|
|
|
|
Previous Topic
Index
