http://wiki.beyondunreal.com/Legacy:Bilinear_Filtering

opengl = With bi-linear filtering
openglnb = Without/Non bi-linear filtering

Ah, gotcha'. Still, the game has the problem of not locking the mouse automatically in both OpenGL modes, so that still stands.

Never heard of that, as the routines don't have anything to do with each other.
Maybe up/downgrade your graphics/opengl drivers or so.

It's not the drivers, because everything else on the system works. I admit to not using the 175.xx nVidia drivers due to them switching to the .NET framework to kiss M$'s butt and get WHQL and thus eating up a much larger amount of memory and degrading Oblivion performance, but I digress on that matter. I use 169.21 and even my own C++/GL apps can lock the mouse. DOSBox is the only program I use that won't lock the mouse automatically, but it WILL lock it using CTRL+F10. There is a bug somewhere in the DOSBox code that seems to ignore the auto-lock setting if using the GL modes. If I couldn't lock the mouse at all in those modes, I'd be worrying about my system, but considering the facts that DOSBox locks it just fine when using CTRL+F10, that all my personal GL apps can take control of the mouse automatically, that DOSBox runs in GL wonderfully, and that major games like UT2004 can run in GL without problems, I have to blame this one on DOSBox.

I just formatted and am not about to start toying with drivers and such. My system works fine, and I don't want to go screwing things up over a minor bug in one program just to prove my point, but anybody else with an nVidia graphics card is more than welcome to go off and install ten different driver versions and see if one auto-locks or not. Not being hard to get along with, but after a whole day blown on an annual format, I am NOT going to screw my system up.

It's not the drivers, because everything else on the system works.

Really bad assumption.

and even my own C++/GL apps can lock the mouse.

Well nice for you. Guess you don't use SDL.
Get a debugger and check what's wrong.

What do you guys use to compile/build DOSBox under Win32? If it's MSVC, what version? I use VS2005 Pro here.

I also know for a fact it isn't the drivers because if it was, why does it happen on my laptop which has an ATI card? Why does it happen on my family and friends' computers who have an array of cards and varying driver versions? This isn't just my machine, or I wouldn't have bothered posting. This happens on nVidia, ATI, and Intel chipsets. It happens on the latest nVidia drievrs and the older ones. It happens on the two most recent versions of ATI's drivers, and it happens on several versions of Intel's drivers, dating from the most recent to ones released in 2004.

Now for the similarities. Every system tested auto-locks on every other rendering mode, just like my own. Every system can lock the mouse using CTRL+F10, but not automatically at start. I think that should speak for itself. If you think I'm lying, I'll get the camcorder out and shoot you videos of at least six systems tomorrow and put it online. OpenGL doesn't lock the mouse automatically, no matter your hardware or software.

The conf file note for autolock states that it happens if you click on the screen. But my experience has been that it won't autolock by clicking until you run a game or app that actually uses the mouse. For example, just starting up DOSBox to the prompt, it won't lock by clicking (it will with Ctrl-F10 though); but once I run any program that uses the mouse, even if I exit that program and go back to the prompt without ever touching the mouse, it will then lock with a click. It's like some flag gets set by running a mouse app. This behavior is consistent for ALL output methods on my system, and I've always assumed it was this way by design.

that it won't autolock by clicking until you run a game or app that actually uses the mouse.

Yes, that's how it works, on some int33 calls (usually mouse reset or enable)
the locking is activated, as you say independent from the output mode.

I use VS2005 Pro here.

Should work, same for vs2008 or mingw.

See that's where my differences are then. I have had it lock without clicking in the other rendering modes, but in GL a big black mouse cursor is visible until I use CTRL+F10 or I click once the game has fired up. I'll bet the other rendering modes simply hide the cursor and I just don't notice it hasn't locked until I click, in which case it's still a bug in the sense that GL shows the cursor instead of hiding it, but it's not as big of a bug.

I asked about the build software because a LOT of stuff made with Visual Studio prior to 2005 won't compile in VS2005 due to VS2005 conforming to the much stricter C++ rules and such. I spent months getting one of my old VC6 projects to compile in VS2005 due to hundreds of errors and warnings that do not show up in VC6. At least M$ fixed their problem with being lax in VS2005!

The cursor is not visible for me if it is locked, and it is visible if the cursor is
not locked, same behavior for all outputs.

> a big black mouse cursor

Seems like it is about fullscreen?

Yeah, I only play fullscreen like the games ran back in real DOS. And I tested it, and that is the real issue. In surface, overlay, and ddraw the mouse cursor is hidden, but it doesn't lock until I click once. In OpenGL and OpenGLNB the cursor is NOT hidden, but it hides and locks when clicked.

Personally I have been building with (free) MinGW.. as WD stated though
graphics is mostly 'outsourced' to libSDL, so the problem is likely in there.

It might help to try a different version of SDL.DLL. (You may have conflicting versions in %windir% and Dosbox build)