Gamecube Digital AV to direct HDMI / VGA mod...

[piratesephiroth]

Yeah, it's also relevant because we get used to the general timing of the movements, for making combos and counter attacks that have already short windows of time to input the command (something like 5 frames or so). Even 10 aditional ms of delay are enough to confuse a player at those situations.

[tueidj]

It's not "10 additional ms of delay", it's 10ms of delay at the most i.e. total. How often do you think the GC controllers are polled?
Reacting to another player in less than 10ms is rather unlikely when each frame period is 16.6666ms, unless you're looking at their hands instead of the screen...

[piratesephiroth]

It's not "10 additional ms of delay", it's 10ms of delay at the most i.e. total. How often do you think the GC controllers are polled?
Reacting to another player in less than 10ms is rather unlikely when each frame period is 16.6666ms, unless you're looking at their hands instead of the screen...

You forget that the games have their own input delay, depending on how they're coded. I remember those CPS2 games with 4 frames of input delay... console versions didn't have that and felt totally different.
Also it's not about lightning fast reactions to single frame attacks, but reacting to/predicting a certain animation and using its timing to strike a precise blow.

[tueidj]

How does the input delay of the game have any relevance when we're discussing different input controllers for one specific game on one specific platform?
If the controller latency is lower than the display latency then obviously you're not going to have a problem anticipating the timing of an animation.

[BenoitRen]

A component to VGA cable gets you VGA. I have one myself and I'm very happy with it. The quality is really good.

A lot of research later due to trying to get VGA out of a PlayStation 2, I feel I need to amend my statement.

What I have is a VD-W2 Wii VGA cable from VDigi. It outputs RGBHV. I suspect that this is cable gets a component signal from the Wii that it transcodes to VGA. This solution is almost as good, if not as good as, native VGA straight from the Wii itself. There certainly isn't a better solution available unless you want to mod your Wii hardware.

[pr0ton]

There certainly isn't a better solution available unless you want to mod your Wii hardware.

Not entirely true. Extrems wrote some code for native VGA, only I couldn't figure things out. There wasn't much interest by then for it, I think: viewtopic.php?f=6&t=881&hilit=+wii+vga

[bronko]

I finally found the time to connect my CPLD-DevBoard to the Gamecube Digital Out and wrote some HDL to decode the digital video signals.

Decoding the 576i PAL output first seemed fine: the framesize I measured was 864x625 @50Hz, however the active video frame oddly came out to be 640x573, according to the blanking intervals.
Then I managed to get some progressive output decoded: measured framesize 858x525 @59.94Hz (this perfectly matches the standard for a 480p signal). But again the active video only had 640x448 pixels.

I don't know if this is maybe specific to the game (tested Mario Golf, only NTSC game I have atm). Maybe other games output true 720x480p active video.

Also, until now I failed to the the video signals onto a screen, I only measured the signals (HSync, VSync, Blanking etc.) using a logic analyzer.

OzOnE:
Did you measure the timings/blanking intervals ?
And in the picture on your first post, it seems you directly connected a HDMI connector to your ribbon cable. Did you drive the HDMI signals using some of the differential FPGA pins ? Where did you get the HDL component driving the HDMI singal ?
I myself tried using another FPGA Board which has a DVI Transmitter chip (however only accepting RGB input), so I tried using the Altera components to get the 8-Bit YCbCr 4:2:2 to 24Bit RGB 4:4:4 and it worked using a pattern generator, but not when connecting it to my decoded Gamecube signals. Maybe because of the odd active video resoultions ? I will try to figure this out next.

[tueidj]

Those active windows look reasonably accurate, the PAL values match the code/SDK exactly but I would have expected the progressive signal to have 480 active lines, so maybe that's just Mario Golf being different.
Games can set the active width up to 720 pixels but most don't, mainly because the internal framebuffer is only 640 pixels and the horizontal scaler handles irregular ratios very badly, it's not worth the effort to do two rendering passes just for 80 more pixels (most of which would probably be cut off due to overscan).

[megalomaniac]

A component to VGA cable gets you VGA. I have one myself and I'm very happy with it. The quality is really good.

A lot of research later due to trying to get VGA out of a PlayStation 2, I feel I need to amend my statement.

