pouët.net

Another contender with more whoopass: The cubieboard...

What "more"? No analog video out --> no sex appeal.

New hardware revision of the Pi out...

now made in the U.K. - revisions, revisions, pfft! I want a Funcube Dongle Pro + now...

If anyone is having problems with a transparent console on their demo, you can get around it by specifying this as the alpha argument to vc_dispmanx_element_add:



This will fix the problem regardless of what is in the alpha channel of your framebuffer.

Been there done that. But you can use that to have a semi transparent cube on your console if you run your demo on the background (./demo.bin &).

ok, I have a Pi, but no real ideas on how to code for it, what would be a good starting place ?

is python the best language to begin making demos with ?

cheers :)

Check the samples provided in the /opt/vc/src/hello_pi folder. And use C++.

Python will be a reasonably good language to make demos in, once I've polished up / documented my framework... so thanks for giving me an extra push towards getting that done :-)

Quick port of San Angeles Observation:
http://iki.fi/jetro/files/sanogles_raspberrypi.tar.gz

Yay! I've got Yellow Rose right here, too, but can't publish it quite yet...

Oops, not Rose, but other stuff!

Shortcrust (my Python OpenGL framework for RasPi, as used on Avocado and Robot Dawn) is now up on Github in a suitable state for other people to play around with :-) I won't promise the API will remain stable, but it's definitely usable now.

https://github.com/gasman/shortcrust

(Some basic OpenGL / GLSL knowledge will come in handy - I picked it up from the Learning WebGL tutorials, which are probably as good a starting point as any, despite being for an entirely different platform and language...)

Woohoo, the last updates fixed sound crackling on a couple of demos when using analog audio!

Could someone test this before it's "formally" released? Needs quite a lot of graphics memory so probably won't work if started from a high resolution mode. Did most of the testing on a video monitor. Speed can be improved with -nofsaa, which turns off the 4xFSAA. The rendering resolution (on a TFT) can be set using the -res x y parameter.

All in all I'm positively surprised by how much the tiny Raspi can crank out in one frame. Just need to use VBOs and index buffers for pretty much everything. It was a rather painful experience converting and optimizing complete immediate mode / display list demo to ES 1.1 - it took several days - but I guess it taught me something at least. One of the worst problems with Raspi is that rendering conflicts with the sound output (the machine doesn't have a real sound chip at all). Need to minimize the amount of state changes and especially avoid drawing individual polys at any cost both for speed and especially to keep the audio from crackling.

Marq: I'm waiting for my PI in the mail so no experience yet, but it sounds like the sound issue is a SW one or? (irq locking/delayed processing?)

The latest Raspbian update improved the sound to a certain extent, but didn't fix all the problems. I guess the proprietary VideoCore driver doesn't play too nice with the rest of the system.

Marq: for an extra performance boost optimize the VBOs / indexes for more cache coherency using something like this. There are is a tool from ATI, and some libraries that do that, also try using halfs instead of floats, etc.

how do you feel after developping for this platform ?

It's like an old Linux box plus a few quirks, but being able to use it with a video monitor is a big plus. Stuff looks somewhat Amiga-like :) Not that tricky to target at all, since I'm coding on Linux/OSX anyway. Raspi was supposed to be a uniform platform, but the different display resolutions/rates break that to some extent.

@Marq: I ran it on the current turbo-moded debian wheezy-raspian. No FSAA option was enabled, resolution to 640x480 (I have it plugged to an old TV screen, it won't show anything at higher resolutions). Runs smooth, sound is ok.

Thanks for the report. 640x480 should run fine with FSAA, too. 1280x720 might be the maximum resolution where it can be started from (worked at least for me using DVI). The Linux framebuffer resolution doesn't apparently have much to do with the videocore res, except that a higher res takes up more memory.

I've been using 1080p for some tests I've been doing. I can get some smoke particles and an high poly 3d model on the screen at around 30fps. Why are you using such low resolutions?

@whizzter: that's a useful document. Thanks for posting :)