Dominus: sliderider has his troll(ish) behaviours . I said last time, he went into it, that he should not be a prick.

Yes, I know. I like feeding my troll so that he doesn't starve 😉

Does it matter what it's called?

The point was that Sliderider considered engine remakes pointless but then recommended one. To not look stupid he now claims that gemrb is not an engine remake but a port. So, uhm, yeah...

Iris030380 wrote:

I played this back in 2002 for the first time, on my Dell P4 2.0 and got almost to the end before a game bug made it impossible […]
Show full quote

I played this back in 2002 for the first time, on my Dell P4 2.0 and got almost to the end before a game bug made it impossible to progress. I just installed the Good Old Games version last week and have been hooked ever since. After turning off Direct Draw acceleration in dxdiag (to fix a bug which causes choppy gameplay on XP SP3 / Win7) I have so far hammered down the Goblin army invading Targos, ripped apart the Orc Fortress and am currently fireballing my way through the Ice Temple level 2.

I get flashbacks now and then of things to come, burnt into my mind from that epic AD+D experience back in 2002 (10 years ago!). I get images of a giant tree being burned down by fire lizards, dark caves full of traps and Hooked Horrors, giant metal golums surrounded by mind controlling mages and some gigantic green dragon in a jungle.

Been playing for a week and got a feeling I have a long way to go!

I keep thinking though, if a game THIS GOOD was made using the severely dated infinity engine, with the minute budget common back in 2002, why the hell do we have to suffer the on-rails shite that publishers these days pay millions to bring our way? If by some miracle some guys ever got a license to make IWD III or TOEE II .... or am I just dreaming? It would probably be dripping in bloom, have combo special moves and a Ministry of Sound soundtrack. And the PC version wouldn't work until patch #4 was released.

Here's to retro gaming. Can't beat the old ones!

If you like IWD2 and other Infinity Engine games, check out Project Eternity.
http://eternity.obsidian.net/
I don't think it is D&D, exactly, but very much in the same spirit.

Dominus wrote:

The point was that Sliderider considered engine remakes pointless but then recommended one. To not look stupid he now claims that gemrb is not an engine remake but a port. So, uhm, yeah...

It's not a remake, it is a port for operating systems that weren't around during the time of the Infinity Engine. To go to the effort of remaking the Infinity Engine for PC when you have the original and only have to change the data files to make a new game would be pointless. 🙄

it's not being done by the original coders, it's not using the original code -> it's an engine remake. You still don't get the difference and why it is the same as the engine remake you labeled pointless... take your meds again...

Dominus wrote:

it's not being done by the original coders, it's not using the original code -> it's an engine remake. You still don't get the difference and why it is the same as the engine remake you labeled pointless... take your meds again...

Who cares if it's being done by the original coders or not? What difference does that make? If Bioware had fired all the original coders between ID1 and ID2 would that make ID2 a remake just because none of the people who programmed the original Infinity Engine were working for the company any longer?

The project mentioned makes the games playable on platforms other than DOS/Windows so it is a PORT, NOT a remake. Just for future reference, porting is when you move a game from the platform it was originally developed on to another platform, which is what this program does, OK?

Genrb, exult, pentagram, nuvie, xu4 and the one you labeled usless as ... are all engine remakes. And these remakes can be ported to other platforms.
What you mean is a straight port done by the company.
The engine remakes are done by reverse engineering the original game and making a new engine. All those I mentioned are not using the original engine at all. So they are engine remakes...
Go back to the one you snubbed and tell the difference to gemrb...

So please take your meds against trollish behaviour again

http://en.m.wikipedia.org/wiki/Porting

sliderider wrote:

The project mentioned makes the games playable on platforms other than DOS/Windows so it is a PORT, NOT a remake. Just for future reference, porting is when you move a game from the platform it was originally developed on to another platform, which is what this program does, OK?

No. A port is when you take an existing codebase and rework it to work on another platform.

Same as Scummvm - it's not a port of DOTT, Monkey Island, whatever. It's a rewritten engine that plays the original game data files.

Game data is not code.

megatron-uk wrote:

No. A port is when you take an existing codebase and rework it to work on another platform. […]
Show full quote

sliderider wrote:

The project mentioned makes the games playable on platforms other than DOS/Windows so it is a PORT, NOT a remake. Just for future reference, porting is when you move a game from the platform it was originally developed on to another platform, which is what this program does, OK?

No. A port is when you take an existing codebase and rework it to work on another platform.

