Beta release 2.0.1b

Information and change log about the latest ZGameEditor release.

Moderator: Moderators

Post Reply
User avatar
VilleK
Site Admin
Posts: 2274
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK »

Kjell wrote:A "CallComponent(Component name)" function would still be nice though, since you won't have to pass all variables each time and you can trigger "trees" using the Condition / Repeat / RenderTransformGroup components.
Already there, simply use: "@CallComponent(Component : MyComponent);"

All kind of function calls have the same syntax for the arguments but here we need a different syntax to allow the "Propertyname : value" arguments. I think also that it is good when reading the code to quickly understand that here a component is used and not a normal function call.
User avatar
Kjell
Posts: 1876
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell »

Hej,
VilleK wrote:Already there, simply use: "@CallComponent(Component : MyComponent);"
Ah of course, since there already is a CallComponent component, you can now use the function-equivalent to call a component :)
VilleK wrote:All kind of function calls have the same syntax for the arguments but here we need a different syntax to allow the "Propertyname : value" arguments.
Understood, I figured you might be able to fetch what kind of function it is from the name, and switch the parser depending on that, but it might be trickier then it sounds.

K
User avatar
VilleK
Site Admin
Posts: 2274
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK »

Kjell wrote:I figured you might be able to fetch what kind of function it is from the name, and switch the parser depending on that, but it might be trickier then it sounds.
I won't rule that out so the syntax might change if I can figure out how to do it better.

I've now also updated the visualizer beta with this feature if anyone is working on effects and want to use this new syntax. It is here.
StevenM
Posts: 149
Joined: Thu Jan 20, 2011 10:03 am

Post by StevenM »

Here is a new powerful technique of mixing components and scripting.
Wow - I really like this new feature. This makes using scripted loops, conditionals, Zlibrary functions much more flexible now.

Just experimenting a bit, but the amount of work required to do something like this has been reduced dramatically.

Code: Select all

void MyCubes(int iter){
@RemoveAllModels(OfType:Cube);
for (int i=0; i<iter; i++){
 Cube.Position.X=(Cube.scale.x*2.1)*i-iter/2;
 @SpawnModel(Model : Cube);
 }
}
User avatar
Lupo
Posts: 76
Joined: Wed Sep 09, 2009 6:21 pm
Location: Montevideo, Uruguay

Post by Lupo »

Hi all,

I'm amazed how ZGE evolved, great work!

Many moon had passed since I opened the editor, I want to rework some of my projects to take advantage of the new additions/plugins.

Thanks again.
Close, but not there yet.
User avatar
y offs et
Posts: 418
Joined: Wed Apr 22, 2009 4:26 pm
Location: BC, Canada

Post by y offs et »

Here is a new powerful technique of mixing components and scripting.
...so it's up to the user to choose between the Component or code-based approach based on personal preference.
Anyone done any testing of performance results using either approach? Any conjecture, or is this a non-issue?
"great expectations"
User avatar
VilleK
Site Admin
Posts: 2274
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK »

y offs et wrote:Anyone done any testing of performance results using either approach? Any conjecture, or is this a non-issue?
Performance should be almost the same so it should not matter from an optimization perspective. Just a decision of personal preference whether to have logic in expressions or component tree. Personally I sometimes prefer the terseness of expressions but other times I find the component method easier to overview at a quick glance.
User avatar
y offs et
Posts: 418
Joined: Wed Apr 22, 2009 4:26 pm
Location: BC, Canada

Post by y offs et »

Of course, the component methods' strength is the elimination of syntax errors, and a visual perspective via the tree.

This addition makes a nice progression ladder for the beginning programmer.

Thanks.
"great expectations"
User avatar
VilleK
Site Admin
Posts: 2274
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK »

Inspired by StevenM's great work on OpenGL lights in this thread I decided it was finally time to attempt bringing more control over lights to ZGE.

Here's a list of the things that's been added:

App.Lights - This is a list that can hold the new Light-component. If this list is empty then the single-light model is active and App.LightPosition is used just like before. You can put several lights in this list (OpenGL guarantees support for 8 lights).

App.AmbientLightColor - This is the global ambient light value. Previously this has been hard-coded at 0.4, 0.4, 0.4 (which is now the default value for this property).

Light-component
- Position
- DiffuseColor,AmbientColor,SpecularColor

Material
- SpecularColor, EmissionColor
- Shininess - Allowed range is 0-127.

