Way point scaling problem

Sali euch, (Hoffe ist inordnung das ich in Deutsch schreibe) habe zwar keine direkte Lösung für euch... Aber wollte au nochmal bekräftigen, dass i mir au nur arg schwer vorstellen kann... Das mit Visionaire erstellte Spiele "insbesondere" von Spielern selbst gemachte, einen heutzutage PC auslasten sodass ruckler oder vergleichbares endstehen! (Ausnahmen bestädigen meines erachtens die Regel)

Allerdings hätte i mal eine frage diesbezüglich... ist das bei jedem Skallierungsfaktor der fall?
Und habt ihr mal schrittweise versucht >99% Skalierung > 98% Skalierungs > usw zutesten?
Oder ob es sich eventuell nur um einen gewissen grad an Skalierung handelt wo es anfängt zu laggen?
(Würd mich echtmal interessieren)

Denn ich hatte mal ein relativ ähnliches Problem, grade weil du (@Cross) die Füsse angesprochen hattest... denn grade bei dennen wirkte es bei mir auch Schlackernd! Allerdings war es in diesem fall nicht direkt der SkalierungsFaktor der dafür verantwortlich war, sondern die Kulissen Grösse... was erklärt bedeutet, sobald der Skalierungsfaktor "grösser oder kleiner" wurde... die Kulisse auf die Person zentriert wurde vom Kamera-winkel her... und es einquasi hoch & runter des bildes kam... was dann Ausschlaggebend für die zuckenden Füsse war!!!! : )

I tried it on a different system today, but still got the same problems and no real solution. But i found a strange behaviour whith the preview-screen in the editor:
If the cursor stays inside the walkarea, it shows in the preview the correct scale of the character. As soon as the cursor leaves the walkarea in y-position, it scales the character extremely small/big (aproximately 0-200%). This would explain the problem to me (game tries to scale two different hights at the same time), even though i don't understand it: does anyone have an explanation, why the scale of the character is at all changed way beyond the 100-115% of the two (only) waypoints?

There's a very basic thing you need to understand about the scaling in Visionare: Horizontal scaling, like you used in your example, simply doesn't work well.
It's better to forget about it and get your scenes looking nice just with vertical scaling. If you need different scale sizes on different X-coordinates but for the same Y-height you should think about redesining the room because it will be very tricky switching the walkmaps without a transition area and to be able to conceal the switch.

Another thing that will save you a lot of time and strange errors is seperating the scaling from the walking grid. Having scale sizes in the walking grid will prevent the engine to make smooth scale transitions because it's trying to set the exact value of the waypoint. It's more convinient to have waypoints outside or at the side of the scene just for holding the scale values.

If the perspective of the room doesn't need the characters walking deep into the scene it's enough to have your max and min scale values on two waypoints. This screenshots shows an example with additional scale points that are used because we needed a faster downsizing at the back of the scene.

Edit: Another note. Make sure that the image' height, you are using as the background, is at least the height of your game / gamewindow. Otherwise you might experience strange scaling behaviour. A bigger height is no problem at all.

Thanks for the post, mowren, it sure makes the basic scaling-mechanics better understandable.

But by now i'm sure, the problem i (and probably Dilated) have, has not especially to do with scaling only. I ran another test with scaling off. I put a second character into the scene, with the walkanimation as standanimation. You can see him on the left, showing the walkanimation smooth and fluent, just as in the editor preview, working as intended. Compare to the character on the right, when he starts walking through the scene: even though it's really bad Video Quality you can see he's stuttering while being moved over the Screen (watch the feet). The stuttering is always there, when walking (not standing), the scaling just makes it more visable. As Dilated wrote, it has nothing to do with the animation itself (size, framerate, etc.), its noticeable even with a single walkframe (or low res animations as in the demogame).

http://youtu.be/aoPrJVIe42A

I'm really sorry for bothering everybody with this, but to me it simply screws up the basic function of walking around.

just tested chains of satinav & it stutters/judders (seems to be less than when you run something in the editor though) although it wasn't something I was paying much attention to ... & the laptop I'm testing on isn't exactly all that good (so that could factor into it somewhat for me)

