Beta release 1.9.9b

Post by **VilleK** » Fri Nov 27, 2009 5:18 pm

I'm glad it's working ok!

Yeah please share some zgeproj-files Kjell, I would like to experiment with this myself and it would save us less math-gifted lots of time

. Btw thanks for the link to the shadowmapping-tutorial, lots of interesting information on that blog.

Post by **Kjell** » Fri Nov 27, 2009 5:44 pm

Hey,

@jph : Sure .. but keep in mind that the "ideal" setup for these kind of things all depend on what you want to do with them.

Anyway, the attached setup uses the Canvas properties* for the effect settings, while the falloff is taken care of in a shader ( too lazy to make it work with RenderSetColor ). But hopefully you'll get the jist of it through this example and can adapt it to suit your own needs.

*Just mess around with the Scale, Rotation and Position settings to change the effect.

It should look something like the attached image.

@Ville : Most of the examples I posted so far don't use any complex math at all ( apart from a pow() in the Fish-Eye example )

K

jph_wacheski · Post by **jph_wacheski** » Fri Nov 27, 2009 5:55 pm

Thanks a bunch! It seems good and stright forward now that I look at a working implementation,. has just been a bit frustrating when a couple elements are outside my limited knowlage base, so this really helps get me going. I will hack around from here and see what I can come up with. cheers.

Post by **Kjell** » Sat Nov 28, 2009 11:29 am

Suggestion / request .. what about a Cubemap component? Even though you can already do it yourself ( see attached ), the TextureCube function of GLSL doesn't take sampler2D as input. Or in case somebody can explain the inner workings of the TextureCube function, I could try to recreate it in GLSL

Not high priority though ..

+ Updated the Fish-Eye demo by doubling the RenderTarget resolution.

K

Post by **VilleK** » Mon Dec 07, 2009 5:30 pm

Beta updated today:

- RenderTarget size now use viewport width/height instead of screen size. This removes the borders in 16:9-mode if you are rendering to a texture. Suggested by Kjell.
- Code-completion in zge-expression editor is improved so that not only global identifiers are suggested. Now if you type "App." the completion will display the properties of ZApplication.
- Updated help file from yoffset included.

jph_wacheski · Post by **jph_wacheski** » Wed Dec 09, 2009 3:45 pm

Very cool working nicely for me,. I am quite enjoying this new tech. and am just barely scratching the surfface of the possibilities, thanks again Ville! Kjell feel free to drop more .proj examples on me, as much as that will be a distraction from my compo,. i do lov to see the amazing stuff you do! especialy when i can actualy play around with it,. .

Ther are some interesting bug report coming in over at TIGsource in that SonnenmördeR thread;

http://forums.tigsource.com/index.php?t ... icseen#new

May be usefull to you as there are a load of testers all with various machine settups trying this. Do feel free to jump in and question them in that thread. I don't have time to trouble shoot all these issues. It seems to work on a good majority of vid-cards.

Post by **VilleK** » Wed Dec 09, 2009 4:32 pm

I've just seen the bug-reports in the sonnenmörder-threads. I might get myself involved in that thread, meanwhile here are some advice:

Virus-warning: Yep, it's upx-compression not 100% accepted by all scanners. Workaround is to skip exe-compression and zip the file instead.