For more info on how to use these properties see these threads:
http://www.opengl.org/sdk/docs/man/xhtml/glMaterial.xml
http://www.falloutsoftware.com/tutorials/gl/gl8.htm

Please note that this is almost not tested at all. I'd appreciate if someone could create and share a test-project for these new features to help me fix bugs that most likely exists in my implementation.
Also your existing projects should not be affected because I've designed this to be 100% backward compatible. If you experience any changes anyway let me know.

New beta can be downloaded here:
http://www.zgameeditor.org/files/ZGameEditor_beta.zip

...and let me also take this opportunity to wish everyone a merry Christmas :)
User avatar
Kjell
Posts: 1876
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell »

:)

Good to finally see a light component. However, there are quite some things I'd do differently ..

- A SpawnLight / RemoveLight ( just like Model ) approach would be more flexible & consistent then a App.Lights list.
- A on / off switch on the Light component would be convenient ( especially considering the fixed-pipeline limitations ).
- Only 1 color property on a Light instead of 3 should be sufficient.
- OpenGL lights come in 3 flavors; point, spot and directional .. a drop-down for this would be nice.

Of course for the spot and directional types you also need a rotation vector .. and for each type there are a bunch of properties such as cutoff, attenuation etc.

Oh, and next to the Diffuse, Specular and Emissive color properties on the Material component, you also want one for Ambient.

K
StevenM
Posts: 149
Joined: Thu Jan 20, 2011 10:03 am

Post by StevenM »

Thanks! this is nice - I love the fact that we can use external libraries, but native support is so much better = making things user friendly.

I agree with Kjell - Ambient color property for material and an off/on property on light components is useful.

Light types point and spot would be awesome. I can't figure out out how to set these up at all.

I think this opens up some new possibilities with shaders too.
User avatar
VilleK
Site Admin
Posts: 2274
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK »

Thanks for the feedback. Here is an update:

- Only one Color property on Light
- "Enabled" on Light, default on
- "Kind" on Light. Directional, point or spot.
- "SpotDirection", "SpotExponent" and "SpotCutoff" on Light (see here how to use: http://www.opengl.org/sdk/docs/man/xhtml/glLight.xml)

Also:
- Fixed problem with texture sometimes not enabled after rendering using a shader
- When clicking on the preview window in ZGE it will receive keyboard focus

Attached a demo project that enables two spotlights.

http://www.zgameeditor.org/files/ZGameEditor_beta.zip
Attachments
Light.zgeproj
two spotlights
(1.04 KiB) Downloaded 835 times
two_spots.jpg
two_spots.jpg (14.81 KiB) Viewed 27826 times
User avatar
jph_wacheski
Posts: 1005
Joined: Sat Feb 16, 2008 8:10 pm
Location: Canada
Contact:

Post by jph_wacheski »

Excellent, I have found the access to lights provided by StevenM's dll to be very interesting, glad it is being rolled into ZGE as standard. Not sure I agree with limiting the colors to one,. (I am not at home, and currently on a mac so I can not test this yet) are you saying DiffuseColor, AmbientColor, and SpecularColor will all be set to the same values with the current implementation? The subtle variations in the three colors is what makes the lighting interesting, as the mixing of the colors generates much more complex shadings,. suppose this is why GL has the four colors per,. . I think you can see this a bit in that test I posted; download.php?id=1198 ( SilverGold.zip )

I will be back at my computer soon, and post some tests,. looking forward to trying the spotlights!

Marry Happy solstice!
iterationGAMES.com
User avatar
Kjell
Posts: 1876
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell »

Hi jph,
jph_wacheski wrote:Not sure I agree with limiting the colors to one, are you saying DiffuseColor, AmbientColor, and SpecularColor will all be set to the same values with the current implementation?
It should, although it doesn't right now .. only the Diffuse is set.
jph_wacheski wrote:The subtle variations in the three colors is what makes the lighting interesting, as the mixing of the colors generates much more complex shadings
Simply use the Material Diffuse / Specular / Emissive properties instead. How something "reacts" to light should be described by the material .. not the other way around.

K
User avatar
VilleK
Site Admin
Posts: 2274
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK »

Kjell wrote:It should, although it doesn't right now .. only the Diffuse is set.
Fixed ;)

http://www.zgameeditor.org/files/ZGameEditor_beta.zip
Post Reply