| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
Best loader for games
What is the best loader for games ? Here's a list of features I'd like and please tell me if there's a loader that supports these.
Fast loading (duh)
Loading by track/sector/file
Saving without reinstalling the loader. Also by track/sector/file
2x 1541 working at the same time (1 game disk, 1 empty disk for "swap")
thanks |
|
... 21 posts hidden. Click here to view all posts....
|
| |
Carrion
Registered: Feb 2009
Posts: 317 |
Quote: Yeah, but I want to make a real-time action rpg like legend of zelda.
#metoo |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
IMHO, then you have to think like making an action game, and keep disk I/O minimal, often only during area transitions, or when loading dialogues and such. By encoding story events or monster alive/dead status into bits you can keep the savestate small. I'm not sure keeping an exact state of the whole world (like X/Y positions of every NPC and monster) actually matters much to the player. Though being able to stash items into the world and having them persist might be good. |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Now that I got thinking how to possibly improve my loader .. are there examples of loaders that do both a custom sector decode, and some degree of drive-side directory caching? Since an optimized decode already uses 2 buffers, there's not a lot of space to work with.
EDIT: Of course Krill's loader does. :) Taking over the diskdrive rather completely instead of relying on ROM routines, it can use more memory.
Others? |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting cadaverSince an optimized decode already uses 2 buffers, there's not a lot of space to work with. A fully-optimised decode routine uses just one buffer ($0100 bytes), holding a decoded and checksummed block only a few cycles after the last relevant GCR-encoded byte has rolled in from the spinning disk. =)
Since the directory-handling code takes up quite some space in the 2 KB of RAM, i only have 9 directory entries in the cache (filenames are stored as 2-byte hashes). This isn't much of a problem for demos, which usually load files in sequential order, such that the next directory chunk only needs to be fetched once for a run of 9 files, when the loader is idle after the 9th file has loaded.
Games tend to load files in random order, so having to go to the directory track is much more likely. |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
And in my loader I put the directory handling in C64 ram instead, and the drive code just deals with T/S. Round trip to track 18 costs too much time for games that constantly load lots of small files. |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Thanks for the insight. I waste an obscene half KB for a full drive-side cache, but it serves well in my scenario. It's just tempting to see how a 1571 in 2MHz mode can handle tighter interleaves even with the stock ROM decode, and dream of how 1541 might be possible to force into doing the same :) |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting cadaverThanks for the insight. I waste an obscene half KB for a full drive-side cache, but it serves well in my scenario. It's just tempting to see how a 1571 in 2MHz mode can handle tighter interleaves even with the stock ROM decode, and dream of how 1541 might be possible to force into doing the same :) While 1571 fully decodes and checksums blocks on the fly already with the ROM routines, the same has been achieved with custom software on a stock 1541.
On a C-64, both 1541 and 1571 (with a single-sided disk) deliver the same speed with my loader, interleave 3 on tracks 18+ and interleave 4 on the dense 21-blocks tracks 1-17 (where interleave 3 is missed by just a few cycles and almost the entire 4th block rolls by uselessly).
However, on a C-128 (running in native mode), 1571 manages interleave 3 across the entire disk thanks to hardware-clocked ("burst") transfer.
Apparently, that's ever so slightly faster than the 72 cycles per byte ATN-clocked bit-pair transfer. =) |
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
Quoting GolaraWell, I want to write more than just a small file with a high score. I wanted to make a game using 1541 like hard disk, with a lot of swapping. [...] This sounds very interesting.
+1 for going into this direction. Maybe this approach evolves so one day we come to see version/cracks of games that no vanilla c64 version exists as of yet (all those nasty CRT/REU/EasyFlash-only-releases f.e.;)). |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
Actually, for a game like that in 2020 I'd just go with a cartridge release. Makes development easier, the player experience better, and the physical release cooler. Enough people have EasyFlash or Ultimate carts for the digital release. Plus it messes with the crackers :D |
| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
This turned into a really interesting discussion, so that's cool. I'm working on the engine now, there's a long way to a game and we will see if it ever sees the light of day. Just want to say that I don't want to use REU or other steroids. I'm looking at this project like it's a demo. That means, C64+1541 only. I would like to add support for these devices as a bonus, just like the Super Mario Bross, but c64+1541 is the baseline. |
| Previous - 1 | 2 | 3 | 4 - Next |
