SFML's OOP handling of primitives.

[Pixel_Outlaw]

I know I've touched on this briefly before but I am curious about primitives being objects. I can see polygons as objects because most of the time the programmer needs to store points and data. Lines seem a bit odd however to make objects for a graphics library.

I've been pondering making a game with line style graphics (like we see in the 80's). It seems like kind of a waste to keep beating on the RAM frame after frame making multiple calls to create line objects just to have an image. I can understand sprites and polygons being good objects to model with static data but perhaps we could be given lower level access to simply drawing directly to the window without creating many many simple line objects? It seems a bit wasteful to have to store a line in memory just to render it to a window.

I'm just curious about the need for objectless drawing commands for more simple and dynamic shapes that must be constantly changed.

I'm very new to SFML so I don't have a lot of room to speak, I'd just like to know if there is any interest in directly rendering to a window without storing data in an object first.

Speaking of drawing directly to a window, is there a possibility of using fast raster warping and distortion effects without dabbling into OpenGL?

Thanks

[Laurent]

I'm very new to SFML so I don't have a lot of room to speak, I'd just like to know if there is any interest in directly rendering to a window without storing data in an object first.

This kind of rendering was good 15 years ago, when rendering commands were directly translated to pixels that were then directly written to the target surface/window.
Now with OpenGL and hardware-accelerated rendering, things are more object-oriented. You must first prepare the data to render, then upload it to the GPU and finally issue a command to make your graphics card process and render the data. This is how you can render millions of polygons per second.
Of course there's no problem to draw dynamic data, and even to hide it behind an "immediate rendering" API (like OpenGL did at the very beginning), but I think it's better to make users directly think object-oriented, so that their program structure more or less matches the rendering process of the graphics card and they can get maximum performances.

Now, let's focus on your particular context, drawing dynamic lines. In SFML 1 there's indeed no efficient way to do this and I'd say use OpenGL. In SFML 2, the (hopefully) upcoming new rendering API will be more low-level, flexible and closer to the way OpenGL & GPUs work. Drawing dynamic lines will then be as easy as this piece of code:

Code: [Select]

// init
sf::Geometry lines;
lines.SetPrimitiveType(sf::Lines);

// update
lines.Resize(count * 2);
for (int i = 0; i < count; ++i)
{
    lines[i * 2 + 0] = sf::Point(/* position, color */);
    lines[i * 2 + 1] = sf::Point(/* position, color */);
}

// draw
window.Draw(lines /* + a few other parameters */);


Speaking of drawing directly to a window, is there a possibility of using fast raster warping and distortion effects without dabbling into OpenGL?

The most efficient way to do this kind of effects is with shaders. Other potential solutions depend on the details of the effect to achieve.