What I have is a VD-W2 Wii VGA cable from VDigi. It outputs RGBHV. I suspect that this is cable gets a component signal from the Wii that it transcodes to VGA. This solution is almost as good, if not as good as, native VGA straight from the Wii itself. There certainly isn't a better solution available unless you want to mod your Wii hardware.

you bought a device that converts Wii analog YPBPR output to digital RGBHV...
...and you suspect there is transcoding involved
...and you indicate this option to be as good as native Wii VGA


would you like to amend your statement again??

[bronko]

This is interesting tueidj, I did not know about the 640pixel framebuffer.
Tested some more games today and it seems most of them use 640 horizontal pixel active video.

The full frame size only seems to be different between 50Hz / 60Hz output:
50Hz output: 865x625
60Hz output: 858x525

The active video region is different between most of the games I tested:

Gamecube Dashboard (PAL/50Hz/interlaced): 640x520
Beach Spikers (PAL/50Hz/interlaced): 640x528
Beach Spikers (PAL/60Hz/interlaced): 640x463
Mario Kart (PAL/50Hz/interlaced): 670x535
Mario Kart (PAL/50Hz/interlaced): 666x447
Resident Evil 4 (NTSC/60Hz/interlaced): 640x447
Mario Golf (NTSC/60Hz/interlaced): 640x463
Mario Golf (NTSC/60Hz/progressive): 640x448

All tested on a PAL Gamecube (unfortunately I could not get Resident Evil 4 to output progressive).
Does anyone know about a HDMI Transmitter IC that can process this type of resolutions ? The best would be if it could upscale these resolutions to proper 480p (or higher). Or not scale the active video at all and output it inside a 480p frame with black borders.

[BenoitRen]

you bought a device that converts Wii analog YPBPR output to digital RGBHV...
...and you suspect there is transcoding involved
...and you indicate this option to be as good as native Wii VGA


would you like to amend your statement again??

VGA is an analog signal. Other than that I don't know what to tell you.

[megalomaniac]

think at an IC level...
if there was no conversion involved to get RGBHV, then there would be no need for a digital converter...
..and the IC is not transcoding

[tueidj]

My understanding is that the wii can output either S-Video (Y/C), Component (Y/Pb/Pr) or RGB depending on how the hardware encoder is programmed (since the signals use the same pins), and that's what Extrems' code was forcing (and also why early homebrew came out "red" when a component cable was used - S-Video mode was activated by accident). However "native" NTSC software will only use S-Video or Component, while PAL software will only use RGB or Component... I don't really know what the deal is with that, whether it's purely a software thing or if the hardware actually differs by region.

[BenoitRen]

think at an IC level...
if there was no conversion involved to get RGBHV, then there would be no need for a digital converter...
..and the IC is not transcoding

So what you're saying is transcoders don't exist and are all secretly digital converters?

[ShortFuse]

We're getting off topic but component video is basically sync on green aka RGsB. VGA is RGBHV. A transcoder will just take the H and V information from the green+sync signal and separate it. The transcoding is usually measured in nanoseconds not milliseconds and thus, the lag is considered negligible.

As for latency the latency questions, I'm just going to quote something I posted on reddit

You are right to a point about input latency, but think of it this way. You see everything 10 milliseconds later than if you were to see it on a "0ms lag" set.
The GameCube (as I'm sure you know considering your work on SSBM Online) polls every 16.666ms (60 times per second).
For the sake of understanding let's say the GC would read your inputs at: 0ms, 16.66ms and 33.333ms.
What you input at 7ms would get read at calculated at 16.66ms (the first frame).
If you lag by 10 milliseconds because of "input lag", you would actually input your control data at 17ms which would get read at 33.33ms (the second frame).
Now the argument is, well, no one can honestly react to something in a 10 millisecond window. And that's true, but say you were to power shield an attack. If you consistently play on a set with 10 millisecond lag, you will start inputting things 10 milliseconds earlier. You can be really good at power shielding and then when you play on a set with different lag time (like CRT's 1ms) your timing is messed up.
This happened to me all the time at tournaments trying to reflect Falcon laser spam.
The solution is to standardize all the sets used for competitive play. For Melee, the standard is sub 20" CRTs. They seem to all have the same response time.
For Smash 4 I hope to see 1 or 2 ms LCDs used like SFIV.

