Render targets

[Aleksander Luiz]

Hey there,

I am new to ClanLib, so I guess this may be a simple question: are there render targets in ClanLib?
I mean, I don't even know if render targets are a concept in OpenGL, but in HGE [Haaf's Game Engine] I used it frequently for drawing off-screen sprites.

What I want to do is blend a few sprites together off the screen (because the pixels in-screen would interfere with the process), and then render the result in the screen. I suppose it has something to do with frame buffers/graphic contexts, but I'm not quite sure, so I just need a little light here.

Besides, I would like to thank you for this great engine. I don't know how stable it is yet, but it has been surprisingly good so far. Looking at all this code makes me understand why you don't have a great documentation: you must have spent a LOT of time working on this. So congratulations for you developers, and thank you for making it free.

[rombust]

ClanLib uses "FrameBuffers" to render off screen images.

So you can create a framebuffer of a specified size to render an image to.

See ClanLib\Examples\Display_Render\Canvas.

Unfortunately ClanLib will not be getting documentation in the near future. Everybody is too busy.

The problem with ClanLib, and it's downfall ... it's too big! It tries to fix all problems in the developing environment.

With hindsight, that's a fatal mistake.

This discourages new developers. There are not enough developers to maintain the existing code base.

It's not easy to turn back the clock. I personally see potential in each ClanLib component.

Off topic, but i'd suggest - without investigating:

1) Drop clanPhysics2D. Instead have an example that uses Box2D. Nobody is maintaining it or using it, as far as I know
2) Drop the CSS component of clanGUI. Have CSS component as a plugin, on top of clanGUI.
3) Drop clanSound. Maybe a dedicated library with a friendly license will be more powerful, and contain nice effects.
4) Drop WindowsXP support. (The WindowsXP layered window support isn't really required in 2014)
5) Drop clanSWRender. We don't want to support machines from the steam age.
7) Drop clanCompute. Noone used it. Nobody will use it, now OpenGL 4.0 is widespread.
8) Remove parts that want port nicely to mobile platforms.

Of course all developers would have to agree, and i'm sure there will be lots of objections, probably all valid.

[Judas]

I completely agree with you, Rombust!

As the few people hanging out in our IRC channel may have noticed, I've spent some time on writing a new UI system as a replacement for clanGUI, but I haven't been doing this as part of ClanLib. Why? Because ClanLib has become too big for its own good. Not only does it make the documentation burden unbearable, it also generates the same problems as any framework has (.Net framework, Qt, etc.) As API design and languages evolve, the burden of backwards compatibility or updating targets becomes a never ending task.

For example, we did the mistake (like everyone else in the industry) to assume the XML DOM API designers had any idea of what they were doing. So we made our XML classes try to follow that standard as much as possible. It turns out that those guys had created an overcomplicated monster that addressed the pet-project of each of the 100 people working on it, but never made it easy or convenient to walk, read or modify a XML tree! In the meantime some other devs realized this and created things like libxml2, jQuery or XDocument in .Net and so on.

But because ClanLib is one huge monster, we can't easily just toss the old idea over right shoulder and swap in a new one. If we do, we discover the old one was being used tons of places in ClanLib itself and also by every other app using the library. Alternatively we could do like Microsoft did and create a new class next to the other one (XDocument vs XmlDocument in .Net), but not only does this mean we have two co-existing for all eternity, we also have two to port to whatever new place we want ClanLib to go. We tried to do a mixture of both, sometimes leaving the old in place and sometimes replacing it. Each time we did so we burned another developer - I'm quite sure there's a lot of ex-users of ClanLib that gave up on the library because they got tired of porting their own code each time ClanLib changed.

