Beta release 2.0.1b

Information and change log about the latest ZGameEditor release.

Moderator: Moderators

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

Re: Beta release 2.0.1b

Post by VilleK »

Added basic style (a.k.a. skinning) support with the built-in styles that comes with Delphi XE2.

When using other background colors it becomes obvious that some of the icons I use does not have proper transparency but it gives a hint what the styling capabilities can do. There is a tool in XE2 that allows you to design custom styles, I don't know if that is redistributable or not, because it would be great to allow Kjell or anyone else interested designing custom ZGE skins.

http://www.zgameeditor.org/files/ZGameEditor_beta.zip
Attachments
zge_vcl_styles.png
zge_vcl_styles.png (71.26 KiB) Viewed 17239 times
User avatar
Kjell
Posts: 1883
Joined: Sat Feb 23, 2008 11:15 pm

Re: Beta release 2.0.1b

Post by Kjell »

Hmm,
VilleK wrote:There is a tool in XE2 that allows you to design custom styles.
Currently the skin data seems to be encapsulated in the executable? Is it ( even ) possible to use external files instead? Otherwise you'd still need XE2 to build / test a skin .. which wouldn't be very convenient for anybody wanting to develop / modify / share ZGE skins without XE2.

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

Post by VilleK »

The styles can be saved as separate *.vsf files and there is a TStyleManager.LoadFromFile method. So I can add "Load style" menu item in the style menu for this. Also you can try the style directly from within the Style Designer. Looks like the designer tool is not allowed to be redistributed separately but hopefully it is included in XE2 trial if anyone wants to try it out. The feature matrix says it is included in all versions of XE2 including starter edition.
User avatar
Kjell
Posts: 1883
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell »

Hej,
VilleK wrote:The styles can be saved as separate *.vsf files and there is a TStyleManager.LoadFromFile method. So I can add "Load style" menu item in the style menu for this.
Alright, nice ~
VilleK wrote:Looks like the designer tool is not allowed to be redistributed separately.
Peculiar decision. Either the VCL Style Designer requires XE2 to run, or they think nobody outside of XE2 users will use it. Can't imagine they expect graphic designers to purchase a XE2 license just to use the Style Designer.

Since styles can be used across XE2 VCL applications, providing the Style Designer to anybody that wants to use it would simply add value to the XE2 ecosystem.

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

Post by StevenM »

This is excellent - thanks! The graphite skins are really going to help reduce eye strain for me - something that has always been a bit of a problem for me.
User avatar
VilleK
Site Admin
Posts: 2277
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK »

Beta updated today with a menu item that let you load a style (*.vsf) from file. Also made a couple of the standard icons transparent so they look a little bit better against a dark background.
User avatar
VilleK
Site Admin
Posts: 2277
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK »

News in this update:

- The colors in the currently selected style are now also used in the expression and shader editors so when selecting a dark style the code window gets a dark background.
- Extended type system for scripts.
Adding support for this new function required me to do some more work in the type system of the expression parser. This will allow more kind of functions that operate on standard components. At the moment while testing this I have added types for two components: Sound and Material.

This mean that this syntax is supported:

Code: Select all

//Declaring local variables of the new types
Material mat;  //Case-sensitive, must be "Material" with capital "M".
Sound snd;

//Declaring a function in a ZLibrary that takes a material as a parameter
void ModifyMaterial(Material mat) {
  mat.Shading = 0;
}
We can easily add built-in support for all components that makes sense to use in this fashion: Shader, Bitmap, Mesh etc. Let's see how this works! As usual, let me know of any problems or suggestions.

Beta updated:

http://www.zgameeditor.org/files/ZGameEditor_beta.zip
Last edited by VilleK on Fri Nov 25, 2011 11:56 am, edited 1 time in total.
User avatar
VilleK
Site Admin
Posts: 2277
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK »

Found a problem with the new data types, they conflict with property names. For instance:

Material m=MyMaterial;
UseMaterial1.Material=m;

This won't compile because when the parser sees the word "Material" in the second line it believes it is a data type and not a name of the property in the UseMaterial component.

I need to update the compiler to be smart enough to know that when to separate those two cases.

The Coco/R library I use for generating the parser supports something called "homographs" that is supposed to solve this but I can't get it to work at the moment. I will look at another Coco-implementation for Delphi and see if that helps, there are some options listed here.
User avatar
VilleK
Site Admin
Posts: 2277
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK »

News:

- Switched implementation of Coco/R parser generator. This seems to solve the problem of data types having the same names as component properties.
- The following components can now be used as data types:
"Material", "Sound", "Shader", "Bitmap", "Mesh", "Camera", "Font", "Sample"
So you can declare them as local variables and pass them to library functions, like this:

Code: Select all

Bitmap bm = Bitmap1;  //declare local var
doSomethingToBitmap(bm);  //pass to user defined function taking a bitmap as parameter
- The name of the chosen VCL style is now saved in the ini-file and restored on next start of ZGE. So if you choose a style it will be default next time too. Only works on built-in styles at the moment, not when you load from file.
- Smarter removal of sound engine in binaries that does not use sound, this makes minimal exe about 26kb.
- Material.Color property now has a default value of 1,1,1,1 (white with full alpha) instead of black with zero alpha. Also when the color is all zeros it will still be applied (previously it would not be used when zero resulting in problems when you want to fade an object to black).

Beta updated:

http://www.zgameeditor.org/files/ZGameEditor_beta.zip
User avatar
y offs et
Posts: 418
Joined: Wed Apr 22, 2009 4:26 pm
Location: BC, Canada

Post by y offs et »

noticed something with this update

Using the new skins only, when I hit the fullscreen button top right, those buttons now disappear on fullscreen, and I have to use file close.
"great expectations"
User avatar
VilleK
Site Admin
Posts: 2277
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK »

Small update today:

- Application icon (property App.Icon) works again and you can also use new style png-based icons (such as this one)

Beta updated:

http://www.zgameeditor.org/files/ZGameEditor_beta.zip
User avatar
VilleK
Site Admin
Posts: 2277
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK »

About linking arrays to shaders: It turns out the method I've used now, mapping arrays to "uniform float x[10]" etc, does not scale well. It works best for small arrays of a couple of hundred values maximum.

Another method would be to map arrays to a texture instead that can be read from the shader using texture1d-calls. This works with larger arrays up to the maximum texture width.

There are also the new texture buffer object-extension: http://www.opengl.org/wiki/Buffer_Texture
However that requires that the GPU supports this extension. And it is also more difficult to implement.

I'm considering switching to the 1d-texture variant here. Stop me if you have another opinion :)
User avatar
Kjell
Posts: 1883
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell »

:?:

Why would you ever need to pass that much data that way? When dealing with vertex data, you usually want to go with glVertexAttribPointer anyway ..

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

Post by VilleK »

The topic I'm investigating now is transferring data from the visualizer: bands (256 values) and audio data (around 512 values). It would not work well in a normal array.

I asked a question about it on Stackoverflow and got a very detailed answer about the options available, see the reply from Nicol Bolas: http://stackoverflow.com/questions/7954 ... ve#tab-top
User avatar
Kjell
Posts: 1883
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell »

Hmm,

Why not simply pass the data as / in a mesh then instead ( unless you want to render using a ray-tracer or something )?

K
Post Reply