forum

Ar10 reading on 60hz

posted
Total Posts
90
show more
Yarissa
You guys do so many calculations over ar10 and different refresh rates and stuff, how about you don't worry about that and practice the AR more? If it's more difficult after changing playstyles the only real thing you can do is practice it until you can do it again. Posting about it on the forums usually won't help.

BTW, it's possible to play ar11 on 60hz.
Yuudachi-kun

Kaoru wrote:

BTW, it's possible to play ar11 on 60hz.
Define "possible to play" because I can stretch that to mean I could play Maffalda DTHRNF.
buny
except I doubt anybody could actually play maffalda dthr
Yarissa
Possible to play/ pass/ fc maps on a competitive level like EP83
ZenithPhantasm
Why hasn't anyone just suggest learning Hidden? It basically gets rid of the ripples.
Mahogany
Because hidden is bad and you should feel bad
Barusamikosu

Mahoganytooth wrote:

Because hidden is bad and you should feel bad
ZenithPhantasm
I dont play hidden tho ;_;
Mahogany
Recommending it is bad enough
chainpullz

Kheldragar wrote:

Kaoru wrote:

BTW, it's possible to play ar11 on 60hz.
Define "possible to play" because I can stretch that to mean I could play Maffalda DTHRNF.
Could stretch the statement to simply DTHR maffalda and wouldn't be able to disprove the statement.
-Makishima S-
Hidden is ok.
Hard rock is godlike, mod for true warriors and man with balls.
DT is bad 8-)

OD10 is brutal but why not to learn it with taste of CS5.2 / CS6.5 and AR10? Too hard?
E m i

[Taiga] wrote:

Hidden is ok.
Hard rock is godlike, mod for true warriors and man with balls.
DT is bad 8-)

OD10 is brutal but why not to learn it with taste of CS5.2 / CS6.5 and AR10? Too hard?
?y-youtoo?
ZenithPhantasm

[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 more
also 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
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.
bigfeh

ZenithPhantasm 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.
This is stupid and not true

jeez zenny I thought you knew what you were talking about
ZenithPhantasm
Its a known fact that game logic only runs at the same rate as fps.
bigfeh

ZenithPhantasm wrote:

Its a known fact that game logic only runs at the same rate as fps.
game logic != input interrupts
ZenithPhantasm

bigfeh wrote:

ZenithPhantasm wrote:

Its a known fact that game logic only runs at the same rate as fps.
game logic != input interrupts
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.
autoteleology
I don't see how 60 v. 120 frames per second makes any noticeable difference in specifically reading high AR rates. Most of its purpose is to reduce motion blur. Most of what I find 120fps to be good for revolves around being able to track my cursor.

It technically affects lag, but only in that it makes the output more granular (which reduces motion blur) - the real damaging part of lag is when it takes time for the monitor to show a frame that has already been sent out, due to monitor processing. Anyone who has tried to play an input-demanding video game on a shitty flatscreen TV (which can have artificial output lags as large as 100ms) knows what that's like. If you have a decent monitor to begin with, there really shouldn't be that much difference.
bigfeh

ZenithPhantasm 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.
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
autoteleology

bigfeh wrote:

Having a higher polling rate will never affect how precise or responsive the game is, no matter how retarded the code gets
You're underestimating the capacity of people to fuck things up, I'm sure there's a way
bigfeh

Philosofikal wrote:

bigfeh wrote:

Having a higher polling rate will never affect how precise or responsive the game is, no matter how retarded the code gets
You're underestimating the capacity of people to fuck things up, I'm sure there's a way
I might be, sure

but then again game logic isn't tied to (as in won't modify the) input, because input is handled on a lower level
chainpullz
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).
ZenithPhantasm
Someone should get Tom in here since he is the only one that actually knows how the game works.
Yuudachi-kun

ZenithPhantasm wrote:

Someone should get Tom in here since he is the only one that actually knows how the game works.
Rip peppy
chainpullz
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
Yarissa

bigfeh wrote:

ZenithPhantasm 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.
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
If you switch directly between hardware with 150hz polling rate and 1000hz polling rate the input delay is noticeable. I have tested it firsthand
bigfeh

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).

chainpullz 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
hey, as someone who's in the same position, yeah, I had assumed this at first too

and everything is true, except for the "always" up there. afaik, and please don't quote me on this, the game (used to?) run(s) in a single thread, but that's second-hand information I never confirmed. It's kind of a gray area and some acknowledge it, some don't, but it's definitely, well, possible.

I know they're common practices, and they're common practices for reasons that should be obvious to anyone with a bit of technical knowledge and at least half a brain. But you need to understand that, given that this game was written by one guy (others joined later on), as a personal project, from ground up, eight years ago, I wouldn't be so sure it follows any common practices or standards.

Kaoru wrote:

bigfeh 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
If you switch directly between hardware with 150hz polling rate and 1000hz polling rate the input delay is noticeable. I have tested it firsthand
missed the point, reread the post

that's not what I said
felicitousname

chainpullz wrote:

Game logic and graphics are always run on different threads.
In the case of osu!, you're wrong.

http://ask.fm/Tom94/answer/126791631310
ZenithPhantasm

felicitousname wrote:

chainpullz wrote:

Game logic and graphics are always run on different threads.
In the case of osu!, you're wrong.

http://ask.fm/Tom94/answer/126791631310
chainpullz
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.
bigfeh

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.
Can I quote this?

I'm gonna quote this.
Please sign in to reply.

New reply