| |
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....
|
| |
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: 2969 |
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: 1088 |
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: 156 |
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: 1074 |
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: 2969 |
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. |
| |
Fix
Registered: Feb 2003
Posts: 54 |
@fix Yes - for example SD2IEC.
I know of several IFFL loaders that support SD2IEC.
Not 2-bit fastload, but it supports it.
Also I know there is support for save too. |
| |
Krill
Registered: Apr 2002
Posts: 2969 |
Quoting FixI know of several IFFL loaders that support SD2IEC. How would they seek backwards within the IFFL file (via KERNAL calls, presumably)? Simply close it, open it again, then read and discard bytes until at the desired position? |
| |
Fix
Registered: Feb 2003
Posts: 54 |
Quote: Quoting FixI know of several IFFL loaders that support SD2IEC. How would they seek backwards within the IFFL file (via KERNAL calls, presumably)? Simply close it, open it again, then read and discard bytes until at the desired position?
There is no seek command, we had another solution.
It's 2 years ago I touched that code.
If I remember right there is another command you can use with SD2IEC to solve that problem. |
| |
Krill
Registered: Apr 2002
Posts: 2969 |
Ah, there is a command to set the position within an open file.
Didn't know that. :)The syntax to position within any regular file is as follows:
OPENlf,dv,15:PRINT#lf,"P"+CHR$(ch)+CHR$(lo)
[+CHR$(mlo)[+CHR$(mhi)[+CHR$(hi)]]]:CLOSElf
Where:
Variable Description
lf the logical file number for the command channel
dv the current device number of the sd2iec
ch the channel of an open file in which to move the position *
lo the (0th) low byte of a 32–bit position
mlo the (1st) mid–low byte of a 32-bit position (optional, defaults to 0)
mhi the (2nd) mid–high byte of a 32-bit position (optional, defaults to 0)
hi the (3rd) high byte of a 32-bit position (optional, defaults to 0) That somewhat mitigates the compatibility argument. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 - Next |
