Beta release 2.0.1b
Moderator: Moderators
Re: Beta release 2.0.1b
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
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 (71.26 KiB) Viewed 17255 times
Re: Beta release 2.0.1b
Hmm,
K
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.VilleK wrote:There is a tool in XE2 that allows you to design custom styles.
K
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.
Hej,
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
Alright, nice ~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.
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.VilleK wrote:Looks like the designer tool is not allowed to be redistributed separately.
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
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:
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
- 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;
}
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.
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.
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.
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:
- 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
- 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
- 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
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
- 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
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
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
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
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