I'd SO prefer the Gamestudio style with OO!

Gosh, sorry for the late response, I've been really busy in the past couple of days and simply forgot about it!

Anyways, I'm afraid I have to disappoint you. Gamestudios approach is just not versatile in any way, it's straight forward, but it's, simply put, very limiting. Rayne features a full fledged Entity system based around scene nodes. A scene node is simply an object that is somewhere within the scene graph, without anything in particular attached to it. It implements the visitor pattern, and gets it update() method called once per frame, and it can have zero or more children attached to it.
By itself, a scene node is kinda boring, so there are subclasses to it, for example the Entity class, which supports rendering of a model and which you can also assign a skeleton to. Then there is the light subclass, which, well, implements a light, and then there is a terrain class, water class etc. We follow the KISS principle here, that is, we encapsulate different logics within their own classes, and don't have a "one fits all, kindaish" gamestudio model. The problem with ENTITY in gamestudio is that, because it doesn't support inheritance, it has to play everything. An ENTITY can be a light, a terrain, an entity, or just about anything within the scene graph, and there are flags that only affect a few of these cases.

In Rayne you instantiate specific subclasses of the SceneNode class (which might be your own) (or you instantiate a SceneNode directly, which is useful in some cases). By default, they are then placed just inside the world without any attachment to anything else, but you can attach scene nodes to other scene nodes. Childs are affected by their parent, that is, if you move/rotate/scale the parent, the childs are affected by that as well. In Occluded we used that to attach the cameras to the player herself, and have the camera move and rotate together with the player, something that isn't possible in Gamestudio for example.

Scene nodes can also have properties attached to them, which is pretty much an inverse relationship; The property affects the scene node it's attached to, for example a collision hull.

Honestly, I think the way we are going is the logical way, although maybe not the one that is most straightforward. But it allows abstraction, and customization. Take Gamestudio for example, if you want to implement your own physics engine on top of it, you then have to figure out how to store the related data for collision hulls and other properties of the entity. You will likely use a skill for that, simply because an ENTITY is static in its way and can't be altered. This is an incredibly unflexible entity system, because it doesn't give you much freedom. On the other hand, if you can simply provide properties for your physics engine implementation, these properties can then be attached to scene node, allowing for a well formed entity system.

offtopic: it was a great idea to ask Eurythmics to write a song for you "Here comes the Rayne again" http://www.youtube.com/watch?v=4c9r15O1JVw

Sivan, I don't see how this could be off topic. If I have ever seen an on topic post in my life, it's yours.

