Transparent Backbuffers

[cyberkilla]

Egon, is it possible to have a quick method/constructor parameter,
that would allow the use of a BITMASK backbuffer, when possible?

I know this isn't used on the 1.1vm, but on the later sun vm's, it is just a simple
change of a flag from OPAQUE to BITMASK.

It don't know how it all works, but, is is possible to set up such an option?

That way, I could pass a transparent color to clear the framebuffer before render.
Then, I would not have to have the additional step of drawing to another image, to manually set the background to transparent.
It is a difference of 25fps, shockingly.

This would be a great help to anyone trying to superimpose rendered models
into a 2d environment.

Perhaps, if its possible, the next version of Jpct could have this functionality?

My appologies, I realise I am asking a lot of questions:) I just want to squeeze as much power out of the engine as possible.

[EgonOlsen]

Try this: http://www.jpct.net/download/beta/jpctapi.zip
It has a new switch in Config called useFramebufferWithAlpha. If you set it to true before creating your FrameBuffer, the framebuffer should support an alpha value (you'll get a console message about this too). Rendered (and blitted) parts automatically get a 255, the rest depends on how you clear the buffer. Does this help?

[cyberkilla]

Unbelievably helpful! Thank you!

Ill report back in a few minutes...

EDIT:



As you can see, your update works PERFECTLY!
Solved a lot of problems. The next problem is with my own z-sorting. After I fix this personal bug, Ill be able to have a good 15-20 models on-screen at the same time, I hope:)



This shows exactly what is being actively updated.
Only models, and intercepting tiles are redrawn:)

Note, these are the test models. I believe I will be using these as the naked body to put textures and clothing on. They look male, and humanoid, so they'll do:)

Thank you Egon!

[EgonOlsen]

COOOOOOL!  

[raft]

Try this: http://www.jpct.net/download/beta/jpctapi.zip
It has a new switch in Config called useFramebufferWithAlpha. If you set it to true before creating your FrameBuffer, the framebuffer should support an alpha value (you'll get a console message about this too). Rendered (and blitted) parts automatically get a 255, the rest depends on how you clear the buffer. Does this help?

as far as i remember i once requested this feature for karga's avatar panel. i'm glad it's now implemented

old transparency functionality with new alpha frame buffer. this way performs better and more important relaxes the restriction on avatar texture colors

Code Select Expand

r a f t

[EgonOlsen]

as far as i remember i once requested this feature for karga's avatar panel. i'm glad it's now implemented

old transparency functionality with new alpha frame buffer. this way performs better and more important relaxes the restriction on avatar texture colors

I dimly remember something like this. I think that i didn't want to add it at that time, because i thought that the additional processing needed in the software renderer would cause a slowdown. But obviously it doesn't, at least not noticable. Great to hear that this change is good for Karga too   .

[raft]

oh yes it is

egon, it's your choice of course but i believe it may be better to add alpha option to FrameBuffer's constructor, either with a new a signature like:

Code Select Expand

new FrameBuffer(width, height, samplingMode, FrameBuffer.USE_ALPHA);

or with a bit mask in sampling mode like:

Code Select Expand

new FrameBuffer(width, height, samplingMode | FrameBuffer.USE_ALPHA);

i suggest this because otherwise for clean usage that one line of code becomes:

Code Select Expand

boolean useAlpha = Config.useFramebufferWithAlpha; // store value
Config.useFramebufferWithAlpha =  useTransparency;
FrameBuffer buffer = new FrameBuffer(width, height, samplingMode);
Config.useFramebufferWithAlpha = useAlpha; // restore

just a suggestion before 1.13 is officially released

Code Select Expand

r a f t

[cyberkilla]

I dont know, it looks fine to me.

I wouldnt use masking, because it looks dirty and evil in this case:)

Well done btw, this is helpful in many ways:)

[EgonOlsen]

@raft: I thought about this too and i don't really like the Config-solution myself, but i dislike the FrameBuffer-constructor one even more. This is because the framebuffer is not coupled to a renderer unless you do so (except that it creates a default one). That would mean that you may enable alpha with it, but it's only valid when software rendering is being used, because hardware doesn't support this.
That makes it a bit unintuitive. On the other hand, i'm flooding Config with all these things that are only valid for OpenGL or software...that's also bad.
Well, i think the design got flawed years ago and it's to late now to change it.  
Anyway, i'll think about it once more...maybe there is a better solution then these two and we haven't seen it yet.

[cyberkilla]

Ah, it is hard to keep things "clean".

I do not like the way people frown on you when you opt for static classes.
Half of the battle with Java, for me at least, is keeping the code reusable, and generic as possible, to permit re-use, and keep everything working with everything else.


You could make a nested static class, inside of Config.

Then perhaps, "Config.software.someHint = true;".

They are just hints, so you need not put them in the constructor, as you say.

[EgonOlsen]

It's not that hard actually...but it's hard to do it without changing the API, which is something that i'm trying to avoid at all costs, because it renders all examples, code snippets, sources etc useless. While this may not be a problem for an experienced developer, it is one for a less experienced.
One of the basic ideas behind jPCT is to be able to drop a new version into your classpath and everything will still work. Of course, sometimes i'm removing a method or two or change a behaviour but i'm always trying to make the transition as smooth as possible.
The drawback is, that things like Config arise...with bad naming, almost no structure and one has no idea why something is in Config and not in the class itself. Light is a fantastic example: You have a Lights-class, which does almost nothing. Lights themselves are managed by the World and there are some settings in Config that affect lighting. To complete the mess, we now have a Light-class in util, which actually wraps the World-methods into cleaner ones and allows to override some global Config-stuff per light, because it was just stupid to put these things there...but that happened years ago, where jPCT was not much more than a simple demo applet rendering a rotating box.
FrameBuffer itself is another great example of a WTF?-class, but that's caused by the fact that hardware and software rendering work fundamentally different (and as if this wasn't enough, the AWTGLRenderer is a completely different story too). You should see the construction that i had to build to make the render-to-texture in 1.13 work in a renderer independant way...no wait...you should not see this...  :wink: I thought very hard about this, created two solutions that i scratched because they felt just wrong and ended up with what we have now...something that seems to be almost intuitive, but if you think a bit about it, it only is 80% intuitive and 20% strange. If you look behind the facade that FrameBuffer builds to hide the difference, it's 90% strange... :wink:

But the damn thing somehow works, it is small and easy to work with IMHO.

[raft]

But the damn thing somehow works, it is small and easy to work with IMHO.

yeah, that's what's most important