PSA – Use ‘SNA’ if you are on optimus

"Optimus" is the tech where your laptop has an Intel AND an Nvidia card, the amount of problems this can cause are more than the sum of the parts on Linux. Trying to run apps on the Nvidia card had all sorts of issues until I switched the intel card on 'SNA' ("the successor to UXA"). It seems like every few years intel changes how their graphics cards work, and the new hotness is SNA. Before this, glitches included black windows, and apps just freezing until I resized their windows, or if you ran more than one GL app. As per the answer here at https://ask.fedoraproject.org/en/question/32960/black-windows-in-gnome-3-suddenly add the following to your /etc/X11/xorg.conf
Section "Device"
 Identifier "Intel Graphics"
 Driver "intel"
 Option "AccelMethod" "sna"
 EndSection
I'm not sure it's entirely problem free, I have had one or two logouts, but at least I can run more than one instance of my own app without random freezing and glitching.   [EDIT] It turns out I'm still getting glitchyness and lockups running on intel, at least running things on the Nvidia card with DRI_PRIME=1 works though. [/EDIT]  

3d in the era of J2me

Back in the deep dark past (2004-2007) I worked on a 3D game for phones of that era (before iphone, android). I recently found some of the test files for the engine, here are some videos.

 

Very low poly racetrack

 

The ubiquitous cube

 

Spacekid in the spacestation corridors

Our Mascot wanders the corridors .. you can't look too far ahead, to keep things really low, which means popup is a little...severe.
Movement is a better in reality - the capture has made the movement a bit jerky.

Dire Straits

Obviously we didn't make this, but it heavily inspired our 3D engine ... textures were just too slow, so we aimed for this look.

Belated post on libregraphics meeting 2014

Here is my very late post on LGM 2014! Back in April I went to Leipzig for my first in-the-flesh meeting of Shoebot devs .. I met with Ricardo + to collaborate on a workshop on shoebot. To make it more fun we hadn't decided what to do it on ! In the anarchic OSP (open source publishing) house we came with a plan to get people making examples for shoebot. Luckily Ricardo had done a lot of this sort of thing before so did most of the talking, then I showed off some bots - evolution, spirals and also the livecoding work. Overall the workshop seemed to go over well; we got a bunch of examples, and there was even a plugin for sublime text !

Things that came out of the workshop:

People want an integrated editor - this is OK, since the IDE still exists. Differences between the Nodebox/Shoebot API and Cairo are not always intuitive. Livecoding is cool! Shoebot 2 ... or something else ? Going forward, it might be best to take the Nodebox approach and build something new based on these lessons, I'm not sure exactly what yet. What is the most intuitive API, how can we be close to standard APIs.

Non Shoebot Stuff

Outside of the workshops and talks there were plenty of time to drink and chat - apart from talking the head off of one of the mypaint guys I learned quite a lot about OSP off Sarah Magnan and Brendan Howell .. which made me regret missing many of their talks, including Brendans on the screenless office. Leipzig was a really great city to visit, the venue for LGM was particularly impressive being inside an old church that the East Germans repurposed to a university. Importantly for me I learned about the "kebab circle" - the ring of gentrification moving from the inside of the city outwards (beyond which you can still buy kebabs). With any luck LGM will be able to make it next year and meet everyone again.

Shoebot experiment – perlin noise..

Perlin noise is pretty cool, you can use it to generate realistic looking clouds or mountains. Here's a bot for shoebot I made a while back that uses perlin noise to generate some nice circles. You'll need shoebot and the lib "noise" installed into your environment for it to work;
# pip install noise
Then to run;
sbot -w perlin-circlescape1.bot
Here's a video of them in action - See below the break for the code - (more…)

Moving things in shoebot – simple particles…

OK, part 3 - now for something fun - extending parts 1 + 2 into a simple particle system.

Particles, generally means - a lot of things moving around (the particles) and a way to generate them, an "emitter"

Here we're going to take the code from the previous two parts and add a couple of things to make a basic particle system.
Note - shoebot, isn't the fastest; but we do get nice looking results.

Here's a video of our arrows as particles (arrowsplosion!):

(more…)

Cairo: Surface for recording commands and playback

An update on my latest cairo adventures...

When cairo 1.10 comes out we'll get a RecordingSurface so you can record commands and play them back to another surface, but how to do something similar now ? Skip to the end if you just want the code, explanation of how I got there ahead: My first advice was to try using PDFSurface, and set the file object to None.
# Record a red rectangle onto a surface.
#
# Create another surface and draw a background on it
# Draw the first surface onto this surface
#
from cairo import PDFSurface, ImageSurface, FORMAT_ARGB32, Context

recording = PDFSurface(None, 200, 200)
target = ImageSurface(FORMAT_ARGB32, 200, 200)

# Record a red rectangle
cr = Context(recording)
cr.set_source_rgb(1.0, 0.0, 1.0)
cr.rectangle(20, 20, 10, 10)

cr.fill_preserve()
cr.set_source_rgb(0.0, 0.0, 1.0)
cr.stroke()

target_context = Context(target)

# Draw background
target_context.set_source_rgb(1.0, 1.0, 0)
target_context.paint()

# Replay recording to target
target_context.set_source_surface(recording)
target_context.paint()

target.write_to_png('output.png')
That seems to work, except when I tried in Windows, when it complained that the file object was wrong. OK, we can work round that:
def RecordingSurface(w, h):
    if os.name == 'nt':
        fobj = 'nul'
    else:
        fobj = None
    return PDFSurface(fobj, w, h)
This seems to be working, but my animation seemed slow... time for some benchmarking; I rendered 1000 frames and got a rough wall clock time: 1m48. Hmm... perhaps SVGSurface will be quicker: 1m28 This is much better, 20 seconds difference just by changing what kind of surface is returned!

Animation not smooth though

The animation still seemed jerky it occured to me that when the surfaces are disposed they will attempt to out their content to the file object ! Luckily, get_similar_surface() comes to the rescue; it returns a surface not associated with a file object. Using this the original surface can be kept around forever, and never output. Wallclock time: 50 seconds!

And here it is:

_svg_surface = None
def RecordingSurface(*size):
    '''
    We don't have RecordingSurfaces until cairo 1.10, so this kludge is used

    SVGSurfaces are created, but to stop them ever attempting to output, they
    are kept in a dict.

    When a surface is needed, create_similar is called to get a Surface from
    the SVGSurface of the same size
    '''
    global _svg_surface
    if os.name == 'nt':
        fobj = 'nul'
    else:
        fobj = None
    if _svg_surface is None:
        _svg_surface = SVGSurface(fobj, 0, 0)
    return _svg_surface.create_similar(cairo.CONTENT_COLOR_ALPHA, *size)
This is really useful, you can record commands and play them back to other surfaces.