[SDL patch version] Hq2x / Hardware OpenGL-HQ scaling

Here you can discuss the development of patches.

Re: [SDL patch version] Hq2x / Hardware OpenGL-HQ scaling

Postby `Moe` » 2005-9-14 @ 21:55

gulikoza, I hope this is your lucky day. I finally encountered a mouse-related problem and fixed it. Unfortunately, I haven't tested my change on windows yet (and I don't provide a windows DLL this time), because my windows development environment got trashed. I'd be very grateful for someone to test my change on win and send me a DLL which I can provide as 'official' DLL.

Download location as usual.
User avatar
`Moe`
Oldbie
 
Posts: 1169
Joined: 2004-4-29 @ 01:06
Location: Oldenburg, Germany

Re: [SDL patch version] Hq2x / Hardware OpenGL-HQ scaling

Postby gulikoza » 2005-9-15 @ 04:13

I'll test it and report back :)
User avatar
gulikoza
Oldbie
 
Posts: 1698
Joined: 2004-6-25 @ 14:53

Re: [SDL patch version] Hq2x / Hardware OpenGL-HQ scaling

Postby gulikoza » 2005-9-15 @ 05:19

yup...this seems to fix the "stuck" cursor problem I've been having. But introduces another problem - mouse speed now depends on the scaling factor: x2 scaling -> 1/2 mouse speed. Can this be easily fixed? I've looked at the code but I don't have a slightest idea what to look for... :pppt:
User avatar
gulikoza
Oldbie
 
Posts: 1698
Joined: 2004-6-25 @ 14:53

Re: [SDL patch version] Hq2x / Hardware OpenGL-HQ scaling

Postby `Moe` » 2005-9-15 @ 14:52

Yes, well... cursor speed is supposed to be like that. It is most apparent in windowed mode: If you scale x2, the mouse must cross twice as much screen space to move from one edge of the window to the other edge. Thus, the mouse is, in a way, half as fast.

I can imagine this is a bit unexpected when the mouse is grabbed, but the pointer should move exactly as fast as the native mouse pointer (at least in well-behaved games, X-Com is an example).

Just for experimenting, I will upload a different SDL patch (look for somethin with your nickname in it) to the archive directory with a little change. Try it and tell me what you think.
User avatar
`Moe`
Oldbie
 
Posts: 1169
Joined: 2004-4-29 @ 01:06
Location: Oldenburg, Germany

Re: [SDL patch version] Hq2x / Hardware OpenGL-HQ scaling

Postby gulikoza » 2005-9-15 @ 15:42

hmm...I'm not seeing any differences in the diff file compared to 14-09 release - same code just different file timestamps, are you sure you uploaded the correct file?
Also, I've done some more testing, I might be incorrect. Mouse speed probably does not depend on the scaling factor, just that the cursor is a *lot* slower than native one. With hwscale=3.0 (and a 320x200 game, window mode) I have to move my mouse almost 1.5 times the width of the mouse pad to get across the screen...
User avatar
gulikoza
Oldbie
 
Posts: 1698
Joined: 2004-6-25 @ 14:53

Re: [SDL patch version] Hq2x / Hardware OpenGL-HQ scaling

Postby `Moe` » 2005-9-17 @ 10:05

I've uploaded a new version, which changes mouse behaviour slightly, and documents possible traps. Gulikoza, please reevaluate, and read the README ;)
User avatar
`Moe`
Oldbie
 
Posts: 1169
Joined: 2004-4-29 @ 01:06
Location: Oldenburg, Germany

Re: [SDL patch version] Hq2x / Hardware OpenGL-HQ scaling

Postby gulikoza » 2005-9-17 @ 17:49

No, this is very much like the 09-14 version. What are those env variables? I could only find references for X11 mouse driver, nothing about win32...
User avatar
gulikoza
Oldbie
 
Posts: 1698
Joined: 2004-6-25 @ 14:53

