Capcom Explains Why Only Resident Evil 5: Gold Edition Works With PlayStation Move

By Spencer . July 27, 2010 . 10:20am

re5PlayStation Move support is coming to Resident Evil 5: Gold Edition via a free, downloadable patch. So, is Capcom going to release the same patch for regular copies of Resident Evil 5? No. Why? It won’t work.


A representative from Capcom explained, while I was mowing down Majini, that PlayStation Move controls require a memory resource. When Capcom developed the original version of Resident Evil 5 the team didn’t know about Move and used the memory resource for another feature. After Capcom saw PlayStation Move, they freed up a memory slot for PlayStation Move controls.


So, how does Resident Evil 5: Gold Edition play with a glowing wand?


The analog stick on the navigation controller makes Chris move while the wand is used to aim. Pressing the trigger button shifts into target mode where you can point at Majini and shoot with the move button. Shaking the wand in target mode makes Chris reload his weapon. If you’re not aiming, shaking makes Chris pull out his knife and slash. It’s possible to waggle a way through a small group of Majini since knifing is easier to do.


Resident Evil 5: Gold Edition does not require a navigation controller. You can use a regular Dualshock 3 pad instead. Gripping a regular controller in one hand and the PlayStation Move wand in the other sounds pretty cumbersome, though.

