Beta release 2.0.1b
Moderator: Moderators
Alright ~
K
In that case you need to be able to look-up the data yes. Will this be a under the hood thing, or will you be able to switch the Bitmap component between byte / float ( would be very convenient for depth maps ) and 1D / 2D?VilleK wrote:I definitely want to have the possibility for raytrace/raymarching fragment shaders.
K
- Updated the way arrays are passed to shaders:
If you have a ShaderVariable:
<ShaderVariable VariableName="array1" ValueArrayRef="MyArray"/>
Then "MyArray" is your DefineArray component and in your fragment shader you declare the array like this: "uniform sampler1D array1;"
Use the GLSL-functions "texture" or "texelFetch" to read values from the array.
- Also recompiled using the latest Delphi XE2 update which hopefully fix a few problems with styles.
http://www.zgameeditor.org/files/ZGameEditor_beta.zip
If you have a ShaderVariable:
<ShaderVariable VariableName="array1" ValueArrayRef="MyArray"/>
Then "MyArray" is your DefineArray component and in your fragment shader you declare the array like this: "uniform sampler1D array1;"
Use the GLSL-functions "texture" or "texelFetch" to read values from the array.
- Also recompiled using the latest Delphi XE2 update which hopefully fix a few problems with styles.
http://www.zgameeditor.org/files/ZGameEditor_beta.zip
Various styles vs windows toolbar results.
Screenshots to follow
1. the way I like my VISTA desktop - toolbar on right
2. gone to fullscreen - gadgets covered (no big deal)
- window buttons lost (look carefully window frame - not hidden)
- all other buttons operate OK
3. basic toolbar setup - bottom
4. gone to fullscreen - everything operates normally
5. secondary popular basic - left side
6. fullscreen - window buttons lost
xml etc. toolbar - OK
file toolbar - cursor highlite offset amount - windows toolbar width, meaning file/edit not highlited but operate when pressed
7. windows toolbar top
8. when expanded from windowed - window buttons disabled
- file toolbar disabled
- xml OK
Screenshots to follow
1. the way I like my VISTA desktop - toolbar on right
2. gone to fullscreen - gadgets covered (no big deal)
- window buttons lost (look carefully window frame - not hidden)
- all other buttons operate OK
3. basic toolbar setup - bottom
4. gone to fullscreen - everything operates normally
5. secondary popular basic - left side
6. fullscreen - window buttons lost
xml etc. toolbar - OK
file toolbar - cursor highlite offset amount - windows toolbar width, meaning file/edit not highlited but operate when pressed
7. windows toolbar top
8. when expanded from windowed - window buttons disabled
- file toolbar disabled
- xml OK
Last edited by y offs et on Fri Nov 04, 2011 6:55 pm, edited 2 times in total.
"great expectations"
This seems to be the general problem with the entire XE2 VCL style implementation. All of the provided styles use ( pretty much ) the same template & settings .. just a slightly different bitmap. As soon as you change anything ( including the desktop circumstances as y_offs_et illustrates ), it starts acting up / comes crashing down.
K
Added a new way of declaring constants. In addition to using the DefineConstant component you can now declare constants in your scripts directly using the "const" keyword.
For example:
Using constants in your code for readonly-values instead of variables has the benefit of generating slightly more efficient expressions.
Note the scoping rules:
- A constant declared in a ZExpression is local to that expression and is not available outside the expression
- A constant declared in a ZLibrary is global and can be used in all expressions (that are declared after the ZLibrary itself)
http://www.zgameeditor.org/files/ZGameEditor_beta.zip
For example:
Code: Select all
const float PI2 = PI*2;
const string S = "String";
const int GL_LINES = 0x0001;
Note the scoping rules:
- A constant declared in a ZExpression is local to that expression and is not available outside the expression
- A constant declared in a ZLibrary is global and can be used in all expressions (that are declared after the ZLibrary itself)
http://www.zgameeditor.org/files/ZGameEditor_beta.zip
Here is a new powerful technique of mixing components and scripting. Up until now there has always been a bit of unclear what can be achieved using script and what can be done with components, resulting in projects that run back and forth between ZExpressions and components. For example there is no way of removing a model using script so you've had to set a variable with a ZExpression, then test the variable in a Condition and insert a RemoveModel in Condition.OnTrue.
Introducing "Script based Component invocation"
Syntax:
@ <component> ( [ <property> : <value> ] ... );
This will declare and execute a component with the properties set to the desired values.
Examples:
For example a tree structure represented like this (from Triple-E):
With the following xml-source:
Can be replaced with this instead:
It makes much more functionality available from scripting so it's up to the user to choose between the Component or code-based approach based on personal preference. The @-syntax perhaps is a bit ugly but it was necessary to distinguish from parsing normal function-calls. Also it is easy to give auto-completion in the editor, just type "@" and you'll get a list of components that can be used. Feel free to suggest alternative syntax!
Note:
- Currently vector based properties cannot be used, so "@RenderTransform(Transform.X : ...)" etc is not supported. I'll see if I can fix that later.
- Since this syntax makes the playSound-function redundant I've removed it for now.
http://www.zgameeditor.org/files/ZGameEditor_beta.zip
Introducing "Script based Component invocation"
Syntax:
@ <component> ( [ <property> : <value> ] ... );
This will declare and execute a component with the properties set to the desired values.
Examples:
Code: Select all
@RemoveModel(); //A component that does not need any properties
//Components with a single property
@SetAppState(State : AppState_TitleScreen);
@SpawnModel(Model : TitleScreenModel);
@UseMaterial(Material : PlayerMaterial);
@RenderMesh(Mesh : PlayerMesh);
//Several properties
@RenderText(Text : "Hello" + intToStr(i), X : -0.5, Y : -1 + (0.1*i));
@PlaySound(Sound : Sound1, NoteNr : 85);
With the following xml-source:
Code: Select all
<Condition Expression="return Temp1==1;">
<OnTrue>
<SpawnModel Model="MonkeyModel"/>
<Condition Expression="return LevelEmitCounter==0;">
<OnTrue>
<SetModelState State="Stage1_LevelState"/>
</OnTrue>
</Condition>
</OnTrue>
</Condition>
Code: Select all
if(Temp1==1) {
@SpawnModel(Model : MonkeyModel);
if(LevelEmitCounter==0)
@SetModelState(State : Stage1_LevelState);
}
Note:
- Currently vector based properties cannot be used, so "@RenderTransform(Transform.X : ...)" etc is not supported. I'll see if I can fix that later.
- Since this syntax makes the playSound-function redundant I've removed it for now.
http://www.zgameeditor.org/files/ZGameEditor_beta.zip
Hej Ville,
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.
K
Why is this exactly? How come the parser can make a distinction between the hard-coded ( sin, sqrt etc ), ZLibrary and External functions without funky syntax .. but not these?VilleK wrote:The @-syntax perhaps is a bit ugly but it was necessary to distinguish from parsing normal function-calls.
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.
K