Follow TV Tropes

Following

History UsefulNotes / SoftwarePorting

Go To



Also, as of 2017, the popular computer systems available have changed since the early days of personal computers and game consoles. The UsefulNotes/PlayStation4 and UsefuleNotes/XboxONE use the same basic system architecture as most [=PCs=]. This makes porting between them much easier than before. Likewise since the Xbox One also runs much of the same software libraries as a Windows PC, porting between those two should also be a much easier task.

to:

Also, as of 2017, the popular computer systems available have changed since the early days of personal computers and game consoles. The UsefulNotes/PlayStation4 and UsefuleNotes/XboxONE UsefulNotes/XboxOne use the same basic system architecture as most [=PCs=]. This makes porting between them much easier than before. Likewise since the Xbox One also runs much of the same software libraries as a Windows PC, porting between those two should also be a much easier task.


Also, as of 2017, the popular computer systems available have changed since the early days of personal computers and game consoles. The UsefulNotes/PlayStation4 and UsefuleNotes/XboxOne use the same basic system architecture as most [=PCs=]. This makes porting between them much easier than before. Likewise since the Xbox One also runs much of the same software libraries as a Windows PC, porting between those two should also be a much easier task.

to:

Also, as of 2017, the popular computer systems available have changed since the early days of personal computers and game consoles. The UsefulNotes/PlayStation4 and UsefuleNotes/XboxOne UsefuleNotes/XboxONE use the same basic system architecture as most [=PCs=]. This makes porting between them much easier than before. Likewise since the Xbox One also runs much of the same software libraries as a Windows PC, porting between those two should also be a much easier task.


** Processor architectures vary wildly from one another, and it's probably a miracle that two are even "binary compatible" (this is the most compatibility you can get, where the 0s and 1s process ''exactly the same''). For example, porting from the 65816 (Super Nintendo) architecture to the M68000 (Sega Genesis) is no easy task, since the two processors use entirely different, entirely incompatible machine languages.

to:

** Processor architectures vary wildly from one another, and it's probably a miracle that when two are even actually "binary compatible" (this is the most compatibility you can get, where the 0s and 1s process ''exactly the same''). For example, porting from the 65816 (Super Nintendo) architecture to the M68000 (Sega Genesis) is no easy task, since the two processors use entirely different, entirely incompatible machine languages.


*** For example, a common complaint when SNES games that were ported over to the UsefulNotes/GameBoyAdvance was usually the music. The audio chip used was only a DAC, software had to do all the mixing whereas the {{SNES}} [=SPC700=] had hardware mixing.

to:

*** For example, a common complaint when SNES games that were ported over to the UsefulNotes/GameBoyAdvance was usually the music. The audio chip used was only a DAC, software had to do all the mixing whereas the {{SNES}} {{UsefulNotes/SNES}} [=SPC700=] had hardware mixing.


*** For example, ''VideoGame/DeusExInvisibleWar'' was developed more with the Xbox in mind than the PC. The biggest evidence to support this is that the level maps in ''Invisible War'' were much smaller than in the prequel game. Much of this design decision could be attributed to the Xbox having 64 MB of RAM while gaming [=PCs=] at the time commonly had at least 512 MB. This likely aided the development of the PC version by not needing to do any extra work. i.e., not having to chop level sizes down to fit the Xbox, much like how levels in ''Deus Ex'' were chopped up for the PS2 version

to:

*** For example, ''VideoGame/DeusExInvisibleWar'' was developed more with the Xbox in mind than the PC. The biggest evidence to support this is that the level maps in ''Invisible War'' were much smaller than in the prequel game. Much of this design decision could be attributed to the Xbox having 64 MB of RAM while gaming [=PCs=] at the time commonly had at least 512 MB. This likely aided the development of the PC version by not needing to do any extra work. i.e., not having to chop level sizes down to fit the Xbox, much like how levels in ''Deus Ex'' were chopped up for the PS2 [=PS2=] version


*** For example, ''VideoGame/DeusExInvisibleWar'' was developed more with the Xbox in mind than the PC. The biggest evidence to support this is that the level maps in ''Invisible War'' are much smaller than in the prequel game. Much of this design decision could be attributed to the Xbox having 64 MB of RAM while gaming [=PCs=] at the time commonly had at least 512 MB. This likely aided the development of the PC version by not needing to do any extra work. i.e., chopping level sizes down to fit the Xbox, much like how levels in ''Deus Ex'' were chopped up for the PS2 version

to:

*** For example, ''VideoGame/DeusExInvisibleWar'' was developed more with the Xbox in mind than the PC. The biggest evidence to support this is that the level maps in ''Invisible War'' are were much smaller than in the prequel game. Much of this design decision could be attributed to the Xbox having 64 MB of RAM while gaming [=PCs=] at the time commonly had at least 512 MB. This likely aided the development of the PC version by not needing to do any extra work. i.e., chopping not having to chop level sizes down to fit the Xbox, much like how levels in ''Deus Ex'' were chopped up for the PS2 version


*** For example, ''VideoGame/DeusExInvisibleWar'', which was made for the XBox in mind, was considered paltry on the PC, despite the XBox running fully compatible x86 PC hardware. The developers actually didn't want to port it and just rebuilt the game for the PC environment. But because the [=PCs=] of the time were already more advanced than XBox (like, routinely sporting 512MB of memory, instead of 64MB, for example), the game looked quite dated compared to the contemporary PC-exclusive offerings.

to:

*** For example, ''VideoGame/DeusExInvisibleWar'', which ''VideoGame/DeusExInvisibleWar'' was made for developed more with the XBox Xbox in mind, was considered paltry on mind than the PC, despite PC. The biggest evidence to support this is that the XBox running fully compatible x86 PC hardware. The developers actually didn't want to port it and just rebuilt level maps in ''Invisible War'' are much smaller than in the game for prequel game. Much of this design decision could be attributed to the PC environment. But because the Xbox having 64 MB of RAM while gaming [=PCs=] of at the time commonly had at least 512 MB. This likely aided the development of the PC version by not needing to do any extra work. i.e., chopping level sizes down to fit the Xbox, much like how levels in ''Deus Ex'' were already more advanced than XBox (like, routinely sporting 512MB of memory, instead of 64MB, chopped up for example), the game looked quite dated compared to the contemporary PC-exclusive offerings.PS2 version


*** For example, a common complaint when SNES games that were ported over to the GameBoyAdvance was usually the music. The audio chip used was only a DAC, software had to do all the mixing whereas the {{SNES}} [=SPC700=] had hardware mixing.

to:

*** For example, a common complaint when SNES games that were ported over to the GameBoyAdvance UsefulNotes/GameBoyAdvance was usually the music. The audio chip used was only a DAC, software had to do all the mixing whereas the {{SNES}} [=SPC700=] had hardware mixing.


*** For example, ''VideoGame/DeusExInvisibleWar'', which was made for the XBox in mind, was considered paltry on the PC, despite the XBox running fully compatible x86 PC hardware. The developers actually didn't want to port it and just rebuilt the game for the PC environment. But because the [=PCs=] of the time were already more advanced than XBox (like, routinely sporting 512MB of memroy, instead of 64Mb, for example), the game looked quite dated compared to the contemporary PC-exclusive offerings.

to:

*** For example, ''VideoGame/DeusExInvisibleWar'', which was made for the XBox in mind, was considered paltry on the PC, despite the XBox running fully compatible x86 PC hardware. The developers actually didn't want to port it and just rebuilt the game for the PC environment. But because the [=PCs=] of the time were already more advanced than XBox (like, routinely sporting 512MB of memroy, memory, instead of 64Mb, 64MB, for example), the game looked quite dated compared to the contemporary PC-exclusive offerings.


*** For example, ''VideoGame/DeusExInvisibleWar'', which was made for the XBox in mind, was considered paltry on the PC, despite the XBox running fully compatible x86 PC hardware. While not exactly a port, the developers didn't want to "port" it and thus the levels were assuming a machine with 64MB of memory, when [=PCs=] of the time could easily have 512MB of memory.

to:

*** For example, ''VideoGame/DeusExInvisibleWar'', which was made for the XBox in mind, was considered paltry on the PC, despite the XBox running fully compatible x86 PC hardware. While not exactly a port, the The developers actually didn't want to "port" port it and thus just rebuilt the levels were assuming a machine with 64MB of memory, when game for the PC environment. But because the [=PCs=] of the time could easily have were already more advanced than XBox (like, routinely sporting 512MB of memory.memroy, instead of 64Mb, for example), the game looked quite dated compared to the contemporary PC-exclusive offerings.


** Using a programming language that has limited or no support for the platform. One of the easiest ways to make software not-portable is to write it in assembly language, which is specific to a family of hardware. Even among high-level languages, some are used more on some environments than others: it would be harder to port a C# application to Mac OS, or an Objective-C application to Windows, than it would be to port a C++ application either way. This also includes relying on libraries or UsefulNotes/{{API}}s that don't have support on the platform.

to:

