Doesn't it work only for .0f and 1.0f alpha values?

You can choose any value which looks well as the cutoff point, but you aren't looking at your screen with a magnifier all the time anyway.

Let me repeat some of my (some rhetoric) questions.

1. The concept considers enough translucent objects, so I have to make own ordering, right?

There are very possible translucent objects over other translucent objects, so what I am doing actually makes sense.

2. If my approach to translucent objects is okay, at this phase it can suffice other purpose, as work with opaque objects. I ignore zBuffer, but I do not create an algorithm to replace zBuffer. I use already existing algorithm that has to exist, as zBuffer isn't compatible with translucency.

3. I need to separate visible objects from not visible, to avoid possibly many meaningless render calls, don't I? This is what my vectors inside order indexed vector easily do.

You can choose any value which looks well as the cutoff point, but you aren't looking at your screen with a magnifier all the time anyway.

But it loses somewhat that I would call "nicety". )))

Edit:

Sorry for double posting.

1. Do the most important thing first, aka the game. There'll be most likely less partial transparency than you think now and for 2 or 3 windows on the screen it can be postponed.

2. You should not slow down your programming and the whole game by running everything through CPU sorting when most objects dont need it. Using the z buffer is (nearly) free and already there (unlike your half-done sorting mechanism), you gain nothing from ignoring it.

3. You are wasting CPU time if you cull every single sprite. The GPU clips all triangles which do not fit inside the screen already, which is nearly free and avoids having holes in the VBO which make you do needlessly many drawcalls or rewriting the VBO every frame. That is only worth doing for large meshes.

1, 2. You are right.

I am not sure of how much translucency there should be.

As I imagine currently, there is a lot of translucency. Translucent environment, translucent cursor, translucent effects, roofs being translucent, units being translucent to make you able to see units that are behind other units, etc.

I am feeling translucency paranoia right now.

(But there is some right feeling behind this paranoia, as I will blame myself once I need much translucency at game making stage, and I didn't implement it well enough)

3. I trust you that it is indeed nearly free, but still, if I do not use batching (as it makes no sense to batch translucent objects), I would better clip them myself, as it's not as nearly free in drawing case as it's with batching. (Because in non-batching approach for translucent objects I have my sprite objects and pass through them. Even if it doesn't draw anything outside of screen, I still call "empty" methods, that are better to avoid if it's possible, and it doesn't require much resource to actually do it)

Edit:

Btw, all these methods are inlined!

There should be just a loop with switch in the result code.

I have another one question!

Seems a bit dumb but still.

Objects are good to put together, so you don't jump far in memory.

As I did,

gfx container is a vector of blablabla of gfxs, not pointers. I did it because I was thinking about passing speed: passing through objects is faster than through pointers. The minus is that I have to swap the whole content in this case, not just a pointer.

But how much significant is the difference between passing through objects and through pointers if the objects themselves are located close each to other (not close to a point where loop starts, but still each to other)?

For example, if I create all my objects on stacks, so they are local.

And then my container is of gfx pointers, not gfxs themselves. This means that every time that I go through array it jumps to stack and back.

The main question is, how much slower is this compared to direct object vector?

If objects would be created not in stack, but scattered throughout all the memory, that might happen by allocating objects 1 by 1, this would have significant speed loss for sure. This would be really bad implementation.

But about creating objects at a stack, I am not sure.

Is it what I really would like to do in this case? Is it a solution to create objects at stack and have pointers to them?

Or it's better to keep it as it is, and just deal with slowness at objects swapping?

3. I trust you that it is indeed nearly free, but still, if I do not use batching (as it makes no sense to batch translucent objects),

I'm curious why it makes no sense to batch translucent objects. I've been working on the UI library which replaces libhwui in Android and batching was one of the most essential parts of it. The transparency of anything may be well... anything. This was actually very difficult case as speaking general UI, you can't predict what user will try to render (bitmaps, paths, fonts, shapes etc. ) and with what kind of setup (color, tint with gradient, opacity and 100 other ways ). Anyway we decided to batch things and create tiled atlas to support it. So in very many cases we could actually render certain android views with a single to few draw calls (with lots of optimisation). So that I don't quite understand why batching in your case makes no sense. Triangles are being rendered in the order of submitting them to the pipeline. If they overlap ( let's say you batch two quads, the second quad overlaps first and is translucent ) so first quad will fill framebuffer, and then the second quad will simply blend with it. If you are more worried about configurations ( different object may have different opacity etc. ) this can be done even with extra attributes, and in many other ways. If it worked for totally unpredictable UI, then why wouldn't it work for you?

Objects are good to put together, so you don't jump far in memory.

What you trying to implement is "data oriented design". It's actually good if you want to make sure you use CPU cache the most optimal way ( but putting everything together doesn't solve the problem entirely ). The major problem with DOD is that its maintainability may quickly get out of your hands. And still you're thinking about optimising stuff too early. From experience I learned that when it comes to performance optimisations, the bottlenecks are not what you expect, so it's better to wait till you have actual game that you can optimise. Otherwise now maybe you wasting time on DOD, which in fact may add "peanuts" to the overall performance and may not be worth time you spend even thinking about it.

3. I trust you that it is indeed nearly free, but still, if I do not use batching (as it makes no sense to batch translucent objects), I would better clip them myself, as it's not as nearly free in drawing case as it's with batching. (Because in non-batching approach for translucent objects I have my sprite objects and pass through them. Even if it doesn't draw anything outside of screen, I still call "empty" methods, that are better to avoid if it's possible, and it doesn't require much resource to actually do it)

No, this is really not true. You want to batch everything, be it intransparent or transparent, doesn't matter. What you do is, you make separate passes for those objects: First, you batch all intransparent objects (eigther make it a flag of the objects that you set manually or analyze alpha values in the textures at load/tool-time). You sort those front to back and per texture (which can be done in one sort-call). You use a z-buffer and have both z-write and z-read on. Then, you make a separate batch-pass for translucent objects. Now you sort those objects back-to-front and per texture (again, possible in one sort combining both conditions in the sorter). Now you disable z-write, but still use the z-buffer for the translucent objects not to overlap the other objects where they should not. If you have additional/subtractive blending, you might want to have another batch pass where you only sort by texture, since additive blending doesn't require any specific ordering.