| |
Bacchus
Registered: Jan 2002
Posts: 154 |
Replacing games loader ...
OK, this on cracking but still highly related to coding.
Most games I fiddled with over the year call the loader using a parameter that was the index of the file. Using the same parameter as index for my IFFL or converting it to a two byte string starting the file name has worked well for me in most cases.
I am now facing two games that are not distributed yet (old, but no scene version is out) where there is a lot of data stored directly on the disk and the game then loads it using direct track and sector. Think of it like action adventures. The game loads strings or other really small things by loading T/S and then exctacting the needed part. It's hence not really "files" most of it and there are so many that a file per string is plainly not within reach.
I can think of a few approaches;
1) Keep it as data on disk. Allocate the sectors used and then store the files on the unallocated sectors. You can't compress it - it does take a full disk side any way you look at it. It does work, looks rather neat but cannot be counted as a firstie.
2) Make a big chunk of the data to a file and push it to a REU the first thing you do. The game become ever so much more playable and fast. And the file can be compressed efficiently. You do need a REU (or simply enable it in your emulator or Ultimate Cart) but it's also still not counted as a firstie.
3) Make a big file which you then need to scan as the original 256 byte sectors are now 254, so a sector that was a full page is by necessity spread over two sectors in a file based option. I guess you can also compress the sectors individually and think of the sectors as files in an IFFL. One IFFL file equals a sector. This is an ugly bitch but could be counted as a firstie.
Any other thought on this technical challenge? I must admit I am growing fond of the REU option, and the firstie restriction is the only thing that holds me back. The Tink games we just released had been perfect in REU version. Would have saved SO much work, loading would have been near instant and it would have been a release of two neat files.
Am I missing any options or can someone provide some lateral thinking, that opens up new options by finding approaches I have missed? |
|
... 36 posts hidden. Click here to view all posts....
|
| |
MagerValp
Registered: Dec 2001
Posts: 1055 |
This is exactly the problem I faced with Ultima IV Remastered where there are 688 raw sectors spread out over three disk sides. Source and docs on GitHub: https://github.com/MagerValp/u4remastered/blob/master/docs/ULoa..
TL;DR: Each sector individually crunched and then packed into IFFL archives that are scanned on startup. Track/Sector/Offset saved under I/O. |
| |
Knight Rider
Registered: Mar 2005
Posts: 114 |
Did you consider an EasyFlash release ? Much wider target audience than REU
Red Storm Rising for example also uses track/sector loading too. This was simply changed to X/Y (tr/se) file base loading and then build as CRT image.
Open the .CRT in a hex editor (from $e1f), and you will even see this
01 00
01 01
01 02
01 03
01 04
01 05
01 06
|
| |
MagerValp
Registered: Dec 2001
Posts: 1055 |
Alternate strategy that was considered: Pack up four sectors into a 1024 byte file that is then crunched. When loading you need a temporary 1024 byte unpack buffer, but it reduces the number of "files" to a quarter. You also get slightly better compression ratio. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
Quoting Bacchus
@chris: well, merging the sectors to tracks means that when I want to load a sector in a higher sector of a track, then I need to start loading+depacking, and then just ditch the data. If compressed, I never know the offset. That is subject to the compression. COmpression makes it so that you cannot compute the offset - you need to scan and store a table.
Oh I'm aware of that - but I've no idea of how much free space or free CPU you have. For some games decrunching a track into a buffer would be affordable, for others it would not. Then there are compromises, like the 1k buffer MagerValp suggested above.
-cjam |
| |
Bacchus
Registered: Jan 2002
Posts: 154 |
Thanks all! I REALLY appreciate your input.
@Knight Rider: EasyFlash or REU is sort of the same. It's a release that doesn't count as a firstie. We need a new point system that encourages the production of quality releases, also supporting alternative platforms that can support making the games more playable. Today we compete over firsties. First is one merit but I really want back the spirit of fighting over BEST version. There we could see a trend of people investing time in doing REU or EasyFlash versions, rather than shit like NTSC fixing which has a value to exactly noone!
@Magervalp - thanks Per. You have the full insight of what I want to accomplish. I do agree there are compromises you can do here. Very fruitful insights!
@Magervalp and @chris: Cluster sectors, to have fewer files - but trading that for a bit slower loading once you are after the last segments of a cluster. The room for tradeoffs is limited by the available RAM for tables. Per had plenty of space for tables in his Ultima. In most cases you don't really have that. I would say that in the normal case, you need to then aggregate enough to get few enough files to fit your IFFL restriction. Nut I do acknowledge that this is an important strategy for moving yourself in a position where the IFFL solution works.
The dilemma here is still why I make significant efforts to replace a working mechanism, just to obtain a result that can be file copied. The merit is to win the accolade of a firstie. That's a gain for me. You are making tradeoffs and make the game less playable as a cost for the file based structure. From the gamer's perspective, you are adding an inferior experience, while playing. Is the file based structure really something worth striving for, worth the cost both in effort for me doing it and for the gamer playing it at a user experience inferior to the original game?
My conclusion is still the same - the fight for firsties is counter productive. We need to add a fight for besties! |
| |
Danzig
Registered: Jun 2002
Posts: 428 |
Do it filecopyable or don't do it at all... |
| |
Bacchus
Registered: Jan 2002
Posts: 154 |
@Danzig - Who are we doing it for? For ourselves and the fun of it, for the first release points or for the people interested in playing it?
The focus on firsties and the associated rules undermine the strive for quality. |
| |
MagerValp
Registered: Dec 2001
Posts: 1055 |
If you like points hunting, digging up unreleased oldies, racing the boards, then the first release scene is for you. If you want to take your time and make the release the best it can be, it's not going to make much sense being in the first release race. Sometimes these paths intersect, sometimes they go in opposite directions. |
| |
Bacchus
Registered: Jan 2002
Posts: 154 |
@MagerValp: My conflicting interest is that I try to do both. Dig up the old stuff and making really good work on them, and still capture the points. Given that the points are only awarded for the firsties today, the rules for this have a reach for anyone wanting to be doing competitive work on games. This is where an alternative mechanism for point scoring (like Gamer's Guide once was) is much needed. |
| |
Martin Piper
Registered: Nov 2007
Posts: 634 |
@Bacchus I would not rely on pre-written IFFL routines. You'd need to find around <2K for the lookup table for all sectors. |
| Previous - 1 | 2 | 3 | 4 | 5 - Next |
