Can I (aka you as I can’t/won’t code) port this game to this device?


Editorial Team
Nov 21, 2005
United Kingdom

Can I (aka you as I can’t/won’t code) port this game to this device?

Yes. Emulate it.

[smash cut to chosen TV show ending credits]

OK OK OK more serious.
Do you have source code to the game? No?

[and they all did anything but live happily ever after]

Of course the greater answer is, as ever, “it depends”. Not a great answer for a question so often asked, hence this thread, but it really is the answer. It should be said though that emulation is a perfectly valid way of playing things on other systems, assuming there is one on your system of choice. Emulation is inefficient so you might not have one for your system, or it might take a lot of power and might have a lot of bugs or quality sacrifices in the name of making it work. This is also to say nothing of for as nice as the cheats, savestates, turbo, filters and more that emulators provide are then playing at code level allows so much more (high resolution, widescreen, camera tweaks, radical game tweaks, easy tweaks for non coders/hackers and much more besides). To that end we can spend more time (though sometimes not much more than a play session) and do something better.

There are many things to consider but as a broad overview

The power of the systems in question, and power is seldom entirely expressed as simple numbers, be it clock speed, number of cores, number of floating point operations aka FLOPs, number of double precision floating point operations, number of bits (whatever that means) or amount of memory.

What information do you have to recreate the game with?

What abilities and options you have on the target system? Can you run your own code and with what limitations, and what libraries are available on that system or do you have to handle it all yourself? Hacking a console from scratch is something you might be able to do but we will skip that today. The rest are however more useful questions as most will be coming to this after it is already hacked/homebrew capable to some degree.

Power of systems.
System design and architecture is a field unto itself. Marketing people and those that listen to them often tend to latch onto a simple metric. This metric might change from time to time but even within that time period where it is “the one” it is far from a complete story. Some of the notable ones from the past were covered in the introduction.

3d. 3d is another of those things that people spend entire careers contemplating but a tiny fraction of. Still in general use up to now there are two “actual” 3d methods used. That being skeletal/bones based animation and vertex based (short version there is you have an imaginary mid line in your shapes, forming a skeleton hence bones, vs you control each and every corner where things join and why you might see very long triangles when graphics/animations go bad). Should your game use one and your system use another then you will have a problem. More generally there are a handful of methods of doing 3d operations in modern computing, generally opengl (which has an embedded version) and directX/direct3d being the two big umbrellas with each having many sub versions and spinoffs (see Vulkan) as well as a few that fell along the way (s3 virge and 3dfx/glide being two that will be noted among older PC gaming fans), though of course most consoles prior to the original Xbox and later PS3 (the PS2 which was contemporary to the xbox did its own thing), or 3ds if doing handhelds, did their own thing, sometimes quite differently to the standards discussed.

Floating point operations per second.
Such things are indeed very nice when dealing with all sorts of things that don’t work with whole numbers or want very large numbers (a 32 bit computer tends to be called that because the basic number it works with is 32 bits long, starting at zero that leaves you ending up at 2^32 or 4,294,967,296; a lot of almost any currency in the world to have, nothing much if you are measuring a map kilometres wide in centimetres (maybe you are making a shooting game and want to assess whether someone was hit) or counting the number of stars, or cells in a body.
Games use these extensively and have done for many years. However the maths underpinning them is not the simplistic “everything is adding” approach that computers from years earlier had adopted.
If you are asking why you would want to do something at the order of number of cells in the human body you are a) suffering a lack of imagination (what could you do if you could? Also how many possibilities are there for even 15 moves ahead in a simple game of chess, never mind a collectible card game ) and b) actually probably thinking in terms of limitations already.

So it was the mid 90s when floating point was implemented widely in games on consoles and PC. 2004 saw the release of the Nintendo DS, one of the most popular systems ever made. It had no floating point abilities, much less ones you would want to lean into. Games for the mid 90s were ported to it, however they in turn required much of their floating point code to be adapted into something that more suited the DS and where that was not possible then everything else had to tighten its proverbial belt to make room for the slow software methods to work in real time.

That is a video covering how 2d art was made back in the day. It was made to deal with the limitations of systems, though in so doing became its own art style and common aesthetic of the era. Today you can trivially exceed the things limiting the systems of the day, though if you are going to port such a thing to a contemporary system of the original games mentioned there then you might do well to learn it. Porting it out of such a thing will also be far easier if you have an appreciation for why things were done the way they were done. A simplistic example is not every 2d console will have a mirror sprite function, so sometimes devs would say why not mirror the sprite in our editing program, add it as an extra one to the game and call that instead. Do you recreate this or do the trivial mirror option in code? We will cover more of this later but mirroring also means a character that might have spent the game being right handed is now left handed. You could correct this.

