Hi folks. I've been working on a little something I want to contribute to the empeg community. Find the file attached to this message.

From the readme:

I recocognized a barrier to implementing userland apps on the empeg/riocar as being the lack of custom graphics libraries. I personally would like to see a lot more development, and sought to help myself and others overcome the initial barrier by writing my own set of graphics routines.

I see a lot of potential for this library in combination with hijack (thanks to mlord) and the efforts of others for a wealth of cool userland apps on the empeg! Now if only someone would automate the installation process of apps then we would really be getting somewhere...

Features:

* Ability to draw points, lines, rectangles, ellipses, polygons, text and bitmaps.

* Includes 3 built in fonts to get you started in getting text onto the display.

* Drawing operations fully clipped to a user definable rectangle. Those of you hungry for more speed can bypass the clipping overhead when careful to ensure drawing operations will not leak outside the display area.

* Written in C with the empeg in mind, meaning fast, compact, optimized integer routines.

* Think you can do better? Please do! The code is open source - help to make it better and share the results with the rest of us.

end of snippet

I may release a small demo showing what my libraries can do, I just want to sort out a few issues first.

Please give me feedback. I want to improve the libraries in any way that will make them more useful to developers.

Happy coding!

Richard
--

awesome! checking this out...

Not even having tried this out yet, I can say with confidence that you are, without question, "the man." I was very hopeful someone would take on the task of a more optimized graphics lib, and this looks great! I'm going to give this a spin sometime this week, and maybe try to port my apps from GD.

Excellent work!!!

Oh, this library is sweet! I already have some plans for some programs I'm going to write with it.

I threw togetter a quit test program to see how the library worked, and it compiled on my first try! (That's pretty rare ) It just moves a string of text around the screen using the knob, and exits with a knob press.

Thanks again for putting this together,

John

P.S. If there are any more-newbie-than-I programmers who want to see how to use the fundamentals of hijack and this library, this has most of the basics-- binding to the menu, using the player's buttons, and clearing and placing text on the screen.

Hey Richard,

Just finished a pretty good deal of coding with your library. What can I say, it is awesome. Any chance of us getting the 8 point font the player and hijack use (or something like it) in the next release? What about anti-aliased fonts? (you couldn't change the shade on these of course, except maybe inverted.) I can't imagine that anyone will ever use VFPFONT_TINY, but I used the other two in one of the two apps I'm going to have finished pretty soon. I think there's an error in you documentation, but I doubt it will matter to many people. The sizes of the fonts as reported by getTextHeight() are 3,5, and 6 point, but the .h file says 3,4, and 5.

I thought it was your library at first that was doing some weird stuff with the pixels in column 0, until I realized it was happening in the player software as well! (and anywhere else when using the display) I wonder if other people see it. Anytime a pixel in column 1 is on, the pixel from the same row in column 121 is on as well, slightly dimmer! I noticed it when I was scrolling through some things and the column 121 pixels were matching the first column. I think its a hardware thing. It's not really noticable (I didn't until I started staring at the way things were displayed for hours at a time .

Oh, I thought of another interesting thing to consider implementing, but it might not be worth your time. What if you had a third mode, or a debug flag for the clipped mode that would stop executing or write to the std out whenever you tried to write outside the display area. In this way you could be reasonably sure that your code is sound before switching to unclipped mode. I actually haven't had a problem with speed in either of the two apps I've been working on, though. (However, they are both text based.)

Anyway, thanks so much for putting this together. It's really cool.

John

Anytime a pixel in column 1 is on, the pixel from the same row in column 121 is on as well, slightly dimmer!

Really?!

Anyway, if it wasn't so darn nice outside I would be porting my apps to this new lib... I also vote for an anti-aliased font like the smaller of the two player fonts (5 pixels high). I painstakingly replicated this in emptriv so I could squeeze five lines of text out of it, and I am quite certain the method I used to do so is horribly inefficient. I'd like to rewrite it some time using a standard font. I guess I'll wait for such a font to appear before I start porting.

Hi John,

In reply to:

---

Any chance of us getting the 8 point font the player and hijack use (or something like it) in the next release? What about anti-aliased fonts? (you couldn't change the shade on these of course, except maybe inverted.)

---

I figured that the fonts I supplied are a bit lacking. I came up with them myself, but they are far from perfect. It's pretty easy to add fonts if I have the bitmaps. If anybody is kind enough to donate graphics files (e.g. a single gif file showing every character) they would like for the built-in fonts I will consider adding them.
Another alternative is to read the font files used by the player. If someone can give the the details needed to do this then I will consider implementing this approach.

In reply to:

---

I think there's an error in you documentation, but I doubt it will matter to many people. The sizes of the fonts as reported by getTextHeight() are 3,5, and 6 point, but the .h file says 3,4, and 5.

---

Good spotting. Will fix in the next release.

In reply to:

---

Oh, I thought of another interesting thing to consider implementing, but it might not be worth your time.

---

Interesting idea. Whether I get around to doing this or not is hard to say. As you say, speed isn't much of an issue so for most apps using the clipped methods all of the time probably wouldn't be much of a waste.

In reply to:

---

Anyway, thanks so much for putting this together. It's really cool.

---

Thanks for the kind words. It's really cool for me to know that others are making use of my work.

Richard
--

I think Bruno (who goes by hybrid8 on this BBS but hasn't been seen in a long while) had done a lot about fonts and had even contributed changes to the player font to the 2.0 betas. Drop him an email at bruno(at)mypocket(dot)com and see if he has some suggestions as to how to extract the fonts from the player, etc.

I would give you the tiny font I created for my emptriv program, but it's just a cheap knockoff of the player's tiny font, and it's probably got some inaccuracies. Plus it doesn't have international symbols or anything.

Also, the font editor written by cypher uses the default font files. I would think he could explain the format of the .bf files.

His thread is here.

I will gladly second, third, and forth the motion to use the default fonts.* To me, the fonts are the most useful part of the library, given that the two apps I'm working on are text based (duh!).

Since they are anti-aliased, I'd also like the inverse of them. (I use use black-on-white text for unselected menu tabs.) Although that won't look as good because the "dim" pixel (2/4) is closer to the bright one than to the black one. (Pixel 2/4 is nearly identical in brightness to 3/4, which is a shame.) Your work with the library is awesome, keep it up!

John

* This can be done through cloning, or some other such process.

Good news guys!

Looks like your wish will be granted. I have succesfully managed to load and display the .bf files used by the player, thanks to Cypher's help in decyphering the format.

You can expect a new release soon, just give me a few days to put the finishing touches on the code.

Richard
--

Sweet. If it works as advertised, I can junk my crappy code for the tiny font I use in emptriv.

Hi Richard,

Any chance you might have a page to host your software at? I wanted to link to it from the RioCar.org developer info section, but I don't want to point at an attachment on the BBS. If you don't have a "home" for your software I would be happy to host it on my site. I think more people should start using this, and to do that, I think it'd help if it had a place to live on the web.

Just a thought.

Why not upload it to the files section of Riocar.org?

Good idea, I guess, but I prefer it when programs are hosted on author's sites, so that people go to the site and can get new versions. A budding developer might see a three-versions-out-of-date release of the libs and start using them, only to find out later things have changed in the new version.

Imagine if Hijack kernels had to be uploaded to riocar.org!!! Eep!

I knew this was something to think about too. I presently don't have a site. Thank you for the offer ynot_.

At the moment I just want to concentrate on getting the new release ready. Afterwards I will give the hosting issue more thought.

Richard
--

Hi guys,

vfdlib now has a home on the web, courtesy of sourceforge:

http://empeg-vfdlib.sourceforge.net/

I really wish I had more time to work on stuff. I've got a little special something in the works but I don't see it being complete for a few more weeks yet

Richard
--

Hey, don't sweat it, we've all slowed down our pace recently... Programmers are allowed to venture out into the sun every once in awhile... I'm sure I'll resume normal operations as the autumn approaches, but for now, it's too damn nice out to be spending time doing what I do for 8 hours out of every day to begin with!

Task #1 will be to port my apps to your new graphics lib. Should I hold off until this "special something" occurs, or does it matter?

No need to hold off. My latest project will only make use of my library, not change it in any way (unless I find some bugs that is!)

Richard
--

Ooooh a new user app... Can't wait!