Read more stories about & & & on Siliconera.

  • Memory allocation? Hmmm..sounds fishy. Maybe Capcom just wants me to buy the Gold Edition (since the regular is no longer at most retailers)? This kinda sucks for me. I own both the CE and regular edition (and all DLC except Versus) and really want to play RE5 with motion controls. Guess I could just flail my arms a bit while blasting Majini with my DualShock…..

  • kupomogli

    Sounds to me like a lot of bs and Capcom just doesn’t want to patch the original version just so they can get more sales.

    • brooklyngamer86

      I couldn’t agree with ya more.

    • Agreed.

    • Exand

      Sounds to me like you don’t know much about programming on the machine level…

      • Then by all means, explain it to him.

        • I decided to beat him to the punch. Explanation posted.

    • All right, let’s give the explanation a shot, for those who aren’t technically inclined. No promises it will make perfect sense, since I’m approaching it from a mostly technical point of view.

      If you complain about this being too long and don’t read this, ALL of you can blame yourselves – you DID ask for a technical explanation.

      The PS3 (like all computers) has various allocations of memory as determined by the PS3. In short, when you ‘load up’ anything into the PS3, like a game for instance, it will require you to load data into various subsets of memory, which will reference (and depending what it is, physically reside in) physical parts of the PS3.

      What they’re claiming (I can’t reverse engineer Resident Evil 5 to verify) is that when they originally released Resident Evil 5, they looked at the console and went ‘We’ll use this bit of memory address to run something’, and their technical documents for the PS3 at the time didn’t say if it was reserved for anything, so they did.

      For those who don’t know, there’s OS level programming (Where you give it key words and the OS will interpret the commands into the binary required) and machine programming, where you LITERALLY reference the hardware and tell it to do things at a very basic level.

      eg. if memory address 77FC is 1, raise a value in address AA22 by 10, then send value of AA22 to the bus on the GPU to be resolved by GPU core 2 at address 11AD for further output – This might be part of the routine to render blood on hit, for example. None of this is real (Real memory addresses are far longer than that for one), considering I can’t reverse engineer Resident Evil 5 but you get the idea.

      If you want speed and efficiency, you tell the computer exactly what you want it to do at a machine level – it’s faster than telling the OS to ‘figure out’ what you want the machine to do, and considering the loads put on by modern games, you’d be a little bit upset if your pretty 3D game ran really, really slowly as a result.

      Sony then probably paid Capcom a visit when they were about to release the edition with all its DLC and go ‘Oh hey, while you’re at it, how about you implement the upcoming technology?’

      Capcom agreed for whatever business reasons, then looked at the specifications to actually implement it.

      Then they realised that the bit of referencing they did that they THOUGHT they could use for faster execution was actually reserved for something else.

      So Capcom had a choice – either recall every version of Resident Evil 5, or just release their gold edition (Which required some rework ANYWAY due to DLC being added directly to the disc (ie, no need to report that DLC wasn’t paid for and to look drectly ON the disc), and a few other odds and ends).

      Sanely, you’re not going to recall every copy of RE5, considering the game works as advertised at the time. Capcom like being in business.

      They then recoded RE5 to NOT use the memory addresses in question during their recoding process, to make way for the eventual ‘PS Move’ references.

      Now, you ask, why don’t they just patch the old RE5 and release that?

      I suspect the addresses in question are referenced through a significant amount of the game code.

      Would you like to download a 2GB+ patch? Heck, if it was something as significant as say the motion capture speech syncing, it could be threaded through the entire game code.

      Do you think Capcom or Sony going to pay the significant hosting and bandwidth costs to get a patch that, if patched wrong (bad PS3 day?), could LITERALLY make your PS3’s HD grind because part of the hardware is doing it wrong?

      Machine code is kinda scary in the sense that a typo or mistake in the code won’t give you a complier error – It’ll more likely do something you won’t expect. It’s where glitches come from.

      On an OS level, your code will do something weird. You know, bugs.
      On a Machine level? Your HARDWARE will do something weird. That’s a lot more dangerous, for one. Sony nor Capcom are fans of having to replace hardware.

      • Is it weird that I understood all that even though I’ve only taken an intro level computer class? Edit: And knew a little bit of that beforehand?

        • No, because even if you only do software programming (Where a complier figures out the machine code) you still need to understand the basics of Machine programming.

          Any programmer of any kind should know all the above pretty much within the first few months of learning.

          • NeoTechni

            All he has to know is about pointers really. And what you’ve been saying is full of crap.

            Damn, I accidentally liked your comment instead of replying…

      • What about Heavy Rain then? That game was being WAY before the PS3 was being made. They were nearly finished with the game by the time Move was announced. How’d they manage to code that in?

        • Answer to that one’s very simple – They never used the said memory resources (ie, the bank of addresses which make up what Sony uses to make the Move work) in the first place.

          In absolute theory, any game on the PS3 can be provided with move mechanics – as long as the game does NOT use certain memory resources (ie Memory addresses as addressed in the article) to let Move work.

          I don’t know, FFXIII could work, but there’s also the chance it WON’T work, for the same technical reason. I don’t know if anyone’d appreciate playing the game with move controls, but there’s a question we could ask SE sometime I guess.

          Heavy Rain DIDN’T use the resources in question (which is a literal reference to the PS3’s HARDWARE) because either they were aware of the fact it’s reserved, or more likely, they never touched that set of memory addresses in the first place because they didn’t think they NEEDED it to run their game.

          Capcom did with Resident Evil 5, and probably used it for something important (I don’t know what the feature they mentioned they used the resources for actually IS) in their first build of the game. They felt that the part of the PS3 they used actually helped run their game (ie. do something for them)

          You could blame Capcom for ‘shoddy programming’ for putting itself into the hole… (Although it is standard practice in machine programming to make as much of the machine as possible to work towards your task as known at the time of development, which means in fact, you’d be complaining about industry standard proceedure, but we’ll ignore that for now…)

          Except that then I’d have to ask you this one question in return. Are you expecting Capcom to be able to look into the future and know about allocations of the PS3 hardware Sony didn’t tell anyone at the time?

      • Even with that explanation, it still doesn’t change the fact that it is possible to patch the original game. Plausible? Maybe not. But still possible.

        And honestly, I don’t even see a 2GB patch being that big a deal. There have been games before that had patches that large (Eye of Judgment in particular is a game that has had massive updates with very large patches), and I’m sure most people would rather download a large patch than buy a game over again.

        • Repeat after me – When we are talking about trying to patch MACHINE code, the risk of a ‘On the fly patch’ going three shades of wrong are HIGHER.If you read the last part, you’d notice me mentioning that when machine code ‘goes wrong’ you risk the hardware going strange. I wasn’t kidding about being able to make your PS3’s Hard Drive sounding like a grinder and subsequently destroying the hard drive – this happened to a a professional acquaintance who had to get the debug PS3 written off over it. Not pleasant.The problem is if they’re talking memory resources, they’re most likely talking about machine code. Why? You don’t directly reference a memory resource via complier code.A 2GB+ patch (And that’s me just throwing out a figure) is actually pretty obscene – and I was throwing out the figure out there. Patching isn’t designed to download 1/4 to 1/2 the game. Remember, a significant amount of a graphics heavy game is the graphics packs themselves. If we go on a estimate that Resident Evil’s graphics assets on the PS3 is 8GB (We know it’s not a full 25 since it managed to get on the PC and Xbox 360 but I’ll be generous and we’ll assume that the PS3’s graphics assets are HIGHER) and we make a guess that about half the game is graphics assets.This means essentially, (Assuming you CAN even, since this level of coding may even require a data restructure and you may not be able to use the disc just for graphics code) That you’re literally (more or less) copying over the entire debug code, writing a custom installation OF the game, and hoping that each client’s PS3 will correctly patch without error.And every instance that it failed, Capcom or Sony would be LIABLE to replace your PS3 because they’d be at fault for breaking it. Unless of course they say ‘Patch at your own risk’ and it’s your problem for the PS3 literally not working anymore due to you accidentally bumping your PS3, the PS3 powering down incorrectly, and a whole bunch of other stuff.Sure, CRC checks and other stuff can help, but there’s always that material risk.And of course, assuming they were planning to take that risk…How many copies of Resident Evil 5 are there out there on PS3? Say 200,000? I’m not that read up on the figure. Remember, it’s US, Japan AND European copies they’d have to ‘fix’.What’s 2GB * 200k? THAT is how much bandwidth they’d have to pay for. Ask a mid sized hosting about the cost of transferring that much data.2GB for a single person? Sure, not a big deal, not even in Australia where we have quotas.Paying for about 200TB of bandwidth? Not so cheap.

          And of course we’re making the assumption that everyone who owns RE5 HAS 2GB + working space to actually ‘forcibly install’ the game, since this is the only way it’ll work.

          Logistics is a pain in the backside, and it’s easy to ‘say’ it’s possible, but executing it? Not so much…

          • You talk a lot and throw out lots of figures, but my point about it being possible to patch the original still stands. And besides, there are still a lot of assumptions being made on your part because as you originally stated you can’t actually verify any of this.

            That’s not me saying I don’t believe you or value what you say, but it is a bit of a stretch to do so when you’re giving the worst case scenario for every situation. It could also be much easier than you’re making it seem (or Capcom could be lying about the whole thing in the first place), but it’s not like I can argue with you on a technical level.

          • I’m looking at the scenario from multiple perspectives, because I’ve worked with legal, technical and financial aspects before.

            1. Technical (Can it actually be done?) The short answer is ‘Yes it can, but it requires a lot of work, and has liability risks to the company’.

            2. Logistical (Can it be executed?) The short answer is ‘Yes it can, but you require a HELL of a lot of resources to do it, as in ‘It’ll cost Capcom millions of dollars to try said move, with the risks listed above.’ and

            3. Economical (Can I afford to do it?) The short answer is ‘Sure, if you’re willing to spend millions of dollars to actually pay for the deployment costs, as well as paying the engineers to actually do it and you’re willing to get no return on it.’

            The safest solution in fact is to just digitally distribute RE5 Gold’s build online. But then Capcom would be paying for the full size of the PS3 game for to all customers, all DLC included.

            There’s no way in hell you’re talking a business executive into letting something that fly unless you can con Sony into paying Capcom a LOT more money than what they probably were paid by Sony into doing the move work in the first place, at least enough for them to be able to write it in as a reasonable loss. (Remember, bandwidth costs, hosting costs, liability risks.)

          • bugmeknot

            Capcom lying? More like some management figure gushing to the press. I’m sure the actual developers know it’s possible.

            There’s a cost/value trade off to take into account. Capcom would have to maintain 2 versions of the game and possibly lower the quality to free up resources for PS move.

          • Nimory

            Devin your are right — and it wouldn’t be hard — the GOLD edition is just a patched version — Remove all the extras and you have RE5. They ALREADY know how to do it.

        • I also would like to note the amusing part of all of this though…

          Capcom could have easily turned around when they made their realisation that the first version of RE5 won’t work with the move and told Sony ‘Sorry, since we can’t according to your technical specifications make all versions of RE5 out there work with the Move, we’ll have to decline making it work for anyone’.

          I wonder how people would react if they did that.

      • NeoTechni

        Your whole explanation is flawed. Downloadable updates do not patch the executable on the disc, the patch is a whole new copy of the executable. Meaning all they had to do was release an update containing the new engine.Capcom lied, and you have the info wrong. It wouldn’t be a 2GB file either. It would be the size of the executable, which MUST be smaller than 256 MB to fit in PS3’s RAM anyway. The executable code is usually the smallest part that fills RAM.Worse, the update for the Gold edition would be the exact same as the one for the other versions.

        • This isn’t the PC version. You can’t just ‘Patch the executable’, because of the fact that you have multiple dependencies, and consequently multiple executable batches of code, and not loaded all at once (namely, things are loaded AND unloaded as needed), as evidenced by the PC version of the game which we CAN look into. (Look into it sometime, it’s interesting.)

          Remember, they specified memory addresses – this is a hardware reference.

          If they were doing it purely through a intermediary language, the compiler would (upon getting instructions from an OS update) NOT use memory addresses reserved for move, because it would interpret the code into avoiding the problem in the first place.

          You’d have to either a) have to rewrite the affected parts of the install and copy or otherwise deploy onto, and/or b) possibly alter the parts that DON’T get copied off the disc. This is what we call ‘non trivial’.

          As well, your information is incorrect, due to the fact even though the limit of the PS3’s ram is 256 MB, the code wouldn’t actually be purely in the initial executed files – You’d be loading AND unloading various pieces of code… during the loading screens as necessary.

          If they decided to load code off disc which is comparatively minor because of the fact that it’s small but is affected, they’d have to alter the install structure as well.

          So they didn’t lie outright for the sake of it.

          Now how true is it? I don’t know – Like I said, I can’t reverse engineer the PS3 version of Resident Evil.

          I do however do know from experience that a) you can use more than 256MB of ram in a rolling format (ie, load and unload routines as necessary), and b) that you can’t just ‘patch a single executable’, because code doesn’t work the way you describe, and definitely NOT at machine level.

          So I call. What PS3 coding have you done?

          • NeoTechni

            “This isn’t the PC version. You can’t just ‘Patch the executable’,”

            That’s what I said. The update isn’t a patch, it’s a full copy of the executable. It loads faster, and doesn’t have the issues you brought up.

            “Remember, they specified memory addresses – this is a hardware reference”

            Irrelevant. That’s not the issue. The exact same executable they use for the Gold edition can be used on the other edition. By using that update, it’d use the new memory addresses from the Gold version.

            You don’t seem to understand how programming works. Just cause they used a specific byte of memory in one version doesn’t mean it’s written in stone that they must use that same byte in every other version.

            “You’d have to either a) have to rewrite the affected parts of the install and copy or otherwise deploy onto, and/or b) possibly alter the parts that DON’T get copied off the disc. This is what we call ‘non trivial’.”

            No, they’d simply have to allow the other version to receive the same updated executable as the Gold edition. All rewriting has already been done for that version and would work with the other one.

            “As well, your information is incorrect, due to the fact even though the limit of the PS3’s ram is 256 MB, the code wouldn’t actually be purely in the initial executed files – You’d be loading AND unloading various pieces of code… during the loading screens as necessary.”

            Your information is incorrect. Executable code doesnt get loaded like that. Assets such as textures/models/sounds/etc get loaded/unloaded dynamically. Code stays resident permanently since it’s so small.

            And you’re flat out lying at this point. As I said, executable code would be the smallest part of the game. Far smaller than 256 MB.

            For someone talking about memory addresses you’d think you’d know code doesn’t get moved around like that.

            “b) that you can’t just ‘patch a single executable’, because code doesn’t work the way you describe, and definitely NOT at machine level.”

            Actually you don’t understand what I described, since I DIDNT say they patched anything. I said they REPLACED the entire file. You’re the one saying they patch files, and I said that’s false.

            And PS3 DOES work how I said. The OS simply loads the updated executable from the HDD if it finds one, and ignores the one on disc. Any update file contains a new version that doesn’t use any data from the old executable file to load.

            “So I call. What PS3 coding have you done? ”

            1) Irrelevant. You haven’t done any

            2) I’ve done some coding for both PS3 and PSP. I’ve also done a lot of PC programming. So now what?

          • I’ve had code hang due to executable code loading and unloading in a rolling fashion. It comes down to speed vs efficiency, and of course, how much memory left in RAM you had left.) Since you’re loading textures, it may be an efficiency thing – and as well, I’m also aware due to the PS3’s… particularities, accessing the full power of the PS3 has always been a pain in the backside, so I was always informed to optimize, minimise and do whatever it takes.

            Now I’m not the most efficient coder around (Considering I’m still learning myself, I’m being supervised to that effect. I may get lucky in a few years.) but the coders that have been instructing me have explained (Because initially I suspected the same thing – Trivial, just replace executable code) that all the assumptions I made when I heard the story break wouldn’t work.

            The memory addresses referenced could in fact be a heck of a lot more difficult without, well, replacing all the executable code. The problem is that depending how you coded it, (And I was literally demo’d this and it was an novel lesson into teaching me about assumptions I was making) you have to replace a lot more executable code than you’d expect due to the fact you’d be talking the binary, not compile. (About 20% or so.)

            You may have to force install the PS3 installation, among other things to make it work. Worst case scenario is to forcibly install RE5 and basically copy out all the code, and whatever they need it to work.

            Patching/compression would reduce the amount (namely, not copying all the code across ), but as I said, we don’t know how much cheating that they did in their attempts to make it work.

            I have no doubts that Capcom took a lot of liberties in trying to get the hardware to do things in ways they shouldn’t – It’s not the first time it’s been done, and I’m fairly sure Capcom has done it before as well. Off the top of my head though, Shining force 3 from memory used one of its processing units to handle something completely different (Was it the Saturn’s sound processor to handle graphics, or was it the other way around? Can’t remember off the top of my head… granted, it is 6am, and I apologize for any lapses.)

            It’s a novel programming feat, but I don’t think Camelot intended to ever revisit the code for any sort of patching in case Sega went ‘Uh, we’re going to enable a feature that uses that chipset you just borrowed to run calculations for something else’. Tearing something like that out and making it work ‘properly’ is… yeah, not the sort of thing I’d be enthusiastic about, and isn’t the sort of thing my instructors are either.

            We both know that you make the code work, and that ‘proper coding that’s fully backward compatible and standards compliant’ is a myth we dream of, not something that happens as often as it should. Capcom could have (And most likely have) coded themselves into a corner, and used the money to code themselves somewhat LESS out of a corner.

            Of course, I don’t think Sony gave them enough money to justify the expenses to COMPLETELY code themselves out of the corner, particularly considering their fiscal position at the moment.

            Remember, there’s not much in terms of return here to make it happen at all. I mean, think about it, it’s a nice thing to have, but it’s not a case of false advertising (RE5 never promised to work with the move period, which people are neglecting to mention), and yes, they could have placed it in the ‘Too hard, impractical or costly’ basket for all versions due to the issues with making it work for one version.

            Does it mean Capcom did anything they should be defended for? Not really (If they knew in advance that their coding monkey trick on first edition would cause obvious problems) – However, it does mean that their cited excuse may in fact be real.

  • Chow

    Translation: more sales of Gold edition.

  • Aoshi00

    How about Heavy Rain, they’re doing the patch for Move right? Though I don’t know how fun it would be to play Heavy Rain w/ Move..

    I have the original RE5 on 360 and bought RE5 Gold on PS3 since the extra is on disc, still haven’t opened it yet, I’m going to get the move controllers to play this later.

  • Eh. Doesn’t matter to me. Not a motion control guy. I will get a move for Light Gun games like Time Crisis and Dead Space: Extraction, but otherwise, I can do without. I have the original RE5 anyway. I bought the DLC chapters and nothing else, so that’s about as far as I’ll take it.

  • cowcow

    From watching SDCC gameplay vids, it looks less cumbersome to use the navigational controller than the analog on the dual shock

  • frankigoestohollywood

    Nice try, but im not buying it. I’ve never heard of a gamecompany incompetent enough for something like this, that they would need to recall back their physical gamediscs so that they could make a patch for a newer version. It just doesnt make sence.

  • DrGhettoblaster

    Bulls***. Capcom is f***ing us all once again. It’s very simple.

    RE5 was originally released March 2009.
    Little Big Planet was originally released 5 MONTHS EARLIER in November 2008.

    LBP is getting MOVE support. Capcom claims RE5 cannot.

    What a slap in the face to all the fans who bought RE5 day one. I will not be “upgrading” to Gold Edition.

Video game stories from other sites on the web. These links leave Siliconera.

Siliconera Tests
Siliconera Videos