Also, let's talk about UI for a bit. A pain in the ass in Gamestudio, not much better in Unity, and in general something you don't really want to touch. Also, it hasn't come up yet and I've got a few questions about it already (Error, Pad, I'm looking at you, you fabulous creatures!)

So, first things first: Rayne doesn't use the immediate rendering approach that Unity uses, but a retained approach like Gamestudio, with the exception that it actually makes sense and doesn't make you want to hit your head repeatedly on the desk until the mental pain is relieved by the physical.

Before I start, let me tell you why Unity got it wrong: Because doing any kind of sensible layouting in Unity goes to shit. It is kind of like HTML in that regard, which is great, don't get me wrong, but loses too much control, which you probably want to have. So retained rendering it is, meaning you create objects and layout them how you want!

So, now that we've got the cleared up, here are the basics: There are three root thingy things, the first one being the ui server. The ui server drives the whole ui, it responds to resolution changes, tracks input, and dispatches input events down the responder chain. Then you've got the Widget class, which represents something similar to a Window, but without any chrome around it. A Widget contains zero, one or many Views, which take care of the actual rendering (and a few other things).
Then, there is the responder chain. The responder chain determines HOW input events are handled. Widgets and Views together build the responder chain, and the ui server passes down input events into the responder chain. I don't want to bore you with too much details, but the basics is that Rayne has a very mature ui and event system.

Then there are concrete subclasses of the View class, which provide all sorts of things. There is the generic Control class, which can be used to implement controls (and which is subclassed for example by the Button and Textfield class), there are subclasses for labels, scrollviews, image views and a fuck ton of other, very high level, stuff, and you can all mash them together to build your interface (views can have subviews, which in return can also have subviews). Even more useful, you can provide your views with layouting options, so your views get automatically resized when their parent view resizes; In a way that you decide! UI that automatically adapts to resolution changes? No problem!
The way Rayne handles the UI allows you to composite highly complex user interface elements out of the basic UI components. For example, the Button class has an ImageView and a Label as subviews, and depending on how you setup the button, it will layout them accordingly (for example, you can tell it to have the image to the left and the text to right, or the image on the top and the label on the bottom).

Here is an actual example of that, a button that displays a title and an image:


And here is the code for that example:


Also note that the button is smart enough to handle the layout correctly, which, by the way, is completely customizable (as well as you can customize different images and titles for the different button states).

Speaking of customization: Raynes UI is completely customizable. There is a JSON file which describes the complete colour scheme, what the default fonts are, how the default controls look like, what textures are used, what the insets are, and so on, and so on. Seriously, it's up to you how your UI looks like (and I hope that you have better UI graphics than we do).

Then, there is Raynes typesetter, and incredibly powerful class. It builds the core to all text rendering, and is completely accessible to you. You have complete control over the way paragraphs are aligned, how they get truncated, how kerning should be applied, how many lines it should render at max, if it should truncate lines... It's a beast, it knows text, it knows about vertical and right to left texts, and it knows how to style text. It knows where the characters of your text are, so you can perform hit tests against them, for example to check on which character the user clicked. You don't have to drop down to the typesetter level, but if you want to, your possibilities are endless.
Acknex TEXT object is a joke compared to the beast that is the typesetter, and I'm going to prove that to you with a few screenshots:




These three screens simply demonstrate the typesetter knows about linebreaks. The first two are two of the three truncation modes, in which the typesetter will add an ellipsis to truncate the text, the second one is simple character wrapping. Supported are the following line break modes:



But that is lame, isn't it. How about something fancy, first of all, all non english speaking people: Rejoice, for Unicode is completely supported in Rayne:


Here is the code for that example (note that I had to change the font because the default Rayne font, Helvetica, doesn't support cyrillic):


Right, so, simple, you can do that in Acknex as well. How about this then, coloured text with different fonts?


And here is the code for that example:


That's almost cheating, isn't it?

all sounds great, and hopefully it is rendered much faster than gamestudio (which is very slow when using true type fonts...)

what I forgot to ask: is there any article about tile based forward rendering, what is relatively easy to understand? it sounds quite promising and up-to-date, but I found only too detailed ones I don't really get... (and mainly dealing with rather tile based deferred rendering)

Since we do a depth prepass, which is anyways needed for the lighting and which helps us to get rid of overdraw, one could already call our approach deferred. The idea behind tiled lighting is, that you split the screen into rectangles of the same size and generate a list for all lights visible in each of those rectangles. Then in the fragment shader used to render the scene, each fragment determines within which rectangle it is and uses the according list of lights for that, which is usually a lot less than the lights of the whole scene. An better approach is probably the so called clustered forward rendering, which also uses 3D boxes instead of 2D rectangles, by also taking the depth into account. I plan to change our system there, but did not yet get to experimenting with it.
I am gonna write a blog post about this somewhen in the future and will post some links for you somewhen later today or tomorrow.

Comparison of different lighting techniques with focus on tiled lighting/bimodal clustering systems and how to make it fast: http://bps12.idav.ucdavis.edu/talks/03_lauritzenIntersectingLights_bps2012.pdf

You´ve probably seen this one before, its about techniques from need for speed the run and battlefield 3, like a bokeh effect, but starting at page 64, there is also a very informative chapter about their tile based deferred lighting. I however just noticed that the High-Z chapter as well as the min max shadow mapping part is looking quite interesting, although the latter reminds of some paper about so called smoothies, I read a few years ago...: http://dice.se/wp-content/uploads/BF3_NFS_WhiteBarreBrisebois_Siggraph2011.pdf

Then there is this one about the clustered shading approach in probably the next just cause or something, which is another really amazing paper: http://www.humus.name/Articles/PracticalClusteredShading.pdf
And then there are the power point slides of basicaly the same from this years siggraph together with a couple of other great presentations: http://advances.realtimerendering.com/s2013/

And this is like the first paper you find when searching for it, which is good but not as good as the others in my opinion: http://www.cse.chalmers.se/~olaolss/main_frame.php?contents=publication&id=tiled_shading

And as a last resource you might want to have look at AMDs forward+ papers: ftp://date.eecs.jacobs-university.de/confMaterials/EG2012/short/pdf/005-008.pdf
ftp://date.eecs.jacobs-university.de/confMaterials/EG2012/short/pdf/005-008.pdf
http://developer.amd.com/wordpress/media/2012/10/AMD_Demos_LeoDemoGDC2012.ppsx

There are probably a couple more, but those should get you started

Well, that was a tad anti-climatic... It does render much faster since it does a lot of smart caching on its content and only renders glyphs that are required. See the Screenshots of Downpour, which feature a huge amount of labels on the same screen.

By the way, Nils just published his blog post about Coordinate Systems, so head over to our devblog and give it a read: http://rayne3d.com/blog/10-05-2013-coordinate-systems-and-other-abstract-things

thanks, now tiled shading is more clear (and decided not to write my own system in the following years ), and the maths related blog post is also a useful overview.