** Using a programming language that has limited or no support for the platform. One of the easiest ways to make software not-portable is to write it in assembly language, which is specific to a family of hardware. Even among high-level languages, some are used more on some environments than others: it would be harder to port a C# application to Mac OS, or an Objective-C application to Windows, than it would be to port a C++ application either way. This also includes relying
** Relying
on libraries or UsefulNotes/{{API}}s that don't have support on the platform.
platform. An example is if a developer primarily uses [=DirectX=] as the API of choice, it'll be difficult to port their applications over to non-Microsoft systems as [=DirectX=] is only supported on Microsoft systems.


Also, as of 2017, the popular computer systems available have changed since the early days of personal computers and game consoles. The ''UsefulNotes/PlayStation4'' and ''UsefuleNotes/XboxOne'' use the same basic system architecture as most [=PCs=]. This makes porting between them much easier than before. Likewise since the Xbox One also runs much of the same software library as a Windows PC, porting between those two should also be a much easier task.

to:

Also, as of 2017, the popular computer systems available have changed since the early days of personal computers and game consoles. The ''UsefulNotes/PlayStation4'' UsefulNotes/PlayStation4 and ''UsefuleNotes/XboxOne'' UsefuleNotes/XboxOne use the same basic system architecture as most [=PCs=]. This makes porting between them much easier than before. Likewise since the Xbox One also runs much of the same software library libraries as a Windows PC, porting between those two should also be a much easier task.


** Processor architectures vary wildly from one another, and it's probably a miracle that two are even "binary compatible" (this is the most compatibility you can get, where the 0s and 1s process ''exactly the same''). For example, porting from the 65816 (Super Nintendo) architecture to the M68000 (Sega Genesis) is no easy task, since the two processors use entirely different, entirely incompatible machine languages. On the other hand, PlayStation 4, Xbox One and a modern PC all uses the same amd64 processor and general UEFI PC architecture, allowing for potentially simpler porting. These days this is much less of a problem, because nowadays code is usually written in a high-level language such as C++, but processor architecture can still cause issues in high-performance code.

to:

** Processor architectures vary wildly from one another, and it's probably a miracle that two are even "binary compatible" (this is the most compatibility you can get, where the 0s and 1s process ''exactly the same''). For example, porting from the 65816 (Super Nintendo) architecture to the M68000 (Sega Genesis) is no easy task, since the two processors use entirely different, entirely incompatible machine languages. On the other hand, PlayStation 4, Xbox One and a modern PC all uses the same amd64 processor and general UEFI PC architecture, allowing for potentially simpler porting. These days this is much less of a problem, because nowadays code is usually written in a high-level language such as C++, but processor architecture can still cause issues in high-performance code.



