| |
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....
|
| |
Bacchus
Registered: Jan 2002
Posts: 156 |
There is never a fixed amount of memory available. Basically, the less memory you have available, the more functionality you must be ready sacrifice.
You want limieted use of zeropage, small files, reasonably fast loader, compatibility with a variety of drives, REU support, compatible save and so on. The more the merrier, but if all won't fit you start scaling down the requirements.
I have come to enjoy Cadaver + Exomizer 3. It's a super robust combination and all the times it failed on me, it was as *I* had done something wrong.
I can link files to so that they become subfiles (the first generation of IFFL), I can just turn off the fastloader flag and then all of kernal is available - including save. It's fast, it's compatible and the files on disk pack really well.
So all in all the benefits outperform any option I have seen. The only key drawback is that, for EVERY release, Hedning feel an unstoppable urge to ask why I don't do IFFL as I "have N0SD0S". :-P
/Bacchus |
| |
Krill
Registered: Apr 2002
Posts: 2969 |
Okay, so which part about available memory did i "get a bit wrong", then? |
| |
Bacchus
Registered: Jan 2002
Posts: 156 |
Memory available for directory caching. It becomes relevant only after you have a number of pages of files, and by that time the memory needed just isn't available.
/Bacchus |
| |
Krill
Registered: Apr 2002
Posts: 2969 |
Quoting BacchusMemory available for directory caching. It becomes relevant only after you have a number of pages of files, and by that time the memory needed just isn't available.
/Bacchus The directory is buffered in the drive, of course. Then a file entry takes:
- 2 bytes if loading by index
- 3 bytes if loading with a 1-char filename
- 4 bytes if loading with a full filename (stored as a 2-byte hash value).
So a directory buffer may take less memory than an IFFL T/S/O table, the same, or more, depending on what your requirements for the filenames are.
Edit: Oh, and it's still just a cache. There may always be more files on the disk than the cache can hold. Going to the dir track once in a while (but by far not for every loaded file) is okay, i guess. |
| |
Frantic
Registered: Mar 2003
Posts: 1646 |
Quote:The only key drawback is that, for EVERY release, Hedning feel an unstoppable urge to ask why I don't do IFFL as I "have N0SD0S". :-P
I find this very funny in all sorts of ways. :D |
| |
jcompton
Registered: Feb 2006
Posts: 70 |
Quote: Crack Competition 2020:-
Alternate Reality - The City
Just putting this out there... it might stop all the arguing ;-p
If I get a vote, I'm calling for Wasteland 101%.
Single volume. Integrate the paragraphs. |
| |
hedning
Registered: Mar 2009
Posts: 4723 |
Quote: Quote:The only key drawback is that, for EVERY release, Hedning feel an unstoppable urge to ask why I don't do IFFL as I "have N0SD0S". :-P
I find this very funny in all sorts of ways. :D
Because Bacchus never answers I have to keep asking. :D He just rambles about how bad BBS’s are and so on. |
| |
Bacchus
Registered: Jan 2002
Posts: 156 |
@hedning So now you can stop asking. I have said the same before and can repeat it but in my view IFFL is obsoleted - and BBS and first release only is a key part of the reason. I would use it in a competition, but if first is the only thing that counts - then really no.
Again;
http://bergatrollet.se/blog/2020/02/the-obsolescence-of-iffl/
And;
If not even your group is doing it, then you are in no position to ask it from someone else. (Supplying and have someone else do the cracking doesn't count).
/Bacchus
PS: And this BBS thing is just plain shit. Lame boring shit. |
| |
hedning
Registered: Mar 2009
Posts: 4723 |
Quote: @hedning So now you can stop asking. I have said the same before and can repeat it but in my view IFFL is obsoleted - and BBS and first release only is a key part of the reason. I would use it in a competition, but if first is the only thing that counts - then really no.
Again;
http://bergatrollet.se/blog/2020/02/the-obsolescence-of-iffl/
And;
If not even your group is doing it, then you are in no position to ask it from someone else. (Supplying and have someone else do the cracking doesn't count).
/Bacchus
PS: And this BBS thing is just plain shit. Lame boring shit.
Well. We would probably use it more if we had NosDos, but we do not, unfortunately. NosDos is really awesome, and I know that as we worked with Triad a few times, as you know. Pristine stuff, that would, in my opinion, have been sweet in this release we are discussing, but even better in the Tink cracks... I really mean it. :) It would have made so much sense.
And just like we love doing stuff on the obsolete C64, we in GP try to embrace the whole C64 scene, including the BBS scene. Why let them out? They are as much part of this scene as the demo scene and cracking scene.
I'll stop asking now. Thanks for your link. And hey, the release still have my 10! <3 |
| |
Fungus
Registered: Sep 2002
Posts: 680 |
Adding Exo 3 (or any other uncruncher) to n0sd0s is a trivial 5 minute job due to the modular approach we took.
If SD2IEC supports SEEK, the offset table can just be used directly with some math, and no scanning needs to occur at all, also simple to add and could add some kernel driver to n0sd0s for that easily enough, the handshake is not that complex, it would never work with IRQ without some modifications and it would only support things such as music and no rasters/sprites which isn't a real IRQ loader anyways.
As for dealing with BAM, neither do I want to mess with that, but there is surely also a solution.
If you want to make a challenge, maybe I take you up on it if I can keep from being bored of C64 long enough and crack this game which I don't even like... I think I'd rather work on games I do like tbh.
Also this blog post you keep making is opinion, and opinions are like assholes, everyone has one. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 - Next |
