Archive for development

Using ARRAY_BUFFER’s in PyOpenGL

Posted in How To, Programming, PyGLy with tags , , , , on 2013/02/16 by Adam Griffiths

I’m in the process of converting my code from Pyglet GL to PyOpenGL.
In doing so, my VBO objects stopped rendering.

It turns out the problem is glVertexAttribPointer.
The Pyglet GL version takes the last parameter (offset) as a number. I set this to 0 for arrays with no offset.

glVertexAttribPointer( in_position, 3, GL_FLOAT, GL_FALSE, 0, 0)

It seems that PyOpenGL expects the pointer value by absolute instead of relative.
The solution is to pass None instead of 0.

glVertexAttribPointer( in_position, 3, GL_FLOAT, GL_FALSE, 0, None)

If you have an actual offset to pass, you need to convert to a ctypes c_void_p (void*).
http://stackoverflow.com/questions/11132716/how-to-specify-buffer-offset-with-pyopengl

glVertexAttribPointer( in_position, 3, GL_FLOAT, GL_FALSE, 0, ctypes.c_void_p(offset))

Adobe Air hanging when using SDK but not when packaged

Posted in How To with tags , , , , , on 2013/01/30 by Adam Griffiths

I just had an issue during the development of an Adobe AIR Application.
When using Flash Pro CS 6, the application hang in certain situations for 5 odd seconds.

I found a few peculiar quirks:

  • Packaged builds didn’t have the problem.
  • Moving the project to a different directory fixed the problem.
  • Clean checkouts of the source didn’t have the problem
  • Re-creating the project in Flash Pro CS 6 didn’t fix the problem.

The console was printing the following messages

Breakpoint not set; No executable code at line ###

It turns out the problem was old breakpoints that don’t exist anymore.
There’s not trivial way to remove all the breakpoints (the button was greyed out!).
The easiest way I found (on OS-X) was to do the following:

vi ~/Library/Application\ Support/Adobe/Flash\ CS6/en_US/Configuration/Debugger/AsBreakpoints.xml

Remove all the breakpoint entries in the XML.
The file should look similar to this:

<?xml version="1.0"?>
<flash_breakpoints version="1.0">
</flash_breakpoints>

This resolved the issue.

PyGLy steps into the future

Posted in Development, PyGLy, Twisted Pair with tags , , , , , on 2012/09/21 by Adam Griffiths

I’ve been working quite heavily on PyGLy for the last few weeks and I’m incredibly pleased to announce that PyGLy is now OpenGL 3 clean!

It took more work than I hoped. Not because of PyGLy (it was already pretty good), but Pyglet’s OpenGL Core (3+) support on OS-X, is well… broken.
I had to integrate a patch written by someone else and patch out 2 of the window event handlers.
The main reason for this is that OpenGL Core on OS-X is limited to 3.2, and is Core only (no legacy compatibility).
These changes can be found in my Github repository.

Pyglet isn’t without it’s problems. It is quite heavy weight in places. There is no support for float or 1D textures.
Other problems are it’s usage of legacy calls. These are scattered throughout the code base and prevent me from using even the Label or VertexList classes.
I would LOVE to help with the development of Pyglet… but I find the code… very confusing.
It’s got a fair amount of abstraction. Tracing even a vertex buffer blows my mind.

Regardless, I hope these issues will be fixed soon.

OpenGL and GLSL support in OS-X

Posted in Twisted Pair with tags , , , , on 2012/08/13 by Adam Griffiths

I had difficulty finding the supported OpenGL and GLSL versions in OS-X.
Using Pyglet, I get errors trying to use versions GLSL 1.30 and above. Printing out the version returns 1.20.

from ctypes import *
from pyglet.gl import *

print "OpenGL version", gl_info.get_version()

plain = string_at(glGetString(GL_SHADING_LANGUAGE_VERSION)).split(' ')[0]
major, minor = map(int, plain.split('.'))
version = major*100 + minor
print "GLSL Version",version

Looking around I found this information.
Mac OS-X OpenGL Support

Legacy would infer the “Fixed Function Pipeline” and Core would be modern OpenGL.
So it seems that legacy OpenGL (normal Pyglet) is stuck with GLSL 1.20 and Core has 1.50.

This code can be found on the Pyglet source repository that enables OpenGL 3 (Core).
Enable OpenGL 3 in Pyglet

But the ouput I get is not correct.

OpenGL version 2.1 ATI-1.0.25
GLSL Version 120

According to this conversation, it appears that Pyglet ignores the OpenGL version on OS-X currently.

PyGLy Progress

Posted in Development, Twisted Pair with tags , , , on 2012/07/06 by Adam Griffiths

Work on PyGLy is progressing well. The code is better designed and cleaner than I’d hoped, so I’m very pleased.

I’m wanting to keep PyGLy thin, so not much more new functionality will be added. New features will go into higher level projects that sit on top.

I tried some NumPy optimisations with BLAS and other libs, but haven’t seen much improvement. Biggest change was running Python with ‘-O’, which got me another 10 FPS.

Dev continues!

Adventures in Kivy

Posted in How To, Programming, Rant with tags , , , , , , on 2012/03/22 by Adam Griffiths

So here is a semi-live blog as I delve into Kivy.

