Question SDL?

[Swatch]

Has anyone looked at it? It would seem to be a good answer to universal program porting, and I've heard nothing but good about it. Finally, it would seem that it has an extremely small footprint when running.

 

[Urwumpe]

I use it from time to time. It is really easy to use, but has only limited capability for 3D applications - you have to use full OpenGL with SDL then. But I mostly use it as base for Rogue-like games.

My personal preference for cross-platform game development is the Irrlicht engine, which is very fast and has a very powerful API (and can load almost ANY mesh format).

 

[Swatch]

Ok, it may not be the solution to an Open Source rendering, but like you said OpenGL should accomplish that and that was looking good for a while. The biggest stumbling block was 2D interfaces, and SDL should do those well yes/no?

 

[Artlav]

Ok, it may not be the solution to an Open Source rendering, but like you said OpenGL should accomplish that and that was looking good for a while. The biggest stumbling block was 2D interfaces, and SDL should do those well yes/no?

If you mean OVP and OGLAClient, then the problem is not in OpenGL being unable to render 2D, but in Orbiter using GDI, which will be as hard to translate to SDL as it is now to OpenGL.

 

[cjp]

SDL does all kinds of useful things: input handling (keyboard, mouse, joysticks etc.), sound, window management (window size, resolution changes etc.) and graphics. It does all these things in a very portable way, so that would be useful, but for graphics, you are mostly limited to two options:

• Either use OpenGL for your graphics (SDL allows you to create an OpenGL context within an SDL window)
• Or use SDL's own graphics functions.

SDL's own graphics functions are limited to very low-level 2D functions. It allows you to do things like bitmap blitting, and manually changing pixels. This is not really useful, because we mostly need high-level 2D functions, like drawing lines, circles and text, and they need to be combined with 3D graphics (OpenGL). Making those on top of SDL (or OpenGL) is a time-consuming job, which the OVP-people will probably try to avoid by using some already existing toolkit for that.

In the current Orbiter version, that toolkit was the built-in GDI engine of windows. But of course, like other microsoft standards, that is not really portable to other systems.

 

[Urwumpe]

What about using Cairo for a test version? It is portable and seems to be pretty fast.

 

[Artlav]

What about using Cairo for a test version? It is portable and seems to be pretty fast.

One thing i don't like about Cairo is that iam not sure that it will be better than GDI from the OpenGL compatibility point of view - "Copy the cairo-surface into an OpenGL-texture with glTexImage2D()". ( http://cairographics.org/OpenGL ), same thing it does now with GDI surface, therefore, same slowness is expected with Cairo.
Custom Orbiter-specific drawing system, however, will allow every client to use whatever drawing system fits it needs and speeds.

 

[Urwumpe]

One thing i don't like about Cairo is that iam not sure that it will be better than GDI from the OpenGL compatibility point of view - "Copy the cairo-surface into an OpenGL-texture with glTexImage2D()". ( http://cairographics.org/OpenGL ), same thing it does now with GDI surface, therefore, same slowness is expected with Cairo.
Custom Orbiter-specific drawing system, however, will allow every client to use whatever drawing system fits it needs and speeds.

Of course. Also I think we could implement more spaceflight or avionics specific drawing functions into such a library as high-level functions as long as all clients at least implement the low level functionality. But the question is, can we do this? And if "we" can't do this, can somebody do this?

 

[cjp]

Of course. Also I think we could implement more spaceflight or avionics specific drawing functions into such a library as high-level functions as long as all clients at least implement the low level functionality. But the question is, can we do this? And if "we" can't do this, can somebody do this?

My experience with implementing 2D graphics APIs is that it's lots of trivial work. So if you keep it very simple, it might only be a moderate amount of trivial work, which is doable.

The most difficult part would probably be to make the decision to make your own API (while similar APIs already exist), and to decide what's going to be in the API and what is not. Of course you could start with a basic API and extend it in later versions.

If you start with a complete low-level API, and add increasingly high-level functions, then you could provide a "non-accelerated" default implementation for all new functions on top of existing API functions, so that OVPs don't have to implement all functions.

So, what would be the priority list? Something like:

• Draw pixel (the fundamental low-level building block)
• Draw bitmap (a lot faster, and allows "client-side" rendering)
• Draw line, circle, oriented ellipse, rectangle, polygon (with line / fill color settings)
• Draw text (x, y, and alignment setting)

Did I miss something important? I guess you can already do most things with the above functions.
Many of them can be implemented easily on top of OpenGL. Text is a bit more difficult, but there are tricks for that. If you want to do it portably, you'd probably end up either using a portable text rendering library, or accepting a low-quality fixed-width font. DirectX isn't portable anyway, so any DirectX implementation might as well use GDI functions for implementing this 2D API.

Edit: added polygon; removed line width. I don't think line width is really necessary, and it could be difficult / slow.

New idea: a compatibility layer could be made for existing plugins, using a bitmap hDC on the plugin side, and then call the bitmap drawing function of the visualization module. Add a big red warning to the API docs that this is for backward compatibility only, and should not be used in new projects.

 

[cjp]

I made a first version of what I call AVSGL: A Very Simple Graphics Library. The header file is attached.

The graphics in the attached screenshot are generated with the following code:

void redraw()
{
        static unsigned int framenum = 0;

        const AVSGL_COORDINATE x[5] = {50, 100, 100,  75,  50};
        const AVSGL_COORDINATE y[5] = {50,  50, 100, 125, 100};
        const AVSGL_UINT numPts = 5;

        framenum++;

        avsglClearScreen(0, 0, 64);

        avsglSetDrawColor(255, 255, 0, 255);
        avsglSetFillColor(255, 0, 0, 255);
        avsglRectangle(100,100, 300,300);

        avsglSetDrawColor(255, 255, 255, 255);
        avsglSetFillColor(0, 255, 0, 127);
        avsglRectangle(200,200, 400,400);

        avsglSetDrawColor(0, 255, 0, 255);
        avsglPolygon(x, y, numPts);

        avsglLine(300,300, 300 + (int)(100*cos(0.1*framenum)),300 + (int)(100*-sin(0.1*framenum)));

        avsglCircle(300,300, 100);

        avsglOrientedEllipse(400,100, 200, 200, -50, 50);
}

I think the bitmap drawing API still needs some tweaking. Using something like "texture objects" is probably more efficient than re-submitting the bitmap data every time.

I'm planning to release my (currently unfinished) reference implementation as GPL, but the interface (including the header file) will be available under a less restrictive license. Basically, I want everybody to be able to make his/her own implementation, but I want to make sure that different implementations continue to be compatible.

Basically, the Orbiter program should export this API to plugins (e.g. MFDs or vessels with a 2D cockpit), and provide a drawing context mechanism. The OVP projects should provide implementations of these functions. If an OVP programmer doesn't want to implement each of these functions, he/she can use my (GPL) reference implementation. The main Orbiter code only needs to make sure that each AVSGL call reaches the visualisation module in the correct way.

Is this an interesting scenario? Or do you OVP developers already have other plans?