| |
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....
|
| |
Krill
Registered: Apr 2002
Posts: 2969 |
Quoting FungusAs for dir buffering, this doesn't make any sense when space is often limited, and there is no room for such things. You know that krill. I was merely refuting the argument that loading by directory means seeking to the directory track for every loaded file. And whether you buffer (cache) a directory or an IFFL T/S/offset table doesn't make much of a difference, in size or otherwise. Of course you'd go for having the buffer in drive RAM first, and even having only 9 entries in the cache (which is just a ring buffer) makes for quite an improvement regarding minimising seeking to and fro the dir track.
Quoting FungusAlso please don't start an IFFL bashing thing, different loaders for different purposes. Demo loaders are mostly useless for cracks and you know it. I didn't intend to bash the very concept of random-access reading from a large file to save block allocation overhead. I simply stated its biggest downsize on this platform is that there never was standardised support for it, so compatibility is the big issue. I also admitted that it does have its uses. But i don't quite see how a "demo loader" would be much different from loaders used in games, in size or otherwise. "G.I. Joe" would like to have a word with you. :D |
| |
Danzig
Registered: Jun 2002
Posts: 440 |
Quote: Quoting FungusAs for dir buffering, this doesn't make any sense when space is often limited, and there is no room for such things. You know that krill. I was merely refuting the argument that loading by directory means seeking to the directory track for every loaded file. And whether you buffer (cache) a directory or an IFFL T/S/offset table doesn't make much of a difference, in size or otherwise. Of course you'd go for having the buffer in drive RAM first, and even having only 9 entries in the cache (which is just a ring buffer) makes for quite an improvement regarding minimising seeking to and fro the dir track.
Quoting FungusAlso please don't start an IFFL bashing thing, different loaders for different purposes. Demo loaders are mostly useless for cracks and you know it. I didn't intend to bash the very concept of random-access reading from a large file to save block allocation overhead. I simply stated its biggest downsize on this platform is that there never was standardised support for it, so compatibility is the big issue. I also admitted that it does have its uses. But i don't quite see how a "demo loader" would be much different from loaders used in games, in size or otherwise. "G.I. Joe" would like to have a word with you. :D
I guess "demo loader" was ment in terms of "linear loading" from start to end instead of "randomly" loading depending fe. where the player decides to go. |
| |
Krill
Registered: Apr 2002
Posts: 2969 |
Quoting DanzigI guess "demo loader" was ment in terms of "linear loading" from start to end instead of "randomly" loading depending fe. where the player decides to go. Okay, but there are only two demo-centric systems that i'm aware of that don't support loading files in dynamic order (Spindle and Sparkle). Which i always felt to be too restrictive, as it doesn't allow for certain kinds of demo/effect. |
| |
Danzig
Registered: Jun 2002
Posts: 440 |
Quote: Quoting DanzigI guess "demo loader" was ment in terms of "linear loading" from start to end instead of "randomly" loading depending fe. where the player decides to go. Okay, but there are only two demo-centric systems that i'm aware of that don't support loading files in dynamic order (Spindle and Sparkle). Which i always felt to be too restrictive, as it doesn't allow for certain kinds of demo/effect.
Are there any more especially "demo-centric"? ;-)
TBH I prefer compatibility over speed, nevertheless I haven't really waited for true drive for ages, just using WARP in VICE nowadays :-D
In my book it's absolutely legit ppl wanting to run multi-loader games/demos from the U1541*IEC*Whatever.
I always ever saw IFFL as a weapon crackers "invented" (yeah, scott, I know ;-) ) because swappers where too m*f dump and copied full-side-multi-file productions with filecopier or (even worse and happened more often) fuxxored the T/S-loader-products using VALIDATE just to copy some silly note on the disk. IFFL was considered swapper-friendly :-D |
| |
Fungus
Registered: Sep 2002
Posts: 680 |
I look at it like people are buying inferior hardware (sd2iec) that will not work with 90% of software released for the c64, so that's on them if things don't work and we shouldn't automatically want to support something like that. I would prefer to encourage people to buy a proper drive emulator like pi1541.
By "demo loader" I meant that they are tailored specifically for demos, built for pure speed, and not for space constraints. They also tend to want to unpack after loading and that's often just impossible with a game due to there being no buffer space for that, although newer crunchers are being able to support in place unpacking, but sacrifice some ratio, which is paramount in a quality crack. Also demo loaders can be overly complex and you have to make multiple versions to support multiple drives, where something like n0sd0s is all in one and supports everything via detection and/or menu choice.
Different strokes for different folks I guess. If you cannot improve on a release from back in the day, then I see no point in doing a new version. That includes supporting actual real hardware with fast loading and IFFL for space saving. It also includes fixing bugs, making sure *everything* is present in the game including loading screens and music loaders. I have other pet peeves about some of the "improved" things released lately but that's a rant for another topic. |
| |
Krill
Registered: Apr 2002
Posts: 2969 |
Quoting FungusBy "demo loader" I meant that they are tailored specifically for demos, built for pure speed, and not for space constraints. Those would be Spindle and Sparkle, which are exceptions. Most loaders are general purpose. Oh, and the two aren't faster than, well, my general-purpose loader. :)
Quoting FungusThey also tend to want to unpack after loading and that's often just impossible with a game due to there being no buffer space for that, although newer crunchers are being able to support in place unpacking, but sacrifice some ratio, which is paramount in a quality crack. With Exomizer being the current reference in pack ratio, the files it generates can be (and are) depacked almost in-place, while loading. That is, three or so bytes are overwritten after the end of the unpacked area. If those cannot be buffered and restored, there are other options with slightly worse pack ratios. That is pretty much independent from the loader, though.
Quoting FungusAlso demo loaders can be overly complex and you have to make multiple versions to support multiple drives, where something like n0sd0s is all in one and supports everything via detection and/or menu choice. You seem to be comparing bad implementations of "demo loaders" with a good implementation of a "game loader", not conceptual differences, of which there aren't many. Detecting the drive and uploading one or the other piece of custom code to it isn't restricted to "game loaders". :) |
| |
hedning
Registered: Mar 2009
Posts: 4723 |
Quoting FungusI look at it like people are buying inferior hardware (sd2iec) that will not work with 90% of software released for the c64, so that's on them if things don't work and we shouldn't automatically want to support something like that. I would prefer to encourage people to buy a proper drive emulator like pi1541.
This! Exactly. |
| |
jcompton
Registered: Feb 2006
Posts: 70 |
If anybody's interested in a player's perspective on this, I'm absolutely as pleased as a Tail of the Dog dinner of pork ribs and sasperilla that we lucked into SD2IEC compatibility in the final day of tweaks and testing.
Yum. |
| |
Fungus
Registered: Sep 2002
Posts: 680 |
As I said, if you want to limit yourself like that, that's your choice. Most of us aren't going to go out of our way to support that hardware and degrade the quality of our work to do so. |
| |
Bacchus
Registered: Jan 2002
Posts: 156 |
Key is still - what are the pros and cons of IFFL?
Pro is faster Dir search (and I agree with Krill that the scan table is basically a dir cache). The extra blocks gained is a TOTALLY minor advantage. Was more back when Gamer's Guide was relevant. Much less now. When there is competition I will reconsider, but it's not like I expect there to be a competing version out any time soon.
Con is still less compatibility. SD2IEC migtht be "inferior" but it's a widespread piece of hardware our there and I think there is aclear advantage for a number of users that it works for this unit.
I don't think it's important to support SD2IEC, but it still think it's MORE important to support it than to gain a few extra blocks in savings.
And this entire first release thing has turned into something we are really not intereseted in participating in. As you need to format it in 6ZIp format and upload it to BBSes (notoriously unstable, busy and with fill disks) so that there had to be a scheme for telling if a valid upload is done by a weirdly complex system of counted BBSes and fallback ones.
And releasing a crap version you look up competition. The valid is not the first working one - it's the first one ragardless the state, and then you have a year to fix it. But it's not like it's open season after the year.
For me first working and a provable time stamp is first. Crap blocking and this silly BBS charade is plain wrong.
/Bacchus |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 - Next |
