Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

16

Not a bug / Re: HSL Value .. Bug?

« on: August 24, 2007, 01:53:23 AM »

Considering how the color-space conversion works, there can be small imprecisions caused by rounding.

Computing HSL as a double precission "fractions of one" I got: 0.833333..., 1, 0.5
Casted to 0..255 range it means 212.5, 255, 127,5 that imo should be rounded to 213, 255, 128

But obviously both methods does very rough estimation and never gives the same color when we convert between RGB & HSL forth and back.

Of course such differences are practically indistinguishable by human eye.

17

Bug reports / volatile Delay value in SpriteEdit

« on: August 24, 2007, 12:22:43 AM »

To reproduce this bug:

1. open/create sprite with 2 or more frames
2. change Delay value of one frame, but don't move focus after typing
3. skip to another frame by pointing it with mouse in the frame list
4. return to edited frame and watch that new Delay value has gone

18

Feature requests, suggestions / Re: Reflecting surfaces

« on: July 31, 2007, 10:02:09 PM »

I'm afraid if there's gonna be reflections one day, they'll need to be defined as planes in the hidden geometry.

Yes, yes! Please let them to come one day.

WME is almost perfect now, but _with_ reflections it will be true perfect ;-)

19

Done / WME skips to "idle" without transition or I've something missed?

« on: July 25, 2007, 02:00:43 PM »

While playing with complex 3d characters we're always trying to keep animations as small as possible.
The "transition" effect gives the great power to simplify things.
Imagine the "take" animation: draw the hand forward and back can be stripped to one frame showing a hand at the grabbing point!
All intermediate frames of animation should be filled smoothly by "transition".

I have used such trick (before new WME beta) for non-walking characters with good result, but obviously cannot applay it to the main actor which needs fast transition when start walking and very slow in some other activities. So, as soon as I got a new beta with possibility of different transition times I've started to play with it. Unfortunately this doesn't work as I've expected.

To isolate my case from our game's environment I've reproduced it on the standard example called "wme_demo_3d".
I've replaced the trinity.script with the following:

Code: [Select]

#include "scripts\base.inc"

var id = "idle";
var tu = "take_up";
var td = "take_down";
var tr = 1000;

this.SetAnimTransitionTime(tu, id, tr);
this.SetAnimTransitionTime(id, td, tr);

on "LeftClick" { this.PlayAnimAsync(tu); }
on "RightClick" { this.PlayAnimAsync(td); }

on "footstep" { }

The script is pretty simple. I'm using variables instead of inline strings to be sure not to make any typo in animation names.

Let's begin from RightClick. "take_down" starts from the upper position, but there is a 1s transition from 'idle', so she slowly raises her hand (excellent!), then play "release" animation in Trinity's fast mood ;-)

Next, try LeftClick. "take_up" lifts her hand up, then I expected to see slow releasing of the hand in the 1s transition to the 'idle', but it skips rapidly with no transition at all.

It doesn't matter if we use PlayAnimAsync() or AnimTransitionTime attribute to define the time.

With the another 3d character (not being the main actor) both transitions works smoothly.

20

Technical forum / Re: have a 3d char walking and running

« on: July 25, 2007, 03:22:22 AM »

I believe jbw mentioned he developed some debugging script for setting the light position interactively. But I don't know if he's able to share it with the community.

