[ / / / / / / / / / / / / / ] [ dir / animu / ausneets / baphomet / p01 / pinoy / sapphic / sonyeon / vg ][Options][ watchlist ]

/tech/ - Technology

You can now write text to your AI-generated image at https://aiproto.com It is currently free to use for Proto members.
Name
Email
Subject
Comment *
File
Select/drop/paste files here
Password (Randomized for file and post deletion; you may also set your own.)
* = required field[▶ Show post options & limits]
Confused? See the FAQ.
Expand all images

File (hide): 4b1a9209d088701⋯.png (398.64 KB, 580x388, 145:97, ps2.png) (h) (u)

File (hide): 6c95ae1da651fe7⋯.jpg (50.39 KB, 500x583, 500:583, owo.jpg) (h) (u)

[–]

 No.903125>>903138 >>903148 >>903153 >>903183 >>903266 >>903276 >>903302 >>903306 >>903332 >>903348 >>903548 >>903986 >>904042 >>904088 >>912568 >>914604 [Watch Thread][Show All Posts]

What would be the benefit of this in $CURRENT_YEAR?

Its a cute port btw ^_^

 No.903138

>>903125 (OP)

OS installation may not have usb drivers for the newest chipset. In such a case you can use ps2.


 No.903145

only if you want to use a legacy mouse/keyboard


 No.903148>>903154 >>903422 >>904080

>>903125 (OP)

it's faster


 No.903153>>903175 >>903196 >>903986

>>903125 (OP)

Because you can reuse your playstation controller on it. It allows more universality.


 No.903154>>903177 >>903228

>>903148

thats what I heard, but how true is that?


 No.903156>>903196

Using those ports cures you of gay


 No.903161>>903196

If you wanna be autistic and disable USB


 No.903168>>903196 >>903328

It might look cute, but you can't hotplug anything or you'll risk frying your computer.

But at least it means you can use keyboard and mouse with an OS that doesn't have USB driver. Like maybe TempleOS?


 No.903175>>903196 >>903590


 No.903177>>903178 >>903189 >>903192 >>903222

>>903154

PS/2 has lower latency than USB


 No.903178

>>903177

This & it was reliable.


 No.903180>>903328

I have a keyboard that uses ps/2. It's nice and I get an extra USB port because of it but it has the problem in that every few months the cable falls out and I have to reboot my computer to make the keyboard work again. This is because ps/2 doesn't support hot swapping. I guess that's just the trade off you make by using it.


 No.903183>>903196

>>903125 (OP)

So, when are you going back to cuckchan? Or any other site?


 No.903189>>903192 >>903196 >>903353 >>904098

I just bought brand new motherboards with a brand new chipset and it still has these fucking ports.

I assumed it's because chinks and shit countries are still using these.

>>903177

i wasn't aware of this.

https://superuser.com/questions/16893/do-usb-or-ps-2-keyboards-respond-faster

>all the USB keyboards tested had a longer effective scan interval (18.77 ms - 32.75 ms) than the PS/2 keyboards (2.83 ms - 10.88 ms).

this also says usb has a limit of 6 key keys that can be down at any one time, while ps/2 has no limit. usb keyboards that want to detect more than 6 keys down at a time have to play games and pretend to be multiple keyboards.


 No.903192>>903321 >>903357

>>903189

>>903177

It largely depends on how the USB is handled. Modern USB 3 is over PCIe IIRC and has a direct path to the CPU eliminating such latencies


 No.903196>>903235 >>903986

File (hide): d1233fa395145e4⋯.jpg (40.07 KB, 466x432, 233:216, pic.jpg) (h) (u)

>>903153

wait, really? I guess u mean original playstation? cause the PS2 (the console), PS3, and PS4 don't use these.

>>903156

*giggles*

>>903168

>you'll risk frying your computer.

really? I heard it won't detect it if you try to plug it in while the computer is on, but I didn't know it could brick your system!

scary

>>903175

meanie!

>>903189

oh cool! That sounds like a really nice advantage, as does >>903161

>>903183

t-they don't like me over there! ;_;


 No.903213>>903266

File (hide): d8d0371a0134f49⋯.jpg (276.51 KB, 1268x1280, 317:320, 1512129934457.jpg) (h) (u)

My keyboard has the superior DIN-5 connector. Have to use adaptors these days.


 No.903222


 No.903228>>903464

>>903154

USB relies on polling to interact with its connected devices and answer their requests.

PS/2 on the other hand has a dedicated interrupt that gains almost immediate attention from the CPU when you press any key; it raises a high priority interrupt flag on CPU (IRQ1), only behind the system timer (IRQ0).


 No.903235

>>903196

Then lurk more until I can't tell.


 No.903266

>>903125 (OP)

>>903213

furfags out


 No.903276

>>903125 (OP)

they use chad interrupts instead of faggot virgin polling, you shouldn't even have to ask this question.


 No.903278>>906410

File (hide): b52543bed67b7a7⋯.jpg (51.1 KB, 1024x832, 16:13, owo.jpg) (h) (u)

5-pin DIN is superior in every way


 No.903302

>>903125 (OP)

Rather than using fucking USB it generates interrupts. It's the patrician way to input text and cursor commands.


 No.903306>>903465

>>903125 (OP)

