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?

EditI 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?

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.

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.

“Throughout history, poverty is the normal condition of man. Advances which permit this norm to be exceeded — here and there, now and then — are the work of an extremely small minority, frequently despised, often condemned, and almost always opposed by all right-thinking people. Whenever this tiny minority is kept from creating, or (as sometimes happens) is driven out of a society, the people then slip back into abject poverty. This is known as "bad luck.”

“Throughout history, poverty is the normal condition of man. Advances which permit this norm to be exceeded — here and there, now and then — are the work of an extremely small minority, frequently despised, often condemned, and almost always opposed by all right-thinking people. Whenever this tiny minority is kept from creating, or (as sometimes happens) is driven out of a society, the people then slip back into abject poverty. This is known as "bad luck.”

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

“Throughout history, poverty is the normal condition of man. Advances which permit this norm to be exceeded — here and there, now and then — are the work of an extremely small minority, frequently despised, often condemned, and almost always opposed by all right-thinking people. Whenever this tiny minority is kept from creating, or (as sometimes happens) is driven out of a society, the people then slip back into abject poverty. This is known as "bad luck.”

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

“Throughout history, poverty is the normal condition of man. Advances which permit this norm to be exceeded — here and there, now and then — are the work of an extremely small minority, frequently despised, often condemned, and almost always opposed by all right-thinking people. Whenever this tiny minority is kept from creating, or (as sometimes happens) is driven out of a society, the people then slip back into abject poverty. This is known as "bad luck.”

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.

“Throughout history, poverty is the normal condition of man. Advances which permit this norm to be exceeded — here and there, now and then — are the work of an extremely small minority, frequently despised, often condemned, and almost always opposed by all right-thinking people. Whenever this tiny minority is kept from creating, or (as sometimes happens) is driven out of a society, the people then slip back into abject poverty. This is known as "bad luck.”

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

“Throughout history, poverty is the normal condition of man. Advances which permit this norm to be exceeded — here and there, now and then — are the work of an extremely small minority, frequently despised, often condemned, and almost always opposed by all right-thinking people. Whenever this tiny minority is kept from creating, or (as sometimes happens) is driven out of a society, the people then slip back into abject poverty. This is known as "bad luck.”

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?).

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.

As for the above being built into the OpenGL code, how come it can't procure the appropriate files upon compilation?

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.