Escape from Colditz bug - Page 3

Retro1234 · 13 June 2009, 11:21

I have tested the files and Bollocks!! the bug was still there so looks like theres no bug with the IPF.
I know this tunnel can be avoided as Port_H has shown but I still think its a shame. I would think this bug would have been spotted and maybe there is another version, I hope so.
Thanks again davideo

Quote:

Originally Posted by IFW

If anyone has the original of Escape from Colditz, please get in contact.
Maybe there are two versions of the game, and one of them has no/less bugs.

ungi · 13 June 2009, 11:54

Quote:

Originally Posted by Boo Boo

I have tested the files and Bollocks!! the bug was still there

anyone contacted the publisher and asked for a bugfix? :-)))

Aperture · 18 August 2009, 12:08

Well, since I announced it elsewhere, and this seems to be the most recent thread regarding Escape From Colditz, might as well announce my Windows and PSP ports here as well (and yes, I did fix the tunnel exit bug in these versions

).

If you want to play the game natively on Windows or PSP (as well as benefit from new features like save/load or guards who remember when they've seen a pass for instance), have a look here.

andreas · 21 August 2009, 12:22

Has anyone here ever verified the bug on the REAL thing?

There was a similar case from the past that I remember: I think it was one of the Dungeon Master games and there was a very annoying closed-doors issue. VERY much later Toni Wilen confirmed that it was a 68020+ specialty which wasn't emulated, causing the closed doors!!!

But I admit it will be a hell of a lot of work to get that far on the real thing and without savestate, because the game is bloody hard!
Yet basically, it could be an emulation issue!

(And alas, I do know well you cannot test IPFs on the real thing just like that, be they as perfect as possible)

Retro1234 · 21 August 2009, 12:34

Quote:

Originally Posted by andreas

Has anyone here ever verified the bug on the REAL thing?

There was a similar case from the past that I remember: I think it was one of the Dungeon Master games and there was a very annoying closed-doors issue. VERY much later Toni Wilen confirmed that it was a 68020+ specialty which wasn't emulated, causing the closed doors!!!

But I admit it will be a hell of a lot of work to get that far on the real thing and without savestate, because the game is bloody hard!

Yet basically, it could be an emulation issue!

(And alas, I do know well you cannot test IPFs on the real thing just like that, be they as perfect as possible)

Intresting - To be fair the game can be completed anyway but puts me off playing knowing theres a bug - I have tried the game on lots of different setups and the IPF can be copied back to disk in this case.

As Aperture has done a lot of work exploring the game he might be able to say if the problem is just in the map data or the executable.

Aperture · 21 August 2009, 19:37

I'm pretty sure the bug also occurs on the real thing, as this is a problem with the offsets added by the main application when doing room I/O. I'm afraid that this looks like yet another case of the game not having been tested/polished enough before release.

The file of interest to us here is COLDITZ-LOADER, which is the main game application. Note that on most images, COLDITZ-LOADER has been compressed into SKR_COLD by the Skid Row gang.

This file contains the (Y,X) offset that is added to the exit location when entering a room, and if you really want to know more, you can look for what I called "Hat Rabbit Offset" in my source (because these offsets pretty much tell you where the rabbit exits from the magician hat

)

In this case, the problematic value from COLDITZ-LOADER is the FFDC 000E (Y, X offsets, signed words), found at address 0x3e9a, as it tells the game to place our guy at -36 (y), +15 (x) from the tunnel exit tile's origin, and this end up being within a wall or desk when these objects are too close.
Changing FFDC to FFEC seems to do the trick from what I have just tested, as it places us further down on the tunnel exit.

Now, if you want to patch the game you have 3 possibilities:

Patch at runtime, using action replay (or the UAE emulated action replay). From what I have seen, COLDITZ-LOADER is always loaded at address 0x00000080 in memory, so what you want do to is issue an "m 3f1a FFEC" to reduce the Y offset.
Patch COLDITZ-LOADER @ 0x39ea and re-compress it into SKR_COLD. Only problem is, while I can provide you with the decompression routine (see "uncompress()" in http://code.google.com/p/colditzesca...nk/low-level.c) I don't have the compression one, since I didn't really have any use for it => you'll have to figure that one out by yourself.
I'm pretty sure someone familiar with compression (or possibly ex Skid Row members...) will recognize the algorithm being used there (which I wouldn't mind knowing the name of, just for the sake of it, since I blindly reverse engineered the stuff before I moved on to the rest of the game engine).
Oh, and FYI, colditz escape! does create and save COLDITZ-LOADER for SKR_COLD, when it cannot find COLDITZ-LOADER.
If there is enough space on the disk, just save the uncompressed COLDITZ-LOADER. If my memory serves me well, I think the uncompressed loader also contains the code to copy itself onto address 0x00000080 when launched from the startup-sequence, but you might want to check that out...

Still, I wish people just used my engine to play the game now, instead of the old slightly buggy Amiga one...

PS: While I'm giving tricks away, if you want to render all guards ineffective in the original game (except one), you can issue an "m 20d0 0". The counter at 20d0 is the number of guards the game is aware of for motion & pursuit.

Hungry Horace · 21 August 2009, 19:47

Bored Seal is the man to speak to with regards to getting this fix added to the WHDload slave

Retro1234 · 21 August 2009, 20:59

Thank you for your reply

I can see you realy have been bussy reversing this game - Not a challenge I would fancy - considering the complexity of the game

Thanks theres a lot of information for me to look through great stuff!

Please could you upload the decompressed file

Ive been loooking at the WHDload install and theres a file called Colditz_Demo maybe this is the Colditz_Loader ill have to have a closer look.

Quote:

Originally Posted by Aperture

play the game now, instead of the old slightly buggy Amiga one...

Of-Course dont worry about that I will playing your game - Just if the game could be fixed - Then Great

Quote:

Originally Posted by Hungry Horace

Bored Seal is the man to speak to with regards to getting this fix added to the WHDload slave

Good idea HH - I probably do this when I realise this is beyond my capabilities

- But I like to try before I bother the WHDload authors.

Hungry Horace · 21 August 2009, 21:27

Quote:

Originally Posted by Boo Boo

Good idea HH - I probably do this when I realise this is beyond my capabilities

- But I like to try before I bother the WHDload authors.

oh, do you have the source? If so, I'm sure between us we could fix it BooBoo - perhaps a trip to abime.net IRC is in order for discussion

Galahad/FLT · 21 August 2009, 21:31

Quote:

Originally Posted by Aperture

I'm pretty sure the bug also occurs on the real thing, as this is a problem with the offsets added by the main application when doing room I/O. I'm afraid that this looks like yet another case of the game not having been tested/polished enough before release.

The file of interest to us here is COLDITZ-LOADER, which is the main game application. Note that on most images, COLDITZ-LOADER has been compressed into SKR_COLD by the Skid Row gang.

This file contains the (Y,X) offset that is added to the exit location when entering a room, and if you really want to know more, you can look for what I called "Hat Rabbit Offset" in my source (because these offsets pretty much tell you where the rabbit exits from the magician hat

)

In this case, the problematic value from COLDITZ-LOADER is the FFDC 000E (Y, X offsets, signed words), found at address 0x3e9a, as it tells the game to place our guy at -36 (y), +15 (x) from the tunnel exit tile's origin, and this end up being within a wall or desk when these objects are too close.
Changing FFDC to FFEC seems to do the trick from what I have just tested, as it places us further down on the tunnel exit.

Now, if you want to patch the game you have 3 possibilities:

Patch at runtime, using action replay (or the UAE emulated action replay). From what I have seen, COLDITZ-LOADER is always loaded at address 0x00000080 in memory, so what you want do to is issue an "m 3f1a FFEC" to reduce the Y offset.
Patch COLDITZ-LOADER @ 0x39ea and re-compress it into SKR_COLD. Only problem is, while I can provide you with the decompression routine (see "uncompress()" in http://code.google.com/p/colditzesca...nk/low-level.c) I don't have the compression one, since I didn't really have any use for it => you'll have to figure that one out by yourself.
I'm pretty sure someone familiar with compression (or possibly ex Skid Row members...) will recognize the algorithm being used there (which I wouldn't mind knowing the name of, just for the sake of it, since I blindly reverse engineered the stuff before I moved on to the rest of the game engine).
Oh, and FYI, colditz escape! does create and save COLDITZ-LOADER for SKR_COLD, when it cannot find COLDITZ-LOADER.
If there is enough space on the disk, just save the uncompressed COLDITZ-LOADER. If my memory serves me well, I think the uncompressed loader also contains the code to copy itself onto address 0x00000080 when launched from the startup-sequence, but you might want to check that out...

Still, I wish people just used my engine to play the game now, instead of the old slightly buggy Amiga one...

PS: While I'm giving tricks away, if you want to render all guards ineffective in the original game (except one), you can issue an "m 20d0 0". The counter at 20d0 is the number of guards the game is aware of for motion & pursuit.

I've applied your patch to the Skid Row version, there was some spare bytes in the decrunch header of 'SKR_COLD', so it patches the correct data before it relocates to the correct memory space.

In the zone now.

TCD · 21 August 2009, 21:34

Cheers Galahad

Retro1234 · 21 August 2009, 21:56

Quote:

Originally Posted by Hungry Horace

oh, do you have the source? If so, I'm sure between us we could fix it BooBoo - perhaps a trip to abime.net IRC is in order for discussion

If only I was anygood at ASM

- I was simply going to edit the Colditz_Loader/Colditz_Demo file - A proper patch of the WHDload slave would of-course be much better!!

Quote:

Originally Posted by Galahad/FLT

I've applied your patch to the Skid Row version, there was some spare bytes in the decrunch header of 'SKR_COLD', so it patches the correct data before it relocates to the correct memory space.

In the zone now.

Sweet!!!!

its great to see how stuff round here gets done

Ill test as soon as possible - If you could, could you upload the decompressed SKR_COLD file.

Galahad/FLT · 21 August 2009, 22:02

patched 'colditz_demo' file in the zone for the WHDLoad version, just copy it over the same named file that is installed and this should fix the same tunnel bug

Retro1234 · 21 August 2009, 22:08

Thats brilliant ill get testing

Thanks Guys

Retro1234 · 21 August 2009, 22:52

Ill do a lttle more testing but

I Just tested the WHDload version - I AusFarted the tunnel and No Freaze!!

Galahad/FLT · 21 August 2009, 22:58

Da ist wunderbar, jah?

TCD · 21 August 2009, 23:01

Jawohl mein Herr

Disk version seems to work a treat now

Galahad/FLT · 21 August 2009, 23:05

Quote:

Originally Posted by TheCyberDruid

Jawohl mein Herr

Disk version seems to work a treat now

Das ist gut kinder?

Aperture · 21 August 2009, 23:06

Nice patch, Galahad.

It's even better than any of the options I suggested, as applying the patch in the decrunch header doesn't mess with the MD5 sums of the COLDITZ-LOADER, which I check in my game engine. This way, you'll be able to use a patched SKR_COLD with it as well.

There seems to be a small problem with the ADF you uploaded in the zone however. Some of the IFFs in it have been renamed (eg. "DPIC.6(EXERCISE)" should really be "PIC6(EXERCISE)").
This makes the original game crash at 09:54, when the exercise picture is called. At least, that's what I got in WinUAE with that ADF.

I'll see if I can upload a working ADF with your patch in the zone...

Galahad/FLT · 21 August 2009, 23:16

Quote:

Originally Posted by Aperture

Nice patch, Galahad.

It's even better than any of the options I suggested, as applying the patch in the decrunch header doesn't mess with the MD5 sums of the COLDITZ-LOADER, which I check in my game engine. This way, you'll be able to use a patched SKR_COLD with it as well.

There seems to be a small problem with the ADF you uploaded in the zone however. Some of the IFFs in it have been renamed (eg. "DPIC.6(EXERCISE)" should really be "PIC6(EXERCISE)").
This makes the original game crash at 09:54, when the exercise picture is called. At least, that's what I got in WinUAE with that ADF.

I'll see if I can upload a working ADF with your patch in the zone...

No idea, I just downloaded the first Skid Row version I could find and hacked the SKR_COLD file, I didn't touch anything else on the disk nor did I playtest, just applied the data change you said.

21 August 2009, 19:37	#46
Aperture Registered User Join Date: Aug 2009 Location: .ie Posts: 10	I'm pretty sure the bug also occurs on the real thing, as this is a problem with the offsets added by the main application when doing room I/O. I'm afraid that this looks like yet another case of the game not having been tested/polished enough before release. The file of interest to us here is COLDITZ-LOADER, which is the main game application. Note that on most images, COLDITZ-LOADER has been compressed into SKR_COLD by the Skid Row gang. This file contains the (Y,X) offset that is added to the exit location when entering a room, and if you really want to know more, you can look for what I called "Hat Rabbit Offset" in my source (because these offsets pretty much tell you where the rabbit exits from the magician hat ) In this case, the problematic value from COLDITZ-LOADER is the FFDC 000E (Y, X offsets, signed words), found at address 0x3e9a, as it tells the game to place our guy at -36 (y), +15 (x) from the tunnel exit tile's origin, and this end up being within a wall or desk when these objects are too close. Changing FFDC to FFEC seems to do the trick from what I have just tested, as it places us further down on the tunnel exit. Now, if you want to patch the game you have 3 possibilities: Patch at runtime, using action replay (or the UAE emulated action replay). From what I have seen, COLDITZ-LOADER is always loaded at address 0x00000080 in memory, so what you want do to is issue an "m 3f1a FFEC" to reduce the Y offset. Patch COLDITZ-LOADER @ 0x39ea and re-compress it into SKR_COLD. Only problem is, while I can provide you with the decompression routine (see "uncompress()" in http://code.google.com/p/colditzesca...nk/low-level.c) I don't have the compression one, since I didn't really have any use for it => you'll have to figure that one out by yourself. I'm pretty sure someone familiar with compression (or possibly ex Skid Row members...) will recognize the algorithm being used there (which I wouldn't mind knowing the name of, just for the sake of it, since I blindly reverse engineered the stuff before I moved on to the rest of the game engine). Oh, and FYI, colditz escape! does create and save COLDITZ-LOADER for SKR_COLD, when it cannot find COLDITZ-LOADER. If there is enough space on the disk, just save the uncompressed COLDITZ-LOADER. If my memory serves me well, I think the uncompressed loader also contains the code to copy itself onto address 0x00000080 when launched from the startup-sequence, but you might want to check that out... Still, I wish people just used my engine to play the game now, instead of the old slightly buggy Amiga one... PS: While I'm giving tricks away, if you want to render all guards ineffective in the original game (except one), you can issue an "m 20d0 0". The counter at 20d0 is the number of guards the game is aware of for motion & pursuit.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Escape From Colditz crashes	crusader86x	support.WinUAE	6	17 December 2009 20:05
Escape From Colditz!	jamamoto	request.Old Rare Games	30	21 August 2009 19:42
Ripping - Escape from Colditz	fairchild	project.Sprites	4	23 April 2005 21:46
escape from colditz	alukolli	request.Old Rare Games	3	09 September 2002 03:18
Map for Escape from Colditz	tomcat666	request.Old Rare Games	0	26 February 2002 15:27

