Hello everyone.
I have written an app that uses SDL 1.2.
LaserBoy is free and open source:
http://laserboy.org/forum/index.php?topic=10.0
It’s pretty simple. All it really needs is a bitmapped screen area and keyboard events.
One of the things I really like about SDL 1.2 is that it can get to a bitmapped screen in many different ways.
My app runs (and looks) exactly the same in Windows, Mac OSX, Linux with X, plus it runs in a native Linux console, taking the whole screen via the Linux Framebuffer.
It runs very nicely in the console of the Raspberry Pi.
Is this still possible with SDL2?
Thanks so much. Have a great day!
James. 
The framebuffer console isn’t supported, but SDL 2.0.1 natively supports
the Raspberry Pi. :)On Mon, Oct 21, 2013 at 10:24 AM, James Lehman wrote:
**
Hello everyone.
I have written an app that uses SDL 1.2.
LaserBoy is free and open source:
DOWNLOAD IT HERE !!!
It’s pretty simple. All it really needs is a bitmapped screen area and
keyboard events.
One of the things I really like about SDL 1.2 is that it can get to a
bitmapped screen in many different ways.
My app runs (and looks) exactly the same in Windows, Mac OSX, Linux with
X, plus it runs in a native Linux console, taking the whole screen via
the Linux Framebuffer.
It runs very nicely in the console of the Raspberry Pi.
Is this still possible with SDL2?
Thanks so much. Have a great day!
James. [image: Smile]
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Sam Lantinga wrote:
The framebuffer console isn’t supported, but SDL 2.0.1 natively supports the Raspberry Pi. 
Oh! That’s kind-of a bummer.
I really liked the fact that I could run my app with no window manager. It runs really fast that way.
I wonder if there is any consideration about adding the ability for SDL2 to connect directly to the Linux Framebuffer.
My main interest in migrating from 1.2 to 2.0 is that I noticed that SDL2 would allow me to stream up to 8 channels of audio to a Dolby 7.1 sound device, plus I don’t want to be attached to a platform that is out of date and no longer supported.
Anyway… Thank you for your reply.
James.
SDL2 uses opengl or other hardware accelerated renderers now, It should be
a LOT faster than 1.2 even with X in the “middle”.On Wed, Oct 23, 2013 at 2:12 PM, James Lehman wrote:
**
Sam Lantinga wrote:
The framebuffer console isn’t supported, but SDL 2.0.1 natively supports
the Raspberry Pi. [image: Smile]
Oh! That’s kind-of a bummer.
I really liked the fact that I could run my app with no window manager. It
runs really fast that way.
I wonder if there is any consideration about adding the ability for SDL2
to connect directly to the Linux Framebuffer.
My main interest in migrating from 1.2 to 2.0 is that I noticed that SDL2
would allow me to stream up to 8 channels of audio to a Dolby 7.1 sound
device, plus I don’t want to be attached to a platform that is out of date
and no longer supported.
Anyway… Thank you for your reply.
James.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Andre D wrote:
SDL2 uses opengl or other hardware accelerated renderers now, ?It should be a LOT faster than 1.2 even with X in the “middle”.
Well… I’m not quite sure I’m ready for that!
LaserBoy creates a 3D vector art space made of signed short integers. Data is stored that way in the open standard for laser vector art file format (ILDA) and that is also the exact same way the data gets exported to time formatted multi-channel wave files that contain the control signals for the laser projector.
So I do all the memory modeling and math in Generic C++ for 3D to 2D vector display and vector to raster translations.
In a nutshell, I make a screen sized bitmap in memory and blast that to the screen whenever there is a keyboard event.
All of the line plotting and text rendering is done in my own code into the bitmap memory.
I’m not sure how I would do this in OpenGL. I’ve never used it!
LaserBoy started out as an application on top of a Linux Framebuffer API that I also wrote.
SDL 1.2 gave me a VERY EASY migration route to be able to compile one single code set and get it to work exactly the same on all relevant systems.
The fact that LaserBoy was designed to run in the Linux Console is what gave it the characteristics and style that it has.
James.
SDL still provides a surface abstraction which does all the magic in the
backend. Should be a black box port from your perspective.On Wed, Oct 23, 2013 at 2:40 PM, James Lehman wrote:
**
Andre D wrote:
SDL2 uses opengl or other hardware accelerated renderers now, It should
be a LOT faster than 1.2 even with X in the “middle”.
Well… I’m not quite sure I’m ready for that!
LaserBoy creates a 3D vector art space made of signed short integers. Data
is stored that way in the open standard for laser vector art file format
(ILDA) and that is also the exact same way the data gets exported to time
formatted multi-channel wave files that contain the control signals for the
laser projector.
So I do all the memory modeling and math in Generic C++ for 3D to 2D
vector display and vector to raster translations.
In a nutshell, I make a screen sized bitmap in memory and blast that to
the screen whenever there is a keyboard event.
All of the line plotting and text rendering is done in my own code into
the bitmap memory.
I’m not sure how I would do this in OpenGL. I’ve never used it!
LaserBoy started out as an application on top of a Linux Framebuffer API
that I also wrote.
SDL 1.2 gave me a VERY EASY migration route to be able to compile one
single code set and get it to work exactly the same on all relevant systems.
The fact that LaserBoy was designed to run in the Linux Console is what
gave it the characteristics and style that it has.
James. [image: Smile]
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
It should work with EGL on the Pi, which doesn’t require X.
JosephOn Wed, Oct 23, 2013 at 09:12:04PM +0000, James Lehman wrote:
Sam Lantinga wrote:
The framebuffer console isn’t supported, but SDL 2.0.1 natively supports the Raspberry Pi.
Oh! That’s kind-of a bummer.
I really liked the fact that I could run my app with no window manager. It runs really fast that way.
I wonder if there is any consideration about adding the ability for SDL2 to connect directly to the Linux Framebuffer.
My main interest in migrating from 1.2 to 2.0 is that I noticed that SDL2 would allow me to stream up to 8 channels of audio to a Dolby 7.1 sound device, plus I don’t want to be attached to a platform that is out of date and no longer supported.
Anyway… Thank you for your reply.
I wonder if there is any consideration about adding the ability for SDL2
to connect directly to the Linux Framebuffer.
This is something that could be re-added. I think it could be useful for
special cases (low-end embedded device that understands it only gets a
software renderer). It would be really painful to try and do complicated
rendering on it, though.
That being said, for your use case–blasting a prerendered buffer of
pixels to the screen–you can do that with SDL2 on the Raspberry Pi with
an equivalent to the framebuffer console…behind the scenes, SDL will
upload the pixels to an OpenGL ES texture and draw a quad with those
pixels, but it looks like fbcon (more or less) to your app.
Might even be faster than fbcon on the Pi? I’d be curious to see.
Anyhow, get the latest SDL2 and read this…
https://wiki.libsdl.org/MigrationGuide#Video
…specifically, this section…
https://wiki.libsdl.org/MigrationGuide#If_your_game_just_wants_to_get_fully-rendered_frames_to_the_screen
–ryan.
2013/10/24, Ryan C. Gordon :
This is something that could be re-added. I think it could be useful for
special cases (low-end embedded device that understands it only gets a
software renderer). It would be really painful to try and do complicated
rendering on it, though.
Dunno, as long as you don’t go crazy and your resolution isn’t very
high (I’m not sure I’d try above 640?480 for anything interactive,
maybe 1024?768 for not-so-demanding stuff) the software renderer
should do just fine. In such a low-end embedded device chances are
you’re more likely to use it for an UI than anything else, and at that
it’d be pretty useful.
I really like the fact that there is no difference in the code or the way the app needs to be compiled or run to make it work in the Linux Framebuffer.
I think it’s really amazing when it can automatically detect that X is not running and use the Framebuffer in console mode.
Maybe I’m old-school, but When I use a Linux machine I am almost always in the console.
James.