| |
jcompton
Registered: Feb 2006
Posts: 70 |
Release id #187773 : Alternate Reality - The City +11D
With a dramatically improved saver and a trainer, it is now much much easier to live long enough to stumble into the original game's bugs!
Notably:
- Certain potion effects (Potions of Protection +1/+2) modify the wrong area of memory and may not actually provide any benefit whatsoever.
- These potion-related memory trashes can affect playfield graphics like door labels and mountain backdrops.
- Too many potion effects will crash the game!
- Banks may exhibit erratic behavior at times.
- Upon transitioning from a building back to the game map, the game sometimes "forgets" whether you are outdoors or in an "enclosed area."
- The game mostly hides the mirroring of door labels, but forgets to do so in certain types of Enclosed Areas, so words like "SHOP" and "TAVERN" will appear reversed on the bottom of the door.
- In silent interiors there's a horrible buzzing sound when the SID should probably just be turned off. |
|
... 92 posts hidden. Click here to view all posts....
|
| |
MagerValp
Registered: Dec 2001
Posts: 1074 |
Since all other cracks are broken, doesn't this count as a first release? Or is 35 years too slow? :D |
| |
hedning
Registered: Mar 2009
Posts: 4723 |
Quote: Since all other cracks are broken, doesn't this count as a first release? Or is 35 years too slow? :D
Yeah. Cracker groups have 1 year to fix bugs and shit after a initial release. But in this case it was never cracked properly (or at all) afaik, so I would say this actually counts as a first release. There might be working cracks of this game out there somewhere, even if it's unlikely - who knows. Time will tell. |
| |
TheRyk
Registered: Mar 2009
Posts: 2219 |
Quote:groups have 1 year to fix bugs and shit
... for a 100% version earning 1stie statwanking points
For a 101% version any group (though I don't think anyone outside FLT will bother the trouble) has all the time in the world |
| |
Raistlin
Registered: Mar 2007
Posts: 659 |
Are the points earned for releasing a 100% and later a 101% the same as just going straight to a 101%? |
| |
Krill
Registered: Apr 2002
Posts: 2969 |
Quoting Bacchus@hedning
What's with this obsession over IFFL? [...]
And IFFL plus save is also a mess. [...]
So again; why this constant moaning over IFFL? Funny, there's this:User Comment
Submitted by Bacchus on 14 August 2018
Kewl stuff. Not let's take it to the next level as per our discussion :) over on Krill's Loader, Repository Version 164 referring to
Quoting BacchusMy wishlist is;
* Option for file and IFFL [...]
<some detailed IFFL requirements> (And no, i don't have any plans to add IFFL because yes, IFFL sucks, but actually only due to Commodore not having seen fit to have a KERNAL call for seek functionality.) |
| |
jcompton
Registered: Feb 2006
Posts: 70 |
Quote: Yeah. Cracker groups have 1 year to fix bugs and shit after a initial release. But in this case it was never cracked properly (or at all) afaik, so I would say this actually counts as a first release. There might be working cracks of this game out there somewhere, even if it's unlikely - who knows. Time will tell.
I've seen someone swear up and down that the MZP version is 100%, but:
1. With over one-third of a century to find it, the most anybody's ever come up with from that version is the boot side (so, just one of the original three, and there's absolutely no evidence to suggest anybody's ever taken on the project of one-siding this game before.)
2. What we *can* see of the MZP version shows clearly that it's been tampered with in a way that would make it much less than a reliable historical artifact.
3. AR fandom may not make major headlines today against a backdrop of Sonic movies and so forth, but it was pretty strong by 1990s Internet standards and the game still has a significant following in some corners today. It is unlikely that anybody who appreciates this game would deliberately hoard a good crack of it.
I'm not a cracker. I only know what the people who *declined* to take on this monumental task have remarked about it, and then my lens into the work that Bacchus did to actually beat it into submission.
And I'm saying it's very, very unlikely that we'd have all collectively forgotten the time somebody actually *did* overcome this challenge back in the day. |
| |
sailor
Registered: Jan 2002
Posts: 90 |
IFFL would made sense on this release, first it would shortened it down a bit... and there are up to 10(?) dirpages it need to process when seeking a file. An IFFL would not had the seek times and the IFFLscan is done once... all depending of course how often it needs to load.
With n0sd0s, for example, you'd get support for a bunch of drives and REU and its notably fast.
Kernal support in this case doesnt seem to be a priority, its stated in the docs.. could had been IFFL aswell in regards of compatibility.
I like this release, I voted 10.
Keep up the good work Bacchus :) |
| |
Krill
Registered: Apr 2002
Posts: 2969 |
Quoting sailorIFFL would made sense on this release, first it would shortened it down a bit... and there are up to 10(?) dirpages it need to process when seeking a file. An IFFL would not had the seek times and the IFFLscan is done once... all depending of course how often it needs to load. Hmm, so directory caches haven't been invented yet in the cracking scene? :) (But yes, IFFL would make sense if ignoring compatibility issues.) |
| |
Bacchus
Registered: Jan 2002
Posts: 156 |
There are like twenty people in the world with whom you can have a sensible discussion over IFFL - Sailor and MagerValp being two of them. It's interesting that their conclusions are different.
I did the following writeup that documents my view:
http://bergatrollet.se/blog/2020/02/the-obsolescence-of-iffl/
It's quite obvious you need to take a pick - compatibility or a slightly faster dir search. These are the two relevant aspects where IFFL is a factor that sacrifices compatibility to gain a faster disk search.
Also; there is no IFFL that supports save as I want it.
I would use IFFL if the additional blocks you could win, was determining if I could oneside it or not - in all other cases I could not be bothered.
What could change my mind? I guess gamer's guide reappearing would be the thing. But still, for this game I wouldn't do it even in that case, as I never expect anyone to crack it again. So the size will not be compared to anything else ever. |
| |
Bacchus
Registered: Jan 2002
Posts: 156 |
Quote: IFFL would made sense on this release, first it would shortened it down a bit... and there are up to 10(?) dirpages it need to process when seeking a file. An IFFL would not had the seek times and the IFFLscan is done once... all depending of course how often it needs to load.
With n0sd0s, for example, you'd get support for a bunch of drives and REU and its notably fast.
Kernal support in this case doesnt seem to be a priority, its stated in the docs.. could had been IFFL aswell in regards of compatibility.
I like this release, I voted 10.
Keep up the good work Bacchus :)
Support for REU would be nice (we don't have that) and Kernal compatibility is implemented. Otherwise it wouldn't have worked on SD2IEC (which is confirmed to be working by a user - I gave up on it, and stopped testing it, but seems to have nailed it anyways).
Having said this, there are files that are always loaded together so I'm sure that it would be possible to reduce the number of files by the Version 1 of IFFL. That could possibly reduced at least 20 files. But please mind that I have populated the disk so that the most commonly accessed are amongst the first, so on the latter part of the disk you find the items loaded one or at most a few times during the span of the game, so the cases where such linking would make any sort of speed difference is really rare... |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 - Next |
