Run mouse in seperate thread

[___________Fellowman]

Hi guys

When Ultima online 3D came out, it suffered from the same slow mouse syndrom that Anarchy Online suffers from.

The developers fixed the slow mouse with an option called "Run mouse in seperate thread". This made the mouse run at the same speed as it normally runs in windows and made the game 100% easier to play.

Is this techinically possible with a game like AO? If an option like this could be incorperated in would make up a lot for the shortcomings of the interface.

I have no idea what the option did technically, I suppose it just ran the mouse seperate from the renderer, I dunno..

Maybe a dev would like to respond.......Maybe pigs will fly too

[Kinkstaah]

It'd make the cursor have its own processor thread, in essence running a seperate program just to point and click.

As opposed to being a part of AO and running within it (and having the same performance)

[supergarr]

yeah, they do that in DAOC and i think AC. Makes the game sooooooooo much better to play like that.

[___________Fellowman]

Yeah that seems to be what I was getting at.

Is it technically possible in a game like AO?
Should we hassle them to put it into the game.
Currently when the frame rates drop its like trying to drag the mouse through syrup and I hate that

[Rubirango]

Oh god I really hate it when the mouse goes sluggish... sounds like a good idea if they could do it.

[Whiterrabbit]

its an interesting idea

[________________Miir]

On topic, I think that giving chat/text and mouse control their own process would go a long way to improving AO.

[_____Poweredge|vault]

Originally posted by ReelBigFish
they could, but it'd slow down AO.

a thread is a java process, threads can be run concurrently, but your processer actually flicks between the processes (threads), suspending one as it runs the other, then back to the first, suspending the second.

its an interesting idea

Umm... and here's me thinking that my 16 years of being a programmer dealing with processes and interrupts was the way to deal with things.

The link between processes, interrupts and Java, is like saying that real programmers _always_ eat quiche on Tuesdays.

[Whiterrabbit]

no i dont have any idea how wrong i am, but have deleted my reply

care to explain why im wrong, ive got my concurrent programming exam coming up, and i would really like to know.

well, it was a massive simplification based on teh massive simplification that ive been lectured on, so im not presuming to have anywhere near the level of competance as either of you two.

if you think you could be kind enough to explain it in idiots terms (as i attempted to but failed miserably) by idiot, i mean so that i can understand it

[Whiterrabbit]

<<note to self, never write anything 5 minutes after waking up and before first cig of the day>>

[________________Miir]

/me pours ReelBigFish a coffee....

[______________Leumas]

Originally posted by ReelBigFish
no i dont have any idea how wrong i am, but have deleted my reply

care to explain why im wrong, ive got my concurrent programming exam coming up, and i would really like to know.

What exam are you taking? The sun java one?

[Whiterrabbit]

no, my concurrent programming module for my degree in AI (god knows why concurrent programming is important in ai, but there you go)

[Arinia]

care to explain why im wrong

a) there's no java in AO (err, maybe there is, that's why it's so slow, problem solved!!! *sarcasm*)

b) Processor is constantly task switching, the timeslices are actually smaller than you think. Deciding how long each timeslice (minimum time on proc before switch) is a complicate formula that you look at in OS classes

c) A process is different than a thread anyway (well, kinda, sorta...)

In short, it'd slow down AO, but never enough that you'd ever notice.

That says nothing as to whether or not it would affect deeper aspects of gameplay, open up exploits, etc etc.

[Whiterrabbit]

true, you wont notice that, and when compared to the lag factor, makes my statement even more stupid

java was just my example, but dont ask me how my brain works first thing in the morning.

[Tentumbs]

First thing first:
1: The programmers wan't read this. Thats not there job.
2: Those who have the job of supervising the thread wan't understand a thing and will not make it on to thje progammers becouse they do not want to disturb them.

The problem:
Yes you could put the mouse in another thread and you can say that it is a programm in addition to AO, but there is no roule against haveing two threads or programms oto talk to each other. The one giving the other a message that the user actualy pushed a button. But thets not the problem

The problem is framrate. When the framerate drops (whatever reason) the mouse get sluggy becouse its drawn as part of the picture. This can be handled in window mode by letting the OS draw it, but not in fullscreen. The only solution to this is to actualy force redraw of the screen more often. It will not improve the framrate, but if you move the cursor on the screen that is redrawn more often it will look like the mouse isactualy responding.

So instead of two frames (The one you see an the one that gets render) you will have tree frames (The one you see, a copy of that which you move the mouse on and the one you render) You then ensure to redraw screen two often and take the tird when the rendring is finish. This can be easy implementable or hard depending on how the programmers have modulated there drawing code.

[Cosmik]

Originally posted by ReelBigFish
its an interesting idea

I agree. I'll look into it.

[___________Fellowman]

Wow I got noticed

Thank you Cosmik, A change like this would really help smarten up the interface, making the game so much more enjoyable to play

Xlesiar

[Tetra]

Originally posted by RealGunslinger
First thing first:
1: The programmers wan't read this. Thats not there job.
2: Those who have the job of supervising the thread wan't understand a thing and will not make it on to thje progammers becouse they do not want to disturb them.

The problem:
Yes you could put the mouse in another thread and you can say that it is a programm in addition to AO, but there is no roule against haveing two threads or programms oto talk to each other. The one giving the other a message that the user actualy pushed a button. But thets not the problem

The problem is framrate. When the framerate drops (whatever reason) the mouse get sluggy becouse its drawn as part of the picture. This can be handled in window mode by letting the OS draw it, but not in fullscreen. The only solution to this is to actualy force redraw of the screen more often. It will not improve the framrate, but if you move the cursor on the screen that is redrawn more often it will look like the mouse isactualy responding.

So instead of two frames (The one you see an the one that gets render) you will have tree frames (The one you see, a copy of that which you move the mouse on and the one you render) You then ensure to redraw screen two often and take the tird when the rendring is finish. This can be easy implementable or hard depending on how the programmers have modulated there drawing code.

It's not *just* a framerate problem though... zone into BS/Newland/omni-trade sometime and right click a pack or try to type /pet behind... you'll notice nothing happens also odds are good you will have problems simply typing <enter>yea im in trade now
letters will be missing from the start and odds are good that if you are a moderately fast typist you will get a ":0" instead at the end.

[Tentumbs]

It is still down to the same problem.

A normal program procedure is like this:

1. Read the input channels.
2. Do the scene change.
3. Draw the scene.
4. Show the scene.
5. Go back to 1.

This is ofcource whery simplifyed.

In DirectX you can have two ways of reading the keyboard.
1. Read the "state" of a key. If it pressed, not pressed and so on. Works excelent for 1.player shootup like quake and equal.
2. Read a buffer which is the last key events pushed.

Funcom probably doing the secound version so they do not miss any events. However when point 3 takes to much time you are risking to make a buffer overflow before you reach back to number 1. I do not remember how many characters the buffer got, but I do remember that it is not much. 10 char or something.

So if your framerate drops to below 1 fps due to loading of graphics and you type more than 10 chars in that window it will not get all the characters.