Skip to content

New speed system differences. #168

wangds opened this Issue Jan 2, 2013 · 11 comments

3 participants

wangds commented Jan 2, 2013

Some differences between the old speed system and the new speed system I have found, mostly due to Dune II's low resolution. I've only tested with quads, so they may well apply to other units too.

  1. Quads move faster on the border of rock/sand than on plain rock. This really is Dune II's fault for penalising wheeled vehicles on "entirely rock" but not on "mostly rock". On normal speed, rounding errors used to make the two equivalent. The new system changes that, and looks really odd if you're used to normal speed.

  2. Quads move much faster when travelling on sand. Moving south-east somehow looks very unnatural.

  3. Quads sometimes miss the little pause you get after every tile when travelling long distances.

  4. Quads moving south or east on sand "pop backwards" as they reach the centre of a tile.

Not sure if you want to consider these bugs or features.

OpenDUNE member

1) yeah, I too noticed this during testing. I first thought it was weird, but after looking at the code it really is what they wrote. With slower vehicles you also see it in original Dune2. But as we see mostly rock, it just feels weird. I might just tune those values to be (almost) identical to rock. Will have to tweak with it a bit.

2) hmm .. will check it out; sounds wrong :)

3) the pause in fact is more a bug, or a problem they couldn't resolve, than anything else. But we got so used to it ... I might add code to simulate the effect, just for the legacy feeling of it all.

4) hmm .. there is code that should prevent that. will check it out :)

Tnx for all the testing. Let's see if we can keep the speed fixes, but tune it back to match the old behavior more (without reintroducing the bugs :P). I really like that Trikes now really go faster than Quads, on every speed :)

rofl0r commented Jan 2, 2013

the proper solution is probably the one that i applied on my fork: simply fix the issue we had, i.e. the sonic blast, but leave everything else untouched.
your approach of "fixing" a non-issue (the speed system works generally well enough) by making everything behave differently and then starting to "tune" will only lead to new bugs, more different subtleties and more code than needed.

OpenDUNE member

The issue I fixed, is the one where GameSpeed would influence the game in an unfair way. For example, a Trike would in many cases move identical in speed than Quads, where Quads should be more than 10% slower. This is one of the oldest problems I have with Dune2, and I tried to fix it. In result, it turned out I fixed a lot of other bugs too, but this was merely a coincidence then anything else. So your reply is rather mute, in the sense I "simply fixed the issue I had".

Nevertheless, thank you for your input. Now only tune down the attempts to be sarcastic, and we would get along just fine.

wangds commented Jan 9, 2013

I found that there is some asymmetry in the Tile_MoveByDirection calculations--it always rounded up, which penalises moving left and up. This might help out with issues 3 and 4, which have a directional dependence. It's probably a good change irrespective of whether you want to keep the new speed system.

I find it strange that they divide the unit's speed by 16 when setting the speed, and then multiply it back up when moving the unit. I experimented with this idea in my fasttrike branch. This seems like a nicer change if you want trikes to be faster than quads. (It reintroduces the sonic tank range bug.)

edit: didn't mean to close.

@wangds wangds closed this Jan 9, 2013
@wangds wangds reopened this Jan 9, 2013
OpenDUNE member

Been thinking a lot about this; how to solve it nicely. What I think would be the best (and what I will do next week if I don't change my mind :P):

  • Revert my commit
  • Pickle out of my commit the changes related to air units (where they always move at the same speed no matter what the game speed is) -- Fixing sonic blast, and other related issues (inconsistency, and plain wrong code)
  • Apply your Tile_MoveByDirection fix
  • Review the speed-fix, check why my code fails, and hopefully cook up a solution

This should make it easier to work on this, by splitting it up over more commits. Then we can see how it goes from there :)

OpenDUNE member

Lolz, don't know if I already said it, but Tools_AdjustToGameSpeed is done twice for moment: once when setting the speed, then when moving the unit. Funny ;)

OpenDUNE member

Okay. I reverted my commits. I pickled out my airspeed fixes. I applied your Tile_MoveByDirection (modified it a bit for readability).

Now looking over your speed-fix, that would indeed do the trick, but I still think it has a lot of over-complicated code surrounding it. The longer I read the code, the more I understand their intention; but the resulting code is rather weird.

So, I took a completely different approach. I published my try in the branch "speedtest". Would you be able to do all your testing etc on it, and let me know what you think? As far as I could test it seems a lot more stable, and more what I expect it would do.

Please do let me know :)

(URL: )

wangds commented Jan 19, 2013

It certainly is an improvement over the previous new speed system. Points 3 and 4 don't bother me so much any more.

2) Quads travelling diagonally on sand is kind of jerky. Somehow my fasttrike test looks nicer, but it had a tendency to snap units into place.

5) Units that are moving when you save a game will be stuck and unable to move when loaded in older versions of OpenDUNE and Dune II. I don't know if that's a big deal, but I do find it useful to maintain compatability for testing purposes.

6) In Unit_MovementTick, the Tools_AdjustToGameSpeed calculation has been duplicated.

OpenDUNE member

2) initial testing gave me same results, but I couldn't reproduce it later one. Back to the drawingboard with them ;)

5) Yes, this indeed has to be fixed. Completely forgot about it tbh :)

6) this is what the original code reads (although on done in SetSpeed, the other in MovementTick); without it, Trikes feel REALLY slow on Fastest. Try it if you like, and let me know what you think :)

wangds commented Jan 20, 2013

6) I'm not sure I'm reading the same code as you. It currently reads:

if (g_table_unitInfo[unit->o.type].movementType != MOVEMENT_WINGER) {
    speed = Tools_AdjustToGameSpeed(unit->speed, 1, 0xFFFF, false);
    speed = Tools_AdjustToGameSpeed(unit->speed, 1, 0xFFFF, false);

I realise that the old code adjusted the speed twice, but this duplicated Tools_AdjustToGameSpeed line doesn't do anything useful.

On fastest, Trikes seem to move as fast as Quads on rock (not faster, as far as I could tell). I certainly wouldn't describe it as "REALLY slow".

OpenDUNE member

Haha, you are absolutely right; damn, that is a nasty mistake. The second 'unit->speed' should be 'speed'.

But I am rather surprised you don't notice the slowdown with the current code. I wonder why that is, as units now move 50% slower than the original. It might be that all the rounding makes it feel the same .. hmm ..

For sure I was wrong, as those 2 lines indeed do nothing but waste CPU cycles ;) Will fix it up tomorrow, and see if I can fix more of your above mentioned points. At least I like the new code, a lot cleaner :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.