IronHorseDeveloper, QA Manager, Technical Support & contributorJoin Date: 2010-05-08Member: 71669Members, Super Administrators, Forum Admins, Forum Moderators, NS2 Developer, NS2 Playtester, Squad Five Blue, Subnautica Playtester, Subnautica PT Lead, Pistachionauts
edited July 2014
@Roobubba
lol thx, but it doesn't really have much to do with aim if you look at that first set of detailed pics..
You can aim center mass and still miss a healthy chunk of bullets thanks to that record breaking tight hitbox / small bullet width - and this isn't even counting the other contributing points previously brought up like issues with transitional animations, dark, busy environments, player warping and netcode, and flinch animations.
I am just bringing up an old discussion because i believe it still has merit and can be worked on more.
Try messing with those values in clipweapons.lua, you don't have to use the one i did. (remove rifle spread first in rifle.lua for testing the width)
I bet you'll agree it feels better to increase that value when you shoot skulks, even with using your aim instead of my own. (after you reinstate the rifle spread ofc)
in NS2 there is a delay to a button being pressed so the game feels laggy. back in NS1's jetpack i could fly around the map without stopping no problem.
Input lag can be caused by poor framerate - in NS2 AND NS1. Since NS2 is more demanding than NS1, I'm guessing that's your issue. It's not poor design, you just need a better machine.
Input lag can be caused by poor framerate - in NS2 AND NS1. Since NS2 is more demanding than NS1, I'm guessing that's your issue. It's not poor design, you just need a better machine.
Bullsnot. In a well coded engine, input lag is almost non-existant at a mere 60 FPS. In NS2 it is a problem well north of 100 FPS and almost unplayable at 60 FPS. There is no fix for it. A common cause for input lag in games is rendering too many frames ahead or some kind of hidden mouse smoothing that you must dick around in config files to turn off.
Turning on DX9 and setting the max renderahead frames / prerender limit (what it's called depends on whether you have an ATi or NVidia card) to 1 perhaps reduces input lag slightly, but not enough so that I could tell the difference. I would say 100 FPS in NS2 feels like 30 FPS in NS1, aiming wise (it obviously looks a lot smoother, but games are not a spectator sport!).
The good news is that halving the input lag should be a LOT easier than doubling the game's performance, and provide almost the same benefit to as many people (yes, it won't LOOK smoother, but it will still be more playable).
It's arguable whether NS2 is more demanding than NS1. The quake / HL engine was designed for a different era, and used slow and expensive legacy functions like GL_polygon. It seemed to demand a better CPU on every new generation of graphics. NS1 would rarely keep pegged to 100 FPS during the action, and would refuse to go above that without developer mode. It often dipped below 100 FPS. HL recieved an update in 2013 or 2014 that fixed these issues and now it can rock 500 FPS during the action without breaking a sweat. Had they released that update in 1999, it would have been a pretty decent improvement; you could compare the performance of Quake 3 versus HL even then, and it was a big difference in polygon pushing power (factor of a few) and it escalated rapidly after that. I'm not sure why VALVe suddenly felt the need to fix an issue a decade and a half too late, but it's better than nothing, I suppose?
Comments
lol thx, but it doesn't really have much to do with aim if you look at that first set of detailed pics..
You can aim center mass and still miss a healthy chunk of bullets thanks to that record breaking tight hitbox / small bullet width - and this isn't even counting the other contributing points previously brought up like issues with transitional animations, dark, busy environments, player warping and netcode, and flinch animations.
I am just bringing up an old discussion because i believe it still has merit and can be worked on more.
Try messing with those values in clipweapons.lua, you don't have to use the one i did. (remove rifle spread first in rifle.lua for testing the width)
I bet you'll agree it feels better to increase that value when you shoot skulks, even with using your aim instead of my own. (after you reinstate the rifle spread ofc)
Input lag can be caused by poor framerate - in NS2 AND NS1. Since NS2 is more demanding than NS1, I'm guessing that's your issue. It's not poor design, you just need a better machine.
Bullsnot. In a well coded engine, input lag is almost non-existant at a mere 60 FPS. In NS2 it is a problem well north of 100 FPS and almost unplayable at 60 FPS. There is no fix for it. A common cause for input lag in games is rendering too many frames ahead or some kind of hidden mouse smoothing that you must dick around in config files to turn off.
Turning on DX9 and setting the max renderahead frames / prerender limit (what it's called depends on whether you have an ATi or NVidia card) to 1 perhaps reduces input lag slightly, but not enough so that I could tell the difference. I would say 100 FPS in NS2 feels like 30 FPS in NS1, aiming wise (it obviously looks a lot smoother, but games are not a spectator sport!).
The good news is that halving the input lag should be a LOT easier than doubling the game's performance, and provide almost the same benefit to as many people (yes, it won't LOOK smoother, but it will still be more playable).
It's arguable whether NS2 is more demanding than NS1. The quake / HL engine was designed for a different era, and used slow and expensive legacy functions like GL_polygon. It seemed to demand a better CPU on every new generation of graphics. NS1 would rarely keep pegged to 100 FPS during the action, and would refuse to go above that without developer mode. It often dipped below 100 FPS. HL recieved an update in 2013 or 2014 that fixed these issues and now it can rock 500 FPS during the action without breaking a sweat. Had they released that update in 1999, it would have been a pretty decent improvement; you could compare the performance of Quake 3 versus HL even then, and it was a big difference in polygon pushing power (factor of a few) and it escalated rapidly after that. I'm not sure why VALVe suddenly felt the need to fix an issue a decade and a half too late, but it's better than nothing, I suppose?