Same as Scummvm - it's not a port of DOTT, Monkey Island, whatever. It's a rewritten engine that plays the original game data files.

Game data is not code.

When you move a game from say, PC to Atari ST or Amiga you have to completely rewrite the code by necessity because a 68000 based system cannot execute x86 code but it's still considered a port and not a rewrite. Just because you are writing new code from scratch on a new system does not make it any less of a port.

Look at the wikipedia article.
And no, this shows again your ignorance, for porting software from pc to other systems doesn't necessarily mean you need to rewrite the code from ground up. See ScummVM, Exult or GemRB - these run well on other platforms besides the PC, including Amiga, PowerPC, Nintendo DS, Wii (Or Dosbox). If what you wrote were true then this wouldn't be possible...

Discussions with you almost always seem pointless because of your lack of knowledge and your inability to learn new stuff. Was this caused by your meds or are you forgetting to take your meds that help you in this regard?

sliderider wrote:

megatron-uk wrote:

No. A port is when you take an existing codebase and rework it to work on another platform. […]
Show full quote

sliderider wrote:

The project mentioned makes the games playable on platforms other than DOS/Windows so it is a PORT, NOT a remake. Just for future reference, porting is when you move a game from the platform it was originally developed on to another platform, which is what this program does, OK?

No. A port is when you take an existing codebase and rework it to work on another platform.

Same as Scummvm - it's not a port of DOTT, Monkey Island, whatever. It's a rewritten engine that plays the original game data files.

Game data is not code.

When you move a game from say, PC to Atari ST or Amiga you have to completely rewrite the code by necessity because a 68000 based system cannot execute x86 code but it's still considered a port and not a rewrite. Just because you are writing new code from scratch on a new system does not make it any less of a port.

Yep. And that is *not* what is happening with gemrb or scummvm. They're re-implementations of the game engine. Not ports as they don't involve the use of any original code.

Think of them as reverse engineering - the game itself is a black box; you don't know what is inside it, but you can observe what happens when you push a certain button or when your cursor hovers over a NPC character. From those observations you can begin to construct a new engine from scratch that very closely approximates the behaviour of the original.

A port involves translating one existing implementation - say your example of Motorola 68k assembly from the Amiga, to equivalent algorithms implemented in C, Pascal, x86 assembly, whatever. The key thing here is that by examining the original source code you know exactly what the behaviour should be. That's a port.

Do you see the key difference here between those two examples? One utilises the original source code for the game (directly using it to build a new executeable for your chosen platform or simply using it as a reference), the other closely approximates the functionality of the original game engine enough so that existing game data can be reused.

Don't bother he doesn't want to understand

megatron-uk wrote:

sliderider wrote:

megatron-uk wrote:

No. A port is when you take an existing codebase and rework it to work on another platform.

Same as Scummvm - it's not a port of DOTT, Monkey Island, whatever. It's a rewritten engine that plays the original game data files.

Game data is not code.

When you move a game from say, PC to Atari ST or Amiga you have to completely rewrite the code by necessity because a 68000 based system cannot execute x86 code but it's still considered a port and not a rewrite. Just because you are writing new code from scratch on a new system does not make it any less of a port.

Yep. And that is *not* what is happening with gemrb or scummvm. They're re-implementations of the game engine. Not ports as they don't involve the use of any original code.

And when you move the game from one platform to another, you aren't using any of the original code, either. If you were to write a game today for ARM and then wrote the same game for Intel you wouldn't be making a remake you would be doing a port. The same applies across operating systems so if you made an Android version first and then wanted to move it to Mac, you would be porting, not rewriting even though none of the original code could be reused on the target platform. The other assets like the artwork or 3D models might be reused, but all the original code would have to be discarded and replaced with code that is executable on the target platform.

Dominus wrote:

Don't bother he doesn't want to understand

No, you just won't stand having your own arguments turned against you.

And when you move the game from one platform to another, you aren't using any of the original code, either.

That's where you are wrong. In the example I gave there is *NO* rewrite necessary, just some added code and that's it. That's porting.

If you were to write a game today for ARM and then wrote the same game for Intel you wouldn't be making a remake you would be doing a port.

that depends, if it is done by the same company or under their name it is considered not a true port if the game was completely rewritten - a true port doesn't need to be rewritten.

The same applies across operating systems so if you made an Android version first and then wanted to move it to Mac, you would be porting

True

not rewriting even though none of the original code could be reused on the target platform.

Not true, that is a rewrite.