Re: [SDL patch version] Hq2x / Hardware OpenGL-HQ scaling

Postby `Moe` » 2005-9-19 @ 14:39

I don't know how it is with win32, I juts looked at the SDL sources and saw that drivers switch mouse behaviour in relative mode (== when mouse is grabbed), which is probably the source of your problems. In the X11 driver, I saw some env vars being used, perhaps win32 has that too, just not documented?

I can't leave the patch as it was before, since then the mouse is unusable on X11 systems with high scaling factors (fullscreen is x4 for me).
User avatar
`Moe`
Oldbie
 
Posts: 1169
Joined: 2004-4-29 @ 01:06
Location: Oldenburg, Germany

Re: [SDL patch version] Hq2x / Hardware OpenGL-HQ scaling

Postby HunterZ » 2005-9-19 @ 18:32

I would be very surprised if Windows used an environment variable that had something to do with mouse behavior. More likely it would be in the registry.

A cross-platform fix would be optimal, although I don't see the point -- I don't understand why anyone would care about untrapped mouse cursor speed with DOSBox?
You're perfect, yes it's true...but without me, you're only you.
User avatar
HunterZ
l33t++
 
Posts: 6057
Joined: 2003-1-31 @ 19:04
Location: Seattle

Re: [SDL patch version] Hq2x / Hardware OpenGL-HQ scaling

Postby `Moe` » 2005-9-20 @ 07:19

HunterZ, SDL uses environment variables exclusively - no registry. I'm talking about things that SDL and the SDL win32 driver does, not Windows itself.

Untrapped speed isn't any issue either - coordinates are reported in absolute mode then, and that's translated correctly. The problem is that the platform SDL-driver switches mouse speed when grabbing the mouse, and that is obviously done differently on each platform.
User avatar
`Moe`
Oldbie
 
Posts: 1169
Joined: 2004-4-29 @ 01:06
Location: Oldenburg, Germany

Re: [SDL patch version] Hq2x / Hardware OpenGL-HQ scaling

Postby HunterZ » 2005-9-20 @ 14:54

Ah, sorry I guess I misunderstand the problem. Thanks for the clarification.
You're perfect, yes it's true...but without me, you're only you.
User avatar
HunterZ
l33t++
 
Posts: 6057
Joined: 2003-1-31 @ 19:04
Location: Seattle

Re: [SDL patch version] Hq2x / Hardware OpenGL-HQ scaling

Postby `Moe` » 2005-9-28 @ 10:15

Just FYI: I'm still on the matter, I just lack a decent idea how to solve it. Rest assured that sooner or later the remaining mouse issue will be fixed. Such ideas usually happen on a sleepless night :-)
User avatar
`Moe`
Oldbie
 
Posts: 1169
Joined: 2004-4-29 @ 01:06
Location: Oldenburg, Germany

Re: [SDL patch version] Hq2x / Hardware OpenGL-HQ scaling

Postby gulikoza » 2005-9-29 @ 17:07

Sorry, I was away in Greece ;)

How about an #ifdef seeing that 09-14 and 09-16-"gulikoza" only differ in 1 if sentence? I still do not completely understand how the code works and I'll need a few days to get back into buisness :)
User avatar
gulikoza
Oldbie
 
Posts: 1698
Joined: 2004-6-25 @ 14:53

Re: [SDL patch version] Hq2x / Hardware OpenGL-HQ scaling

Postby `Moe` » 2005-9-30 @ 20:52

Well, I guess the main problem is how people expect the mouse pointer movement. For a given amount of mouse movement, they probably expect

a) the same amount of pixels
or
b) the same percentage of the (DOS) screen/window

... regardless of scaling factor!

In full-screen mode, a) and b) are the same, so this applies to windowed mode only. I would expect that people like (a) better, since that is what the native mouse does. That was what I wanted to get. I still want to get that effect, but I don't know how to do this correctly (the problem is what I explained in a previous post).
User avatar
`Moe`
Oldbie
 
