| |
Magic Pockets patch released |
| |
swirlythingy (15:42 24/8/2013)
sirbod (17:59 24/8/2013)
swirlythingy (23:27 24/8/2013)
sirbod (06:32 25/8/2013)
swirlythingy (15:52 25/8/2013)
sirbod (17:36 25/8/2013)
swirlythingy (19:52 25/8/2013)
sirbod (22:26 25/8/2013)
sirbod (22:23 27/8/2013)
tlsa (17:39 25/8/2013)
tlsa (18:15 25/8/2013)
|
| |
|
Martin Bazley |
Message #122577, posted by swirlythingy at 15:42, 24/8/2013 |
Posts: 460
|
Do you own a copy of Magic Pockets? Do you hardly ever play it because you simply can't be bothered to hunt for an aged floppy disc before the game will deign to start? This patch is for you!
Also applicable if you want to play the game on an emulated system, or if your original floppy disc has (as is not unlikely) bitten the dust.
Copy protection is, more often than not, the single thing which is most likely to keep me from playing a game. After removing it from Magic Pockets, I found the game much more accessible, and consequently enjoyable. It's also nice not having to endlessly fret about whether this will be the day the disc finally stops working! |
| |
 [ Log in to reply ] |
| |
|
Jon Abbott |
Message #122578, posted by sirbod at 17:59, 24/8/2013, in reply to message #122577 |
Member
Posts: 563
|
Sorry, not directly related to the patch, but to the game...
JASPP will be releasing Magic Pockets at some point, free to all, for use under ADFFS. It's one we have rights too.
We currently have it working up to RO3.5, what's preventing RO3.6+ up working is the tracker module it uses - we have 32bit tracker module shims in development.
I've not tried it on the Pi yet (as we need the tracker shim), but we'll be starting on Pi video translation very soon, so fingers crossed its one that we can get working early on. |
| |
[ Log in to reply ] |
| |
|
Martin Bazley |
Message #122579, posted by swirlythingy at 23:27, 24/8/2013, in reply to message #122578 |
Posts: 460
|
I have it working on RO4.39 with a StrongARM.
I'm not sure what version of the game you've got. |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #122581, posted by sirbod at 06:32, 25/8/2013, in reply to message #122579 |
Member
Posts: 563
|
We have the boxed original. If your copy runs from the original floppy past RO3.5, please send me an ADF of it to compare. If its a later version, we can arrange to take an image with the protection intact.
EDIT: I've just checked the image, there's no specific version mentioned, but the file date on Pockets is 17:20:58 05 Nov 1993
[Edited by sirbod at 12:22, 25/8/2013] |
| |
[ Log in to reply ] |
| |
|
Martin Bazley |
Message #122584, posted by swirlythingy at 15:52, 25/8/2013, in reply to message #122581 |
Posts: 460
|
Hmm, interesting. There appears to be a difference between the program on the original floppy and that on my hard disc. The installed version has two files, "PM" and "PM_old", the latter of which identifies itself as "TrackerModule 4.09 (25 Dec 1992) [dev] (Mercier, Fiennes & Farrow)" and is datestamped 22:26:37 08 Jan 1993, and the former of which is "TrackerModule 4.09 (17 Dec 1996) [dev/C]" and is datestamped 20:43:18 14 Jun 1998". The floppy version only has the latter, this time named "PM". Also, the floppy version crashes.
(The "Pockets" datestamp matches yours.)
I have no idea at what stage it could have been replaced, except that I would not have had the technical knowledge to work out that it was solely the player module at fault for myself, and I didn't own Magic Pockets in 1998 anyway.
Personally I don't see the point of meticulously preserving every single aspect of old games, including all the bits which don't work. There are limits to what an emulation layer can achieve, and from what I've heard about what ADFFS does to one's system in order to trick games into working (doesn't it replace the ADFS module, and what's all this business about memory remapping?), I'm not at all sure I'd want to run it on my computer!
I can remember the days when an expected consequence of launching a game on your Archimedes was that you'd have to cold-reset the computer afterwards, and I don't miss them. |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #122585, posted by sirbod at 17:36, 25/8/2013, in reply to message #122584 |
Member
Posts: 563
|
Thanks for that info, it sounds like you have a patched TrackerModule, could you please eMail me a copy of it?
As Pockets is the original, it does at least confirm that once we shim TrackerModule it should work up to RO4.39/SA and possibly even on the Pi.
ADFFS doesn't replace the ADFS module, it sits between FileCore and ADFS and handles requests to ADFS::0 should a floppy image be mounted.
Memory remapping...it's identical to GameOn and only enabled if you explicitly turn it on. As we've not released any games yet, there should be no reason to use it. We've gone a bit further than GameOn, in that we've fixing overscan issues, but essentially it's identical.
I agree with you about consequences of launching a game on an Arc, most games mess about with modules, memory or CMOS. Module and CMOS changes can be blocked by ADFFS, but there's nothing we can do about poorly written code or games that don't provide a means to exit cleanly. I could provide a means to break out of a game and return to the OS, but it will probably be hit and miss as the Desktop doesn't recover very well after mode and Dynamic Area 2 changes.
I wouldn't advise running any game on a work machine, if your a casual user, just make sure you close everything first and have a backup of your CMOS on floppy or an accessible ADFS drive. There's next to no protection or isolation in Risc OS, so any badly behaved code could render your machine unbootable without a CMOS reset.
My advice would be to run games under emulation, or on a dedicated games machine. Under emulation you'll see the benefits of ADFFS, as it will allow you to play protected games without having to hack them or find a patch to do it.
When we start releasing games to the public, the point of ADFFS will become clear. You could of course mount them under ADFFS, hack them and then run them from a HD; provided they're not used for commercial use, people are free to do as they please with them. |
| |
[ Log in to reply ] |
| |
|
Michael Drake |
Message #122586, posted by tlsa at 17:39, 25/8/2013, in reply to message #122584 |
Posts: 1097
|
There used to be a few sites with patches for making old games work with StrongARM and RO4. One was by Darren Salt, and another by Alex Macfarlane Smith. I think there was at least one other.
Those sites have now vanished, but many of the patches were on one of the Acorn User CDs. |
| |
[ Log in to reply ] |
| |
|
Michael Drake |
Message #122587, posted by tlsa at 18:15, 25/8/2013, in reply to message #122586 |
Posts: 1097
|
I think there was at least one other. Was probably: http://home.wanadoo.nl/tvdb/.
Another related tool was NoDisc (the WIMP SA compatibility aid for 4th Dimension/CJE/FedNet games) by Richard Wilson: NoDisc CSAG threads.
To Quote Richard in one of the threads:
> What games does it make run?
A lot of 4th Dimension titles, and helps SF3000 too. It basically removes
the self modifying code at the start of the files and optionally removes
the key-disc code which causes problems on certain disc drives.
[Edited by tlsa at 19:17, 25/8/2013] |
| |
[ Log in to reply ] |
| |
|
Martin Bazley |
Message #122588, posted by swirlythingy at 19:52, 25/8/2013, in reply to message #122585 |
Posts: 460
|
As Pockets is the original, it does at least confirm that once we shim TrackerModule it should work up to RO4.39/SA Well, for a certain value of "work". The video code of the ROL fork includes an unfortunate 'feature' which causes redraw of non-background objects (the player, monsters, text, etc.) to flicker severely. It disagrees with some other games as well.
and possibly even on the Pi. No chance. It's stuffed to the brim with non-32-bit-compatible code.
I'm actually amazed it runs on the StrongARM, what with the amount of self-modifying code it includes, none of which calls OS_SynchroniseCodeAreas. I think the logical distances between the modification code and its data may be larger than the cache, thereby accidentally sidestepping the problem. |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #122589, posted by sirbod at 22:26, 25/8/2013, in reply to message #122588 |
Member
Posts: 563
|
The video code of the ROL fork includes an unfortunate 'feature' which causes redraw of non-background objects (the player, monsters, text, etc.) to flicker severely. It disagrees with some other games as well. That may be the screen caching that RO4 enables, I'm currently working on a fix. |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #122600, posted by sirbod at 22:23, 27/8/2013, in reply to message #122589 |
Member
Posts: 563
|
The video code of the ROL fork includes an unfortunate 'feature' which causes redraw of non-background objects (the player, monsters, text, etc.) to flicker severely. It disagrees with some other games as well. That may be the screen caching that RO4 enables, I'm currently working on a fix.
It was screen caching causing the flickering and is now fixed in ADFFS 2.18, although there's a lot of testing to do before we can release it to the public. |
| |
[ Log in to reply ] |
| |
|
