A little demo.

[Argh]

Basically, yes. But then again, that's pretty much all Zpock's code is doing, too- it's just a coordinated series of parts wiggling

The script takes into account the amount of slope over time, and wiggles appropriately, depending on some other factors, such the amount of "inertia" (this is actually just a catch-all variable that is factoring in the vehicle's mass, momentum, and the stiffness of the suspension, because I think factoring in all three is a waste of perfectly good CPU cycles), gravity, etc. It knows whether it is a positive or a negative slope, and changes the wiggles in an appropriate fashion.

Basically, what's happening when a vehicle with a loose suspension (or something that functionally acts like it) hits a dip or rise?

Well, the wheels have springs, or something that acts like springs. The vehicle's momentum, however, is greater than the counter-force of the relaxed springs. Therefore, the vehicle's body moves in an inverse way.

I could just make it bounce on the Y axis, but this really doesn't represent the forces involved very well. When a vehicle hits a serious bump or dip, it is decelerating a lot, and the angle of acceleration is now different than the vector of the vehicle's body.

Suspensions don't get rid of energy. That's impossible. They are merely spacing it out over time- a short, sharp shock becomes a longer, smoother one. When you watched that tank video, which if you didn't, I suggest you do, you can see that the tank's visual behavior is pretty much what I'm showing here- it hits a bump, the body wants to keep going in a straight line, then the suspension re-directs the force of that bump upwards, causing the body's vector to change. Then gravity takes over, bringing the vehicle back down on its springs, etc.

Here's another good video I found, showing another way real-world engineers have handled a similar problem:

http://www.youtube.com/watch?v=ieMIO626dwc

Now, I could make my vehicles "fly" a bit, like the trucks do, if the threshold exceeded either X angle or Y velocity, X angle AND Y velocity. That's what I was referring to, in my long post earlier- it's the one area where I'm not totally satisfied with the results. It'd require two GETs and one simple logic step, so I'll probably go ahead and try writing it, and if it doesn't suck, I will post another video.

[TradeMark]

lol wtf @ the first post. "look at this cool thing" - "wtf are we looking for!?"

You should tell what the video is... now when i know what it is, i can say i wasted my minute, it has so crap frame rate that i cant see that what you are trying to show.

[jcnossen]

tbh it doesn't really look like a actual suspension. The wiggle amount and direction seem unrelated to the ground. It looks like it happens randomly.

IMO you've hacked the thing too much, you need more actual simulation and less hack. Maybe just take zpocks script and try to remove ATAN's, lower the number of iterations.
You can do the tilting less frequently as the wheel position changes.

[Argh]

Well, part of that is how I was calculating changes of slope over time. I was, basically, giving it a high value too often, by not really factoring in time at all. That should account for a lot of the bounces.

I'll change that, and come back with another version.

[edit]Hey, cool, this gets rid of two GETs and two Pieces, so I get my costs back and then some![/edit]

[Zpock]

tbh it doesn't really look like a actual suspension. The wiggle amount and direction seem unrelated to the ground. It looks like it happens randomly.

IMO you've hacked the thing too much, you need more actual simulation and less hack. Maybe just take zpocks script and try to remove ATAN's, lower the number of iterations.
You can do the tilting less frequently as the wheel position changes.

The atans in my script can be removed straight away, I have done it and works fine. I just put them in becouse I was too lazy to figure out a conversion from linear to angle in scriptor. I tried decreasing the updating frequency but that didn't turn out very well, it has to be pretty much every frame. For a standard 4 wheeled truck my script is not that heavy, it needs like 12-20 math ops, mostly adding. And I don't know, isnt reading the script lines taking most of the performance, not the actual operations? I'll try to demonstrate this soon.

[AF]

the script is compiled into bytcode, and its the bytecode instructions thats executed by spring. Only the cob compiler interprets the script

[jcnossen]

However it is true that the VM is most of the cpu cost. So I guess it doesnt really matter what kind of operations you do, just that you do 20 of them.

[Zpock]

the script is compiled into bytcode, and its the bytecode instructions thats executed by spring. Only the cob compiler interprets the script

I'm sorry for my ignorance but does this mean that reading in this bytecode and executing the math is as fast as hard coded (c++) math ops?


edit :

However it is true that the VM is most of the cpu cost. So I guess it doesnt really matter what kind of operations you do, just that you do 20 of them.

Ah ok this was what I suspected at first.

[Argh]

No, it matters what operations you do- some of them take longer to "unpack" and run than others do. Simple math ops can get run as-is, pretty much. Stuff like ATAN needs to be broken down into steps, then run, because the results expected back require conversion, if I recall that section of the COB interpreter correctly. I know that certain things are being converted, because of the resulting PRINT returns, which I'm using to study what's happening.

And frequency matters a LOT. Running a script every frame is terrifically wasteful. If you can't get it to run every half-second or so, then, hmm... what's going to happen when you have three variants of this running at once, with 50 units assigned to each? That's why I'm hacking around the problems, duh.

Because each variant on a COB is its own separate item moving through the stack, you can't just have 5 different trucks all use the same script, even if they're written identically. Kind've puts things in perspective, eh?

[AF]

taking a complex bos command and simplifying it aka unpacking, is the compilers job not springs.

what you mean is takign stuff off of the VM stack and turning it into actual data.

[Argh]

No! That's a very common mis-perception!

XZ_ATAN == bytecode value "12". It says so, in our header files! That means that Spring is reading a bytecode 12, then says, "hey, that's XZ_ATAN, which expects an argument, etc., etc.".

Here's the sourcecode, actually, straight from CobInstance.cpp:

case XZ_ATAN:
return (int)(TAANG2RAD*atan2((float)UNPACKX(p1), (float)UNPACKZ(p1)) + 32768 - unit->heading);

[KDR_11k]

Talking about instruction-level optimizations can become pointless quickly since modern CPUs tend to rearrange and simplify instructions as they see fit.

[AF]

No I was right, youve misinterpreted.

UNPACK etc is a macro containing a bitfield

Code: Select all

#define UNPACKX(xz) ((signed short)((Uint32)(xz) >> 16))
#define UNPACKZ(xz) ((signed short)((Uint32)(xz) & 0xffff))
#define PACKXZ(x,z) (((int)(x) << 16)+((int)(z) & 0xffff))

At this point the value has already been taken out of the VM. Packing is just a name fnordia would have used.

Code: Select all

			case GET:
				r5 = POP();
				r4 = POP();
				r3 = POP();
				r2 = POP();
				r1 = POP();
				ForceCommitAllAnims();
				r6 = owner->GetUnitVal(r1, r2, r3, r4, r5);
				stack.push_back(r6);
				break;

Taken from CobThread.cpp in the Tick() function, these are the bytecodes. GET is a bytecode, it is an instruction/opcode. XZ_ATAN is not an instruction, it is a parameter, a BOS macro. Parameter 1 to be specific, the last parameter stored in the list on the VM stack. The packing here refers to how the cob engine stores co-ordinate values on the VM stack.

Remember, COB bytecode translated into text again != BOS. BOS is not COB assembly, and there are versions of plaintext COB at lower levels than BOS. You can see them in the ota community.

You see that XZ_ATAN is a constant.

http://visualta.tauniverse.com/Downloads/ta-cob-fmt.txt

Particularly the bytecode push_constant followed by the constants value in the next index in the bytecode. This pushes the value onto the stack.

So XZ_ATAN is not bytecode value 12. Its just a static value. There's nothing special about it. So what its defined in your header, it could be any name, itd still work. Its a constant that the preprocessor replaces. To suggest it is a command at all shows a lack fo udnerstanding.

Here are the cob commands along with their opcodes and information on the stack

http://visualta.tauniverse.com/Download ... mmands.txt

[jcnossen]

COB is not a religion, its not up for interpretation....

Because of the GetUnitVal call those get functions are probably a bit more expensive than the normal add/multiply stuff, and that's all.

Because each variant on a COB is its own separate item moving through the stack, you can't just have 5 different trucks all use the same script, even if they're written identically. Kind've puts things in perspective, eh?

TBH, you reason too much with too little information. I'm not even sure what you mean here but it doesn't make any sense.

- Each COB thread has its own stack
- Unit types could be using the same script files, however the names are currently linked together so X.cob is always using X.3do/X.s3o

[Argh]

AF, calling "get" an opcode, while omitting that it's completely worthless (and probably crashes Spring) if it doesn't have a parameter to pass... is kind've beside the point.

My point was that most people have no idea exactly what they're invoking when they're calling up the parameters, and they have a tendency to over-use stuff they shouldn't. I don't really care about the semantics of it all, frankly- I'm a lot more interested in what's actually happening, and why some things are incredibly slow, while others are nice and fast. And, as the code showed, just UNPACK is doing quite a few things, and as the source showed, you're invoking quite a few other operations, every time you call ATAN. It doesn't mean ATAN's evil, or whatever, just that it shouldn't be abused. Using it once per Unit per frame is wasteful. Use it to get a value, then use TURN, and fake your way through a few frames, then use ATAN to steer whatever-it-is perfectly again. It's much, much cheaper.



Now, as for me and my hack-around, I am doing exactly two trig operations. And I do it them the old-fashioned way. I don't see a point in doing more than those two, either- we just need angle-over-time. If written perfectly, my script will allow the scriptor to simply speed up / slow down the simulation in order to deal with relative speeds of units- slow it down for slow-moving things, speed it up for fast ones. Then just tweak a couple of values for effect. Voila, instant action.

Interesting factoid: if I speed up the sim enough (say, a quarter-second or less) then everything started jumping around like crazy.

I looked at the animation closely, and found that when I sped the code up enough, that Spring's heightmap basically looks like stairsteps to the code- it basically sees a big drop every pixel, and is reacting accordingly. So, I'm going to have to write some code that checks for two cases- going "up" and going "down", and stops the oscillations. No biggie.

[Argh]

Because each variant on a COB is its own separate item moving through the stack, you can't just have 5 different trucks all use the same script, even if they're written identically. Kind've puts things in perspective, eh?

What I'm saying here, badly, is that if you have five scripts that all run like this:

MyScript()
{
DoSomethingComplicated;
sleep 30;
}

Then you're invoking instruction every frame. Any script written this way is very likely to swamp the stack very quickly. And if you're doing this all the time, then you're quite likely to run into severe lag when you start adding in all of the other things that go on in a real game. Because COB code is sync'd.

So, if DoSomethingComplicated is 20 lines here, 30 lines there... you will start seeing errors pile up. Sounds will play late, the game will start-stop through synch events, etc.

The three biggest things I try to avoid in Spring scripting at this point are:

1. Interrupts.
2. Calling events too often.
3. Calling too much code at once.

All three things cause major problems. All of them are avoidable.

[Warlord Zsinj]

Interesting discussion. :)

