Slashdot Mirror
Capcom To Use Emulation In Upcoming Products
JayBonci writes: "The emulation and classic gaming world has been a large grey area for a while. The subject of reverse engineering other products for the sake of emulating has come up numerous times (see also the Bleem and Connectix lawsuits), but what about emulating your own stuff? It seems that Capcom is going to use emulation as a standard way to make more games cross platform. The blurb is short, but an interesting though. How viable a solution is this? If the performance hit is fairly minimal, how will this affect the future of cross platform game development? It's an interesting solution, IMO."
"Starting next fall Capcom will allow users of personal computers, PlayStation 2, Dreamcast, Xbox and GameCube to enjoy online matches with other players regardless of the machines they use" (emphasis mine)
Note: "enjoy online matches". In other words, if you have MvC2 for DC, you can play online against someone playing MvC2 on PS2. That says absolutely nothing about the underlying code, emulation, APIs, anything -- just that they can talk to one another online. (qv the fact that just because multiple systems support HTTP, it doesn't mean they all emulate one another..)
The article is a bit sparse, but it implied binary compatibility, while SDL, OpenGL and OpenAL only provide source compatibility. But yes, they're more likely to be developing a common API on all platforms, which may well lead to their 25% reduction in development costs. Note that there's no real benefit in true binary compatibility -- they still have to ship seperate versions for each console anyway due to the media differences (CD, GD, DVD, cartridge, etc.)
"The invisible and the non-existent look very much alike." -- Delos B. McKown
Dreamcast may be "underpowered" in your opinion, but don't discount it quite yet!
Planetweb 3.0 for SEGA Dreamcast will offer java support. The current "2.0" release offers support for SWF compliant up to Flash 3.0 features as well as MP3 support. Version 3 will also add the ability to play streamed MP3 and use the SEGA Ethernet adaptor, and probably some other cool things. I think 2.0 also supports the Dreamcast mouse when it is released. Most of the hardware releases will coincide with the release of Quake 3 Arena for Dreamcast.
Also, doesnt the PS2 have USB ports? Kind of makes the "two controller ports" a non-issue.. plus the fact that like the original PS, they could easily develop a multitap adaptor to add more ports.
Also, when (if) the Dreamcast zip drive is (ever) released, it adds USB to the Dreamcast. The hardware already exists, someone just has to start creating enough games that use the drive before it's viable to start mass production and selling the thing. The DC's Maple bus (controller port protocols) probably are only good up to 1mb/s which isnt really good for mass storage, video, etc. even though the Maple standard allows for 1, 2, 4, and 12mb operating modes (may be a little off on the exact numbers though)
~GoRK
The Namco Museum collection of games, with about 5 volumes, uses emulation and original ROMs to play classics like PacMan and Xevious on the PSX. This is nothing new -- it's easier to emulate one piece of known hardware (or so) than to try and re-write some of these arcade games.
Pretty cool really...
--
You are not alone. This is not normal. None of this is normal.
That's the key here: the bread and butter of Capcom are precisely these common denominator games; namely the Street Fighter series. All consoles support the technology for these, because it's such an entrenched genre. So it's pretty straightforward to write an abstraction layer for them.
Capcom's business model is to provide good gameplay and content. They're not as focused on wringing every last cycle out of the unit to show off the technology. So the emulation techique will work just fine for them, but it's certainly not a good general solution for all developers.
Some of its 3D fighters and fancier shooters (19XX runs on x86 hardware, I believe) aren't likely to be emulated, but the article doesn't say it'll be for all their games anyway.
Ita erat quando hic adveni.
Speaking of Zork, I would dearly love to finish playing the original Zork. (I made it through a few puzzles when it was on ARPANET.) You can still buy PDP-10 compatibles, but the power drain is horrendous. Does CompuServ still use them? Anybody done an emulator?
(I know about the 16-bit FORTRAN vesion. Played it. Parser not as smart, not all puzzles.)
For that matter, I'd love to see a new adventure game -- graphic or non-graphic -- done the Zork way. You start with a few rooms and puzzles, and let people from all over the word bang on it. Then you grow the thing organically. Commercial adventure games were rarely as good.
__________
The problem is that game machines have drastically different capabilities and features. Emulation doesn't help for developing new games because they are expected to take full advantage of the hardware. I could see it for a puzzle game or a re-release of an old classic.
The Amiga 2k/Tao Elate system offers a better solution than emulation - which is run-time code translation and hardware abstraction to a certain degree... but they don't abstract a lot of things. Writing a high-end PS2 game requires learning 5-6 different assembly languages (EE-core, VU macro mode, VU micro mode, EE-multimedia instructions, VIF, GS). There really is no way to abstract these without diluting the power of the system.
You can write a game to the "lowest common denominator" but then you end up with crap. EA used to have this policy of "4 wide, and 4 deep" meaning every title would run on 4 systems and be translated into 4 languages. They gave up on this when they found out it was basically impossible given the demands of the customers and the time available to the developers.
My philosophy now is to pick a fixed target (i.e. console) and develop a game for it not worrying about portability or what might have to be done later. Then if it sells, bastardize the product and rip it to shreds to port it to other systems.
-- Virtual Windows Project
If you go to ARDI's pages, you'll see that they've been very infrequently updated. Some of them are dated 1997... They say that one of the reasons for this is that they've been concentrating on marketing and making custom implementations of their emulation engine, the core that emulates a 68k Motorola processor on an x86 machine, for companies which want to have apps available on x86 without rewriting their old code.
/. Read all about it, how to use it, and where to get the latest stable or dev release, here:
.org/co mments.pl?sid=00/10/17/1442251&cid=127
This makes sense since I'm sure there are many companies with legacy apps written for 68k machines--not just Macs exclusively--which they don't want to discard just yet, but which are sorely wanting for decent hardware. They'd run much faster on a modern x86 emulating the old processor, than on an old 68k machine.
But if you really like using Executor for Mac apps, I have a much better and more complete and satisfying solution for you. Use Basilisk II, the open-source Mac emulator, with a free copy of the Mac System 7.5.5 downloadable from Apple's own FTP servers. It's much more satisfying to have a real Macintosh OS being emulated, instead of ARDI's reverse-engineered runtime environment which, while efficient, lacks all the charm and nostalgia of running the *REAL* MacOS.
Coincidentally, I wrote a post about Basilisk II the last time emulation was mentioned here on
http://slashdot
"The more corrupt the state, the more numerous the laws."--Tacitus, *The Annals*
I seem to recall the old Sierra adventure games were in a specialized format. They were then loaded by an interpreter on the machine. When porting to another OS all they had to do was port the small loader mechanism-- the game itself required no changes.
It seems like that all that they are going to do is make sure that all of the major platforms can run the software. The equivulent to Java running on any platform, or having certain executables to run programs on windows, as well as linux for example.
It's cool what they are doing however, They wont have to spend as much money rewriting and repackaging games, but I also can see games being written for the least common denominator in order so one platform wont have a edge over the others.
They have source code, why would they use performance-hogging emulation?
It's more likely that they are writing their own compatibility layer for each plaform, such that the same game source can be compiled for each platform with few or no changes. Think of it as porting Linux and glibc from x86 to PowerPC, so that Apache can be compiled for both with no changes.
I suspect the E word slipped in somewhere along the line when someone who doesn't know what emulation is wrote a press release, or something.
--
Let's hope Sony picks up on this real quick. Why, with this technology, we might be able to play our playstation games on our PS2!
Wouldn't that be great?
-Denor
For yonks, Hanaho have bundled a CD with licensed Capcom ROM images (including one of the earlier Street Fighter IIs) and MAME with their Hotrod joystick - look on the FAQ page.
Not sure if someone else may have posted this idea, and it's buried somewhere...
....Paul
It occurred to me while reading this, that there are more than a few companies, orgs, individuals writing virtual machine emulators to run other games. But suppose, instead of having to build some hardware first before developing for it, build an emulator first.
What I mean is this...
As an open source project, design the perfect (or at least really good) game machine architecture. What would the APIs for everything it needed to do look like? What hardware services would be available? Then, write and emulator for this API/hardware. The emulator could be made portable and games (or any software) could be written for the emulator standard.
There are portable libraries already, but I don't think anyone has quite gone this far. There are after the fact emulators as well, but they are limited by the capabilities of the original hardware and/or the hardware running the emulator.
Just a silly thought I had...
F U NE X N M? Son: "Dad... How do you spell 'hourly'?" Dad: "0 * * * *"
What he is really talking about is something like Java, or Pascal's p-code, or Sierra On-Lines AGI and SCI interpreter, you could even think PostScript. The word emulation was probably used so that teenage snotbags would understand it.
As a geek, there is nothing new here. I would have done the same thing their shoes.
So they're going to implement some sort of VM. Woo. It's not a bad idea, all things considered, but it's hardly anything to get excited about. (The same could be said of Capcom's games, but that's just pure opinion.)
--
Proud member of the Weirdo-American community.
Just to play devil's advocate, this doesn't sound like anything more than Capcom throwing out a buzz word to generate publicity... so they develop a midlayer that exports a generic API on several different platforms, and then code their games to that API. That's *NOT* emulation. That's what SDL does, that's what OpenGL and OpenSound do. It's basic tiered design, and it's a good idea. Hell, the point would be moot if all the game console manufacturers would get together and implement a unified API anyway, which they ought to do. But using the word 'emulation' just to stir up interest is pretty weak, IMHO.
25% Funny, 25% Insightful, 25% Informative, 25% Troll
I remember buying a CDROM full of games from Activision that were for originally written for the Commodore 64. That was several years ago.
The CDROM included a frontend program and an emulator that would allow you to play these games under Windows. It was a great idea, and the CDROM was priced rather cheap.
I think that it is an absolutely great idea for gaming companies to release thier old titles via emulation. Especially if the price is affordable. However, I would rather see some of these companies release some of their older games, that have lost almost all of their capacity to produce cashflow, into the public domain, source and all (ID software has led the way with source releases of many of its top titles.)
I read a recent article that stated that the computer gaming industry has outgrown the motion picture industry by leaps and bounds. If the Academy of Motion Pictures has setup a film-preservation society, why doesn't someone setup a software preservation society (needs to start now before some of the real treasures of the software industry disappear!)
Brought to you by Frobozz Magic Penguin Fodder.
All the old Infocom games did this. It allowed Infocom to port one single app (the zmachine) to each new platform and then have their full product line available on that platform. There's still a thriving interactive fiction community centered around an open source, reverse-engineered copy of the interpreter (several, actually, on desktop systems, Unix/Linux, PalmOS, ...) and an open source compiler that generates code. More details at http://www.iflibrary.org/
Nothing new under the sun...
"It is our blasphemy which has made us great, and will sustain us, and which the gods secretly admire in us." - Zelazny
It's not VMs. It's not APIs. It is making moving a lot of hand-tweaked assembly code easier to move from the arcade to the home system. And that's why it's news.
Ita erat quando hic adveni.
I seem to remember that Sega released a Sonic CD for the PC, which contained all the Sonic games, emulated, including the MegaCD Sonic CD game.
Does my bum look big in this?
imagine that, that'd make emulation real easy...
but even better, now we'll see which console really is the most macho, because the exact software will be running on all of them... i hope it doesn't get dumbed down to an lcd type of deal though ^^;;
but imagine if this emulator was released to the public! we could develop for all consoles simultaneously! wow.
psx2 has only 2 controllers, dreamcast is underpowered, gamecube has encryption to deal with just about anyone trying anything, xbox has no protected memory. will capcom really save money this way? hm.
--
Peace,
Lord Omlette
ICQ# 77863057
[o]_O