Allegro.cc - Online Community

Allegro.cc Forums » Programming Questions » Framebuffer?

This thread is locked; no one can reply to it. rss feed Print
 1   2 
Framebuffer?
Eric Johnson
Member #14,841
January 2013
avatar

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.

Trent Gamblin
Member #261
April 2000
avatar

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.

Eric Johnson
Member #14,841
January 2013
avatar

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?

Trent Gamblin
Member #261
April 2000
avatar

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.

Eric Johnson
Member #14,841
January 2013
avatar

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?

Arthur Kalliokoski
Second in Command
February 2005
avatar

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.”

― Robert A. Heinlein

Eric Johnson
Member #14,841
January 2013
avatar

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?

Arthur Kalliokoski
Second in Command
February 2005
avatar

I have to

#include  <allegro5/allegro_opengl.h>

and link in at least the GL library.

“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.”

― Robert A. Heinlein

Eric Johnson
Member #14,841
January 2013
avatar

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

Arthur Kalliokoski
Second in Command
February 2005
avatar

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.”

― Robert A. Heinlein

Trent Gamblin
Member #261
April 2000
avatar

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.

Arthur Kalliokoski
Second in Command
February 2005
avatar

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.”

― Robert A. Heinlein

Thomas Fjellstrom
Member #476
June 2000
avatar

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

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Arthur Kalliokoski
Second in Command
February 2005
avatar

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. :o

“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.”

― Robert A. Heinlein

Thomas Fjellstrom
Member #476
June 2000
avatar

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

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Arthur Kalliokoski
Second in Command
February 2005
avatar

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

“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.”

― Robert A. Heinlein

Eric Johnson
Member #14,841
January 2013
avatar

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? :D

Thomas Fjellstrom
Member #476
June 2000
avatar

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

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:

Sheegoth said:

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

It's built into the opengl code.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Eric Johnson
Member #14,841
January 2013
avatar

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.

Thomas Fjellstrom
Member #476
June 2000
avatar

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.

Sheegoth said:

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.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Eric Johnson
Member #14,841
January 2013
avatar

"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.

Thomas Fjellstrom
Member #476
June 2000
avatar

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.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Eric Johnson
Member #14,841
January 2013
avatar

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!

Trent Gamblin
Member #261
April 2000
avatar

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.

Thomas Fjellstrom
Member #476
June 2000
avatar

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

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

 1   2 


Go to: