To test this i hex edited the engine to replace the filename for gearbox\cl_dlls\client to updated\cl_dlls\client. If the client could hint to the engine that it's using SDL2, as any Half-Life mod using the current SDK is doing, then the engine can correctly set up SDL state as it does for official Valve games. BUsesSDLInput only considers official Valve games using an app id and client dll path check. Maybe try once with the old DLL first to verify the problem exits and then with the new DLL to test if it's gone.)īut I assume we won't see a fix in Half-Life too soon, since will probably want to wait for a stable SDL2 version I guess i looked into this and i think the solution is as Alfred said above to add a way to hint the engine that SDL is being used.Ĭurrently the engine sets relative mouse mode using SDL_SetRelativeMouseMode if BUsesSDLInput returns true. (You might need to scroll several lines before it reacts, but it should react now. It would be cool if you could test if that DLL file or your own compiled version of it (rename the original one for backup and don't join any VAC servers while using the modified one), solves the mouse issue in default settings (I mean with the driver normally installed where you got the problem). no XAUDIO2 support, because I don't have enough harddisk space to install the DirectX SDK.compiled as /MT (not /MD), just as Valve probably does. However that version differs form the hg version as follows: In case you can't download compile it yourself (has a VC 2010 Express Edition project inside), I put together a compiled version of the SDL2.dll at rev d8fb783475d5 here. Short motion = GET_WHEEL_DELTA_WPARAM(wParam) / fixed the bug in SDL2 in the hg repository. FIXME: This may need to accumulate deltas up to WHEEL_DELTA (The post linked above, might also contain solutions for you )Īnd I looked into the SDL2 code to find this in SDL_windowsevents.c However, the Intellipoint software causes mouse wheel events with smaller "delta" value (the expected finer grain control), and programs which use the 120 value that way just fail to register the wheel movement, because in integral values, 30 / 120 = 0… Since then, several programs use that value directly to test whether the mouse has been scrolled down or up (delta / 120 = 1 -> down, delta / 120 = -1 -> up, or something like that). This is an arbitrary value that has been chosen by Microsoft in the past to allow finer control. Most (almost all) mouse drivers cause mouse wheel events with a "delta" of ☑20. As noted, nVidia implements it pretty well, whereas AMD does not.Mousewheel not working might be due to the following: Hardware drivers have to implement support, but can do this however they please. I've been reading up about OpenGL's history and they explicitly note that immediate mode is a deprecated feature kept in the API for backward compatibility only. My guess is that all the state changes undergo tremendous amounts of conversions through the graphics driver to suit the average modern graphics card, turning the CPU into a bottleneck. The graphics engine, "GoldSource", uses this API in an old-fashioned way ("immediate mode") which does not suit modern graphics card architectures at all. I guess nVidia were just nicer when it came to retaining strong compatibility with older software."įirst to clear things up, OpenGL is just an API to perform rendering on the graphics card. I did ask AMD about this but they blamed the games (GoldSrc and Minecraft), due to them not making the best use of a modern OpenGL API. I have exactly the same issue with my AMD R9 280X, where as my (years older) nVidia GTX 560Ti handled Sven Co-op and Minecraft much faster. You can experience the same issue in Minecraft (before 1.8), as that was entirely using immediate mode OpenGL too. AMD (and ATI) GPU's have bad performance issues with immediate mode OpenGL, whereas nVidia GPU's handle this much quicker. The OpenGL in GoldSrc (and all other OpenGL games of the time) were executing OpenGL instructions in immediate mode, meaning that everything to be drawn on screen must be sent to the GPU and redrawn every frame - the GPU forgets everything when it comes to rendering the next frame. "The GoldSrc engine was written long before modern graphics programming techniques such as vertex buffer objects were around. I think this is the cause of the FPS drop:
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |