Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > CSDb Entries > Release id #187773 : Alternate Reality - The City +11D
2020-02-15 17:47
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....
 
2020-02-19 15:52
sailor

Registered: Jan 2002
Posts: 90
IFFL would made sense on this release, first it would shortened it down a bit... and there are up to 10(?) dirpages it need to process when seeking a file. An IFFL would not had the seek times and the IFFLscan is done once... all depending of course how often it needs to load.

With n0sd0s, for example, you'd get support for a bunch of drives and REU and its notably fast.

Kernal support in this case doesnt seem to be a priority, its stated in the docs.. could had been IFFL aswell in regards of compatibility.

I like this release, I voted 10.

Keep up the good work Bacchus :)
2020-02-19 16:22
Krill

Registered: Apr 2002
Posts: 2804
Quoting sailor
IFFL would made sense on this release, first it would shortened it down a bit... and there are up to 10(?) dirpages it need to process when seeking a file. An IFFL would not had the seek times and the IFFLscan is done once... all depending of course how often it needs to load.
Hmm, so directory caches haven't been invented yet in the cracking scene? :) (But yes, IFFL would make sense if ignoring compatibility issues.)
2020-02-19 22:35
Bacchus

Registered: Jan 2002
Posts: 154
There are like twenty people in the world with whom you can have a sensible discussion over IFFL - Sailor and MagerValp being two of them. It's interesting that their conclusions are different.

I did the following writeup that documents my view:

http://bergatrollet.se/blog/2020/02/the-obsolescence-of-iffl/

It's quite obvious you need to take a pick - compatibility or a slightly faster dir search. These are the two relevant aspects where IFFL is a factor that sacrifices compatibility to gain a faster disk search.

Also; there is no IFFL that supports save as I want it.

I would use IFFL if the additional blocks you could win, was determining if I could oneside it or not - in all other cases I could not be bothered.

What could change my mind? I guess gamer's guide reappearing would be the thing. But still, for this game I wouldn't do it even in that case, as I never expect anyone to crack it again. So the size will not be compared to anything else ever.
2020-02-19 23:01
Bacchus

Registered: Jan 2002
Posts: 154
Quote: IFFL would made sense on this release, first it would shortened it down a bit... and there are up to 10(?) dirpages it need to process when seeking a file. An IFFL would not had the seek times and the IFFLscan is done once... all depending of course how often it needs to load.

With n0sd0s, for example, you'd get support for a bunch of drives and REU and its notably fast.

Kernal support in this case doesnt seem to be a priority, its stated in the docs.. could had been IFFL aswell in regards of compatibility.

I like this release, I voted 10.

Keep up the good work Bacchus :)


Support for REU would be nice (we don't have that) and Kernal compatibility is implemented. Otherwise it wouldn't have worked on SD2IEC (which is confirmed to be working by a user - I gave up on it, and stopped testing it, but seems to have nailed it anyways).

Having said this, there are files that are always loaded together so I'm sure that it would be possible to reduce the number of files by the Version 1 of IFFL. That could possibly reduced at least 20 files. But please mind that I have populated the disk so that the most commonly accessed are amongst the first, so on the latter part of the disk you find the items loaded one or at most a few times during the span of the game, so the cases where such linking would make any sort of speed difference is really rare...
2020-02-20 03:23
Fungus

Registered: Sep 2002
Posts: 602
Lets get some things straight first since there is a lot of misinformation about stuff which has floated around for decades.

1) G*P did not invent IFFL, nor is a true IFFL with byte linking. V-MAX and Rapidlok used this technique YEARS before, and it is also truely byte linked. It is just taken from a commercial loading system. So lets not continue this useless sack riding of Snacky who didn't invent dick.

2) n0sd0s is compatible with almost any commercial drive, including CMD devices, ide64, and almost any 3rd party 1541 clone. We tested that exhaustively, so this argument is invalid.

3) If you don't like something or that n0sd0s doesn't do, and I know you have the source. Add it, which is what any capable cracker/coder will do. If this is beyond your skill, then ask one of us, I'm sure we can manage for you.

As 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. Also please don't start an IFFL bashing thing, different loaders for different purposes. Demo loaders are mostly useless for cracks and you know it.

*Nostalgia Council*
2020-02-20 08:53
ChristopherJam

Registered: Aug 2004
Posts: 1359
Firstly, mad props on the achievement - getting down to a single side is amazing work.

Secondly 9's not a downvote if it's what the original 9 voter genuinely rated the release as - and hey, this means whoever it was now has room to give a higher rating to a 101% version :) (note - I've not voted yet :P )

Anyone who doesn't like anon votes is free to ignore them - csdb already gives two scores :P


As for the whole IFFL thing - yeah, I can see compatibility arguments against it, and clearly the extra space wasn't needed. It also sounds like Bacchus has done a nice job of moving the most commonly used files to the front to minimise the dir scanning.

Interesting that there are some pairs of files that are always loaded at the same time though. Sounds like there's room in the toolkit for a loader/decruncher pair that can deal with fragmented memory. (fwiw, nucrunch can decrunch to multiple areas, but the source has to be contiguous, and besides the decruncher isn't all that small)


Again, excellent work on this release!
2020-02-20 08:57
Krill

Registered: Apr 2002
Posts: 2804
Quoting Fungus
As 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 Fungus
Also 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
2020-02-20 09:34
Danzig

Registered: Jun 2002
Posts: 428
Quote: Quoting Fungus
As 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 Fungus
Also 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.
2020-02-20 10:34
Krill

Registered: Apr 2002
Posts: 2804
Quoting Danzig
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.
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.
2020-02-20 11:02
Danzig

Registered: Jun 2002
Posts: 428
Quote: Quoting Danzig
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.
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
Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
iAN CooG/HVSC
nucleus/TempesT
sebalozlepsi
Guests online: 342
Top Demos
1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 No Bounds  (9.6)
6 Comaland 100%  (9.6)
7 Uncensored  (9.6)
8 The Ghost  (9.6)
9 Wonderland XIV  (9.6)
10 Bromance  (9.6)
Top onefile Demos
1 Party Elk 2  (9.7)
2 Cubic Dream  (9.6)
3 Copper Booze  (9.5)
4 Rainbow Connection  (9.5)
5 TRSAC, Gabber & Pebe..  (9.5)
6 Onscreen 5k  (9.5)
7 Dawnfall V1.1  (9.5)
8 Quadrants  (9.5)
9 Daah, Those Acid Pil..  (9.5)
10 Birth of a Flower  (9.5)
Top Groups
1 Booze Design  (9.3)
2 Nostalgia  (9.3)
3 Oxyron  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)
Top Diskmag Editors
1 Jazzcat  (9.4)
2 Magic  (9.4)
3 hedning  (9.2)
4 Newscopy  (9.1)
5 Elwix  (9.1)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.048 sec.