For me, using PS/2 is a pain in the ass. I use it because I have a "dinosaur" keyboard, an IBM MODEL M. I love this keyboard but it is a little obnoxious to use an active converter if I want to use this keyboard in conjunction with a laptop that isn't from 2002.


 No.903321>>903328 >>903467

>>903192

No keyboard or mouse would use USB3, at least not any non-RGB gaymer models desperate for a gimmick.

I'd be surprised if some aren't still using USB1 chipsets.

`lsusb -v` and check bcdUSB


 No.903328>>903593 >>914397

File (hide): c6a430d5dfedb69⋯.jpg (13.28 KB, 500x380, 25:19, ADB-Stecker.jpg) (h) (u)

>daisy chain topology, no need to use hubs for up to 16 devices per port

>can send cold power signal directly to PSU through dedicated pin

>software stack support for hotswap, could've been made hotswap safe with a simple redesign (and actually was in the very final G3 mobos

>price and pin-count same as dumb busses

Still using my Extended II via ADB/USB adapter

>>903168

>>903180

Note that while nearly all older PS/2 interfaces and devices aren't hotplug safe, many newer ones actually are. Another problem is that even if it's safe to hotplug, the software might not recognize a hotplugged device.

>>903321

Newer USB standards don't just increase speed, but offer other changes that are helpful even in slower modes. That said, yeah, I very much doubt anybody will make ultra-low-latency USB3 gaymur keyboards.


 No.903332

File (hide): 605f177b39b34fe⋯.jpg (18.8 KB, 500x282, 250:141, dd.jpg) (h) (u)

>>903125 (OP)

thanks doc


 No.903348>>903387

>>903125 (OP)

>What would be the benefit of this in $CURRENT_YEAR?

it's 10x cooler than vinyl, OP


 No.903353>>903422

>>903189

>i wasn't aware of this.

>https://superuser.com/questions/16893/do-usb-or-ps-2-keyboards-respond-faster

>>all the USB keyboards tested had a longer effective scan interval (18.77 ms - 32.75 ms) than the PS/2 keyboards (2.83 ms - 10.88 ms).

>usb has a limit of 6 keys at one time

Don't get usgayed. 1/10th to 1/16th the lag sounds pretty comfy anons


 No.903357>>903388

>>903192

USB has to be polled, PS/2 sends an interrupt command directly to the CPU.

I don't think it's possible to be faster than PS/2


 No.903387

>>903348

anything would be cooler than vinyl

because vinyl is useless crap with shit objective audio quality (only placebophiles will tell you they hear muh analog purity etc, which is obviously bullshit if you start doing any real comparison with the scientific methodology)


 No.903388>>903448 >>904413

>>903357

>I don't think it's possible to be faster than PS/2

it can be made arbitrarily close to make the difference disappear in measurement noise.

500Hz polling for mice is pretty common btw.


 No.903406

reported


 No.903422>>903445 >>903449

>>903353

>>903148

is the port faster or the keyboard itself?

I have a PS/2 mouse/key to USB. Do thinkpads have PS/2?


 No.903445>>903456

>>903422

http://www.burtonsys.com/ps2_chapweske.htm

don't know how reliable but this seems reliable enough.

device generates the clock speed

clock speed must be 10 - 16.7 kHz.

8 bits of useful data per cycle

max speed

16.7*1000*8 = 133600b/s = 16700B/s = 16.7kB/s


 No.903448>>903562

>>903388

Yes you can make it close insofar as input latency but the CPU can still decide to ignore the USB input, unlike PS/2.


 No.903449>>903456

>>903422

by faster it means the latency is lower because ps/2 generates an interrupt on the cpu, while the host has to poll a usb device


 No.903456>>903548

>>903449

>>903445

Oh. I should find a laptop with PS/2 then. Isn't laptop's keyboard also the same since it's not

USB?


 No.903464

>>903228

Unless you're running your programs on bare, OS-less metal (or under DOS, which is effectively the same thing), the keypress still has to bubble through the OS driver stack to the running application. Typically, this means the interrupt will simply save the new state somewhere, which is then polled by higher layers whenever the app is ready to receive input. You lose most of the advantage this way.


 No.903465

>>903306

>IBM MODEL M

Patrician taste, anon.


 No.903467

>>903321

I would actually love a kb with an integrated USB3 hub.


 No.903548>>903635

>>903125 (OP)

No latency, detects more keys at once, uses less power, no drivers needed.

>>903456

Laptop keyboards are usually connected over a PS/2 port, though a lot are using a USB-like interface nowadays.


 No.903562>>903568

>>903448

>CPU can still decide to ignore the USB input, unlike PS/2

CPU can decide to ignore anything if the software instructs it so.

bullshit argument tbh.


 No.903568>>903638

>>903562

>CPU can decide to ignore anything

Non-maskable interrupts also?


 No.903590

>>903175

#triggered


 No.903591>>903598 >>903635 >>904504

time to take a few guesses to my own question

why was ps/2 depreciated

ps/2 peripherals were depreciated due to

A. port design that is easy to break and twist due to lonely pins

B. relatively large for a connector with few contacts

C. bulky

D. not able to be used for non-peripherals

but I still don't understand why they didn't remain popular for >muh esports, since ps/2 connector on high end peripherals were manufactured at some point


 No.903593

>>903328

It looks like some people are building specialist USB3 HID devices. These seem to be meant for industrial controls, although I have no clue why they went with USB3 in this specific case - the provided software seems to just behave like a normal USB keyboard.