Posts: 1169
Joined: 2004-4-29 @ 01:06
Location: Oldenburg, Germany

Re: [SDL patch version] Hq2x / Hardware OpenGL-HQ scaling

Postby HunterZ » 2005-9-30 @ 21:11

Can SDL get the current coordinates of the unlocked mouse if DOSBox is in the foreground and the mouse cursor is over its window? It must be able to do this in a cross-platform way, since SDL programs like SCUMMVM have GUIs.

You could then sample the absolute position over time if you need to convert it to movement.
You're perfect, yes it's true...but without me, you're only you.
User avatar
HunterZ
l33t++
 
Posts: 6057
Joined: 2003-1-31 @ 19:04
Location: Seattle

Re: [SDL patch version] Hq2x / Hardware OpenGL-HQ scaling

Postby gulikoza » 2005-9-30 @ 23:27

Hmm...it's really hard to make accurate tests how far the mouse cursor moves...now I have the feeling that with openglnb (& hwscale=2) the mouse cursor is faster than native cursor. It's also roughly the same speed with overlay, D3D and 09-16 openglhq. And this is the most important I think - to make mouse speed consistent across all output modes.
User avatar
gulikoza
Oldbie
 
Posts: 1698
Joined: 2004-6-25 @ 14:53

Re: [SDL patch version] Hq2x / Hardware OpenGL-HQ scaling

Postby `Moe` » 2005-10-09 @ 22:44

Hunter, when dosbox (or rather, SDL) grabs the mouse, it is switched into relative mode on purpose - the reasoning is that you can use a higher resolution/different acceleration then. And that's exactly what bites us.
Making SDL stop this behaviour would mean "dirty" patching in several locations, so this is no option for me. Although you might just have brought me on to something...

gulikoza, perhaps that's the best behaviour: Behave exactly like normal2x and all other scalers. I'll try some things.
User avatar
`Moe`
Oldbie
 
Posts: 1169
Joined: 2004-4-29 @ 01:06
Location: Oldenburg, Germany

Re: [SDL patch version] Hq2x / Hardware OpenGL-HQ scaling

Postby `Moe` » 2005-10-10 @ 11:54

Well, after some testing (and your valid reasoning that mouse movement should always be the same regardless of scaler), I have now uploaded the (hopefully) final version. It should be the same as one of the "fast mouse" experiments we had earlier. My tests show that now the mouse works exactly like in other scalers. A Win32 binary build is welcome, as usual ;)
User avatar
`Moe`
Oldbie
 
Posts: 1169
Joined: 2004-4-29 @ 01:06
Location: Oldenburg, Germany

Re: [SDL patch version] Hq2x / Hardware OpenGL-HQ scaling

Postby gulikoza » 2005-10-10 @ 12:24

hmm...this looks exactly like the 09-16-"gulikoza" version (with the exception of one '(' that actually does not belong there) which you said does not work that well in X?
User avatar
gulikoza
Oldbie
 
Posts: 1698
Joined: 2004-6-25 @ 14:53

Re: [SDL patch version] Hq2x / Hardware OpenGL-HQ scaling

Postby `Moe` » 2005-10-11 @ 03:27

Yeah, mouse was a little fast for my taste, but in the end it is exactly like it is in other scalers, so I should either quit complaining or set sensitivity in dosbox.conf ;)

Another update: I have optimized partial screen updates so that the mouse no longer laggs during fast movements in scummvm. dosbox should not be affected by that. Unfortunately, there is now a crash hidden somewhere - but that, too, should not affect dosbox or scummvm.
User avatar
`Moe`
Oldbie
 
Posts: 1169
Joined: 2004-4-29 @ 01:06
Location: Oldenburg, Germany

PreviousNext

Return to DOSBox Patches

Who is online

Users browsing this forum: Baidu [Spider] and 1 guest