On the subject of dimensions then while most will get hung up, quite justifiably, on 2d vs 3d devices then even among 2d devices there is discussion to be had.
Document covering the nature of game cameras.
However anybody around during those times would have heard debates over parallax scrolling, or simply that scrolling could happen at all (for a while even the mighty PC, though then not so mighty, had it as a thing it could not do that consoles and arcades could happily do) and games did not have to be a series of single rooms.

Most coders when assessing the feasibility of a port will be considering power required. They will then tend to also rate it on a sliding scale between “trivial” as you have resources to burn handling idiosyncrasies that the original coders are responsible for, that the original system benefited from being played to, or things are just so similar that it does not matter, going through “possible but will take some effort” wherein you don’t have as much to burn, continuing on through “a lot of effort on the part of an exceptionally skilled coder/team” wherein someone willing to put the time in to truly learn a system and the game being ported and still spend the time getting it working will get something done, and finally to straight up impossible (unless you stream it your gameboy is just not going to play the latest and greatest system grinder PC game. It might however do a minigame for it, a platformer that effects the same aesthetic or a choose your own adventure that tells the same story).
There is no formal approach here and most view it as rather more holistic thing, possibly tainted by their own skills and desires. Broadly 2d vs 3d hardware and the nature of it, how similar in power systems are, what scope the game attempts (64 player FPS over kilometres of map is rather a big ask for the PS1, even if it can nominally do a first person shooter, though we have contemporary examples of infinitely generating, aka procedural generation, maps in things like Delta Force, or far earlier examples still in Elite, and you can potentially break things up such that it is not trying to do it all at once) which is to say how much resources the game is likely to need, what styles of coding were employed and do they match what the target console has to offer (floating point on the DS being but one example), languages used and desired outcome (online play is boring for me so give me campaign mode and I will be delighted, for me then you could skip most online multiplayer aspects of a game and I would still be just fine).
Some will go a bit further and ask how they might bring it in line with more modern approaches as game design is itself an ever evolving art – a good book from the 1970s is still good today, as is a film, but a good game back then might well be lacking from the far larger developments made in the times since then for gaming.

As a very basic first pass. What are the requirements of the PC port of the game in question, or a similar game made for the same device? What are the ports and games being made commercially available on your target device? Bear in mind that this sort of homebrew porting action is a hobby during the weekend rather than many paid coders going full time for a year or two so take a bit off what is capable, though if you have source code then maybe call it parity. If there is a suitable console port somewhere along the way then that can also make things easier, though probably not (did you see Mario 64 DS on the 3ds prior to the source release? No) unless you count emulation (the PSP could not really emulate a PC contemporary to the PS1, could emulate PS1 games though). There you go. Such a thing is far from flawless (many indie darlings might look like they are straight from the 1990s but underneath it all are anything but) but may stop you from looking too silly.

What information do you have?
Short version is do you have source code of some form? If not then be prepared for a very long haul, even longer if you want to go further than just a PC port wherein your resources are effectively infinite and instead have to limit yourself to a game console or some kind of embedded computing device.

