Hi. I've been playing around with Allegro 5 on my Raspberry Pi for a little while now (enjoying it a lot, by the way). I recently purchased a small LCD and followed this tutorial to get the drivers working for it. Now I'd like to be able to display Allegro happenings to the TFT, but it doesn't work by default. It plays on my TV through composite cables, but not on the LCD itself. So, I was wondering if there was anyway to make it work with the LCD's framebuffer, or if it could detect and display on the LCD in any way possible. Is there a way to specify the framebuffer? Do you know?

Edit
I know that both pygame and SDL have things to allow for the setting of environment settings to use a framebuffer. For example, in pygame I'd use: os.environ["SDL_FBDEV"] = “/dev/fb1″, and in SDL I'd use: SDL_putenv(“SDL_FBDEV=/dev/fb1″);. Does Allegro have any such feature?

I appreciate feedback.

Allegro 5 on RPi can't use the framebuffer devices. It uses some broadcom thing to get OpenGL. The only way you could do it (if it is limited to fbdev) is fish out the old GP2X Wiz code from Allegro git history. That had a framebuffer device driver that should work with some tweaks.

I appreciate your reply, Trent.

So this "GP2X Wiz code" was under the Allegro 5 development at one point, or was it Allegro 4? Also, where would I find the git repository?

Allegro 5. There were some optimized blitting routines for it for 16 bit color... not sure they're faster than what we have now or not.

Interesting. Why was it removed/not included in proceeding versions of Allegro 5? Are there any plans to implement framebuffers to Allegro 5 at any point in the foreseeable future?

By framebuffer, you mean CPU addressable display memory? You can emulate it with glDrawPixels(), or I think you can still do it with DirectDraw for windows, just blitting a memory buffer to/from the video memory.

Pretty much, Arthur. Allegro has/uses some OpenGL at its core, right? Would the Allegro 5 library itself support glDrawPixels(), or would I need to include OpenGL in my project alongside Allegro 5?

I have to

#include  <allegro5/allegro_opengl.h>

and link in at least the GL library.

"...and link in at least the GL library." The wording on that bit throws me off. Care to elaborate?

I know very little about RP, if you're using GCC, you'd link -lGL at the command line, similar to -lallegro.

How is this screen connected? It sounded to me like it wasn't a regular monitor. If it's a regular monitor A5 should work with OpenGL. If it's just something that you plugin USB or something that gives you /de/fb* device, it won't work with OpenGL. You'll have to add framebuffer support to A5.

Just for fun, I threw together a little "framebuffer" demo. First couple seconds, it shows a blank white screen, then it draws a red line and blue line across the screen, and after four seconds, starts filling the screen with a gradient (one scanline per frame) and then after a few more seconds, draws 1000 random pixels per frame. It'll end by itself after the screen is full of dots, or hit ESC.

[EDIT]

I forgot the compile command

gcc -s -O2 -Wall main.c -o t -lallegro -lGL

In this case I think we're talking about the linux framebuffer "fbdev" drivers.

I remember playing with the framebuffer a bit a couple years ago on Slackware, but what difference does it make? In that demo I put up last post, you set ints in an array to whatever color you want them to be, then use glDrawPixels() to blit that to the screen. You could do a software rendered 3D game if you wanted.

You use the framebuffer device to actually output to the screen attached to it. And there may not be GL support on those devices.

So A5 for Raspberry Pi uses DirectX? Or A5 has something else?

[EDIT]

After googling a bit, I see that OpenGL ES doesn't have glDrawPixels().

First off, let me say that I am extremely appreciative of each of you posting your thoughts and ideas on this forum. Secondly, yes, this does pertain to the Linux framebuffer "fbdev" drivers. I have a small (128x160 resolution) TFT LCD attached to my RPi via GPIO pins, and have it attached to /dev/fb1. I followed this tutorial to get the drivers working.

