I dont play hidden tho ;_;
Could stretch the statement to simply DTHR maffalda and wouldn't be able to disprove the statement.Kheldragar wrote:
Define "possible to play" because I can stretch that to mean I could play Maffalda DTHRNF.Kaoru wrote:
BTW, it's possible to play ar11 on 60hz.
If you use raw input and a mouse with 1000hz you would need atleast 1000fps or else you will have inconsistent mouse tracking. Turning off raw input and applying mouse fixes seem to solve this issue.[MY] yummy90 XP wrote:
As what Endaris have mentioned, according to this table
with a 60Hz you get an input delay of 0.01666666 seconds which is about 17 ms which is way below the requirement for ar10 (450)Higher hz only helps with eyestrain and games with alot of motion which standard isnt. Suck less and play morealso I find this thread on steam quite informative
As for fps, most people would say that 240 fps is more than enough anything higher would be hardly noticeable but good to have
This is stupid and not trueZenithPhantasm wrote:
If you use raw input and a mouse with 1000hz you would need atleast 1000fps or else you will have inconsistent mouse tracking. Turning off raw input and applying mouse fixes seem to solve this issue.
game logic != input interruptsZenithPhantasm wrote:
Its a known fact that game logic only runs at the same rate as fps.
Interrupts are still handled by a kernel-level driver, not the game. Raw input simply bypasses OS postprocessing, if there's anyZenithPhantasm wrote:
Sure if it was over PS/2. But USB is polled and I doubt the vast majority of osu players use PS/2 mice and kb.
You're underestimating the capacity of people to fuck things up, I'm sure there's a waybigfeh wrote:
Having a higher polling rate will never affect how precise or responsive the game is, no matter how retarded the code gets
I might be, surePhilosofikal wrote:
You're underestimating the capacity of people to fuck things up, I'm sure there's a waybigfeh wrote:
Having a higher polling rate will never affect how precise or responsive the game is, no matter how retarded the code gets
Rip peppyZenithPhantasm wrote:
Someone should get Tom in here since he is the only one that actually knows how the game works.
If you switch directly between hardware with 150hz polling rate and 1000hz polling rate the input delay is noticeable. I have tested it firsthandbigfeh wrote:
Interrupts are still handled by a kernel-level driver, not the game. Raw input simply bypasses OS postprocessing, if there's anyZenithPhantasm wrote:
Sure if it was over PS/2. But USB is polled and I doubt the vast majority of osu players use PS/2 mice and kb.
Having a higher polling rate will never affect how precise or responsive the game is, no matter how retarded the code gets
chainpullz wrote:
Game logic and graphics are always run on different threads. What actually pops up on your screen is a snapshot not a live feed. Your fps only determines how frequently snapshots are taken. Taking a snapshot takes a negligible amount of resources in comparison to rendering. Input devices come in on an entirely separate thread as well which is devoted simply to listening for signals from the drivers. If you select raw input you can see what the polling rate is for this (it's pretty disgusting for tablet if you don't already know).
hey, as someone who's in the same position, yeah, I had assumed this at first toochainpullz wrote:
I'm just explaining common practices for pretty much any application with a graphical interface. If you don't want to take my word on it as a software engineer then in my eyes you are a lost cause (not that I keep my hopes up). :p
missed the point, reread the postKaoru wrote:
If you switch directly between hardware with 150hz polling rate and 1000hz polling rate the input delay is noticeable. I have tested it firsthandbigfeh wrote:
Interrupts are still handled by a kernel-level driver, not the game. Raw input simply bypasses OS postprocessing, if there's any
Having a higher polling rate will never affect how precise or responsive the game is, no matter how retarded the code gets
In the case of osu!, you're wrong.chainpullz wrote:
Game logic and graphics are always run on different threads.
felicitousname wrote:
In the case of osu!, you're wrong.chainpullz wrote:
Game logic and graphics are always run on different threads.
http://ask.fm/Tom94/answer/126791631310
Can I quote this?chainpullz wrote:
Tom's reply there is quite vague. Without more specific details I'm not convinced one way or another. I will say this though, it's easy to learn a programming language and be able to write code that does things. Developing software on the other hand is an art form and requires much care.