| |
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....
|
| |
Fungus
Registered: Sep 2002
Posts: 616 |
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: 2839 |
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: 4595 |
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: 616 |
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: 154 |
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 |
| |
Fix
Registered: Feb 2003
Posts: 54 |
@Bacchus
IFFL CON: compatibility ?
If you ask me it depends on what drives you support in your loader.
For me IFFL is a matter of taste and choice of the cracker.
I like to use IFFL if there are many files, else a normal fastloader is working fine. Since scanning takes some time with IFFL. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting BacchusPro [of IFFL] is faster Dir search (and I agree with Krill that the scan table is basically a dir cache). Shouldn't buffering a directory be faster than scanning a large file, as the directory is on a single track?
Quoting FixSince scanning takes some time with IFFL. Seems like on-the-fly scanning hasn't been invented yet? =) |
| |
Burglar
Registered: Dec 2004
Posts: 1031 |
Quote:Seems like on-the-fly scanning hasn't been invented yet? =) well, the iffl I used in return of heracles actually doesn't need to scan, but I guess my loader is the only one that has that feature ;)
anyways, I like iffl, despite its obvious drawbacks. |
| |
Bacchus
Registered: Jan 2002
Posts: 154 |
This entire discussion starts by Hedning requesting IFFL - a feature GP themselves haven't implemented. I don't have any IFFL that supports Exomizer 3 and save as I want it (dynamic files).
@fix Yes - for example SD2IEC.
@krill Well the disk should be file copyable and if you do that, the track and sector cannot be assumed. It needs to be scanned to generate the table. The FLT IFFL scan and build a table that is track&/sector/offset totally dynamically. IFFLs such as N0SD0S need to be linked with a dedicated linker and add the offset table in the beginning of the file. Scanning is not a big thing - you fire away the scanner before you launch the intro and don't allow exit before the scanner is done, so the time it takes is not really wasted anyways.
@burglar How do you do it if you don't scan?
/Bacchus |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 - Next |