I've always believed in small self-contained code and ClanLib itself is internally a bunch of different mini-libs already (with class families inside that are separable too). And lately there's been this trend to have a "drop in this single file into your project to get functionality X" trend - like the miniz library, sqlite and so on. But the problem is that the entire suite of libraries in ClanLib share the same namespace and always have to stay in sync. This means for example the clanCSS and clanGUI experiment (which failed) now causes problems rather than helps. If we remove them, some poor guy that now wrote something with clanGUI will be screwed. If we keep it then we are screwed ourselves.

Now one could argue the source of the problem is that I've been coding too experimentally on ClanLib itself. And they would be right. But at the same time this is exactly what I find fun about coding in general, so if that is taken away I have no reason left to contribute. Virtually all the modules you list are things that I experimented with or needed at one time. The OpenCL module I needed because OpenGL 4 wasn't out at the time, and lucky me when I finally finished that module they release OpenGL 4. Someone out there might actually have found that module very interesting if they did OpenCL and didn't fancy C or the "C++ wrapper" included with OpenCL. But the average guy interested in games development no longer cares and the other OpenCL usages don't want the rest of ClanLib.

The size of ClanLib is also the direct reason why we have no fully functioning OS X, iOS or Android ports. Porting the most basic functionality wasn't actually that hard, but because of the monolithic nature of ClanLib, to support my game I also had to support windowing concepts only relevant for clanGUI system window managers. Things that might have taken a couple of days to port in ClanLib 1.0 now would take weeks because of all the guarantees given by ClanLib that I had to keep. I had the Pacman example and Rombust' game up and running years ago on the iPad 1, but supporting *everything* requires surprisingly much work. And everyone else attempting to finish the job drown in complexity.

Okay to end this rant I'll say that because of all the above issues, I decided to change tactics. I'm now focusing on minor libraries that only does a couple of things but does it well. That keeps the mature things away from the experimental things and allows me to cherry pick functionality I need more closely. Each of them will have their own namespace or may be designed in a way that allows me to drop them into other projects on a need basis. I'm still considering a sqlite amalgamation-like approach so I can still keep older code bases working and port modules and libraries when I explicitly need them.

The UI toolkit library I'm currently working on is only the first step in this new approach. Hopefully it will turn out to work better than the ClanLib way. In any case, don't be too surprised if I suddenly have a bunch of minor libraries using a very ClanLib-like API (often even using the same code behind) for the parts of ClanLib I really like. As a bonus such things should be easier to document and contribute to too.

[Aleksander Luiz]

Rombust,

as my understanding it is not a good idea to try implementing every kind of library in one big-as-**** library like clanlib. It is very pretty seeing it done - this massive all-in-one well organized library - but in practice it becomes impossible to maintain it. One annoying problem of doing so is that all technologies are constantly changing, and you probably won't have the time to update everything before they change again.
So the best idea is to use one specialized library of each kind. This way you can be sure they all will be kept up-to-date and well tested.

As for what you pointed about, I won't be using physics in my game and neither GUI, and I have chosen to work with Bass Audio Library as I will be needing the fourier transform. I also don't think that game developers should be worrying about making games for computers that don't run windows 7, as XP itself had its support ended and vista is just microsoft's prodigal son.

I don't blame you for not being able to maintain a few parts of clanlib, and I don't think they are that important. After all, most people will end up choosing a specialized library for SQL / Networking / GUI. I think you guys should focus on what clanlib is primarily designed for: making games. If you want to keep going with all the other stuff, you better get a bigger team.

Finally, I don't feel intimidated by the lack of documentation of clanlib, and so far it has been nice to unfold its functionalities. Perhaps when I get better on this, I can contribute with the documentation if you can correct my english mistakes .

[rombust]

We don't plan to change anything soon. Even if we did, it would be a slow migration, not rushed.

Many people still use ClanLib, for Open Source or Commercial. There would be nothing gained from simply chopping components, without an alternative.

I believe someone is experimenting in modularising problematic areas (for example, separating the XML model from clanDisplay and CSS from the GUI). It will be interesting to see how this develops.

What might happen is that the ClanLib is separated into more modules. With some moved out of the official source tarball.

