The fact that one of the bugs still remains from his original/2007/ Month of PHP Bugs shows that the PHP developers are clearly not doing a thorough job.
From the forum thread at CoreAVC discussing this, the founder of CoreAVC says "Again without going into all the details... this is mostly about reverse engineering without permission under the DMCA... by us giving Alan permission.... problem solved".
Without seeing the coreavc-for-linux code I can't say whether or not he had to reverse engineer anything about CoreAVC to get it working, but it doesn't seem like hooking up a DirectShow filter via a (relatively) standardized API would need anything like that. Since this claim was made under the DMCA, he would have had to be reverse engineering something related to copy protection. Perhaps there is some sort of product activation that had to be hacked around to get the codec working on a non-windows platform?
DVD9 layer switches are/slow/, not the sort of thing you want to be doing whenever you load a new file. The only dual-layer PS2 games are linear level-based games that switch layers once at the midway point of the game.
For Oblivion, you couldn't even try to split up the dialog so that certain towns were on one layer and the rest were on the other layer; NPCs can technically go anywhere they want on the worldmap.
There's also the issue of the time investment people make in MMORPGs. If you've spent thousands of hours on getting a single character up the level/item grind curve, it'll take substantially more for you to suddenly switch and start playing another game.
> Incidentally, try using / in a path in the address bar of Windows Explorer in a modern Windows (eg >= 2k). You might be surprised.
Then try using it in a File Open/Save dialog, find that it doesn't work, and notice that it's a one-off hack that I imagine stems from the integration of IE and Explorer...
Some software DVD players disable TV output if they detect that the video card doesn't support Macrovision. (yes, even some high-profile cards had issues with this) Of course, Media Player Classic + hardware overlay mode + full screen overlay video devices = no issues.
Perhaps early on, but all of the "killer app" titles for PS1 used up most of their space with movies. The music was usually synthesized MIDI, not streamed audio files. Recompressing those with MPEG4 and replacing the movie playing code could easily trim all of the huge 4-disc Final Fantasy games down, probably even to less than a single CD.
Same thing with PS2 games. For example, the most recent Onimusha game used about 1.3GB for its game data, the rest was huge high-bitrate MPEG2 movies. I'd even bet that a large portion of that game data was audio in the PS2's inefficient native compression format, which could be recompressed to push it even further.
>We can only wonder how things would have been if Intel had opened things up like IBM has, instead of making it so people have to figure things out on their own.
It's not quite as clean as it looks. "Full specifications" doesn't include any information on instruction latencies, cache performance, etc. They've documented the platform itself, but not the specific implementation. This makes optimization difficult.
I've had to distill information from several publications to determine even basic things like how many cycles it takes to retire a floating point add. So the information/is/ out there, you just need to do a lot of work to get it.
Perhaps they want to avoid the PR troubles that will come up when peoples' new shiny TVs and monitors don't work at their full resolution? It's not really/that/ much money/time.
Microsoft actually supports this method of running executables - the xbox emulator update for the 360 can be installed just by downloading a default.xex from their website and burning it to a DVD. Nothing special there.
Some games stream, some don't. And even games that stream often require an initial loading screen to load in the currently viewable areas.
For a good example, look at everything on the GTA3 engine: it has a long loading screen the first time you start the game, but once that's done you can drive across the entire world without seeing a loading screen. (yes, changing back and forth between interiors and the exterior involves a loading screen, but that's probably so they can dedicate the full resources of the streamer to exterior streaming)
It's a good idea, but it would require something like an internal framebuffer inside the monitor, and delaying the video by at least a half of a frame. CRTs are mostly analog and very simple, so it would need a substantial amount of new hardware to implement.
On the other hand, this means you could put all of this hardware in a seperate box outside the monitor and use it with any video source and any monitor (assuming you put enough memory and fast enough RAMDACs in the box). Sounds like an interesting project.
> Oh yeah, and the fact that, apparantly, you can listen ONLY in shuffle mode - hence the name.
Sorry, no:
"With Play in Order mode, you manage the music. If things take a turn for the predictable, never fear. Turn iPod shuffle over, flip the slider to Shuffle and mix on the go." http://www.apple.com/ipodshuffle/
If he's talking about the Power Macintosh 61xx series, those didn't have software power off. Pushing the button would immediately turn the machine off.
Most of those numbers are based on the fast matrix-multiply operation that the FPU can perform. It was still pretty fast for a console at the time, but the numbers are somewhat unrealistic.
I don't think that this was intended, but installing the memory expansion did crazy things with the frame limiting on Mario Kart 64. If I remember correctly, playing the skyscraper battle level with three players made it run at at least 150% of normal speed. Several of the other levels had similar problems, primarily the Donkey Kong level.
He's going to have some trouble getting a MAME port with only 1-4MB of RAM to work with. Even games with relatively simple hardware go over that easily: pacman needs about 6MB just for the emulator core.
On the other hand, if the graphics chip is thoroughly customizable, we might see some dedicated single-system emulators that use the built-in graphics and are designed with low-memory situation in mind. Could be pretty cool.
A 64-bit PowerPC chip doesn't need to "emulate" anything to run 32-bit code, unlike the Itanium, which uses completely different instructions. There should be no speed hit: the only real difference is that the CPU can perform calculations using all 64 bits.
This also won't remove the speed hit caused by the ABI.
Slashdot Mirror
The PHP developers didn't find these bugs, Stefan Esser did. (see http://php-security.org/)
The fact that one of the bugs still remains from his original /2007/ Month of PHP Bugs shows that the PHP developers are clearly not doing a thorough job.
From the credits list: "Protocase for putting up with hundreds of small 3-D case design tweaks", which I assume is http://www.protocase.com/.
From the forum thread at CoreAVC discussing this, the founder of CoreAVC says "Again without going into all the details... this is mostly about reverse engineering without permission under the DMCA... by us giving Alan permission.... problem solved".
Without seeing the coreavc-for-linux code I can't say whether or not he had to reverse engineer anything about CoreAVC to get it working, but it doesn't seem like hooking up a DirectShow filter via a (relatively) standardized API would need anything like that. Since this claim was made under the DMCA, he would have had to be reverse engineering something related to copy protection. Perhaps there is some sort of product activation that had to be hacked around to get the codec working on a non-windows platform?
DVD9 layer switches are /slow/, not the sort of thing you want to be doing whenever you load a new file. The only dual-layer PS2 games are linear level-based games that switch layers once at the midway point of the game.
For Oblivion, you couldn't even try to split up the dialog so that certain towns were on one layer and the rest were on the other layer; NPCs can technically go anywhere they want on the worldmap.
There's also the issue of the time investment people make in MMORPGs. If you've spent thousands of hours on getting a single character up the level/item grind curve, it'll take substantially more for you to suddenly switch and start playing another game.
For those of you who are bored, you could try to get any of the addresses listed in the web form taken down.
<FORM METHOD="POST" ACTION="http://www2.fiberbit.net/form/mailto.cgi" ENCTYPE="x-www-form-urlencoded">
<INPUT TYPE="hidden" NAME="Mail_From" VALUE="Yahoo">
<INPUT TYPE="hidden" NAME="Mail_To" VALUE="havinfunfun@gmail.com">
<INPUT TYPE="hidden" NAME="Mail_Subject" VALUE="Yahoo id">
I'm sure google would have a fun time going after whoever referred havinfunfun@gmail.com.
> Incidentally, try using / in a path in the address bar of Windows Explorer in a modern Windows (eg >= 2k). You might be surprised.
Then try using it in a File Open/Save dialog, find that it doesn't work, and notice that it's a one-off hack that I imagine stems from the integration of IE and Explorer...
Some software DVD players disable TV output if they detect that the video card doesn't support Macrovision. (yes, even some high-profile cards had issues with this) Of course, Media Player Classic + hardware overlay mode + full screen overlay video devices = no issues.
> I'd like to see it try. The game doesn't have to know you turned on AA. It can't force you to pick "Application controlled".
Perhaps it uses a floating point frame buffer that the hardware can't anti-alias?
Perhaps early on, but all of the "killer app" titles for PS1 used up most of their space with movies. The music was usually synthesized MIDI, not streamed audio files. Recompressing those with MPEG4 and replacing the movie playing code could easily trim all of the huge 4-disc Final Fantasy games down, probably even to less than a single CD.
Same thing with PS2 games. For example, the most recent Onimusha game used about 1.3GB for its game data, the rest was huge high-bitrate MPEG2 movies. I'd even bet that a large portion of that game data was audio in the PS2's inefficient native compression format, which could be recompressed to push it even further.
The entire thing is just an English translation of the original article at Game Watch: http://www.watch.impress.co.jp/game/docs/20051207/ 3dwa.htm. Posted there last year, actually.
>We can only wonder how things would have been if Intel had opened things up like IBM has, instead of making it so people have to figure things out on their own.
/is/ out there, you just need to do a lot of work to get it.
It's not quite as clean as it looks. "Full specifications" doesn't include any information on instruction latencies, cache performance, etc. They've documented the platform itself, but not the specific implementation. This makes optimization difficult.
I've had to distill information from several publications to determine even basic things like how many cycles it takes to retire a floating point add. So the information
Perhaps they want to avoid the PR troubles that will come up when peoples' new shiny TVs and monitors don't work at their full resolution? It's not really /that/ much money/time.
You can do that, just link to an old page in the history: http://en.wikipedia.org/w/index.php?title=Prostate _cancer&oldid=6782986
Microsoft actually supports this method of running executables - the xbox emulator update for the 360 can be installed just by downloading a default.xex from their website and burning it to a DVD. Nothing special there.
i lity.htm
http://www.xbox.com/en-US/games/backwardscompatib
> Also, I am tired of Elves and Orcs so a good Sci-Fi MMO game would be appealing.
Look at the top three races in their poll. I'm not saying that variety is bad, but I wouldn't look for it here.
Some games stream, some don't. And even games that stream often require an initial loading screen to load in the currently viewable areas.
For a good example, look at everything on the GTA3 engine: it has a long loading screen the first time you start the game, but once that's done you can drive across the entire world without seeing a loading screen. (yes, changing back and forth between interiors and the exterior involves a loading screen, but that's probably so they can dedicate the full resources of the streamer to exterior streaming)
Unless your game is streaming something from the hard disk. Like the next room, or dialog, or music, etc.
It's a good idea, but it would require something like an internal framebuffer inside the monitor, and delaying the video by at least a half of a frame. CRTs are mostly analog and very simple, so it would need a substantial amount of new hardware to implement.
On the other hand, this means you could put all of this hardware in a seperate box outside the monitor and use it with any video source and any monitor (assuming you put enough memory and fast enough RAMDACs in the box). Sounds like an interesting project.
> Oh yeah, and the fact that, apparantly, you can listen ONLY in shuffle mode - hence the name.
Sorry, no:
"With Play in Order mode, you manage the music. If things take a turn for the predictable, never fear. Turn iPod shuffle over, flip the slider to Shuffle and mix on the go." http://www.apple.com/ipodshuffle/
If he's talking about the Power Macintosh 61xx series, those didn't have software power off. Pushing the button would immediately turn the machine off.
Most of those numbers are based on the fast matrix-multiply operation that the FPU can perform. It was still pretty fast for a console at the time, but the numbers are somewhat unrealistic.
I don't think that this was intended, but installing the memory expansion did crazy things with the frame limiting on Mario Kart 64. If I remember correctly, playing the skyscraper battle level with three players made it run at at least 150% of normal speed. Several of the other levels had similar problems, primarily the Donkey Kong level.
Of course, this wasn't really a bad thing.
He's going to have some trouble getting a MAME port with only 1-4MB of RAM to work with. Even games with relatively simple hardware go over that easily: pacman needs about 6MB just for the emulator core.
On the other hand, if the graphics chip is thoroughly customizable, we might see some dedicated single-system emulators that use the built-in graphics and are designed with low-memory situation in mind. Could be pretty cool.
A 64-bit PowerPC chip doesn't need to "emulate" anything to run 32-bit code, unlike the Itanium, which uses completely different instructions. There should be no speed hit: the only real difference is that the CPU can perform calculations using all 64 bits. This also won't remove the speed hit caused by the ABI.