http://xkeys.com/xkeys/xk3swi.php

I also noticed a few folks with broken English looking for information on setting up hardware for this mode. USB3 keyboards are coming...


 No.903598>>903635 >>903700

>>903591

> I still don't understand why they didn't remain popular for >muh esports

They can't have macros, and le gaming laptops usually didn't have a pair of PS/2 connectors, and they seldom have even a single one anymore.


 No.903629>>903704 >>904149

My keyboard came with a USB to PS/2 adapter, would it be worth it to use it?


 No.903635>>903813

>>903548

>uses less power

So no RGBs.

>>903598

>They can't have macros

So no proprietary keys.

>>903591

>port design that is easy to break and twist due to lonely pins

First actual good reason.


 No.903638

>>903568

it still won't magically know what to do.

and then it's up to software to choose.

I can write a trivial program that will ignore every other keypress, for example.


 No.903700>>903701 >>904148


 No.903701

>>903700

they belong to the software side

macros in peripherals are 100% cancer


 No.903704>>903706 >>903708 >>903741 >>904413 >>912520

>>903629

i seriously doubt most people are going to be able to perceive the difference between 2ms and 30ms for a keypress.

your also going to gain ms in that adapter.

another point, forgetting the monitor's actual response time, a 60hz refresh rate is 16ms. if the keyboard response is under the refresh rate it's especially not going to make any difference. though gaymers claim to notice a difference between 60fps and 120fps on a monitor that only displays 60fps.


 No.903706

>>903704

> if the keyboard response is under the refresh rate it's especially not going to make any difference.

Not necessarily, there is latency in e.g the computer too.


 No.903708

>>903704

the latency adds up, there are many possible causes of more latency, and when it crosses a certain threshold, you will just suck balls at gaming because of poor reaction time and incoherence of your own motions (lack of proper visual feedback)


 No.903710>>903715

Is there a good way to measure input latency without having a high speed camera?


 No.903715

>>903710

120 FPS is not high speed but it's present in almost every smartphone.

that leaves you with ~8.33ms of error for single measurement.

depending on your goal, that may be sufficient.

BUT, even if it isn't, you may retry and average.

the measurement error will be random and will mostly cancel out.


 No.903717>>903722 >>903878

I have always heard this meme about PS/2 allowing unlimited simultaneous keypresses but that doesn't seem to be the case for me. It seems like after 5 or 6, any more will depend on the specific key I'm pressing. Although I'm not sure when you'd ever need to press more than 3 or 4 at once anyway.

I do use a PS/2 keyboard but I think it doesn't really matter unless you have a specific need for it.


 No.903722

>>903717

considering it's a USB device it should be trivial to get around that limitation with a driver.

the benefit that I see here is because of the interrupt if the cpu is under heavy load and not polling the usb as often as it should be, then the keyboard should still go through.


 No.903741>>903745 >>904413

>>903704

but I use a 144Hz monitor for coding. The difference between 2 and 30 milliseconds is huge. Regular people can definitely feel a difference.


 No.903745>>904150

>>903741

>2ms

What are you, a keyboard virtuoso?

I use 10ms buffers with jack for midi controllers and never feel any lag until 20 ms.

30ms < 1000ms/60hz.

Why does /tech/ hate throughput?


 No.903813

>>903635

>no RGBs

that's the best part


 No.903878>>904090

>>903717

Doesn't the keyboard itself need to support >6 keys as well? So you'd need a keyboard that supports it with a PS/2 connector. Or am I wrong? I don't know a whole lot on the subject, because I've not played a lot of PC-only games that require many keys pressed simultaneously.


 No.903895>>903982 >>904029 >>907193

File (hide): d56072f3860427a⋯.jpg (4.28 MB, 4000x3000, 4:3, IMG_20180401_180814.jpg) (h) (u)

File (hide): e7118cba87c6960⋯.png (637.77 KB, 1000x1070, 100:107, bird.png) (h) (u)

I use the PS/2 port for my Model M


 No.903982

File (hide): 7afc19854a74ed7⋯.jpg (27.59 KB, 500x491, 500:491, neat.jpg) (h) (u)


 No.903986>>904029

File (hide): a0241bc132aadb8⋯.webm (1.12 MB, 640x360, 16:9, The Simpsons Marge gets m….webm) (h) (u) [play once] [loop]

>>903125 (OP)

>^_^

>>903153

>tripfag

>>903196

>*giggles*

>u


 No.904029

>>903986

I love u! ^.^

>>903895

Cool desktop


 No.904042

>>903125 (OP)

>>903125 (OP)

there is a great virgin/chad meme of this


 No.904080>>904101 >>914394 >>914398

>>903148

wow tech is full of larpers isn't it?

PS2 polls around 125Hz to 200Hz at best, USB can go to 1Khz+. So no, its not faster. It *may* have had a perceived advantage of being tied directly to an interrupt but in reality there doesn't seem to be any real world plus to this.


 No.904088

>>903125 (OP)

ps/2 can handle unlimited key presses at the same time, but usb can only handle 4.

usb also has to share bandwidth with other usb devices so its slower than ps/2 because it's waiting its turn.


 No.904090

>>903878

You may be right. The keyboard itself is PS/2 though, I'm not using an adapter or anything. But it may be a limitation in my device rather than in the connector itself.


 No.904098

