| |
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....
|
| |
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 |
| |
MagerValp
Registered: Dec 2001
Posts: 1055 |
Quoting Bacchus@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.
What Krill suggests is making the game files copyable, but not packing multiple files into one like IFFL. That way you only have to read and cache track 18 to get the T/S of every file, you don't have to scan the sector links like with IFFL.
But really, dir cache vs IFFL scan makes little practical difference for the player, it happens once at startup and if you do it right like you say you mask it with the intro. Both give you faster file access when the game runs, which depending on the game can be a noticable improvement.
Personally I wouldn't bother with IFFL again unless it was critical to fitting the game on one disk side, like with U4, but to each their own. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting MagerValpQuoting Bacchus@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. What Krill suggests is making the game files copyable, but not packing multiple files into one like IFFL. That way you only have to read and cache track 18 to get the T/S of every file, you don't have to scan the sector links like with IFFL. I was stating this:
Loading by directory: Read and buffer directory once, then never go to dir track during the game.
Loading by IFFL: Scanning the entire file before running the game takes longer than just buffering the directory.
But then you don't need to scan everything before running the game, or mask the time required by refusing to exit the intro until scanning is done.
You scan to the required file on demand, building the track/sector/offset table piece-wise, which is what Burglar did (if i got him right).
Assuming the files are linked in a somewhat reasonable order (such that in general, stuff to be loaded later in the game would appear later in the IFFL file), there would be little overhead for dynamic scanning during gameplay.
(And of course IFFL must be file-copyable and fixed T/S cannot be assumed.)
Edit: Oh, and thinking about it, even with fully-random file access in some hypothetical malicious game, the loader could partially scan through the IFFL file whenever nothing is to be loaded, i.e, when the drive would be idle normally, until everything is scanned. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 - Next |