** Programs between operating systems won't work, even if the hardware is exactly the same. The OS has specific function calls to do things, and between Linux, UNIX, [=Mac OS X=], and Windows, they're all different. [[note]]Linux, UNIX, and [=Mac OS X=] more or less follow POSIX which is a standard. Of course, nobody forced them how to implement the standard.[[/note]]
*** There are still examples that goes the other way though. Xbox One have the same kernel, driver model and programming model as desktop Windows, and uses the same amd64 UEFI PC architecture. If Microsoft decided to release a Windows 10 update with all Xbox One support libraries, any and all Xbox games will be immediately playable on any Windows 10 PC. No porting is even needed.
** Using a programming language that has limited or no support for the platform. One of the easiest ways to make software not-portable is to write it in assembly language (which is specific to a family of hardware). Even among high-level languages, some are used more on some environments than others: it would be harder to port a C# application to Mac OS, or an Objective-C application to Windows, than it would be to port a C++ application either way.
*** This also includes relying on libraries or UsefulNotes/{{API}}s that don't have support on the platform.
** Fortunately, there is a novel approach to avoiding potential software incompatibilities, and that is translating and compiling the base code from one programming language to another without the need for additional libraries or [=APIs=] that will bloat both the program and the system it is installed in. One example is [[http://www.eqela.com/ Eqela]].
*** Another alternative is to write games in some universally accepted scripting languages that is supported on most hardware platforms. [=WebGL=] is such an example, shoehorning a full [=OpenGL ES=] into [=JavaScript=], allowing games being written in this scripting language virtually any web browser will accept, and allowing games being played right in the browser of the user without being downloaded first.

to:

** Programs between operating systems won't work, even if the hardware is exactly the same. The OS has specific function calls to do things, and between Linux, UNIX, [=Mac OS X=], and Windows, they're all different. [[note]]Linux, While UNIX, and [=Mac OS X=] more and Linux (more or less less) follow the POSIX which is a standard. Of course, nobody forced them how to implement the standard.[[/note]]
*** There are still examples
standard, they may have implementation details that goes the other way though. Xbox One have the same kernel, driver model and programming model as desktop Windows, and uses the same amd64 UEFI PC architecture. If Microsoft decided to release a Windows 10 update don't align with all Xbox One support libraries, any and all Xbox games will be immediately playable on any Windows 10 PC. No porting is even needed.
each other.
** Using a programming language that has limited or no support for the platform. One of the easiest ways to make software not-portable is to write it in assembly language (which language, which is specific to a family of hardware). hardware. Even among high-level languages, some are used more on some environments than others: it would be harder to port a C# application to Mac OS, or an Objective-C application to Windows, than it would be to port a C++ application either way.
***
way. This also includes relying on libraries or UsefulNotes/{{API}}s that don't have support on the platform.
** Fortunately, there is a novel approach to avoiding potential software incompatibilities, and that is translating and compiling the base code from one programming language to another without the need for additional libraries or [=APIs=] that will bloat both the program and the system it is installed in. One example is [[http://www.eqela.com/ Eqela]].
*** Another alternative is to write games in some universally accepted scripting languages that is supported on most hardware platforms. [=WebGL=] is such an example, shoehorning a full [=OpenGL ES=] into [=JavaScript=], allowing games being written in this scripting language virtually any web browser will accept, and allowing games being played right in the browser of the user without being downloaded first.


Added DiffLines:


Fortunately, there is a novel approach to avoiding potential software incompatibilities, and that is translating and compiling the base code from one programming language to another without the need for additional libraries or [=APIs=] that will bloat both the program and the system it is installed in. One example is [[http://www.eqela.com/ Eqela]]. Another alternative is to write games in some universally accepted scripting languages that is supported on most hardware platforms. [=WebGL=] is such an example, shoehorning a full [=OpenGL ES=] into [=JavaScript=], allowing games being written in this scripting language virtually any web browser will accept, and allowing games being played right in the browser of the user without being downloaded first.

Also, as of 2017, the popular computer systems available have changed since the early days of personal computers and game consoles. The ''UsefulNotes/PlayStation4'' and ''UsefuleNotes/XboxOne'' use the same basic system architecture as most [=PCs=]. This makes porting between them much easier than before. Likewise since the Xbox One also runs much of the same software library as a Windows PC, porting between those two should also be a much easier task.



to:

*** Another alternative is to write games in some universally accepted scripting languages that is supported on most hardware platforms. [=WebGL=] is such an example, shoehorning a full [=OpenGL ES=] into [=JavaScript=], allowing games being written in this scripting language virtually any web browser will accept, and allowing games being played right in the browser of the user without being downloaded first.


** Processor architectures vary wildly from one another, and it's probably a miracle that two are even "binary compatible" (this is the most compatibility you can get, where the 0s and 1s process ''exactly the same''). For example, porting from the 65816 (Super Nintendo) architecture to the M68000 (Sega Genesis) is no easy task, since the two processors use entirely different, entirely incompatible machine languages. These days this is much less of a problem, because nowadays code is usually written in a high-level language such as C++, but processor architecture can still cause issues in high-performance code.

to:

** Processor architectures vary wildly from one another, and it's probably a miracle that two are even "binary compatible" (this is the most compatibility you can get, where the 0s and 1s process ''exactly the same''). For example, porting from the 65816 (Super Nintendo) architecture to the M68000 (Sega Genesis) is no easy task, since the two processors use entirely different, entirely incompatible machine languages. On the other hand, PlayStation 4, Xbox One and a modern PC all uses the same amd64 processor and general UEFI PC architecture, allowing for potentially simpler porting. These days this is much less of a problem, because nowadays code is usually written in a high-level language such as C++, but processor architecture can still cause issues in high-performance code.



** Programs between operating systems won't work, even if the hardware is exactly the same. The OS has specific function calls to do things, and between Linux, UNIX, [=Mac OS X=], and Windows, they're all different. [[note]]Linux, UNIX, and [=Mac OS X=] more or less follow POSIX which is a standard. Of course, nobody told them how to implement the standard.[[/note]]

to:

** Programs between operating systems won't work, even if the hardware is exactly the same. The OS has specific function calls to do things, and between Linux, UNIX, [=Mac OS X=], and Windows, they're all different. [[note]]Linux, UNIX, and [=Mac OS X=] more or less follow POSIX which is a standard. Of course, nobody told forced them how to implement the standard.[[/note]][[/note]]
*** There are still examples that goes the other way though. Xbox One have the same kernel, driver model and programming model as desktop Windows, and uses the same amd64 UEFI PC architecture. If Microsoft decided to release a Windows 10 update with all Xbox One support libraries, any and all Xbox games will be immediately playable on any Windows 10 PC. No porting is even needed.

Showing 15 edit(s) of 19

Top

How well does it match the trope?

Example of:

/

Media sources:

/

Report