Arthur, I appreciate you writing a demo for me. One thing I've noticed from examining the source files is that there is no GLES directory on Allegro 5.0.6. So, when I tried your demo, it threw me an error saying... "In file included from main.cpp:4:0:/usr/local/include/allegro5/allegro_opengl.h:63:21: fatal error: GLES/gl.h: No such file or directory compilation terminated." So, allegro_opengl.h is including GLES/gl.h, but that doesn't exist as far I can see on 5.0.6.

[EDIT]

I took a look at the 5.0.9 release and couldn't find GLES there either. Perhaps I'm blind?

After looking at the OPs links, yeah, no the LCD device he's talking about will NOT have hw GL support of any kind. Its a small TFT lcd riding on the SPI bus. It might be possible that the lcd driver on the tft lcd module might have some acceleration for basic things like clears and basic drawing, but I highly doubt it'll have anything more than that.

So basically, all he gets is framebuffer access to the device, which is likely going to be very slow as the SPI bus can be quite slow (1-10MB/s?).

append2:

It's built into the opengl code.

Actually, I have the console and x11 desktop environment displaying on the LCD at ~60 FPS, so the display itself is actually quite fast. As for the above being built into the OpenGL code, how come it can't procure the appropriate files upon compilation?

If Allegro 5 is ultimately unable to draw to my LCD, then the only other options are to 1) Use SDL (which I believe can accomplish this), or 2) Use an LCD with composite jacks, which would act like a regular TV. The issue with the first option is that I enjoy Allegro much more than SDL, and the second is that it would cost me more money and is more cumbersome. So at this point I'm willing to try virtually everything with Allegro.

Are you really sure the LCD is actually updating at 60fps? I somehow doubt it. Some google results hint at 32mhz being the maximum useable SPI frequency on the pi, which might get you 40fps for 16bit color.

I meant to say that allegro's OpenGL ES code is part of allegros OpenGL code. They aren't separate ports, a lot of the code between the two is very similar, so there's a few ifdefs here and there to determine whether you want GL or GLES for each port.

"Are you really sure the LCD is actually updating at 60fps? I somehow doubt it. Some google results hint at 32mhz being the maximum useable SPI frequency on the pi, which might get you 40fps for 16bit color." (Too lazy to properly quote you, sorry. Ha ha.)

I'm not an expert at frame rates, nor did I properly measure it myself, but it feels and definitely looks like ~60 FPS. I'm quite impressed with the small display, actually. Also keep in mind that LCDs on the Pi itself are quite experimental, so there's a lot of mention of it floating around, some of which is spot on and others which is outdated.

As for GL and GLES, do you know what ifdefs I'd need to use to specify one over the other? I'm unexperienced in this respect.

There is no GL or GLES support for your LCD device. I am 100% certain of that.

What you'll want to do, is try and get Mesa Software support on the fbdev device, and see if allegro plays well with that, or do as Trent suggested and see if you can't resurrect the old GPX Wiz driver code which knows what a /dev/fbX device is.

I imagine you mean this when you mention "Mesa Software"? As for resurrecting old drivers, do you know where the build for that is? I did a few quick searches for it and only came across mention of it on forums and a few entries from Trent's blog, but not source itself. Perhaps you'd know, Trent?

Thanks for the continual input, Thomas.

[EDIT]
You're correct about the lack of GL nor GL ES support on the Pi. I'm looking for the Wiz whatnots now. I pinpointed where Trent's work on the GP2X Wiz began; it was here. Also, it seems that the last entry in his blog regarding the Wiz was this one here. At least, the last I've seen so far. Cool stuff!

You have to go back in git history to find it. There are ways to search old history like git log --name-status. You can narrow the search by looking around those dates of those blog posts. git help <command> and Google will tell you all you need to know to dig it out.

Ha, scratch that. It was never removed from the repo. It's in src/gp2xwiz.

Wha? I could swear you committed a "remove gp2x" changeset. Maybe we're both crazy.