It is no very big secret (and please don't expect too much).

I have started my adventure of adventures from the "wme_demo_3d" example, so:
 - my script system is still similar to it
 - you can apply my code to it and quickly see results

1. All my interactive debug extensions are called from infinite loop of game_daemon.script by:

Code: [Select]

  if (Game.DebugMode) Game.debugkeys();
This is deliberately limited to debug mode only.

2. The main code is placed in the game.script:

Code: [Select]

method debugkeys()
{
  var shift = Keyboard.IsKeyDown(VK_SHIFT); //-- it is smarter to check it once
  //-- some stupid actions on some stupid keys, like:
  if (Keyboard.IsKeyDown("0")) Game.QuitGame(); //-- exit without annoying dialogues ;-)
  //-- and more, and more, and finally:
  var max = 300; //-- reasonably big limit
  var mod = max+max; //-- our numbers will be changed in circular manner with "modulo"
  var inc = 10; //-- increment by tenths is precise enough
  var chg = false; //-- no changes so far
  if (shift) inc = mod-inc; //-- [Shift] key forces decrementing instead of incrementing
  if (Keyboard.IsKeyDown("x") && (shlx != null)) { shlx = ((shlx+max+inc)%mod)-max; chg = true; }
  if (Keyboard.IsKeyDown("y") && (shly != null)) { shly = ((shly+inc)%mod); chg = true; }
  if (Keyboard.IsKeyDown("z") && (shlz != null)) { shlz = ((shlz+max+inc)%mod)-max; chg = true; }
  if (chg) //-- we have changed something
  {
    actor.SetLightPosition(shlx, shly, shlz);
    Game.Msg("shadow casting light:"+shlx+","+shly+","+shlz);
  }
}
Keys 'x', 'y', 'z' leads to change light position toward X, Y or Z axis respectively (with 'Shift' in reverse direction).
Note that this is not 'click', but rather 'depress' handler, so values will be changed continously as long as we hold the key.
For X and Z the range -300..290 was good for me, and Y - 0..590 (negative Y makes no sense).
Checking for 'null' prevents unwanted action before initialization (see below).

3. Globals are placed in base.inc:

Code: [Select]

global shlx;
global shly;
global shlz;
and initialized for each scene in scene.script:

Code: [Select]

if (Scene.shlpos == null) //-- no scene's custom property named 'shlpos'?
{
  shlx = -40; shly = 200; shlz = -40; //-- default for 'trinity'
}
else //-- get shadow light position from custom property
{
  var tmp = new String(Scene.shlpos); tmp = tmp.Split();
  shlx = ToInt(tmp[0]);
  shly = ToInt(tmp[1]);
  shlz = ToInt(tmp[2]);
}
actor.SetLightPosition(shlx, shly, shlz);

Current light position shows itself in debug message area on the screen - we can read it using eyes and keep it by pen-and-paper method ;-)
Catched numbers can be coded permanently as the 'shlpos' property of scene in the form of comma separated list.

I'm sorry for the extended delay, but I'm not reading posts here much frequently. If somebody wishes to get rapid answer please ask me by e-mail.

21

Technical forum / Re: Dynamic Shadows

« on: July 24, 2007, 11:36:16 PM »

Look at it from another point of view: we want true fixed light for the shadow. Currently that light isn't fixed as it walks everywhere with the actor (it is not common in the real life). I think the shadow light should be sticked to the scene, not to the actor's head. ;-)

22

Technical forum / Re: have a 3d char walking and running

« on: June 25, 2007, 12:38:40 AM »

and use WalkTo() instead of GoTo() in all your scripts..

I have another idea how to do that by changing the file "game.script" (thinking of script system similar to that used in WME demo).

1. Replace header of mouse event handler from:

Code: [Select]

on "LeftClick"
to:

Code: [Select]

function lclk()

2. Add new event handler:

Code: [Select]

on "LeftClick"
{
  actor.WalkAnimName = "walk";
  actor.Velocity = 100;
  actor.AngularVelocity = 400;
  lclk();
}

3. Add handler for double click:

Code: [Select]

on "LeftDoubleClick"
{
  actor.WalkAnimName = "run";
  actor.Velocity = 300;
  actor.AngularVelocity = 1200;
  lclk();
}

Now single and double clicks shares all the (possibly sophisticated) behaviour except of actor's moving speed.

Beware that this trick (as well as that mentioned above) has side effect: if the actor motion is triggered in other way (e.g. by scene startup script) it will use last-used, not the default walk style, so we must remember to reset walk parameters in the begining of such action. Unfortunately it cannot be done at the end of doubleclick handler as the "gotos" are nonblocking.

23

Done / catch hidden geometry into the viewport jail

« on: March 26, 2007, 02:18:19 PM »

It would be very nice if we can stretch hidden geometry to viewport box. Currently the geometry follows only "game resolution" dimensions.

Our situation is:
viewport starting at (0, 32) of size 1024 x 640
the main (and only) layer is 1024 x 640
game resolution is 1024 x 768
the hidden geometry apparently follows changing of viewport's Y origin
but it fits vertically *always* in game's height
we would be VERY happy if the geometry could stretch to viewport's height

We want to place some 2d decorations above and below the viewport and limit the game's 3d world to viewport only.

Regardless of that WME is the best!

--
jbw

24

Technical forum / Re: Iterate Through All Entities in a Scene

« on: January 22, 2007, 04:26:44 PM »

Yes, I can iterate all entities in all layers, but what about FREE entities? They aren't belong to any layer, so how to get them?