Source code probably ought to be covered for the unfamiliar in the audience. Computers are horrifically simple devices when it comes down to it. They do very very very basic operations, just millions of them a second. Coding in this manner, especially in the modern world, is a programming style called either machine code or assembly depending upon a fairly arbitrary distinction. For most, especially those aiming to make anything like a modern 3d game, it is tedious and demanding beyond all belief, and in some ways may be beyond even the smartest humans, and even for those that do manage it they tend to reserve it for things that they really need to either be sure of working in a manner they can explain or be as fast as it possibly can be. If it is even taught at all any more it is to try to get programmers to behave more nicely for their higher level languages, and most people making any practical use of it probably are the hackers that pull apart games to figure out how they work and how to make them better.
To that end fairly early on programmers abstracted some of the basics away into prebaked setups, which evolved further and further taking more and more control all the while, but in turn making it easier and easier, such that today we mostly write code in programming languages. Bonus is for most of computing history going from a piece of code the machine itself runs back into a programming language was considered impossible, in many ways it still is but in others not so much but we will cover that in a little bit.
The shift in console games compared to general PC coding, which included many games too, came rather later. Ignoring those machines running BASIC (Commodore 64 and its contemporaries) a few tiny inroads were made during the late 16 bit era (that being the SNES and megadrive/genesis) but the big shift was the console generation after that (the Playstation 1, the Sega Saturn and the Nintendo 64) wherein everything mostly moved to C. Assembly stuck around for those time critical pieces of code but even then started to fade away as compilers got better still. The GBA and then DS marked the departure in the handheld world. Newer consoles may use newer languages still, though typically still something like C or C++ (or the spinoffs various companies make for that -- Microsoft have C# which forms the basis for a lot of their later xbox and PC games).

As mentioned above then for most the act of compiling the source code into a binary/machine code is a one way affair, though there are some exceptions and you can still learn what the game is doing.

A good place to start looking for source code is
However they adopt the approach that games there need to have a measure of legality to them. If the source code was leaked, released and then retracted because of an unforeseen legal issue (a few cases of this have happened) but internet is forever so available if you look, or generated via a means that is questionably legal (discussion of decompilation still to come) then it might well not be on there. Also just because it is there does not mean it is far advanced if it is a recreation rather than a release, and might be missing key features or be inaccurate in some manner. covers more than the above, though as more of a historical list than a current one.
There are also generally open source games

Legality will also play into things here for doing things underground is possible, however it does rather limit your options.
Now if I am lawyer I am likely not one in your jurisdiction, and beyond that a lot of this being on the bleeding edge of computing means laws have not necessarily caught up. Or if they are around then they seem not to be enforced, and a law that is not enforced is essentially not a law. For instance Nintendo, a famously litigious and protective company for many decades now, seems to routinely ignore things that were otherwise a settled debate in the 1980s as being contrary to the law (assuming you can prove it, and they could here). Examples of this being the Mario 64 decompilation ( ) and the various disassemblies of their Pokemon (émon_disassembly_projects.html ) and Mario franchises ( , ), all of which are about as blatant an example of derived works or the complete opposite of clean room reverse engineering* as you are going to ever get. This is also saying nothing about the ever fun world of software patents, , article about video linked as video playback libraries have prevented developers from releasing source before, and have also seen a few revoke it after the fact.

*you will need to read further here but generally speaking if you recreate something by playing it and observing it work then that is held as acceptable. Start peeking at the code itself running and you get into trouble. Some go further still and class the people doing the original observation as utterly cursed and not to be allowed anywhere near the new recreation project lest they taint it. Or if you prefer there is a reason why those that have confessed to reading various leaked development tools for Nintendo consoles are often not allowed to write code for emulator projects like Dolphin.

Spend almost any time contemplating games and you will hear the term engine. For those somehow reading this without an understanding of what such things are then in engineering nothing is ever so nice to design as something someone else already did. The business types like it as well as you don’t now have to spend a year (or ten) designing something that might not even work, all while those already out there have something and indeed another ten years on top of that while you were getting things started. To that end people realise that their games are probably going to vaguely simulate real physics (or at least that is a constraint they can deal with and still scratch the itch to make a game) and someone that is offering to let them deal with character movement, writing a story, composing some music and whatever else and thus buy in those engines from another.
If the engine works OK out of the box (and it is the job of the engine maker here) then everybody is happy and it gets used. Another game maker then uses the same engine to do another game (or maybe a sequel) and thus all that code used with more or less just a different script on top might well be able to be reused to run the assets of another game. However a game developer may get code for an engine and expand it beyond what the original engine developers did with it and thus break cross compatibility. At the same time if another suitable engine is available you might well be able to make something using similar behaving weapons, enemies, level layouts not unlike a type of remaster. This is more commonly seen on the PC but consoles are possible too.
Examples of the same game engine being used multiple times are commonly seen in discussions of Doom (Doom clones, as FPS games were once known, often did use the Doom/ID engine of the day), Quake (same story), Unreal (once a big competitor to ID and today encompassing quite a lot) but one of the purest examples is probably THUG Pro which aims to collate all the various Tony Hawk Skateboarding games, and things like the Disney characters spinoff, into one monster game.
Cross game recreations are a fairly popular means of attempting a port, and sometimes spinning off into their own game. As the barrier to entry is rather lower than other stuff covered thus far in that you don’t need to be able to code there are a lot of these attempted and fizzle out. There are those that make it, some of the more interesting examples coming from those that recreate a previous Elder Scrolls or Fallout game in a newer engine.
Though maybe fans of the Thief series are interested in

But let us talk about the long haul.
Games are systems, commonly with fancy audio-visuals and maybe a story. If you can describe a game you can recreate it. For instance know the rules of chess and you can create if nothing else a two humans game that keeps track of the rules, this despite never having seen a chess program before.

You also have the question of how accurate do you wish to make it?
Bomberman on the Megadrive. Wait on a part of the level with horizontal cover towards the bottom of the screen. The enemy will come and plant a bomb above you. While they are doing that move down and trap them with one of your own (possibly multiple if you have the double press to lay a line powerup). Congratulations you have killed them unless they are riding a creature, repeat step if they are. Bomberman is now winnable against the AI. Would you recreate that if you were recreating the game or would you seek to improve the AI to be more like a human, or indeed a really good human? Most would answer yes and with that in mind you have changed the game. We hack games every day with cheats, savestates, turbo, self imposed challenges, house rules, and more besides so it is not like games are a sacred cow that must remain untouched. In some cases there are considerable technical hurdles, in some cases maybe even legal, to making a meaningful change in a game but as mentioned we do this every day and have done for many years.
What if instead you told the game humans were playing but fed the emulator controls with output from an AI that is watching the game? Some that were apprehensive previously now seem to think this is more legitimate. This is also one aspect of hybrid emulation approaches. Hybrid being seen in everything from high res texture replacement emulators, to things like DS International Karate, to various releases of classic Final Fantasy games on Android and IOS devices.

You can also build up and outwards to recreate a game.
Imagine a real time strategy game (or maybe a turn based one).
So you boil a game down to a list of core concepts.
Maybe some core units.

You don’t however need them all to make a plausible simulation of a game. Certainly not all maps will feature all units.
You don’t need to necessarily support the original assets to make a simulation of the game. You will probably want to eventually but at the same time it is possible to build out a game and get the core of it sorted before figuring out how to import assets, or maybe import and polish up at the same time.

However many thousand words and multiple teases this is now we are finally discussing it.
Most gamers probably would have first had an encounter with a decompilation adjacent field with the first N64 emulators. They reasoned, rightly, that if the game was written in C that there would be certain tells that it is trying to do a specific operation. Rather than have the virtual N64 CPU and associated hardware take the long winded approach to arriving at the result then if you can determine what the original operation was supposed to be (you have a lot of tells and knowledge of what is to come) then you can recreate that snippet in code for the host system and save yourself an awful lot of hassle. This is why you can emulate various N64 games on a PC that is not 10 times the power of the emulated system, as was generally the rule of thumb for emulation prior to that/emulation using the “recreate the whole architecture and run it as a simulation of that” approach used by prior emulators. This process is called dynamic recompilation, though often shortened to “dynarec”, and today is a mainstay in emulation. It can help in decompilation, though the bridge between it and the more static analysis approaches discussed below is still being built in many ways.
Taking a step back from that though we get to look at a fundamental aspect of computing called the halting problem. Adding things is fun and computers do it well but the real fun starts when you get to make a decision on where to proceed next, possibly based on previous information you generated.
Working backwards is hard and going forwards is hard if you don’t know what will happen/something relies on external input you can’t simulate.
This means if you have a decision then trying to predict what will happen next can’t be done, you will come to a halt if you will. However some eventually realised that practically speaking not every decision is a useful one to explore. To take it back to games you are playing a basic 2d platformer. You might jump in a pit and die, might hit an enemy and die, might hit a hazard and die, might run out of time and die. Dying however is fairly banal so in those cases imagine you had instead not died and taken the path of life. Far more opportunities to experience new things that way and thus the boring paths are closed off and you can. Also while there might be thousands of possible decisions if you have the ability to crunch millions of possible decisions then thousands becomes a feasible option.
While there are many languages ( ) and even more compilers than that the practical realities of a lot of game consoles is there are fewer than that in common rotation throughout its lifetime and thus fewer targets.
Also when you think about it most things are a basic (main if you will, or perhaps core in some parlances) loop that call other functions, which you might well want to note (declare) ahead of time, and even if not will tend to light up like a Christmas tree once you know what to look for when running the code a few times and trying to see all of what there is to see (which is usually not all that much as someone has to code it in the first place and coding is all about being lazy).

The developers might even (accidentally) leave in some clues too

or outright tell you things about the game

In some cases the developers might even opt for a language that inherently, or maybe just most of the time, does not make machine code until the last possible moment. If it is then basically a script that the thing runs rather than code, albeit code made by a compiler, then that script might well be just as readable as the original coder that made it, or readable after a little bit of work.

Also while assembly was ragged on above then in small chunks it is not actually so bad, especially if you are more concerned with knowing how something works than making it work well on the clock for a paying customer.

Decompilation is still the subject of intense research, arguably it is one of the current forefronts of computing with any amount of research, phd thesis, constant discovery, constant refinement and leaps made every week it seems. Practical results are however possible as it stands today (or indeed has stood for a year or two now), though it is by no means a magic wand to turn an old game into source code and arguably has a limited period of applicability (though one that will get larger as time goes on). Said window is likely the start of the use of C (this being the PS1 and N64 on up, later DOS through Windows 95 on the PC side of things but with many exceptions there) through to the rise of C++ (which is a lot harder to sensibly decompile, though getting more possible hence the larger window) a generation or maybe two later. Earlier stuff being written in assembly then is not going to be decompiled (hard to decompile something that was never compiled in the first place). Later stuff in harder to decompile languages can still be analysed in many ways.

Some tools to help you along the way
Probably the biggest three are

Hex Rays. The main commercial example for most people. Their disassembly tools (see IDA) and hex editors do however form the gold standard for many people, or if you prefer pick any hacker conference you like and there will be many people showing screenshots of those when discussing code reverse engineering. Their decompiler is a rather newer offering but never the less is as much a mainstay of reverse engineering in the decompilation age.

Radare 2. The open source world’s answer to IDA. Cutter is its decompiler, though most looking to do anything here will want the whole package as its abilities to handle other aspects will be needed.

A decompiler from the NSA known as ghidra

Most of these are PC based (likely geared more towards X86/X64 Windows at that) but can be persuaded to look at other architectures.

More general reverse engineering tools

ROM hacking guide

So far most of this has been focused on code and game design concepts. The ability to pull apart formats to get at the art used by the games, and the underlying formats used in the levels, and the general flow of games in their actions are worth considering as well in this. ROM hackers do this sort of thing all the time.

Often the first introduction to game hacking on the PC for a lot of people is done with this. A simple debugger but quite powerful never the less.

dll exporter

Dependency analyser is the most famous of these. It will attempt to analyse an executable to see what files it needs to work with and all sorts of other good info to have when doing such a project.

exe unpacker (also going under the banner of PE aka Portable Executable analysis, PE being Microsoft’s name for their format, the open source world tending to favour ELF)

Executables are often also scrambled by various means to prevent those wishing to take a peek at what is going on underneath it all from doing that, or simply to make them smaller, though coders also have their own methods (see obfuscation). Should your subject be scrambled, packed, compressed, encrypted or otherwise protected you will need to work around them. Many methods of this, especially for vintage games, are already known and bypassed but you may encounter others. covers some more practical aspects here. This is less common in consoles, as is protections applied to the data itself.

plain disassembly tools

Scripting languages
Python ( ) is a common language in computing, indeed many dub it the glue that holds modern computing together, but seldom seen in games. Seldom is not never though

Lua ( ) is a not so common language but seen all the time in games ranging from the DS games (see Puzzle Quest: Challenge of the Warlords) to emulators ( and indeed most things in the tool assisted speedrunning world ) to popular independent titles to mainstream games from the biggest game makers out there.

C# ( along with and XNA) is technically a multi platform setup but mostly limited to Microsoft based systems. It however is generally noted as being something in the C family (albeit more of a distant cousin than most) but in many cases rather subject to decompilation.

Java ( ).
Hugely popular in the business world, commonly taught in programming schools, fading somewhat in the commercial PC space but never the less powers a little game called Minecraft, and also largely underpins a small and not so well known platform that goes by the name of Android ( ).

There are dozens of other scripting languages (php is an insanely popular web development language, one in which there are many examples of games but probably not something you would consider so much in game development) but we would be here all day if we were to cover them all. If it is a scripting language then look to see what there is for decompilation, or how you might recover the script .

What abilities do you have on the target system?
So anyway you have some source code by whatever means, have decided a mod of an existing game is not going to cut it in this instance, have examples of the same sort of gameplay working on the system (or the power of it is just so much in excess that it is a non issue), have some coding skills in the relevant setups and the time to make it all happen. You are still not done, or indeed might only just be beginning.

Again we are assuming you have homebrew coding options of reasonable potency here, or perhaps just sufficient potency. For instance the Java scripting options of blu ray discs for menus there are enough to do real computing, including basic emulators, however they are far from the full power of the PS3. The PS3’s Linux options (removed in a later update) had more power but were also less than the full potential of it. Sometimes devs themselves are not allowed full power of things, or have their hands tied; the 3ds memory protections almost guaranteed its javascript to be awful and with it the web browser as a whole, and the 360 had similar memory fun which removed the options for certain approaches in coding but subsequently allowed by homebrew which removed them (partially at least, or at least enough to do something with).

SDL as it is usually known is an immensely popular library, does not quite reach the status of engine, that many developers of games (usually on the smaller side) use. Should SDL be ported to your system of choice then generally anything that uses a similar version of SDL can in turn be ported rather happily. The DS mostly lacks SDL while its contemporary in the PSP did in fact support it and gain many ports of things by virtue of that. What the DS did eventually get of such a thing might well have came rather later than the PSP release, possibly because you then had to recreate all the SDL once did to do it, and might well have been a more limited version in some ways.
This sort of thing is repeated across gaming, and computing. It is why when someone like Epic games say that Unreal is not coming to your console, or the new version of their engine is not, while it is for other consoles that people see the potential game library being sliced in half, and not necessarily the good half being kept.

Languages available, possibly even compilers available.

Most developers making commercial games on a system will be using the compilers provided by the console makers. These are not necessarily available to you as a homebrew author of games, and if they are then it is a legal hassle. Or if you prefer there is a reason that most homebrew for the original xbox is not available as a simple download like everything before it and since, that being most homebrew for it was made using the official xbox software development kit (aka the XDK).

GCC ( ) is the not so well known if you are not a developer part of the open source world. It has compilers for most things out there, on most systems, and if not it is probably what will be used to attempt to create one. For most of the consoles seen commonly on this site then GCC will make its way to you via but there are others.

There are however other compilers that have their own additions and quirks that other compilers might not handle. Some will be attempts to make coding easier for coders, others will be to keep those coders using their tools and paying the substantial sums some of those cost ( ). This is of course in addition to the system specific quirks the code might have that the previous sections sought to cover.

Input method. Can you play a Megadrive game on a Gameboy? Before we even start to consider power then the Megadrive/Genesis has 6 buttons while the Gameboy has two, four if you count the select and start. Good luck playing a nice high, medium, low kick + punch + jump + block + grab and so forth fighting game there. More generally mouse and keyboard vs analogue sticks, and one analogue stick vs two (though do you really need two if you have a decent camera?) and how you might handle things.
On mouse and keyboard vs other things then what measure of auto aim do you seek to include?

Porting games is possible for a lot of things, however the fact that companies pay large teams of talented people a lot of money to do such things attests to its complexity.
Generally you want to look at the power of the original device, the power of the target device, whether you have some code to look at and what will have to be made from scratch. The newer the game to a point (older stuff being made for weird and esoteric hardware), the more power available over the original system, and the availability of cleaner code (sometimes the community will clean up code over what existed from the original devs) in general then the easier it all ends up being. Start getting closer in power, or deviating in hardware architecture philosophy, lacking code or having to first clean up code and things get far trickier. Some things may improve as we enter a time when decompilers will be doing useful work and the general power of contemporary devices far outstrips hardware used for games of yesteryear but for the most part it is going to be an active and involved process, the domain of skilled coders and sometimes skirting the edges of the law for a while yet.



New Member
Mar 31, 2023
United States
Can I put this game on another device? Yeah, you can try to copy it or use an emulator. But wait, do you have the original game's secret recipe (source code)? No? Well, that's a problem.

The real answer is, it depends. Emulation can work, but it might be slow or buggy. It's not as awesome as playing it on the original.

Here are the main things to think about:

how powerful is the other device? it's not just about speed, but also how it's built.
do you have the game's secret recipe (source code) to make it work on the new device? if not, you'll have to do some fancy stuff.
what can the new device do? Can you run your own stuff on it? does it have any helpful tools or libraries to make the game work?
games are pretty picky about how they work in 3D. if the game and the new device don't speak the same 3D language, it's trouble.
floating point what now? games like big numbers, but they use special math that's not just about adding. some old devices couldn't handle this math.

Long story short, it's a bit like trying to fit a round peg into a square hole. You might need to get creative to make it work on a different system, and sometimes, it's just not worth the effort.

Site & Scene News

Popular threads in this forum

General chit-chat
Help Users
  • No one is chatting at the moment.
    BigOnYa @ BigOnYa: @BakerMan Yep it was embarrassing, but I know what you did last summer, in the woods... +1