Page 1 of 1
Cursor movement issue
Posted: Thu Jul 20, 2006 9:59 pm
by 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.
Posted: Thu Jul 20, 2006 10:50 pm
by 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?
Posted: Thu Jul 20, 2006 11:07 pm
by 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.
Posted: Fri Jul 21, 2006 1:18 am
by 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.
Posted: Fri Jul 21, 2006 1:37 am
by 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
Posted: Fri Jul 21, 2006 4:25 am
by 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.
Posted: Fri Jul 21, 2006 5:29 am
by 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)
Posted: Fri Jul 21, 2006 3:24 pm
by Paul Stevens
ST Sprite?
Posted: Fri Jul 21, 2006 4:25 pm
by 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...
Posted: Fri Jul 21, 2006 6:42 pm
by Paul Stevens
Sounds simple. Anyone care to wiggle similar
code into CSBwin?
Posted: Sat Jul 22, 2006 5:14 am
by Sophia
Or not.
Yet another way the ST sucks, I guess.
Paul Stevens wrote:ST Sprite?
Posted: Sat Jul 22, 2006 11:35 am
by Gambit37
An quick solution to the perceived problem is to play full screen.