- Tech Member: Tech Members
- Active Posts:
- 1656 (0.43 per day)
- Most Active In:
- Engineering & Reverse Engineering (335 posts)
- 11-January 03
- Profile Views:
- Last Active:
- Yesterday, 11:02 PM
- Member Title:
- 24 years old
- May 18, 1989
- National Flag:
- Wiki edits:
Posts I've Made
18 June 2013 - 04:40 PMY is on Green because it there is Sync on Green connection and Y is probably only of the 3 DACs that can do sync insertion. In SCART RGB connection sync comes from the composhit signal though...
You misread the addendum. Y *should* be on Green. On the Wii, it's actually on Red.
Pin 3: Composite (PAL/NTSC; disabled when using component)
Pin 7: Red (PAL), Y (NTSC S-Video), Y (component)
Pin 9: Green (PAL), C (NTSC S-Video), Pb (component)
Pin 11: Blue (PAL), Pr (component)
18 June 2013 - 03:08 PMDo GC component cables output higher resolutions ? If so then that explains why the internal DACs are not used to make the component signal.
It allows for 31.47 kHz (aka "480p"), in addition to 15.6/15.734 kHz.
The only reason they insisted on a second cable was because there wouldn't be any way for the system to tell if a component cable was connected to the regular AV port, since it doesn't have any mode sense pins. It's a rather stupid reason to add a whole other video port that requires an external DAC though, especially since they could have just added an extra 'pin' somewhere else in the connector, similar to USB 3.0.
Addendum: On the Wii's AV port, the "RGB" lines are mapped directly to "YPbPr" when a component cable is connected, rather than using the logical order of mapping Y to G, Pb to B, and Pr to R. No idea why.
14 June 2013 - 12:09 PMAlso if you are thinking C++ is faster than C# or Java in games, well... no. If you spend the same amount of time working on both native and managed version, the managed version is going to perform faster because you spent more time actually working on your algorithms. And the games are never going to be CPU bound unless there is something fundamentally wrong with your code.
And then you realize that both C# and Java end up wasting at least twice as much memory as an equivalent C++ program. Also, good luck using C# on anything that isn't Windows. (Mono doesn't cut it for most things.) Not to mention that neither C# nor Java use the system's native UI. (Java has a poor emulation of Win32 and GTK+ themes. C# uses WinForms, which also attempts to approximate the Win32 theme, though it uses non-native Office 2003-style menus,)
12 June 2013 - 10:33 PMNew screenshot!
Files highlighted in yellow were found in "empty" blocks. The timestamps are obviously all wrong, since the timestamp data is stored in the file table (which is wiped when the card is formatted). I'll eventually implement modifiers to recover part of the timestamp if they're present in the file description; otherwise, it will default to the current time.
The "Save" and "Save All" buttons don't work yet. (I've tested the save files by saving them manually using debugging code.)
12 June 2013 - 03:48 PMThat was a really neat interview. The most interesting part to me is that Lost World was originally being made for PC.
It was being made on PC, not for PC. Like, before they knew exactly which platform it would be going to. I think Sonic Team does a lot of their development on PCs first.
This shouldn't be a shocking revelation. PCs are the primary development platform for pretty much all embedded devices, including consoles. I don't know of a single console (past or present) where developers had to run the compilers directly on the target system instead of running the compiler on a PC.
(Sidenote: Nintendo used to provide GCN emulation libraries that provided things like the GX API for Windows, which developers could use to test a GCN game without having to set up the development hardware. Obviously it wasn't as thorough as testing it on the real thing, but it was probably more convenient.)