Raspberry Pi
category: code [glöplog]
gasman: that wasn't exactly serious ;) I do think there should be a bit more merging and a lot less fragmenting going on though, as it is we'll have more linux distress than computers in the world pretty soon.
Ah, and autocorrect has a fine sense of humour today, changing distro to distress :D
Mine now appears to have shipped from Farnell, despite that I ordered it on Friday. Website said there would be a 5 week wait!
Quick, write a good demo for it
Quote:
Quote:And having a recompiled distro which finally uses an ABI which fully supports the FPU is totally useless, integer float emulation is so much more fun.
If only linux was open source! Then they could have simply updated the original distro and saved all of the confusion and fragmentation.
That is technically what they did. They just changed the name because that ARMv6 ABI with hardware float support is not an officially supported platform of Debian.
...if coding graphics, what resolution are you using?
(framebuffer res)
Release Candidate 4 of RaspBMC just arrived: http://www.raspbmc.com/
Interface is much faster now, since its based on raspian now (hw-floats), playback is smooth as ever.
Interface is much faster now, since its based on raspian now (hw-floats), playback is smooth as ever.
The GertBoard (GPIOs, ADCs/DACs, Motor controller, fancy shit for hardware projects) can be ordered now from Element-14 (UK link).
SUKKZ!
hArDy./tRSi : Stop being a bellend.
So, you may have noticed that I released a RasPi demo at Evoke. I wrote it in Python, which was both a good thing (because it isn't C) and a bad thing (because it's mostly unchartered territory, and there's a distinct lack of documentation and support code for writing OpenGL ES in Python).
What I ended up writing is not just a demo: under the hood there's a cross-platform, demo-oriented OpenGL wrapper library called Shortcrust. (As in shortcrust pastry, because it's a wrapper for a pie... oh, please yourselves. I wanted to call it Piglet, but the name Pyglet was already taken. Bah.) It will select an appropriate backend depending on what platform you're running on: either PyOpenGL + GLUT for grown-up machines, or my own fairly patchy hooks into the proprietary Broadcom framebuffer / OpenGL ES stuff on an actual RasPi.
As a further demonstration of its potential, here's a port of Chocolux by Auld using the library - in principle the Python code here is a direct analogue of Shader Toy / GLSL Sandbox, so you ought to be able to replace the fragment shader with one of the many other examples that use the same API. Exactly how successful that is is for you to discover...
I intend to package up Shortcrust properly as an open-source project soon, but in the meantime, if writing OpenGL demos in Python on the Raspberry Pi sounds like your cup of tea, then you may like to have a poke around at the source code. At the moment it's just the minimal subset of OpenGL ES necessary for Avocado to run, but hopefully it's a useful starting point. (Just steer clear of the matrix module for now - it's severely broken, and half of the operations are probably back-to-front, which is why there's very little actual 3D in Avocado. I'll fix that for the next demo, I promise...)
What I ended up writing is not just a demo: under the hood there's a cross-platform, demo-oriented OpenGL wrapper library called Shortcrust. (As in shortcrust pastry, because it's a wrapper for a pie... oh, please yourselves. I wanted to call it Piglet, but the name Pyglet was already taken. Bah.) It will select an appropriate backend depending on what platform you're running on: either PyOpenGL + GLUT for grown-up machines, or my own fairly patchy hooks into the proprietary Broadcom framebuffer / OpenGL ES stuff on an actual RasPi.
As a further demonstration of its potential, here's a port of Chocolux by Auld using the library - in principle the Python code here is a direct analogue of Shader Toy / GLSL Sandbox, so you ought to be able to replace the fragment shader with one of the many other examples that use the same API. Exactly how successful that is is for you to discover...
I intend to package up Shortcrust properly as an open-source project soon, but in the meantime, if writing OpenGL demos in Python on the Raspberry Pi sounds like your cup of tea, then you may like to have a poke around at the source code. At the moment it's just the minimal subset of OpenGL ES necessary for Avocado to run, but hopefully it's a useful starting point. (Just steer clear of the matrix module for now - it's severely broken, and half of the operations are probably back-to-front, which is why there's very little actual 3D in Avocado. I'll fix that for the next demo, I promise...)
OpenGL ES on the Raspberry Pi is OpenGL ES. There aren't any py specific tricks (you could take advantage of it having a fixed GPU somehow, but it's not easy without pointers).
I offered myself to do a graphics programming on the raspberry pi talk at Sapo Codebits in November, but I have no idea on what I'll say about it in 45 minutes.
I offered myself to do a graphics programming on the raspberry pi talk at Sapo Codebits in November, but I have no idea on what I'll say about it in 45 minutes.
hm, maybe you could ask gloom about writing about it for Displayhack
Anyone doing coding C with no window system, what are you using for music playback with accurate timing?
You can set a pretty good low-latency blocksize with SDL at least. Just received mine and did a couple of experimental ports as warm-up. Interesting little board indeed. One big plus has been I can use the video monitor that is sitting there for the 8-bit gear. X is unusably slow and io-bound operations are sluggish in general, but I guess those will improve over time.
With the plain SDL fb some porting results were too ugly to publish, because of the lack of vsync and pages (please do tell if it's possible!). Need to put together some hack with ES when there's time. There's more to come :)
With the plain SDL fb some porting results were too ugly to publish, because of the lack of vsync and pages (please do tell if it's possible!). Need to put together some hack with ES when there's time. There's more to come :)
Marq: very cool, i'm interested to see how you get on!
I may be doing a 45 minutes talk/seminar/workshop about graphics programming on a raspberry pi, any tips and suggestions are appreciated as my target audience apparently can't even read the talk description.
On other news you can now encode h264 on the pi, which is awesome.
On other news you can now encode h264 on the pi, which is awesome.
Yessss-ss! Got together that fb-routine using ES, which means the future ports shouldn't have tearing or require a particular resolution for fullscreen. Started with dose2. The Buenzli prod still uses the old hack.
The current source here. Makes porting sw rendered 8- or 32-bit stuff rather easy. Scales the buffer according to the resolution (or at least it should!) with ES. Palette mapping and rgba byteorder swapping would probably be considerably faster if done in a shader, so I'll probably look into that sometime soon. Bug reports welcome. 16-bit fb doesn't work yet, that's known.
Marq, you're using SDL to play music then? I've tried the ARMv6 port of BASS but it seems to not work for me on Raspbian with hardfp :(
For sound and keyboard reading, yes. Our own mod player and mpglib work fine on top of SDL Audio. Libmodplug and libmpg123 are available in the normal repositories, so there's plenty of options. I do see the point of trying not to rely too much on extra libs that aren't installed on a vanilla system.
Thanks, I will probably try one of the libraries you mentioned. I've posted on the BASS forums so we'll see what happens...
If anyone's still feeling enthused by the boot menu idea from three pages back, it's probably worth pointing out that this operating systems tutorial seems to contain all the key components, including the all-important USB keyboard driver.
(personally, I'd say that MOAR DEMOS is still the priority at the moment, but don't let me stop you...)
(personally, I'd say that MOAR DEMOS is still the priority at the moment, but don't let me stop you...)
If anyone is interested, libbass.so work fine on Debian wheezy (softfp) and the author of it is looking into creating a hardfp version of the library.