ZGameEditor forum

WhooHoo, wicked awesome! This will save loads of time working with the editor,. and these new scripting additions look amazing as well,. for loops in the code editor is one I had been missing,.

can i get a quick explination of these; Pre/post increment/decrement syntax for local variables: "i++; ++i; --i; i--;"

what is the difference between pre and post?

kattle- your idea sounds intreguing, got any new simple primitive like stuff for me to play around with? I can always use new ways to build / add to models,. you know me insects and robots are my faves,. I will eventually get back to that 100 Spokes idea we where playing with,. just have to figure out how your rendering transformation works,. made me a bit confused :S so i put it aside for a bit,. I still think there is a game there,. peace

For statements! The last major missing non-OO link in the scripting language What a great start for ZGE in 2009 ~

K

Pre increment: the variable is incremented BEFORE the expression is evaluated.
Post increment: variable is incremented AFTER expression is evaluated:

EG:
i=5; j = ++i; the value of both i and j is now 6.
i=5; j = i++; now j is worth 5 and i is worth 6;

kattle87 wrote:When a mesh producer is added, it does not overwrite the array of triangles, but instead it adds triangles to the array, so in the end we can get a single complex mesh instead of using several meshes in the "OnRender" component

I guess the way to do this is to create a MeshCombine-component that behaves consistently with BitmapCombine. That way you would do a producer-list like this:
MeshBox
MeshExpression
MeshBox
MeshExpression
MeshCombine
That is, put two warped cubes on stack and combine them to a single mesh for faster rendering.

I'll think about that, but first I will probably make this beta a proper release if no bugs are reported.

Hi Ville,

Not exactly a bug, but something I did notice .. integers take about double the time to access then floats. Usually when working in for example C, it's the opposite. Does the script compiler pull the assignments out in floats, then truncates them and assigns them to the integer type memory slots? In any case, performance issues can always be addressed at a later stage.

K

Kjell, can you post an example? If you turn on "View compiler details" in the zge-menu you will see where the compiler inserts int/float conversions. For instance looping a int-array using local int loop variables and int assignments should be faster than floats.

Hej Ville,

Ah, you are right. When using local variables integers are the same if not faster then floats. However, when you're using integers defined with the DefineVariable Component ( I use this allot to pass around variables ), the results are a bit different*. Here's a example .. which ironically doesn't differ much from yours

K

*The difference is even greater when you just use X<100000; instead of Count.

Unrelated to this versus issue, I notice that the new Circle2d type does not work with the Stop collision setting,. is that an oversight or a intended limitation?

Hey jph,

Quoted from this thread.

I now updated the beta with a new collisionstyle: Circle2D. I have not touched the code that is supposed to move objects out of collisions.

K

Jph, it works for me now when I try. Both Circle2D vs Circle2D, and Circle2D vs Rect2d_OBB with stop setting. That is it "works" exactly like before, objects stop but they sometimes get stuck. Can you please post more details?

Kjell, with your example on my computer ints are about 5 times faster than floats. But as soon as there are conversions involved it becomes slower. As far as I know int/float conversions are slow even with C++ compiled code. The general rule is that unless your whole expression is without conversions (watch compiler details for (int) or (float)) you might as well stick to floats for most variables to avoid conversions.

There may be an ordering bug.
Try the attached; no stoping.., then reverse the DefineCollision Cat1 and Cat2 values,. i.e Cat1=2 and Cat2=1 and then it works,.

Hej Ville,

Dismiss the integer performance remark, my computer was acting up. The example runs about 6 times faster using integers then floats on various machines

K

Jph, it turns out that this is a general problem with stop-collisions, not just for the new Circle-style. You need to define collisions in the order moving-objects vs stationary-objects for it to work, such as Player vs Walls. Since this is not a new bug I'll go ahead and release the beta then come back to hopefully fix the problem later. Can you use it the way it is now?

yup,. in fact I have developed a method using Steering components that is working well,. demo soonish,. . if you do go back to look into that issue perhaps a "MoveOutside" addition would help,. as the Stop one seems to steal all momentum,. MoveOutside would keep the objects from overlaping while maintaining velocity in the direction it could still move,. .

perhaps it's not a bug and you can just add that info the the wiki,. so people don't pull hair out! Thanks again.

Beta updated today with a few bugfixes to scripting:
- expressions such as "x=5 + + 5;" crashed the compiler
- integer comparisons sometimes generated invalid code