MSK Software Development

When we were talking about OpenGL we looked at other solutions and what you need is very simple: you need mostly 3-dimensional or 4-dimensional vectors - and these vectors are mainly given to the OpenAPI’s. Sometimes only one instance, but very often as vectors of OSFloat32 or OSFloat64.

These subclasses are well suited to be used as transfer instances for values to OpenGL - but they are worse, if you want to do heavy calculations with them.

These classes are also pretty well useable for vectors - and they give you the option to transfer values to os based memory.

But they are slow ….

Therefore people very often are using subclasses of Array to simulate vectors - and these solutions are pretty often the fastest available.

Therefore you have two possibilities:

* subclasses of OSStructure
* subclasses of Array

One of the worst problems of these classes are accessing: one-based index access when using Array and zero-based index access when using OSStructure solutions. That means, that code written for one solution is not suitable for the other one.

Regarding speed you may have a look at this picture shows benchmarks for vector addition:

The upper lines show typical solutions of a vector addition using plain OSFloat32 classes in pure Smalltalk and typical code like:


array3 at: index put ((array1 at: index) + (array2 at: index))


The lines in the middle show solutions based on Arrays in pure Smalltalk. They show, that Array-based solutions are 3 times faster than the OSStructure-based solutions.

The lower lines show OSStructure solutions with a little help by primitives for float and doubles. These solutions are around 3 times faster than the Array based solutions and 10 times faster than the original OSStructure based solutions.

*Summary *

That means, that these primitive-supported solutions are the fastest solution and they are ideal suitable for transfering data to external C-API’s.

* Instance Creation is time consuming *

One additional word to the benchmarks - when building these benchmarks one can notice, that the creation of objects can be a pretty time consuming task. Therefore reusing of arrays might be a good idea to improve the speed of your application

Also I have to admit, that my OpenGL binding simply does not work under Wine. At best I get a flashing window (when doing the swap buffer command) or at worse the whole X-server crashes. This is amazing, because the example programs (from the OpenGL superbible) compiled for windows are working without problems ….

Some holidays and now a newer version. Lots of refactoring, most of the problems during initialization phase solved. Semaphore introduced to allow several OpenGL windows to work on their own and to secure process switching. A new example framework introduced. First wrapped API’s of “glut32.dll” introduced.

New version of MSKKernel 1.2.5 is needed, which is included in the archive. Also a binary fr the Windows glut32.dll is included, which is build using _stdcall calling convention. This version is available from the maintainer of the windows version of “glut”.

Software version upgraded to 0.2.x, because all the standard API calls were new generated and now the parameter handling is converting the parameters when needed…

myopengl-0-2-3

Hmm, I tried to create the rendering context using a different pixelFormat approach - but that did not work.

And now ? Well I call “createRenderingContext” and if this fails I call it again - ok, now the software works as it should !!?!?!?!?

mskopenglsupport-0-1-10

Ok, got lost between my laptop repository and my main repository. This version now has the correct loading sequence and will load without errors ….

BUT, when I start my application in a fresh image for the very first time I get an pixelformat error - do not know why … the same problem is, when starting an image with this code - always for the first time I get a pixelformat error ….

Just close the example and start it again an it will work …

mskopenglsupport-0-1-8