ClanLib should be modular, with few prerequisites for each module (e.g. clanCore components ... Vectors, Rects).

ClanGUI is a strange beast, it can do anything and everthing! But if you want to create a simple pushbutton in a game, not using CSS, Resources and position it at 100,100 at 32pixel size, with 2 alternerate forms of png's for the background.... You can ... But you need to be an expert to ignore all the API that you just don't need! Even myself would have difficulty. So, I ignore clanGUI and write it all myself.

[moogtrain]

All GUI components in ClanLib REALLY need to be rewritten from scratch. It's not because they are badly designed but because they are all implemented using the CSSLayout and XML modules. The abstractions used in their implementation, piled up with improperly documented and incomplete code makes them a huge pain in the ass to work with and they are practically unmaintainable.

1. Heavily nested if-if-if-if-else-if-if-if-else-if crap needed when processing InputEvents. A helper class/function could've made this so much more readable.
2. To change the look of a built-in GUI component one has to open at least 3 files and work with them simultaneously. They are: the stylesheet (CSS), the resource descriptor (XML) and one or more PNG files for each individual image used by the GUI component.
3. The themes provided are hard to modify. On the unpacked theme you need to load >1 image for that ONE component and work on them simultaneously. Meanwhile in the packed theme, everything is stuffed inside one PNG file and every positional value is hardcoded into the XML, so you can't make the images larger without having to re-order everything. Why not just have all the images used by that one component be inside one image file?
4. ZERO technical documentation on how the builtin components are laid out and rendered in the pipeline. Placed on top of the huge list of abstractions, I always assumed that these things are magical.
5. clan::GUILayout is marked as deprecated yet it still remains as a vital part of the GUI system to make it possible to instantiate subcomponents using a position parameter.

I pretty much gave up at #2 and wrote my own GUI components to do the job because it's just so much more easier. Here's a simple switch button in ~200 LOC, rendered using only 4 lines and a quad, supporting all 5 different input states (off, on, off-hover, on-hover, pressing).

[Judas]

I do not see the problem with a 360 lines long input processing function.

OK, more seriously, yes a lot of things have gone wrong with clanGUI and most of the standard components were there along for the entire ride. Originally, clanGUI did not use CSSLayout and had its own simplified property system for styling. It also did not have any official way to position components beyond set_geometry(box). GUILayout was introduced as the way to do automatic layouts, but Harry was the only one to ever implement something using this interface (the top,left,right,bottom scaling layout algorithm). Then later on CSSLayout was introduced as an attempt to layout and style the way HTML does it. The standard components never really got properly ported and still use some nasty mixture of manual layout and hardcoded spacing rules.

I would caution against trying to rewrite all the components from scratch though. Especially the line/text edit controls and the listview are a lot of work. It is a lot easier to simply clean up a function like the one you linked by creating the helpers you mention and move the code over. This is easier than a rewrite because the amount of small things an input control must support adds up. A rewrite would most certainly result in forgetting half of the features in the initially rewritten version.

Anyway, to move clanGUI into a more repaired state, you'd have to figure out which of the following things you want to do:

1. Remove all styling code. Remove all layout code. Remove all XML/CSS code. Remove all standard components. clanGUI is now a simple component tree with event and focus handling. It is repaired and sane, but still lacks especially a proper automatic layout strategy.
2. Create a new styling strategy that doesn't rely on CSS. Create new layout method. Port the standard components. Still remove XML/CSS stuff as it won't port.
3. Rewrite the entire thing.

Personally I'm working on a sort of mix between a rewrite and porting. It is still very much in its earliest stages and currently doesn't rely on ClanLib at all. It is called UICore and its github project can be found here: https://github.com/dpjudas/uicore. The main difference between this version and current clanGUI is that I'm trying to describe the style in a way more useful from code and without CSS selectors. If my experiments in that project turn out successful I may create a ClanLib backend for its Canvas for my ClanLib UI needs.