For everyone asking about simultaneous keypresses, what you want is NKRO (N-Key RollOver), which while it can be implemented easier on PS/2, is also possible over USB with workarounds (usually, as >>903189 said, by pretending to be multiple keyboards). See here for a full overview of the subject:

https://deskthority.net/wiki/Rollover,_blocking_and_ghosting#n-key_rollover


 No.904101

>>904080

you have some evidence to back that up or are you just going to be a nigger?


 No.904102

Simultaneous inputs of 104 keys any and all combinations of key presses registered with 100% accuracy.

USB can do 6 at a time then stops taking inputs.


 No.904148

>>903700

Didn't specify it, but I referred to mice.


 No.904149

>>903629

for NKRO, yes


 No.904150

>>903745

>why do we hate throughput?

excessive throughput is wasted electricity and bloat


 No.904317>>906314

Do PS/2 Mice have the same advantages as keyboards? And is it worth it to use one of those cheap adapters?


 No.904413>>904415 >>905498 >>906250

>>903388

>500HZ

>every input has delay between 0ms and 2ms

great.

>>903704

30ms probably _is_ a problem.

>another point, forgetting the monitor's actual response time

LCDs are now in the 1-4ms range, according to sites like TFT Central

>a 60hz refresh rate is 16ms.

It's not so simple. On a CRT with vsync, the top left pixel has 0ms latency and the bottom right has approximately 16ms. An LCD is exactly the same except you now have pixel response time as well as display input latency added to this.

>if the keyboard response is under the refresh rate it's especially not going to make any difference.

Input latency is strictly _added_ to end-to-end latency.

>though gaymers claim to notice a difference between 60fps and 120fps on a monitor that only displays 60fps.

I just started timing this recently. It becomes impossible to aim consistently in an FPS when vsync of any type (double buffered, triple buffered (OpenGL), FIFO vsync (also called "triple buffered" by D3D)) is enabled in any game (aside from maybe beam racing, but i doubt any modern TPS/FPS has this). Double buffered vsync normally adds around 16 to input latency (it cannot add more, but it can add less for example if the game does some heavy computation before input in each frame), and this already makes the lag unbearable from my experience. Contrary to 99% of retards on the internet, vsync doesn't add input lag "because it locks the framerate" - locking the framerate to 60 on 60HZ feels much better (and looks much worse) than 60HZ vsync.

Again:

>though gaymers claim to notice a difference between 60fps and 120fps on a monitor that only displays 60fps.

