Cursor movement issue

[Sabreman]

Couldn't see anything obvious on this subject, and it barely seems worth a topic, but...

In CSBWin the mouse cursor moves very choppily, it's quite offputting. Is this just a factor of the engine or is there anything I can do to smooth it out? (I'm purely a player, not a modder or designer).

Thanks.

[Paul Stevens]

Playing what game? What kind of machine
do you have? I have never encountered this
except when something is using nearly 100 percent
of the CPU. Doyou have a 'Task Manager' to
look and see who is using CPU time? What resolution
video are you using? What resolution is your monitor?

[Sabreman]

Playing any game running on the CSBWin engine (Conflux, Towers of Flame, or indeed the original DM and Chaos). I'm using a P4 2.4, 768MB RAM, Radeon 9600 card. Desktop resolution 1024x768, game resolution default.

Nothing significant running in the background

I wouldn't expect it to be a PC performance issue, for sure. Everything else in the game is running fine, there's just this odd refresh rate-type slowness to the mouse cursor.

[Paul Stevens]

If I put a CSBwin window on my screen I can move
the mouse back and forth horizontally rapidly and
the cursor follows the mouse quickly but is displayed
at only a few intermediate locations.....perhaps 4.

If I move the mouse out of the CSBwin window and move
it back and forth rapidly, the cursor follows the mouse
quickly but I can see it at many intermediate positions...
perhaps 10.

Is this your problem? Or is it that the cursor lags
behind the mouse and 'catches up' after a delay?

The problem I see (The few intermediate positions)
cannot be fixed. The cursor is part of the screen in
CSBwin. It is not drawn independently over the
game window. And the window (and therefore the
cursor) gets drawn only about 6 times a second.
That is how often the internal clock is incremented.

Outside the CSBwin screen the video is updated
60 to 90 times per second. Inside it is updated only
6 times per second. Like I say, if this is your problem
then you are stuck with it.

[Sabreman]

Ah, I see. Yes it is what you describe. It was probably the same on the ST and Amiga but it's so many years since I've played those versions I can't remember.

I guess I've been spoiled by modern refresh rates!

Thanks

[Paul Stevens]

It was probably the same on the ST

No. On the ST they did it right. The cursor was
interrupt driven. I translated the program but of
course I had no video horizontal and vertical interrupts.
They used the horizontal interrupt to change the palette
twice during each vertical scan and the vertical interrupt
for such things as cursor management.

It is a long story but the final result is that the cursor
in my version is part of the window and does not
float above it as a proper cursor ought. I seldom use
the mouse because all movement, fighting, and spells
are more easily done with the keyboard.

[Sophia]

Wasn't it a hardware sprite on both the ST and the Amiga?

(Hence the ugly monochrome hand on the ST! The Amiga allowed 16 color hardware sprites, because the Amiga rules)

[Paul Stevens]

ST Sprite?

[George Gilbert]

On the off-chance that anyone's interested, the RTC main game loop looks something like:

Code: Select all

WinMain(...)
{
  while (TRUE)
  {
    if (TheresAWindowsMessage)
    {
      store new mouse coordinates, but otherwise do nothing
    }
    else
    {
      RTCMainGameLoop();
    }
  }
}

RTCMainGameLoop()
{
  if(Every1/6thSecond)
  {
    DrawMainScreen()
    take a copy of the screen under the mouse coords
  }
  else
  {
    put back the copy of the screen under old mouse coords
  }
  
  DrawMouseAtCurrentMouseCoords()
}

It's somewhat more optimised than that, but you get the general idea.

The practical upshot being that even though everything is done in software on a single bit of screen memory and that the main dungeon view is only updated every 1/6th of a second, the position of the mouse bitmap is updated at the maximum speed your monitor can handle (1/60th of a second for 60Hz etc) without the need for any interupts / video layers or other fancy hardware stuff...

[Paul Stevens]

Sounds simple. Anyone care to wiggle similar
code into CSBwin?

[Sophia]

Or not.

Yet another way the ST sucks, I guess.

ST Sprite?

[Gambit37]

An quick solution to the perceived problem is to play full screen.