The other assets like the artwork or 3D models might be reused, but all the original code would have to be discarded and replaced with code that is executable on the target platform.

and no, again your lack of knowledge, these days, for true porting, you can reuse almost all of the code. Most of the times you just need some ifdef PLATFORMNAME and a compiler targeting that platform.

No, you just won't stand having your own arguments turned against you.

Again wrong, I just can't stand you not understand the difference between an engine rewrite, a port, a true port. Your meds cloud your mind and you *think* you are turning an argument against me/us, while there is just evidence that you don't understand things.

But I'll try to tell you again how each works:

true port:
software changed so it works on another platform. If the original code is written with portability in mind, this can be done. Exult (http://exult.sf.net) as an example can be compiled for multiple platforms: Windows, Linux, Mac OS, Mac OS X (ppc and intel), Amiga, Xbox, Playstation Portable, Zaurus, iOS, Android. Of course the code will need some adjustments, mostly regarding the controls.

rewrite:
software is rewritten and parts of the original code is used (if any at all). Maybe the new software will make use of the data files of the original software. A rewrite can result in more portability. A rewrite is almost always done by the original company with insight int the original code.

engine remake: Games specific. Also a rewrite of a game engine but in most cases there is no access to the original code and thus everything needs to be figured out by trial and error or decompiling the original engine. Almost all engine remakes are portable, run on a lot of platforms.
Examples: GemRB, Exult, ScummVM etc., including the one you dissed some time ago as useless.

console port:
(quoting from http://en.wikipedia.org/wiki/Porting)

Porting is also the term used when a video game designed to run on one platform, be it an arcade, video game console, or personal computer, is converted to run on a different platform. Earlier video game "ports" were often not true ports, but rather reworked versions of the games. However, more and more video games are now being developed using software that can output code for one or more consoles as well as for a PC without the need for actual porting. Many early ports suffered significant gameplay quality issues because the hardware of PCs and consoles differed so dramatically.

so, yes in some areas you were "allowed" to label rewritten game engines for other platforms as ports but keep in mind these ports were all done by having access to the original code and by the same company (or contract work for that company - exceptions to this rule are of course only proving the rule 😀).

This is how it is generally regarded, except by people on heavy medication. Now please explain how GemRB can still be regarded as a port and not an engine remake...

"and no, again your lack of knowledge, these days, for true porting, you can reuse almost all of the code. Most of the times you just need some ifdef PLATFORMNAME and a compiler targeting that platform."

So tell me then, how do you port a game written in x86 code to say, a PowerPC processor, and still use the x86 code? How does the PowerPC processor interpret and run the code? You have to discard the x86 code and replace it with PowerPC code. I don't care if you use something like a cross compiler to translate x86->PowerPC, the finished product on the PowerPC machine still is NOT running x86 code. There is ZERO x86 code in the finished port.

So tell me then, how do you port a game written in x86 code to say, a PowerPC processor, and still use the x86 code? How does the PowerPC processor interpret and run the code? You have to discard the x86 code and replace it with PowerPC code. I don't care if you use something like a cross compiler to translate x86->PowerPC, the finished product on the PowerPC machine still is NOT running x86 code. There is ZERO x86 code in the finished port.

You don't run code, you run binaries compiled from that code. And the code doesn't change... really, get a clue...

sliderider wrote:

"and no, again your lack of knowledge, these days, for true porting, you can reuse almost all of the code. Most of the times you just need some ifdef PLATFORMNAME and a compiler targeting that platform."

So tell me then, how do you port a game written in x86 code to say, a PowerPC processor, and still use the x86 code? How does the PowerPC processor interpret and run the code? You have to discard the x86 code and replace it with PowerPC code. I don't care if you use something like a cross compiler to translate x86->PowerPC, the finished product on the PowerPC machine still is NOT running x86 code. There is ZERO x86 code in the finished port.

Because you don't write x86/ppc/arm code.

You write in C/C++, or an equivalent, which is a (mostly) platform agnostic language. That code (which is simply text, there's nothing about it that ties it to one cpu architecture or another) is then turned into an executeable binary (your 'x86 code') by a compiler and linked to any supporting library routines (eg for input/output, audio playback, video compression etc).

As long as someone supplies a working c compiler, linker and the correct libraries, your C code will compile to a runnable programme for any platform.

It seems as though you believe that everything is written in assembly language, or even machine code specific to the host machine. That may have been true in 8bit and early 16bit home computer era, but it hasn't been the case for a long, long time.