25th August OpenGL Part II

This is going to be a more “technical” blog entry.

I am going to tell about the recent changes – mainly about implementing a JOGL rendering “engine”. I already mentioned JOGL in one of the last entries – but the last weeks I finally came around implementing it in earnest.

Preface
As I hate throwing good code away – the old graphics engine is still in place and can be switched on/off using configuration settings. Internally I call the two engines “java” and “jogl”.

The actual display implementation of the emulator output changed quite a bit. Before the output was done on a “normal” panel using java graphic primitives. To be able to switch the display from “java” to “jogl” back and forth at runtime – the whole display had to be “outsourced” from the “VecxPanel” and called via a display interface implementation.

Some of my old programmings helped with that a lot – some where hindering. Hindering was mainly, that the display functionality was quite interwoven with the mentioned VecXPanel. I extracted every function that was display only and exported it to a new class. The actual “pure” display classes are now called:
– VecxiPanel_JOGL
– VecxiPanel_JAVA

Which are both derived from a JPanel and implement an interface called DisplayPanelInterface. When switching the output class I just need to remove the old panel, instantiate a new panel and add it to my display window. Once implemented – quite easy – the “hard” part was sorting it all out.

What really helped was, that right from the start the actual vectrex emulation class “VecX” never knew (and still does not know) above VecXPanel. All it knows is another interface DisplayerInterface that mainly consists of one function call “updateDisplay“. This implies, that all vector display data is internally very closely encapsulated – and does not know anything how it will be displayed later. The display class does only one call to VecX when a display is immanent:

 VectrexDisplayVectors list = vecx.getDisplayList();

That list contains all data that is neccessary to display the data correctly (or so I hope). One item of the list consists (mainly) of following entries:

 public class vector_t 
 {
     public int x0, y0; /* start coordinate */
     public int x1, y1; /* end coordinate */
     public int speed;
     public int color; // Brightness only!
     public int imagerColorLeft;
     public int imagerColorRight;
     public boolean midChange = false;
 };

The coordinates speak for themselfs.
Speed is either the strength with that a vector is drawn – or in case of a “point” (dot) a “dotDwell” value.
Color is a value between 0 and 255 that is exactly the “intensity” of the vectrex.
Imager colors (in case of 3d imager emulation) is a color index for the “eye”.
MidChange is set to true if a vector is “curved” (changes of integrator values in the middle of ramping 🙂 ).

A list of these vector data is investigated by the display classes and than output by various means to the actual user display.

JOGL

OpenGL comes in different versions. The fact that my iMac has a graphic card that only supports version 2.1 made it neccessary for me to also use only openGL features that are compatible with that version. Since the newest OpenGL versions are quite a bit newer I had to do some internet digging to come up with “introductions to OpenGL” that basically are over 10 years old.

In the following I will describe the current state of JOGL support in Vide is in – and what is still planned. The easiest and shortest part will be what is not done (yet):

Following things are not implemented for JOGL – but planned:

• color display when emulating 3d-Imager
• lightpen support
• LED emulation output
• debugging features (integrator position, arrows, “messages”)
• fullscreen support

Implemented are following “things”

Drawing vectrex vectors
– while this is quite obvious – I still will lose a few words. While implementing – and viewing various results on my screens, it became apparent to me, that for optimal results I should use three different “graphic” primitives openGL has to offer:

• Points (using lines with a length of zero really looks bad!)
• Lines (obviously)
• LineStrips (for custom generated CatmullROM splines – curved vectors, OpenGL does not know about curves)

You can configure openGL to use antialiazing:
a) if you graphic card supports MSAA than this can be turned on with a given number of sampels (preffered) I implemeted MSAA support using a special MSAA enabled framebuffer, drawing to it, and blitting the result back to my “work” framebuffer.
b) if not you can use openGL settings of “SMOOTH” – but this may be “costly” since it my be implemented by the driver software (and thus not ensured to be fast)

Shaders

Various shaders to enhance the output to the screen can be configured:
a) spill shader
b) a glow shader (standard Gauss blur)
c) persistency
d) overlay
All of the above can be configured to your liking.

Also configurable are (as before):
– line width
– brightness
– brightness influences by vector speed and dotDwell

A more extensive version of the things done can be viewed in a video:

Malban