Let's keep the egos out. If there's anything bigger then my ego in the room, I want it caught and shot

[Argh]

Here we go, a lot closer to what I was wanting. Finally.

So... we have jumping now, a check to see if it's still going "up" or "down", and it can be adjusted very easily to accommodate a very wide variety of factors, including how bouncy the "suspension" is, how fast you need it to update (very useful, considering that vehicle speeds are a major factor here), how far the "travel" of the suspension elements are, and other stuff. Does everybody want to see sourcecode, or is there something still seriously sucking? It looks pretty good to me, at this point...

[BlackLiger]

Interesting discussion. :)

Let's keep the egos out. If there's anything bigger then my ego in the room, I want it caught and shot

You want to be shot? </burn>

But yeah, WZ's right, anything bigger than his ego will be shot. Then spit roasted on an open flame in the moderation forums....

[Warlord Zsinj]

I would like to see it on something with more then two wheels, that moves a little faster, and perhaps on some more severe terrain. One of the biggest problems with comparing the two is that you only have two wheels (and importantly, only one on each side), and it's bloody hard to see any wheel comparison, while zpock's has 3 on each side, which makes it very easy to see where each wheel is in relation to the others, and the way the wheels are following the contours of the ground.

A good comparison would be to see the new version and the old version together; it's so subtle there I don't think you would really notice too much of a difference. Watching it next to Zpock's version could be interesting too.

The jump is there, but it is very subtle, and unless you're looking closely I don't think you would really notice it that much. I realise this is just tweaking; but I think for RTS purposes, it should probably be exaggurated to a hollywood level of effect. Also, the jump needs to exist in both the up and down direction. If you look at zpock's video, you can see the way it doesn't just maintain it's original heading when it goes over a bump, while the wheels themselves fall away, it will eventually fall down, but not to it's original level, if falls quite low to the ground, to indicate it bouncing against the suspension.

Also, the wheels don't really appear to be moving much in relation to the body, so you can't really see the suspension effect.
For example, in your video, between 1:25 and the end, there are several spots where the wheels should quite clearly be unaligned, and should have quite a bit of displacement, but they remain reasonably stationary, and very similar in relation to each other.