Beta release 1.9.9b
Moderator: Moderators
Beta updated today.
- TexCoord on MeshExpression to create/modify texture coordinates.
- New WebOpen-component to access web-pages. See included project YakYakReader for an example.
I also modified the fbo-examples to use 512x512 size rendertargets instead to make them ati-compatible.
Since there is no string support in ZGE-expressions the web-component use arrays (DefineArray-component) to get url-string and receive html-result. The RenderText-component has a new TextArray-property so that the contents of a array can be displayed.
- TexCoord on MeshExpression to create/modify texture coordinates.
- New WebOpen-component to access web-pages. See included project YakYakReader for an example.
I also modified the fbo-examples to use 512x512 size rendertargets instead to make them ati-compatible.
Since there is no string support in ZGE-expressions the web-component use arrays (DefineArray-component) to get url-string and receive html-result. The RenderText-component has a new TextArray-property so that the contents of a array can be displayed.
- jph_wacheski
- Posts: 1005
- Joined: Sat Feb 16, 2008 8:10 pm
- Location: Canada
- Contact:
So to post some data we would just use this OpenWeb component and the data to be sent would be in the url in some form of post link using the peramArray? Know any links that explain a way to set something like that up (sql?) or the other formats that can be used?
A highscore table is the first obvious use for this,. but yeah turn based games or user submited levels etc. could be fun,. . nice one.
A highscore table is the first obvious use for this,. but yeah turn based games or user submited levels etc. could be fun,. . nice one.
iterationGAMES.com
@ y_offs_et
This is something I had some trouble with in the beginning as well, but it is behaving as it should. There are two rules at play here.
- All Components are always global and can be accessed from anywhere.
- Components in a Model's Definitions are local to each Clone of that Model.
So for example when spawning a bunch of Models, you can set each of their individual energy ( a DefineVariable in the Model's Definitions ) just before spawning, and as soon as a Clone is spawned its energy will start with that value but behave independently from thereon.
K
This is something I had some trouble with in the beginning as well, but it is behaving as it should. There are two rules at play here.
- All Components are always global and can be accessed from anywhere.
- Components in a Model's Definitions are local to each Clone of that Model.
So for example when spawning a bunch of Models, you can set each of their individual energy ( a DefineVariable in the Model's Definitions ) just before spawning, and as soon as a Clone is spawned its energy will start with that value but behave independently from thereon.
K
- jph_wacheski
- Posts: 1005
- Joined: Sat Feb 16, 2008 8:10 pm
- Location: Canada
- Contact:
The one thing that I find most bothersome with the local Variables decleared in the Definitions, is that the editor will not permit me use the same name in different Models. although these Variables are not accessable outside of the local Model. i.e. I would rather use the same name for some local values stand for the same thing accross all Models,. such as 'pow' for unit strength,. so Model apple.pow and orange.pow should be possible, as the local .pow is always Clone based. Currently I have to use things like apple. apple_pow and orange. orange_pow. Just a pet peev
iterationGAMES.com
Yea,
I have to agree with jph .. being able to define local variables that are static* and are allowed to have "conflicting" names ( by the current rules ) would be convenient.
But in case of the fruit example I usually create a Model called Fruit, put the "Energy" variable in Definitions ( + a "Type" variable ), and create a ModelState for each type of fruit. Then just before spawning I set the "Type" variable to the desired fruit ( 0=Apple, 1=Orange ), and let the Model automatically switch to the correct ModelState in the OnSpawn event.
* Static means that the variable keeps it value between frames.
K
I have to agree with jph .. being able to define local variables that are static* and are allowed to have "conflicting" names ( by the current rules ) would be convenient.
But in case of the fruit example I usually create a Model called Fruit, put the "Energy" variable in Definitions ( + a "Type" variable ), and create a ModelState for each type of fruit. Then just before spawning I set the "Type" variable to the desired fruit ( 0=Apple, 1=Orange ), and let the Model automatically switch to the correct ModelState in the OnSpawn event.
* Static means that the variable keeps it value between frames.
K
Beta updated today. Not much new functionality, the main thing is that I've transfered my developer environment to Delphi 2010 and that needed lots of code changes.
The generated exe-files are slightly larger than before but I'm confident I can trim it down again later on.
In case there are fatal problems with this release, here is a link to the previous beta.
- getSystemTime() function returns system time in number of seconds passed since midnight.
- quit() stops the application in the designer too.
- Suppress log-message when using MeshLoad component inside MeshLoop.
The generated exe-files are slightly larger than before but I'm confident I can trim it down again later on.
In case there are fatal problems with this release, here is a link to the previous beta.
- getSystemTime() function returns system time in number of seconds passed since midnight.
- quit() stops the application in the designer too.
- Suppress log-message when using MeshLoad component inside MeshLoop.

A rare screwup by Ville himself ..
Code: Select all
Result := T.wHour * 24 + T.wMinute * 60 + T.wSecond;
Code: Select all
Result := T.wHour * 3600 + T.wMinute * 60 + T.wSecond;

K
The beta has been updated today with the first version of string support. See first post for details. There are probably still lots of bugs with strings so use it carefully
. I made it support 8-bit strings for now because it was the easiest and most compact to implement.
If strings work out fine then we can make other simplifications. For instance WebOpen now has a ResultString-property for easier access to the result. I will probably remove the ResultArray-property because I see no more need of it. Also ParamArray can be replaced by just setting the Url-property directly from a script.

If strings work out fine then we can make other simplifications. For instance WebOpen now has a ResultString-property for easier access to the result. I will probably remove the ResultArray-property because I see no more need of it. Also ParamArray can be replaced by just setting the Url-property directly from a script.
Last edited by VilleK on Sun Jan 24, 2010 11:05 pm, edited 2 times in total.