[tueidj]

Component isn't RGB, it's YPbPr. You can't connect component to a VGA monitor without a conversion circuit (not just to generate sync which can be easily taken from the composite output, which is always active). When it comes to analog TV signals, only SCART uses RGB.

Your post about input lag has an error, "If you consistently play on a set with 10 millisecond lag, you will start inputting things 10 milliseconds earlier." How can you start reacting to things you haven't seen yet?
Apart from that it explains well about the max latency of the original gamecube controllers (16.666ms) due to the polling period, whereas USB based controllers (like bluetooth) are driven by interrupts with a 10ms max delay.

[piratesephiroth]

Your post about input lag has an error, "If you consistently play on a set with 10 millisecond lag, you will start inputting things 10 milliseconds earlier." How can you start reacting to things you haven't seen yet?

It's more like a desynchronization. You get accostumed to a certain delay so if you play on a faster response set you'll react slower simply because you're expecting the game to respond slower. Also if you play on a slower device you'll start entering commands too soon because you're expecting the game to respond faster.

[tueidj]

Still makes no sense. How can you react at all (never mind "too soon") when the thing you're reacting to hasn't yet happened?

[piratesephiroth]

Exactly. The thing hasn't happened yet, but you know when it's going to happen BASED ON A VISUAL CUE.
Your reaction is to press the button at the precise moment you SEE that thing will occur.

A simple example would be the player having to press a button in a certain rhythm, according to a blinking spot on the screen. If the game accepts input as valid during a 5 frame window, a visual delay of 1 frame (16ms) is enough to ruin the gameplay for a player that's not used to it.

[BenoitRen]

Component isn't RGB, it's YPbPr.

It can do both. It's how VGA works on the PlayStation 2.

[tueidj]

Exactly. The thing hasn't happened yet, but you know when it's going to happen BASED ON A VISUAL CUE.
Your reaction is to press the button at the precise moment you SEE that thing will occur.

A simple example would be the player having to press a button in a certain rhythm, according to a blinking spot on the screen. If the game accepts input as valid during a 5 frame window, a visual delay of 1 frame (16ms) is enough to ruin the gameplay for a player that's not used to it.

Exactly, you react to a visual cue. Meaning it's impossible to react "too soon" to visual stimulation because that would require the TV to have a negative lag - something which physically makes no sense. To use your example it would be equivalent to the player pressing the button before the spot even appears.

It can do both. It's how VGA works on the PlayStation 2.

It might be able to output RGB over the same pins, but that doesn't mean component is RGB. There has to be a setting (either via hardware or software) to choose one or the other, and if it's set to RGB then it's no longer standard component output. The same goes for a wii, if you take a component cable and unjoin the sense pins (I think they're pins 8 and 10) it will output RGB over the components pins for PAL software and Y-C (S-Video) for NTSC software. You also lose the ability to enable progressive output though so it's not very useful for VGA.

[tesla246]

looks like that guy marshall came through on the benheck.com forums.

Anyone knows how to contact him? I dont know how to register there. Does he post on this forum as well?

[piratesephiroth]

looks like that guy marshall came through on the benheck.com forums.

Anyone knows how to contact him? I dont know how to register there. Does he post on this forum as well?

He started to get the n64 adapter ready.

[Ashen]

Here's a handy video guide, I'm sure there are some errors as I made it mostly from memory. But its should be mostly accurate:

http://forums.shockslayer.com/viewtopic.php?f=44&t=137

[ShortFuse]

Still makes no sense. How can you react at all (never mind "too soon") when the thing you're reacting to hasn't yet happened?

Not everything in gaming requires you to react at 0ms. For example, to powershield a Falcon Punch, you could do it based on an audio queue to time L or R the exactly as he said the 'P' in "FALCON PUNCH!". With a video queue that lags, you'll have to input earlier by how much the display lags.

Let me simplify what I mean which something else. If you were to rely on a video, let's say you're playing a stacker type game. In stacker you need to time when a block is above another block. If you were required to input a button frame-perfect exactly, on a set that lags 10ms, you would have to input your button 10ms earlier to what you see on the screen offset the 10ms video lag.