Skip to main content

OpenGL in a Workspace

On some modern Linux systems, Croquet does not work anymore because OpenGL failes to initialize. Now, I originally wrote that code, and it worked fine for years. So it can't possibly be buggy, right? Jens Lincke of impara tracked it down to the "Composite" extension that is enabled by default nowadays. With Composite disabled, it works, enable it, and it does not.

So I turned to NVIDIA for help, thinking their driver might be buggy. Had to give them an easy way to reproduce the problem, this is the snippet I came up with:
| ogl green |
ogl := OpenGL newIn: (0@0 extent: 100@100).
green := 1.
[[
        ogl glClearColor(0, green, 0, 1).
        ogl glClear(16r4000).
        ogl swapBuffers.
        Sensor waitClickButton.
        green := 1 - green.
] repeat] ensure: [ogl destroy]
Beauty, eh? ;-) I guess nobody has done this in a workspace for a long time. Stop it with Alt-.

Anyway, NVIDIA could reproduce the problem, and found our bug:
[...] the app is trying to create a depth 24 child window of a depth 32 parent and the app specifies neither a border pixel nor a border pixmap.
Doh! I forgot to specify the border! We were just lucky that this did not happen before. Jens and y.t. made a patch, should be in the next VM. And big thanks to NVIDIA developer support!
Labels:

Comments

Anonymous said…
...
ogl glClearColor(0, green, 0, 1).
ogl glClear(16r4000).
...

I'm sure I don't get that. Most of the syntax here in the snippet looks like Smalltalk syntax. But then there's this mixed in? It's amazing, because immediately I have no idea what the glClearColor arguments mean. Or the glClear. Is this one of these "on beyond Smalltalk" things I keep hearing some of the spring-from-Squeak projects talking about?
February 17, 2007
Vanessa said…
This is called "positional arguments", Andreas allowed this syntax in Croquet. The actual selector in this case is #'glClearColor()/4'.

The reason is that this is the syntax that is used in any piece of OpenGL documentation. You can alternatively write

ogl glClearColor: 0 with: green with: 0 with: 1

which I find even less readable. These are FFI methods, so they directly call out to the corresponding C function. Personally I like this, it reminds me that this is a C call rather than a Smalltalk method.

A "cool" hack is to use cascades, which allows you to copy C code almost verbatim:

ogl
glClearColor(0, green, 0, 1);
glClear(16r4000);
yourself.
February 18, 2007
Anonymous said…
I'm looking for a way to do this cleanly within a Tweak project, but I can't seem to find the right offset(s) to put the OGL area in the project window. Any ideas?
March 10, 2007
Vanessa said…
There is no official way to convert Tweak coordinates to absolute Squeak Display coordinates. Here is a hack involving Sensor.

Besides, you might find this useful: COpenGLPlayer
March 10, 2007
Anonymous said…
Thank you! The Sensor hack is what I was looking for. I actually have the COpenGlPlayer code already, although when I tried to backtrack to find where I had gotten it, I looked everywhere except the Tweak list. Thanks again. daf
March 10, 2007
Post a Comment

Popular posts from this blog

Frontend-only Multi-Player. Unlimited Bandwidth. Or: What is Croquet.io, really?

A multi-player web app needs a backend, right? What if I told you, it doesn’t? Read on for how Croquet gets rid of servers. No, really . Instantaneous Shared Experiences  is how we describe Croquet on our website. And while that excellently describes What Croquet does, as Croquet's Chief Architect, I wanted to share a bit about How we do that. So I wrote a Twitter thread . Here it is in blog form, slightly extended. Click the animation above if it does not play automatically Croquet lets you build completely client-side multi-user web apps. Read that again. Client-side. Multi-user. No I’m not kidding. I built it, I know it works. 😁  Croquet apps run completely client-side: can be hosted as a static web site no server-side code needed no networking code needed  Croquet is literally virtualizing the server: Instead of running code on a server (or in a serverless function) we run it as a virtual machine (VM) on each client.  Croquet carefully controls the inputs to these identi
1 comment
Read more

Deconstructing Floats: frexp() and ldexp() in JavaScript

While working on my  SqueakJS VM, it became necessary to deconstruct floating point numbers into their mantissa and exponent parts, and assembling them again. Peeking into the C sources of the regular VM, I saw they use the  frexp ()   and ldexp () functions found in the standard C math library. Unfortunately, JavaScript does not provide these two functions. But surely there must have been someone who needed these before me, right? Sure enough, a Google search came up with a few implementations. However, an hour later I was convinced none of them actually are fully equivalent to the C functions. They were imprecise, that is, deconstructing a float using frexp() and reconstructing it with ldexp() did not result in the original value. But that is the basic use case: for all float values, if [ mantissa , exponent ] = frexp (value) then value = ldexp ( mantissa , exponent ) even if the value is subnormal . None of the implementations (even the complex ones) really worked. I
6 comments
Read more

Connecting fields

Quick Recipe To connect field a in obj1 to field b in obj2 , use this: obj2 startScript: #b: when: {obj1. #aChanged} Now for the whole story ... Problem A colleague of mine wanted to make a drop-down list, where the options are not just set once, but provided and updated by the application. So, of course, when the options in the application changes, the items of the list widget have to be set to this new value. Nothing easier than that, just write a handler: onOptionsChanged     <on: optionsChanged in: app>     listWidget items: app options HOWEVER, he wanted to build this programmatically, not using a separate method. So, he easily came up with the following: listWidget startScript : #items: withArguments: {app options} when: {app. #optionsChanged} HOWEVER, this does not work as intended because the arguments to the script are evaluated only once, rather than every time the script is triggered. Well, this is what blocks are for, right? So this indeed works as intended: listW
2 comments
Read more