Ha ha; Trent, you rock! There it is: wiz_display_fb, wiz_display_opengl, wiz_joystick, and wiz_system! What I'm really here for is the wiz_display_fb, right; you think it could be modified to support what I have going on?

[EDIT]
Also, people on the Raspberry Pi forum are telling me that the Pi supports both GL and GL ES (there's even a sub-forum about it). Yet Allegro on the Pi doesn't use GL, does it?

Allegro uses OpenGL ES. But if I understand this thread right, the question is whether OpenGL ES (not Allegro) can work with your monitor (since it might just send the data to the HDMI port).

Oh, I see. Thanks, Elias. Then scratch the GL and GL ES whatnots. I'm looking at the GP2X files now.

[EDIT]
Taking a look at the wiz files, I've found a few issues. In wiz_system.c, the inclusion of "allegro5/internal/aintern_gp2xwiz.h" doesn't exist; the same applies to wiz_display_opengl.c. Also, aintern_bitmap.h and aintern_opengl.h are missing. As a matter of fact, this also applies to wiz_display_fb.c. This comes at no surprise though, as this is older, so it makes sense things go missing.

In those blog posts I made is the important stuff you need. There should be a libwiz or something like that attached to one post. That has the main bulk of the framebuffer code. Actually it's based on libcastor which you can probably find for wiz.

I haven't yet found the attached file(s) you speak of (still browsing the blog), but I did find libcastor 0.2, which debuted on January the 26th, of 2009. The contents of the libcastor files are opaque to me; I understand C's constructs and whatnot, but it's difficult to follow... Aah, I see there's a readme with documentation links. I'll explore those for a while.

[EDIT]
The documentation site has a lovely SQL error; nice. Trent, what you did was modeled off of the libcastor files (or perhaps modified off of)?

I modified libcastor but only slightly. You should be able to start with that and work from there.

Sounds good; thanks, Trent. I don't quite know where to start with this, but I'll give it a go and play with it for a while. Also, on an off-topic question: how long must a thread remain untouched for it to be locked by the system? I've gone places before and left threads for a while, only to return and have them locked. I'd rather than not happen here.

Threads get locked after 1 week of inactivity. But opening a new thread is no problem and is even encouraged. So don't worry man.

The stale threads are locked to avoid people dredging up stuff that's several months or years old, and nobody cares about them anymore. But if you have something truly valuable to say, go ahead and make a new thread.

Thanks for clearing that up for me! On other forums, posting new topics that continue threads which have been locked is deemed as spam, so I wasn't sure. Thanks for the input.

If the thread was locked my a moderator, then yes, continuing it in the same way the thread ended would be seen as spam or against the rules.

But even in the case it was locked by a moderator, if you continue it on topic, (threads usually get locked by a mod after they go way off topic) then its ok.

The rules here are fairly lax.

That's good to know, Thomas; thank you.

Trent, I found some files pertaining to the Wiz on your blog. I don't know if they are the correct files, but they're the only ones I've found so far. I'm looking them over now, trying to make sense of them. There is hope yet.

[EDIT]
You even were kind enough to upload a bitmap example file for the Wiz. I'll post it here just for the heck of it.

Well, there's no point in me looking up my modified version of libcastor really. All it did was combine the OpenGL libraries and libcastor and clean it up a little but that's mostly Wiz specific. If you're serious about writing a framebuffer driver, look into SDL's framebuffer code, or optionally libcastor's. When you get that far, the attached file might help with optimization (too big to inline.)

That is one file that was removed from the Allegro repo. I believe I got 30-60 fps on Wiz (a very slow system) with these routines.

I am serious about this, as it'd be quite helpful to me. I'm going at it somewhat blind though, so it'll take some time. I appreciate you giving me these files.

[EDIT]
I've been messing around with drawing low-level "graphics" (just colors really) to the framebuffer in C. It's pretty cool how this stuff works. So basically I'm getting a feel for how this stuff works before I go into attempting to make it work with Allegro. Cool stuff though.