Again, it's not so simple. At 120FPS on 60HZ, you will usually see one half of frame A and half of frame B, and the tear between the two frames will move around depending on how far off your timer is from the monitor's clock (it's always off, even on high resolution timers).

Now what I want to test is whether 60FPS on 60HZ is as good as 120FPS on 60HZ. The main issue with this is that if your game is locked to 60HZ, the tear will noticably move up and down the screen (as the framerate fluctuates and didn't have a true 60HZ period equal to the monitor in the first place). I feel like this makes it harder to aim in many cases. But I think even increasing the framerate a tiny bit (61FPS for example) on 60HZ already remedies this because the tear moves so fast that it becomes negligable (aside from the game still looking like shit as it always will without vsync). So far I have been unable to tell the difference between 120FPS at 60HZ and 65FPS or so at 60HZ.

Having a framerate _less_ than the refresh rate is certainly bad though, because it causes stutter and increased motion blur. On that topic, 120HZ screens have half the motion blur of 60HZ (one of the only true advantages of 120HZ). Pixel response time has not been a significant cause of motion blur for LCDs for a long time now - instead it's mainly caused by the fact that the LCD displays one image for a period of time before showing the next (as opposed to CRT which shows any part of the image for a tiny amount of time (<1ms). This type of motion blur is much worse than any pixel response based motion blur of the last 10 years, and even on 120HZ or 240HZ it still looks like shit. But the reduced blur on 120HZ is actually noticeable so that may be one of the reasons gaymers are thinking 120HZ feels better.

>>903741

I use a 240HZ monitor for showing the standby screen.


 No.904415

>>904413

>>another point, forgetting the monitor's actual response time

>LCDs are now in the 1-4ms range, according to sites like TFT Central

wait, I thought you're talking about display latency, but both display latency and pixel response time are said to be this low now.


 No.904504

>>903591

>why was ps/2 depreciated

For me I always assumed it was because USB is so versatile and you could plug fucking anything into those ports, and because USB ports are so commonly manufactured, at some point it probably became cheaper to just use those.


 No.905080>>905512 >>906383

File (hide): c4721250c5b0050⋯.png (9.61 KB, 512x964, 128:241, m.png) (h) (u)

It's damned easy to code for.


 No.905493

>>905490

also in quake 3 it is somewhat common to always look slightly below normal, unless you specifically expect some this happening above you.

as without vsync you will get the upper parts of screen earlier than the lower parts, this will again improve your reaction time.

(it combines naturally with some aspects of the correct usage of rocket launcher too)


 No.905494

>>905490

fucked up while editing

>unless the game uses some retarded this

replace with

>unless the game uses some retarded shit


 No.905498>>906250 >>906396

Shit, I somehow messed up with deletion password.

Here's normal version of my text, mods please kill my previous 2 replies and I promise to be a good boy and not to do this shit again.

>>904413

>So far I have been unable to tell the difference between 120FPS at 60HZ and 65FPS or so at 60HZ

Not sure if it depends on a game but I can tell difference between that in all flavors of Quake 3 that I played, and also between 120 FPS and 200+ FPS at 60Hz too.

The difference is in the average display latency (and I'm very sensitive to visual latency) and the tearing looks uglier with less FPS, and also it has super ugly spots when FPS is close to being a multiple of the refresh rate or even refresh rate/2 (60, 90, 120, 180)

In Quake 3 latency basically trumps everything else, if you need to improve your game you need to make the latency as low as possible.

In many other fast games it is going to be the same (unless the game uses some retarded this to always force some minimal latency so that improving further from somewhere is intentionally made impossible, but I won't play that shit, it's the same level of retardation as locking the FPS to 30)

also in quake 3 it is somewhat common to always look slightly below normal, unless you specifically expect some this happening above you.

as without vsync you will get the upper parts of screen earlier than the lower parts, this will again improve your reaction time.

(it combines naturally with some aspects of the correct usage of rocket launcher too)


 No.905512

>>905080

That's some sexy Bit bashing


 No.906250>>906253 >>906397 >>907513

>>904413

>LCDs are now in the 1-4ms range, according to sites like TFT Central

>Pixel response time has not been a significant cause of motion blur for LCDs for a long time now

I wouldn't strictly call that motion blur, as compared with the "sample-and-hold" artifacts you mention later, better terms are "ghosting" or "smearing".

As for LCDs, the official ratings for pixel response are as fantastically insane as their ratings for contrast ratio or viewing angle. Here's some lab photos of what is supposedly a "1ms GtG" panel, displaying over 5 frames of visible ghosting even with carefully tuned overdrive:

https://pcmonitors.info/reviews/asus-vg248qe/#Responsiveness

The only solution to this problem will be with a transition to OLED (or basically anything other than LCD), clearing the way not only to 120Hz displays that actually work, but to displays that approach the 1kHz barrier.

>But I think even increasing the framerate a tiny bit (61FPS for example) on 60HZ already remedies this because the tear moves so fast that it becomes negligable

Isn't the correct approach exactly the opposite, capping 1-3 FPS lower than display framerate to substitute for v-sync without lag, in games that can't use 0-flip queue triple-buffering?

>one of the only true advantages of 120HZ

The primary advantage of 120Hz, regardless of blur, lag, ghosting, or stutter, is that your eye gets twice as much data from the game every second.

>>905498

>Quake 3

>framerate

Isn't Quake 3's default physics tied to framerate in some subtly fucked up way?

http://openarena.wikia.com/wiki/Game_physics


 No.906253

>>906250

>Isn't Quake 3's default physics tied to framerate in some subtly fucked up way?

in any reasonable tournament port, such as CPMA, no, they aren't.

it's now all about latency.


 No.906314

>>904317

I think any mouse you find that has a PS/2 plug will have a DPI rate too low to be beneficial overall.


 No.906383>>907185

>>905080


static void kbd_int_handler(void)
{
static uint16_t kbd_recv;
uint32_t data;

data = gpio_port_read(GPIOB) & GPIO9;

kbd_recv >>= 1;
kbd_recv |= data;

if (kbd_recv & 1) {
kbd_recv >>= 1;
char c;
if ((c = ps2_key_parse((uint8_t)kbd_recv))) {
keyq[keyq_head++] = c;
keyq_head &= (KBDQUEUE - 1);
}

kbd_recv = 0;
}
}

less branching version :^)


 No.906396>>906431

>>905498

>the tearing looks uglier with less FPS, and also it has super ugly spots when FPS is close to being a multiple of the refresh rate or even refresh rate/2 (60, 90, 120, 180)

Yeah if it hovers in one spot its very distracting. But I still see the artifacts even far from a multiple of refresh rate at say 320FPS on 60Hz.

>but I won't play that shit, it's the same level of retardation as locking the FPS to 30

But assuming there's some refresh rate that's optimal for humans it may make sense to lock it there. The one big problem with variable refresh rate which pretty much every modern game uses is interpolation of player posistions. I wouldn't be surprised if it turned out in the future that it's better to lock to some constant framerate=tickrate=refreshrate (120Hz? 240Hz?) and remove interpolation.

>also in quake 3 it is somewhat common to always look slightly below normal, unless you specifically expect some this happening above you.

>as without vsync you will get the upper parts of screen earlier than the lower parts, this will again improve your reaction time.

m8, you're explaining how it is with vsync. the screen will look like this (but with a constant added to all lag values - for example 16.66ms with 60Hz double buffering or 0ms with beam racing):

0ms
1ms
2ms
3ms
4ms
5ms
6ms
7ms
8ms
9ms
10ms
11ms
12ms
13ms
14ms
15ms
16ms

Without vsync: Without a real close frame period to the monitor's refresh period, the tear will be a completely new random position every frame. But with an equal period the tear will start in a random position and will be in roughly the same position the entire game, so it can be the exact same thing as the above diagram, or it can be like this:

10ms
11ms
12ms
13ms
14ms
15ms
16ms
0ms
1ms
2ms
3ms
4ms
5ms
6ms
7ms
8ms
9ms

or like this

6ms
7ms
8ms
9ms
10ms
11ms
12ms
13ms
14ms
15ms
16ms
0ms
1ms
2ms
3ms
4ms
5ms


 No.906397

>>906250

>official ratings

the official rating are exaggerated, they're almost always multiple ms lower than the results testers post

careful, pcmonitors guy doesn't know what he's talking about (the only English sites I've come across that seem to be not full of shit are Display Corner and TFT Central). I'll quote some of his misconceptions from [https://pcmonitors.info/articles/factors-affecting-pc-monitor-responsiveness/]:

>[With 120Hz] The monitor also responds twice as frequently to user input updates

No, LCD (ignoring display input lag) and CRT both in fact respond immediately regardless of refresh rate, because (ignoring VBI), it's always updating part of the screen. At 120FPS on 60Hz (ignoring vsync phase) each half of the screen has between 1-8ms of lag.

>https://pcmonitors.info/wp-content/uploads/2013/11/Sampling-comparison.png

No, the "dark phase" (which is completely irrelevant) is the VBI which is only ~1ms out of 16.67 at most. This is actually a big difference.

No, LCDs do not instantly display the frame and do nothing for 15ms, they do the exact same thing as CRT (ignoring added lag values here and there) but pixels stay the same until the beam comes by and updates them.

After rereading this article I'm not sure if he actually thinks stuff works this way or is trying to simplify it, but it's hugely misleading.

>Frames are being held for a much shorter duration and your eyes are being fed a greater number of distinct frames -- as a result, your eye movements are reduced.

>your eye movements are reduced.

That's also not how it works oy vey.

>Scanning or strobe backlights are those that pulse ‘on’ and ‘off’ in much the same way as a CRT,

Scanning would be like a CRT (no LCDs do this), strobing is not, since CRTs do not strobe since they scan out the image slowly over the period of 16.66ms-VBI.

>There are drawbacks to enabling LightBoost. Whilst the fluidity benefits are great if you’re running at a frame rate matching the refresh rate, there is rapid degradation in smoothness as the frame rate dips even slightly below this. In particular stuttering becomes much more pronounced as it isn’t masked by motion blur.

Yeah but now you can actually see more stuff than blobs moving around your screen in an FPS because there's no motion blur. Except this is still slightly wrong, because when a frame is shown twice that can lead to reintroducing smearing or similar bad effects.

Also, PixPerAnn pictures aren't super meaningful aside from proving that pixel response time is less than 1 full frame (if they were 1 frame or longer you'd see two ghosts instead of just one). also camera shutter speed probably comes into play

But yes, as I said, response times to seem pretty low these days, but that still doesn't help much because of "sample-and-hold".

>The only solution to this problem will be with a transition to OLED (or basically anything other than LCD), clearing the way not only to 120Hz displays that actually work, but to displays that approach the 1kHz barrier.

Do you know about strobe reduction black lights? They solve the problem as well. In order to do them properly the backlight should always be off except for a small period of time during the vertical blanking interval (right before displaying the next frame). They can introduce some input delay but at a high enough framerate that shouldn't be an issue. I'd assume this acceptable framerate with motion blur reduction is far less than 1kHz.

>Isn't the correct approach exactly the opposite, capping 1-3 FPS lower than display framerate to substitute for v-sync without lag, in games that can't use 0-flip queue triple-buffering?

I'm not sure what you're saying. Capping the framerate without vsync will always introduce tearing. Capping below the refresh rate means some parts of the screen will show the same frame twice.

>0-flip queue triple-buffering

Are you talking about using the Direct3D with the prerender queue set to 0, or are you talking about OpenGL tripper buffering? The former sounds like lag and/or tearing. The latter has issues with stutter and requires massive refresh rates to reduce your input latency.

>The primary advantage of 120Hz, regardless of blur, lag, ghosting, or stutter, is that your eye gets twice as much data from the game every second.

Yes, assuming that actually makes a perceptable difference. As I said it would reduce "sample-and-hold" smear by half which is a huge effect, but I'm not sure whether there's other big benefits. I've never tried 120Hz yet aside from the CRT days but I didn't pay much attention. At the very least very fast motion would be less likeky to be ruined by only beeing able to see an object for one frame as it crosses the screen.


 No.906410>>906414 >>907418

File (hide): a65900333adb01c⋯.png (157.63 KB, 606x606, 1:1, 9940624300_1429377724.png) (h) (u)

>>903278

It's virtually the same identical shit.


 No.906414>>906420

>>906410

>pin not used

enjoy your bloat


 No.906420>>906430

>>906414

>pins

Clear the shit from your eyes m8.


 No.906430

>>906420

no man should be honest about a din that mini


 No.906431>>906641

>>906396

>m8, you're explaining how it is with vsync. the screen will look like this (but with a constant added to all lag values - for example 16.66ms with 60Hz double buffering or 0ms with beam racing):

this is in practice bullshit for LCD as they change pixels at the same time. it's gonna be all 16 ms.

or otherwise how would you explain the higher latency with vsync?

any kind of vsync adds so much to the average latency it's making quake 3 unplayable.

>>906396

>But I still see the artifacts even far from a multiple of refresh rate at say 320FPS on 60Hz

these are more mild.

of course you'll see some tearing, what I meant is that when the tearing is consistently in one position of the screen or moves slowly across (this is what happens near multiples) then it's nuts.


 No.906463

>shitting on the only thing from PS/2 that ever succeeded


 No.906641>>907147

>>906431

An LCD couldn't possibly change all pixels at once because then it would have to buffer for 16.66ms at 60HZ which an means input lag of 16.66ms, but everyone claims they are down to 1-4ms now. Since (I assume) every type of connection like VGA, DVI, DisplayPort, HDMI uses the same raster scan protocol as original CRTs, you have to spend 16.66 slowly sending the data of the frame to the monitor. So it can either choose to display that data right away, by slowly scanning from top to bottom, or buffer and show it all at once.

>or otherwise how would you explain the higher latency with vsync?

How would _that_ explain the latency for vsync? In double buffered vsync, you render and then call some function like Swap() which waits for VBI (Vertical Blanking Interval, the short period before the next frame where the monitor isn't scanning out any data to screen) and copies your data into the framebuffer (or just swaps pointers). When Swap() returns, you start rendering right away, but it will not copy your data until the next VBI, so your game is sitting there doing nothing from the time it finished rendering to the next frame. This means if you can render in 1ms there's around 16.66ms latency. Direct3D's triple buffering is even worse. OpenGL's triple buffering can be better but has other problems.

With double buffer your code basically looks like this:


while (1) {
Physics();
Input();
Render();
Swap();
}

Even if Physics(), Input(), and Render() finish right away, your frame wont start to be visible until Swap() returns, which is 16.66ms later, giving you 16.66ms input latency at the top of the screen and 33.32ms at the bottom. If Physics() so happens to take 15ms, then your input will only be sampled (Input()) 1.66ms before the monitor starts displaying the result, so you only get 1.66ms input lag at the top and and 18.32ms at the bottom. Of course you could just deliberately delay Input() such that Swap() happens a few microseconds before VBI, reducing the input latency to 0ms at the top and 16.66ms at the bottom, but that requires your game to be real time.


 No.907147>>907513

>>906641

>every type of connection like VGA, DVI, DisplayPort, HDMI uses the same raster scan protocol as original CRTs

only VGA.


 No.907185

File (hide): eeffa0c9ede867e⋯.gif (54.18 KB, 620x549, 620:549, stm32f401-nucleo-pinout3.gif) (h) (u)

>>906383

Ha. That would be a neat hack ...if PB9 was on the LHS of the board and not annexed by the Arduino LCD shield.


 No.907193

>>903895

6/10

+1 if you put lightings behind your screen to reduce eye contrast

+2 if you change into the glorious matte screens


 No.907418>>912554

>>906410

What's the point of having pins they don't use?


 No.907513

>>906250

oops, I (906397) completely misread your comment about response time. Where do you see 5 frames of ghosts though?

https://pcmonitors.info/wp-content/uploads/2013/02/60Hz-Trace-Free-0.jpg

only shows 3 frames

and the worst looking one

https://pcmonitors.info/wp-content/uploads/2013/02/60Hz-Trace-Free-100.jpg

shows 4 frames but

1. you shouldn't use that mode because the overdrive is too broken on it

2. this is likely a photo taken shortly after the new frame began (a few ms at most). no matter how good your response time is, you will always be able to get a photo where the new frame is translucent and the previous frame hasn't fully faded out yet. that's probably what's happening on the leftmost car here as well as the rightmost

if you look at Trace Free=60 or TraceFree=80, they only have one ghost at 60Hz,120Hz, and 144Hz in these pictures. The only way you'll ever get more than 1 ghost at 144Hz for example is if the pixel response is >6.9ms, which according to sites like TFT Central, is pretty much impossible on the most modern LCDs, such as the Asus ROG Swift PG278Q [http://www.tftcentral.co.uk/reviews/asus_rog_swift_pg278q.htm#detailed_response ].

However, these response times are still near 6.9ms which is the limit for 144Hz so I suspect 144Hz is still crap on most modern LCDs, as the screen is almost always displaying two frames.

>>907147

So how do DVI or HDMI work? it still takes time to send (assuming 3 bytes per pixel at 1920x1080) 6220800 bytes (6MB). If we can send an entire image in 1ms, that would mean a transfer rate of 6220800000 bytes (6GB) per second. If you wait for a full image that means more latency. If it took 1ms to do the transfer, then no matter how the electronics is implemented, at 60Hz it would grab your framebuffer once every 16.66ms, and spend 1ms doing so. That means there's a 1ms period of time where you can swap the framebuffer pointer and observe tearing. From my experimentation it simply isn't like that. You can synchronize the main loop timer to the monitor, and the tear will slowly move down (or up) the image and disappear for a short amount of time (presumably because VBI) and reappear at the top (or bottom). Can't remember what configurations I used but I'll try on HDMI and DVI later and see if it does the same.

Also wikipedia seems to imply I'm right:

>DVI does not use packetization, but rather transmits the pixel data as if it were a rasterized analog video signal. As such, the complete frame is drawn during each vertical refresh period. The full active area of each frame is always transmitted without compression. Video modes typically use horizontal and vertical refresh timings that are compatible with CRT displays, though this is not a requirement. In single-link mode, the maximum pixel clock frequency is 165 MHz that supports a maximum resolution of 2.75 megapixels (including blanking interval) at 60 Hz refresh. For practical purposes, this allows a maximum 16:10 screen resolution of 1920 × 1200 at 60 Hz. [https://en.wikipedia.org/wiki/Digital_Visual_Interface]


 No.912520

>>903704

>another point, forgetting the monitor's actual response time, a 60hz refresh rate is 16ms. if the keyboard response is under the refresh rate it's especially not going to make any difference. though gaymers claim to notice a difference between 60fps and 120fps on a monitor that only displays 60fps.

The difference is massive, you massive mongoloid.


 No.912554

>>907418

PS/2 M&K was designed to last forever, the spare pins are for PS/2 2

alternatively, to hold the bugger in place

alternatively, so that the rest of the pins would feel less lonely


 No.912568>>912590

>>903125 (OP)

>Its a cute port btw ^_^

Are you faggots so deluded that you think a literal semicircle of dots in a circle with a couple notches cut into it is cute?

>why am i 3v3n asking? of course you do.


 No.912590>>912592

>>912568

idk, I just think its a lot more unique of a design compared to USB, which has a flat design like everything else out there. You don't really see ports that look like this anymore, and its really colorful and I guess it kinda does look cute idk why but yeah..

To add to the conversation though, with faster new standards like USB-C, do keebs based on that technology have potential to match or beat PS/2? Or is the interrupt-based way always better and that's the end of it?


 No.912592>>912686

>>912590

Even with the new standard USB will never be comparable to PS/2 because of the old polling vs interrupt problem. Concerning the shape of the port itself I also prefer PS/2. USB was an awful standard to adopt because of the way the port is shaped. If it had a notch on one side it would be a non-issue but some genius thought a rectangle was a good idea. Makes it a PITA when attempting to connect something to a port that you can't see (like on the back of a tower).


 No.912686>>912698 >>912731

>>912592

how is usb any worse than ps/2 when you can't see. i remember distinctly reaching around the back of towers and rotating the fucking ps/2 cable back and forth forever to try to get it to go in the damn port. and if you really fucked it up you'd bend the pin and it would never go in, so you would have to straighten them out and try again.

usb only has 1 right position and 1 wrong position.

ps/2 has 1 right position and 359 degrees of wrong position.


 No.912698

>>912686

PS/2 is a bad example but typically you can just twist until it finds it way in. USB ports only have two ways but it seems like you always try the wrong way first. PS/2 is a bad example though and it would benefit from a notch as well. What I mean is they had a chance to correct the issue when USB was becoming a standard but they decided fuck it and went with that design anyway.


 No.912731>>912766 >>912770

File (hide): 44368dbbd2e45d2⋯.jpg (56.83 KB, 1024x576, 16:9, DSC_0021_zps7459c219.jpg) (h) (u)

>>912686

That's why the older 5-pin DIN socket was better. The pins are sturdier, and the cable is easier to plug in than PS/2, as well as much less prone to shorting out if you hotplug. And USB is just an overcomplicated design, just like so many other things in modern computers.


 No.912766>>912774

>>912731

Really? So how would you design a universial serial bus that is truly universal in scope while simultaneously not being overcomplicated?


 No.912770

>>912731

>And USB is just an overcomplicated design

Only USB C is overcomplicated for what it needs to do (its really just a poor mans Thunderbolt tbh), USB 3.0 is complicated but that's because of its need for backwards compatibility.


 No.912774

>>912766

>So how would you design a universial serial bus that is truly universal in scope while simultaneously not being overcomplicated?

maybe being universal is the problem


 No.914073>>914213

File (hide): e3661322e625ed3⋯.png (23.62 KB, 1304x892, 326:223, 1465699321219.png) (h) (u)

Are there any modern mechanical ps/2 keyboards available?


 No.914213>>914228

>>914073

Looks like theres some still being made, usually advertised as "gaming", but they don't have LEDs so they just look like regular keebs.

If you wanna go old-school theres unicomp. They make clones of old IBM keebs like Model-Ms and stuff, and sell with both USB and PS/2 options.


 No.914228

>>914213

Model M's aren't actually mechanical but they are buckling spring. a ps/2 keyboard is nice to have though


 No.914239

for gaymers


 No.914394

>>904080

>fast

>poll rate

there's more to it than that, obviously. if a 1000 Hz input is delayed then a 100 Hz input with no delay is "faster". not saying that is the case with USB.


 No.914397

PS/2 keyboard input is interrupt-based and it allows for key rollovers higher than USB.

It has lower latency, less cpu overhead and it's more reliable.

There's literally no reason to use USB over PS/2 for keyboard input.

PS/2 mouse input is based on a set amount of ticks per second just like USB, so if you're using a mouse stick to USB.

What you should do is plug your keyboard to PS/2 and your mouse to USB.

>>903328

>the software might not recognize a hotplugged device.

That's just windows. Windows doesn't have hotpluggable ps/2 to this day. Any other OS that's still supported does.


 No.914398>>914403

>>904080

>accuses others of larping while larping

okay...


 No.914403

>>914398

>he doesn't know it's all Larpin' Jack Flash on this board


 No.914604

>>903125 (OP)

idk




[Return][Go to top][Catalog][Screencap][Nerve Center][Cancer][Update] ( Scroll to new posts) ( Auto) 5
126 replies | 15 images | Page ???
[Post a Reply]
[ / / / / / / / / / / / / / ] [ dir / animu / ausneets / baphomet / p01 / pinoy / sapphic / sonyeon / vg ][ watchlist ]