David has an idea for a new walk cycle system, but I don't know if it's possible & or if or when it will or will not be done. - I'll point him towards this thread later on - if he doesn't check it beforehand

ARFLme, you're mixing general performance issues with older machines and with scroling (resulting in stuttering) with the animation issue of Cross.

@Cross
Could you give use some more information about your animations?
- The game resolution
- How many frames do you use for the walking animation?
- The frame measurements
- Are all of the frames of the same size?
- The frame length setting for the animation
- The walking speed of the character

Could you lay out you animation frames in a walkcycle sheet because it seems your walking movement doesn't have a nice sinus curve for the head movement. Even the walking animation on the same spot doesn't look very fluently (or this impression is the result of the judder).

I know that this particular animation i have shown in the videos is not perfect at all, and it is also huge and has a lot of frames:
Game Window resolution: 1680x1050, 31 Frames, all 800x900 png files, 45ms, 310 walkspeed.
I used it, because it makes the problem more visable, that i experience with ANY walkanimation, even the ones used in the Visionaire-demogame.

In this video for example you can see the preview-screen of a scene with the wayborders and two vertical waypoints, scaling from 110% to 70%. The preview shows just a single frame animation, but the stuttering you can see here, is exactly the same i have IN game. Good news is, the preview represents the game performance precisely, bad news is, it stutters.

http://youtu.be/AxT21Pb8OE4

In the demogame this is less visable (due to higher walkspeed, lower res animations) but still there:

http://youtu.be/oyXNV9-IYBc

Sorry to bring this old issue up again, but:
I downloaded the free game "Sand und Rost" from this website as well as the "halfcut monkey island style gui" and notice the same walking-problems described above in both of the games, when i run them on my computer: the characters are not scaling fluent but are shaking and scaling in little steps.

Could probaply anyone who knows these titels confirm that he dosen't have the same issues with them on his computer? That way i would know its a hardware or driver problem (although i tried nearly everything the last year to fix it and wouldn't know what to check next).

Nigec made the half cut demo.

I'm not sure about the shaking/vibration of the characters as it's still doing that even in the laptop I bought a few months back which has more than enough (plus) spec, ram & dedicated graphic memory etc to run pretty much anything made in vs & yet the characters still vibrate. I think maybe the whole walk system needs replacing to fix this (maybe?) as object animations & non-walking character animations all seem to play nice & smooth as they are supposed to.

I'm not sure if this is being addressed for the upcoming release (scaling or the vibrating walk cycle animations) or maybe for a future release afterwards, if at all.

Simon might know how to fix it as he has already been doing a bit of work on updating the current walk system a little bit.

We’ve got the same issue with the game we are busy creating. What bothers me is that it seems to be possible to solve the issue; Night of the Rabbit, Deponia and Edna and Harvey 2 seems fine, but Chains of Satinav shows the same kind vibration/stutter while walking and scaling.

I took a video with FRAPS while walking upwards (scaling from 100% to 10%), exported it to stills and inspected the images. The reason for the stuttering seems to be the following:
* Visionaire linearly distributes the scaling values between waypoints, but due to the data type of the scaling factor (integer) it only updates the animation size in 1% increments.
* With high resolution images (e.g. 1920x1080) scaling over a long range causes a step-like effect: in my case it was a 1% decrease in size for every 5 or 6 pixels.
* The final effect is a character animation (at size x) moving up 5 pixels (in position), then it reduces in size (0.99x), moves up 5 pixels, reduces in size (0.98x), etc.
* The top of the frame moving up and then suddenly reducing in size is where the stutter is most visible. This is further compounded when large (e.g. 1000px high) characters are used – a 1% size reduction is 10px! Not something the eye fails to perceive.

Ideally how I would like to solve this problem is setting a real value for the scaling factor on the animation and then rounding to the nearest pixel. I am however not sure if this is even possible. Is there no way to maybe specify a specific animation height?

Like I mentioned, Night of the Rabbit scales very smoothly and they used Visionaire, right? So how did they do it?

I'm rewriting the scaling system at this time, it will have floating point precision opposed to integer precision. That will be included in the next version. But the position of the character will be snapped to 1 pixel. So don't squeeze your points to hard. For all scaling only the y-coord of the points and the character applies by the way.