Mission #1: Attempt to resize the default window

Ok let’s start at the start.

We first create an object that inherits from App. Done.

Ok, and the examples all return a widget from the App’s build() method. So we don’t over-ride __init__… ok… thats… unique.

Perhaps the widget is the window if it is returned from the build() method?

Widget is not the window. Widget returned from build() is added to the window. So… where is the window created?

Window docs state the window has a constructor that lets you set the window size. Ok, cool. But we don’t create the window… so.. we can’t use the constructor… sigh.

Ok, Window has a static accessor.

kivy.core.window.Window = None

No comment on what is stored here but I assume it’s the instantiated window. It doesn’t mention when it is set… handy!

Only 1 window allowed. Ok… weird. Well… let’s try that.

import kivy.core.window.Window
AttributeError: 'module' object has no attribute 'window'

Awesome…

Let’s scour the code.

Screen capture of Kivy window module

No Window.py file……… how far does this rabbit hole go.

Ok, let’s check out the __init__.py file in the window module.

class WindowBase(EventDispatcher):
 '''WindowBase is a abstract window widget, for any window implementation.

So… window base is in there. Feel free to scream now.

So we can get this by importing kivy.core.window and just leaving the class off the end.

import kivy.core.window
...
def build(self):
    print kivy.core.window.Window.size
    return None
(800, 600)

Ok sweet, thats our window.

So let’s change its size.

def build(self):
    print kivy.core.window.Window.size
    kivy.core.window.Window.size = (1024, 768)
    print kivy.core.window.Window.size
    return None
File "/Users/adamgriffiths/Workspace/VirtualEnvs/progress_quest/lib/python2.7/site-packages/kivy/core/window/__init__.py", line 243, in _set_size
 if super(WindowBase, self)._set_size(size):
 AttributeError: 'super' object has no attribute '_set_size'

FFFFFFFUUUUUUUUUUU

Ok, so after some googling we find this post about the relationship between the App and Window classes.

His solution is to pass the size as a command line parameter……….. LAME. That kinda throws the whole configuration settings thing out the window.

Looking through the Kivy code we find this block inside their base window class’ __init__ method.

if 'fullscreen' not in kwargs:
    fullscreen = Config.get('graphics', 'fullscreen')
        if fullscreen not in ('auto', 'fake'):
        fullscreen = fullscreen.lower() in ('true', '1', 'yes', 'yup')
    kwargs['fullscreen'] = fullscreen
if 'width' not in kwargs:
    kwargs['width'] = Config.getint('graphics', 'width')
if 'height' not in kwargs:
    kwargs['height'] = Config.getint('graphics', 'height')

Ok, so we can try and set it via the global config object.

So let’s add that to our App class.

def build_config(self, config):
    config.adddefaultsection('graphics')
    config.setdefault('graphics', 'width', 1024)
    config.setdefault('graphics', 'height', 768)
    config.set('graphics', 'height', 1024)
    config.set('graphics', 'width', 768)

Run the code and……

(800, 600)

……. sigh

So let’s put some debug INSIDE kivy and see what is happening. We’ll also force it to pull the ‘graphics’ setting and ignore kwargs.

if True: #'width' not in kwargs:
    kwargs['width'] = Config.getint('graphics', 'width')
print kwargs['width']
if True: #'height' not in kwargs:
    kwargs['height'] = Config.getint('graphics', 'height')
print kwargs['height']

And the output…

800
600

…. calm blue ocean…. calm blue ocean….

Ok… google…

Hmm.. ok, this post on the kivy-users forum (because documentation is for lusers) shows a similar method.

They use the Config module directly instead of the config object passed to App….. because….. they’re not the same? Well.. let’s try it anyway.

from kivy.config import Config
Config.set('graphics', 'width', 1024)
Config.set('graphics', 'height', 768)

And our output

(800, 600)

Ok, weird because the window HAS ACTUALLY CHANGED SIZE.

Whatever. We’re all living in crazy-ville atm so let’s just pretend everything is normal.

So let’s move that inside our build_config() method.

def build_config(self, config):
    Config.set('graphics', 'height', 1024)
    Config.set('graphics', 'width', 768)

And the output

[INFO ] Kivy v1.1.1
[INFO ] [Logger ] Record log in /Users/adamgriffiths/.kivy/logs/kivy_12-03-22_40.txt
[INFO ] [Factory ] 102 symbols loaded
[INFO ] [Text ] using <pygame> as text provider
[INFO ] [Loader ] using <pygame> as thread loader
[INFO ] [Window ] using <pygame> as window provider
[WARNING] [Window ] Unable to use <pygame> as windowprovider
[CRITICAL] [Window ] Unable to find any valuable Window provider at all!
Fatal Python error: (pygame parachute) Segmentation Fault
Abort trap: 6

(╯°□°)╯︵ ┻━┻

Install GCC with XCode 4.3

Posted in How To with tags , , , , on 2012/03/21 by Adam Griffiths

XCode 4.3 removed GCC from the default installation. To get it back simply do the following:

  1. Run XCode
  2. Select XCode -> Preferences -> Downloads -> Command Line Tools -> Install

Voila! GCC is now installed and libraries such as PIL will once again install.

%d bloggers like this: