Okay I'm currently developing a game for the Empeg for which I am using a port of the GD graphics library. It basically gives you the routines to do rectangles, lines, ellipses, etc. and some simple text. Well, it's working well except that it's quite slow. All I'm doing is a simple menu system and when the player is running, it's very sluggish. Even when it's not, the graphics are way slower than they should be.

Now, I'm thinking that the GD library is hardly ARM optimized. So presumably things would benefit from some ARM assembly routines for low-level graphics. My assembly experience is limited to one class I took on Motorola 68000 assembly, so I'm hardly capable of doing this myself.

So is anyone aware of any work anyone's done in this arena that might be helpful? I know there are a lot of handhelds out there using the StrongARM so I thought someone might have tackled this issue. If there's nothing out there then I guess I'll have to use GD and wait for someone with better assembler knowledge to develop a lightweight 2D graphics API.

Anyway, I'd love to hear opinions on this issue.

At an initial guess, I'd say it's because of some floating-point algorithms in GD that the ARM does slowly. Try using the 1.x versions if you're not already. They relied less on floating-point arithmetic, IIRC.

Scan through some of the development sites for the GBA (Game Boy Advance). It's using an ARM and there are a lot of people playing around with assembly as well as writing APIs (these in C mostly).

Good luck.

Bruno

Hmm I don't own a GBA and thus am not familiar with any good sites. Any you're aware of? I've been doing some Google searches and haven't been coming up with anything resembling a graphics API.

Let me see if I can remember any....

www.gbadev.org
www.devrs.com/gba/

Obviously I suggested them as places to look for info and leads, not some place you'll find the code you're looking for. :) There are a lot of resourceful people, so maybe someone will have additional insight.

Don't forget that all new PocketPC machines are also using StrongARM. Ah, how far that series has come (and I thought it was being put to good use in the Newton).

Oh, and if you do ever get a GBA (they're pretty neat), then www.portablemonopoly.com is a site you'd want to check out for a lighting hack.

Bruno
Who's never owned a legacy Acorn product.

This explanation sounds plausible so I downgraded to GD 1.8.1 and built with that. Sadly there seems to be no speed difference. Still very sluggish.

I think some of it might be my fault... I'm attempting to recreate the Empeg player's small font (like the one used on the track details screen) because it's a nice small font and I need to get a lot of text on the screen. So I painstakingly created the font, converted it to the GD image format, and I have it do a gdImageCopy of each letter into the string I want to display. I am SURE this is inefficient but I couldn't think of a better way to do it. I thought of making a GD font for it, but GD fonts are only in one "color" so the shaded parts of the letters wouldn't work properly.

But even without my custom text routine, things looked pretty slow. So I'll look into some other options. GD 1.8.1 doesn't seem to make a difference. Thanks for the suggestion though.

Hi.

I somehow started creating a graphics lib for the empeg (and still would like to complete it). Could you list the functions you need? And specify exactly what those functions should do?
I was stuck trying to find out what to include in the lib without having any specific application in mind. And currently I am stuck with no time, but that should change shortly.

cu,
sven

Well I'm interested in just the basic 2D functions such as the ones that are in the GD library...

Draw a Pixel (x, y, color)
Draw a Line (x1, y1, x2, y2)
Draw a Rectangle (x1, y1, width, height)
Draw an Arc/Circle/Ellipse (x, y, width, height, start degrees, end degrees, color)
Draw a Polygon (array of points, number of points, color)

And filled versions of all of the rectangles, polygons, etc. It also has text display functions with some default font files. Check out The Docs for the functions they have.

It also has the ability to write fonts to the screen, but I wanted to use the tiny anti-aliased font from the empeg player, and the GD library doesn't have anti-aliased fonts. So I found a different way to do my text which requires a lot of image copying, but it works.

GD was really written for creating GIF, PNG, JPG images, not really for writing those images to a 128x32 display. So each of the above functions has to be given an "image pointer" to which the shapes are drawn. So brianosaurus wrote a function to convert that image object into a 2048-byte buffer which can be written to the display via normal methods (I'm using mlord's hijack ioctl for this and it's working well.)

I think the slowness I'm seeing is from three factors. First, as I mentioned, GD is not optimized for the Empeg. Second, I think the process of creating an image object and then iterating through the entire image and getting the color value of each pixel (as needs to be done to blit it to the Empeg's screen) is less efficient than simply writing to the display in the first place. Third, all the image copies I'm doing are probably not the best idea for writing text to the screen. Probably some slowdown there.

So I'm not sure how your library was taking shape, but those are the things I would like to see. Were you going to do you libraries in C or in assembler? What does it look like so far? I'm happy to hear that some work has been done in this area. Right now I have a servicable graphics library, but in the future it'd be nice to see something more Empeg-friendly. It's the least we can do after what mlord has put into his kernel mods.

Has anyone bugged the person writing the current set of visuals about this? Toby, if I'm not mistaken. I'm sure he'd have a lot of information that would be useful to both of you.

Bruno

Well, yeah, of course Toby is a wizard with ARM assembly and quite possibly has an extensive library of graphics routines on top of which the visuals are built. But he's an Empeg employee, the player software is closed-source, and the visuals are part of that source code. I hadn't seriously considered the prospect of them releasing any part of the source. If this were to happen it would be great, and would facilitate a LOT of good development, but I just didn't think it would be an option.

If getting some source from Toby is an option then I'd love to hear how we could make it happen. Otherwise I was looking for some contributions from non-Empeg types.

You'll never know if you don't ask. Specifically about information for accessing any draw API. If people don't ask for it they might never consider opening it up in the future. They've got IP to protect, but they can also provide a lot of doorways to 3rd party development with some documentation and interface to their existing code base. Just a suggestion in any case.

Bruno

You'll never know if you don't ask

Absolutely. And by all means Toby, Hugo, and the boys are all regular readers of these forums. When I asked my question about a graphics API, I was asking anyone who might have that knowledge. That includes the Empeg team.

We would of course would appreciate any assistance they can give us in this regard. But it's not like I'm asking a specific question about a specific hurdle I'm trying to overcome, I'm really asking for a complete Empeg graphics API. I didn't address them specifically on this request because I didn't consider the thought of them releasing any of their code, and knew some others had worked on a graphics API in the past.

Getting our hands on the assembler routines that are used for the visuals would be awesome, but I guess I didn't consider it as a possibility based on the previous responses to such requests.

In any event, the GD libraries are working well enough for me to release a "playable" version of my game in the next week or two. I was just looking ahead to other more graphics-intensive user apps which might be on the horizon.