I understand you what you are doing (I have been practising with unit's variable a lot) but although I think it's very original, it has little practical use.

The idea is really good, but the fact that you are comparing P0 variable with P1 and they increase 1 and 2 per second has the problem os slowness as you said.

If you want to add the half of 10, it would be

1 - 8

2 - 6

3 - 4

4 - 2

5 - 0

You have 5, the half of ten, but it has taken 5 seconds (2.5 if you loop each 500ms).

Now imagine you have 1000 gold, or 10.000. It would be allmost impossible to calculate that 5.000 of gold in one scenario, or if it's, when you have the result then the player has forgot about it (if you bet for that, you can win the half of your gold - the player has 1000 of gold, he wins and after 8 minutes he receives 500 of gold...).

About multiplying, I think your method isn't practical too.

See, it's like computers. When the CPU has to calculate the multiplication of two numbers, it cannot say "lets see, 10x10, then lets add 10 to the result ten times". Why? Cause (according our teacher ) you DONT know how many cycles of clock it would need. When the CPU has to do an arithmetic op. it MUST know (well, the CPU doesn't, but the programmer must) how many cycles it would last.

So, how does a CPU multiply two numbers?

Exactly as you multiply two numbers on paper: first you multiply with the "less significant bit" (aka the righter number), then the second one, and so on until you reach the lefter number ("the most significant bit"). And you multiply per 10 each line.

The CPU do the same, it multiply the lsb (remember, it can be a 1 or a 0, as it's binary, so that multiplication is really easy), then the second lsb and it multiplies per 2 (again, it's binary, so muliplying per 2 is a displacement to the left, an easy operation) and so on. And then it sum all the results. So it only need x simple multiplications (where x is the amount of numbers) and one sum. So it needs x+1 operations. But with the "add method", if you want to multiply per 100 f.e., it would take 100 sums, 100 operations, and with the other method 4 operations.

However, can we implant that algorithm in Empires?

First, each cycle has at least 0.5 seconds so instead of doing 100 operations, doing 4 is an important saving.

However, Empires'trigger can only implant "elementary" operations, so for more complex it would take many cycles. And many cycles represent MANY time.

If you want to multiply 2 numbers, first we must isolate the first number, then the second, and so on. Can we do it? With one cycle I think it's impossible. Then we must multiplicate that isolated number with the entire cipher. As it isn't 0 and 1, we should do your system. Anyway for multiplying 999 it would take 27 cycles, instead of 999, so for large numbers it is still an advantage. We must have a counter that stores the position of the number. And add the same number of 0s (multiplying per 10). Perhaps (I haven't tested) we could do /*value0, but I don't think it would accept that as a 10 multiplier Imagine it does. Then it would take x cycles where x is the sum of all the number position. Hmmmm many cycles. But we are still saving many, so let's go on. Then we can sum all the results. It would take a few cycles, the first is to store the first result in one variable, and then add the following results in that variable. That's pretty easy.

And we have the multiplication result.

Is it worth the effort and time? As Empires hasn't got basic operations, we have had to create them with more elementary ones. We have saved many cyles FOR LARGE numbers, but we have wasted too many for LITTLE numbers. And that represent 0.5 extra seconds per cycle.

Conclusion:

except if you are using numbers smaller than 5, or you are very patient, your algorithm isn't worth. For larger numbers we could use the algorithm I exposed above, but doing it in Empires would be SUICIDE

So the only practical use of this is do "microoperations" with little numbers for, for example, using them for unit variables. Well, the option is here, then the designer has to think how to use it for a practical stuff.

The easiest solution: wait for SSSI to implement a trigger that allows you to do this operations in a few CPU cycles (miliseconds) in the next X pack

I am sorry for this suffocating post, as you can imagine I was VERY bored

[This message has been edited by Andres_age (edited 03-28-2004 @ 03:12 AM).]