Write your own Einstein@home screensaver

It is amazing how easy nowadays computer grahics can be written.
Just one line of code
m_rotation = glm::rotate(m_rotation, 0.01f, m_axis);
and the whole array is rotated and even using a hardware acceleration when it is possible. No need to write own code for rotation matrix. Just one line...
I remember those days when I have to write the whole rotation and rendering proccess
by myself. And it works without any hardware acceleration at all. Though it was a one color transparent fading cube. But the aim was to understand and to make it all myself.
So I'm long for those times. May be I'm getting older... :)

Yeah, talking to repo is what I do when I desperate of what I've done and why it is returning me this :)

Ok. This is customer feedback :)

On this stage you have already to think about making all these things switchable, by hotkeys for example, have you? ;)

P.S. And please add constellation names with very small letters along longest line in each constellation (and also switchable).

Thank you in advance.

Heart Beat. Whack ! :-0

Well how non-trivial it is to get text on the HUD - nearly solved ( tracking down one errant pointer as we speak ) and is the only real remaining barrier of significance in this enterprise. Hope springs eternal. Rough heuristic as follows :

- SDL is the library to interface for acquiring a rendering context ( read : instance of an OpenGL conforming state machine ), plus input from devices/files etc.

- SDL_ttf is the library to gain pretty painless access to font representations and extract the crucial glyph patterns.

- obtain an SDL_Surface pointer/reference ( for some given text string ) via a call, say, to TTF_RenderText_Solid().

- using SDL_ConvertSurfaceFormat() get a different SDL_Surface with suitable pixel value representations : RGB @ 8 bits per color.

- load up one of my TextureBuffer objects with said SDL_Surface derived values. Now you have a ( wrapped ) object subject to OpenGL state.

- hence a texture shader may pick out values ( technically sample the pixel map ) to determine fragment color eg.

#version 150

// This is a fragment shader. It samples/interpolates the
// texture object currently bound to GL_TEXTURE0.

// With these texture coordinates ...
in vec2 pass_text_coords;

// ... lookup using this sampler device ...
uniform sampler2D color_map;

// ... to determine the fragment color.
out vec4 out_color;

void main()
{
out_color = texture(color_map, pass_text_coords.st);
}

- however that pixel map interpolation has to occur with respect to texturing coordinates for some geometric primitive.

- there aren't GL_QUAD objects available anymore. So one uses two triangles with a common edge to make up a quadrilateral shape. That common edge becomes a diagonal across that shape.

- but to keep that quadrilateral both planar and convex, I have selected a parallelogram model. You specify the bottom left corner's coordinates ( in world space ) and two vectors indicating displacement from that point.

#version 150

// This is a vertex shader. Creates a parallel sided quadrilateral
// area based at lower left corner, with offsets along the sides.
// Both dimensions of texture coordinates are bound/clamped to
// zero and one at extents.

uniform vec3 base_position;
uniform vec3 height_offset;
uniform vec3 width_offset;

out vec2 pass_text_coords;

uniform mat4 CameraMatrix;

void main()
{
// Start at lower left corner.
vec3 position = base_position;
// With texture coordinates of zero.
pass_text_coords.st = vec2(0.0, 0.0);

// For odd numbered vertices.
if((gl_VertexID % 2) == 1) {
// Add the width_offset.
position += width_offset;
// With the 's' texture coordinate is 1.0.
pass_text_coords.s = 1.0;
}

// For the vertex numbered two & three.
if(gl_VertexID > 1) {
// Add the height offset.
position += height_offset;
// With the 't' texture coordinate being 1.0.
pass_text_coords.t = 1.0;
}

// Emit final position of the vertex.
gl_Position = CameraMatrix * vec4(position, 1.0f);
}

- the interesting ( OpenGL Shading Language ) feature here is the gl_VertexID inbuilt variable. It counts from zero to however many vertices are invoked by a given call to glDrawArrays() ( either four or six times per triangle pair, depending upon another optimisation ).

- that parallelogram can be wherever you choose to put it in your modelling/world space, subject to transforms like any other OpenGL geometric primitive and subsequent projections ( perspective for a 3D look, orthographic for the HUD ).

- in summary the interior of the parallelogram is painted with the pixel map representing some chosen text in a certain font as selected. You get the full advantages of font processing prior to glyph construction, especially kerning and conjoined glyphs.

- my encapsulation is via C++ class interfaces of course, and I have chosen the following key constructor :

TextString::TextString(glm::vec3 position,
	  	       glm::vec3 height_offset,
		       glm::vec3 width_offset,
		       TTF_Font* font,
		       const char* text,
		       SDL_Color foreground)

... so you have to fully specify from the get-go. However once instantiated there are several methods available to change any of the above parameters individually, with invisible reconstruction of the back-end objects and devices using magic incantations. :-)

- AND all of that without going outside of the provided libraries ie. it remains a cross-platform solution. Phew ! :-)

Now if only I could track down that bloody pointer. Jeeves, pass me Brown Bessie ......

Cheers, Mike.

( edit ) Sharp punters will note that no color information needs to be provided on a per vertex basis. So those points are natively invisible or non-rendered, only serving to define the extents of the quadrilateral and texture coordinates to be later interpolated upon. Indeed vertex positions are deduced by access to uniform variables - implying direct load from client side code and not via any OpenGL array objects. So this is an example of when one only needs a Vertex Array Object to trigger pipeline activity for a certain number of instances, the rest is defined intra-shader. This is the most efficient choice for a small number of vertices.