18 August 2009, 12:08	#43
Aperture Registered User Join Date: Aug 2009 Location: .ie Posts: 10	Well, since I announced it elsewhere, and this seems to be the most recent thread regarding Escape From Colditz, might as well announce my Windows and PSP ports here as well (and yes, I did fix the tunnel exit bug in these versions ). If you want to play the game natively on Windows or PSP (as well as benefit from new features like save/load or guards who remember when they've seen a pass for instance), have a look here.

21 August 2009, 12:22	#44
andreas Zone Friend Join Date: Jun 2001 Location: Germany Age: 50 Posts: 5,857	Has anyone here ever verified the bug on the REAL thing? There was a similar case from the past that I remember: I think it was one of the Dungeon Master games and there was a very annoying closed-doors issue. VERY much later Toni Wilen confirmed that it was a 68020+ specialty which wasn't emulated, causing the closed doors!!! But I admit it will be a hell of a lot of work to get that far on the real thing and without savestate, because the game is bloody hard! Yet basically, it could be an emulation issue! (And alas, I do know well you cannot test IPFs on the real thing just like that, be they as perfect as possible)

21 August 2009, 19:47	#47
Hungry Horace Wipe-Out Enthusiast Join Date: Nov 2005 Location: . Age: 43 Posts: 2,545	Bored Seal is the man to speak to with regards to getting this fix added to the WHDload slave

21 August 2009, 21:34	#51
TCD HOL/FTP busy bee Join Date: Sep 2006 Location: Germany Age: 46 Posts: 31,975	Cheers Galahad

21 August 2009, 22:02	#53
Galahad/FLT Going nowhere Join Date: Oct 2001 Location: United Kingdom Age: 50 Posts: 9,016	patched 'colditz_demo' file in the zone for the WHDLoad version, just copy it over the same named file that is installed and this should fix the same tunnel bug

21 August 2009, 22:08	#54
Retro1234 Phone Homer Join Date: Jun 2006 Location: 5150 Posts: 5,814	Thats brilliant ill get testing Thanks Guys

21 August 2009, 22:52	#55
Retro1234 Phone Homer Join Date: Jun 2006 Location: 5150 Posts: 5,814	Ill do a lttle more testing but I Just tested the WHDload version - I AusFarted the tunnel and No Freaze!!

21 August 2009, 22:58	#56
Galahad/FLT Going nowhere Join Date: Oct 2001 Location: United Kingdom Age: 50 Posts: 9,016	Da ist wunderbar, jah?

21 August 2009, 23:01	#57
TCD HOL/FTP busy bee Join Date: Sep 2006 Location: Germany Age: 46 Posts: 31,975	Jawohl mein Herr Disk version seems to work a treat now

21 August 2009, 23:06	#59
Aperture Registered User Join Date: Aug 2009 Location: .ie Posts: 10	Nice patch, Galahad. It's even better than any of the options I suggested, as applying the patch in the decrunch header doesn't mess with the MD5 sums of the COLDITZ-LOADER, which I check in my game engine. This way, you'll be able to use a patched SKR_COLD with it as well. There seems to be a small problem with the ADF you uploaded in the zone however. Some of the IFFs in it have been renamed (eg. "DPIC.6(EXERCISE)" should really be "PIC6(EXERCISE)"). This makes the original game crash at 09:54, when the exercise picture is called. At least, that's what I got in WinUAE with that ADF. I'll see if I can upload a working ADF with your patch in the zone...

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)