Monochrome sprites and white square: Shaders not present (many Intel cards either don't have shaders or are implemented in software which makes them slow).

I'm not sure what happens when FBO:s are not supported but hopefully it will only result in the feedback-effect not working.

When shaders are present but still not working it is likely to do with difference in syntax (glsl-shaders are compiled with the graphics driver). This is difficult to get right. If possible send the zgeproj-file (or a small project with just the shader) to the person having problems and ask him to run it in ZGE because the beta version displays GLSL-errors.

jph_wacheski · Post by **jph_wacheski** » Tue Dec 15, 2009 3:30 pm

Orel posted over at TIGs;

haa!, gave it another try this evening. good news! i've probably found what was wrong...
the render target texture dimension should always be a of two... otherwise ATI drivers obviously stop working right.

that was the only change, which was needed: Content -> Group "Canvas" -> CanvasTarget: RenderTarget -> CustomWidth/Height

so i've set those to a power of two, and it suddenly worked. 1024 x 1024 looks ok...
(here the modified project file.)

i've also checked my old example code, and saw that i exactly had that problem too back then.
so, you could send this info also to the ZGameEditor coder maybe... it's probably not only a problem on my compi.
one solution, to still use unstretched textures for FBOs, with the the same dimensions as the viewport, would be to make use of the GL_TEXTURE_RECTANGLE_ARB extension... since i've tested that in that old example, this could also help to implement it into the ZGameEditor too, (but i don't remember how all this really works, never used it really)... here this small test zipped up. should also be useable in Pascal, since the OpenGL part remains the same...

hope that will fix it Coffee

ZGameEditor is really powerful, i don't really get the interface yet, but maybe i'm going to play around with a little further soon...

Perhaps to increase compatability the "Viewport, 1/2, 1/4" settings of the Render Target component could be modified to internaly use a power of two, based on the port size, while still using the smallest fit?? I will try a hardwired 512x512 in the game I am working on and have him test to be sure.

Post by **Kjell** » Tue Dec 15, 2009 4:05 pm

Agreed

@jph : Keep in mind that sampling pixels from a stretched FBO in a fragment shader is quite slow ( on NVIDIA cards at least ).

K

jph_wacheski · Post by **jph_wacheski** » Tue Dec 15, 2009 4:12 pm

problem is not having the FBO as a factor of the viewport throws off the fullscreen alignment destroying the effect..,

EDIT; I just set the CustomViewportRatio to 1,. works a charm.

Post by **Kjell** » Tue Dec 15, 2009 4:30 pm

That's not what I meant .. even when you render a 768x768 viewport to a 1024x1024 FBO, ( and right now ZGE uses the full FBO ) the "texture" will be stretched ( scaled down ) when you render it at a 768x768 resolution again. Same with 512x512 of course .. but then it's the other way around ( scaled up ). Plus it never looks as good as using a FBO 1 on 1.

Not a major issue .. just something to keep in mind.

And "alignment" can be corrected by dividing the vertex coordinates of your fullscreen sprite by the viewport ratio.

K

diki · Post by **diki** » Wed Dec 16, 2009 11:28 pm

i'd like to report that my laptop (intel t2600 1.67ghz w/ ati mobility radeon x1600) is running less than 1 frame per second on anything with FBOs involved. i've got no clue wether this is a problem of old hardware or ati, but i'll be glad to help in finding the bug - provided it is one - if it should reoccur with other people, too. (but lets see what villes new laptop will say about it.)

jph_wacheski · Post by **jph_wacheski** » Thu Dec 17, 2009 1:00 am

have you tryed my proto 5 or 6 here;

http://forums.tigsource.com/index.php?topic=9682.0

the power of 2 thing seems to help but I would like to hear if that helps your speed issue,. . please report.

also just try changing to CustomWidth/Hight in power of 2 for Kj's above example,. .

Post by **Kjell** » Thu Dec 17, 2009 6:16 pm

Another suggestion / request .. what about a depth-map component? Allot of effects ( shadows / DOF / SSS / volumetric ) make use of depth, and while you can already just render it to one of the channels of a normal FBO, the difference between 8-bit and 32-bit data is huge obviously.

8-bit = 0-255
32-bit = 0-4294967295

K

diki · Post by **diki** » Fri Dec 18, 2009 12:33 am

sorry, i didn't read orel's post about it - setting the RenderTarget to a power-of-2 size helps tremendously! kjell's feedback example runs smoothly even with a canvas of 2048x2048px, jph's sonnenmörder looks fabulous. and now that this feature is being interesting, i'll have to allocate some time for it ;) ...