| |
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 |
|
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Is interruptible loading ("IRQ-loader") required? |
| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
Quote: Is interruptible loading ("IRQ-loader") required?
yes, forgot to add that. Also two 1541s at the same time is nice to have, but not a must. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Just a few suggestions:
You might want to take a look at Cavader's Covert BitOps loader. It was invented specifically for games. If there is an IRQ loader supporting multiple active drives, this would be it.
I guess it comes with a (hiscore) saving feature, too.
I think MagerValp's uload could also fit your bill.
Bitbreaker's Bitfire does not support multiple drives, afaik, but i think i've heard of somebody adding a hiscore saver lately (possibly on Plus4, so some backporting might be required).
As for saving, i've had that on the list for a while now, but alas... same for multiple active drives support, but that's a tough one with the 2bit+ATN protocol.
In any case, make sure that there is a fallback to KERNAL calls. You want to have those if not running the game from those pesky floppy drives. :) |
| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
Quote: Just a few suggestions:
You might want to take a look at Cavader's Covert BitOps loader. It was invented specifically for games. If there is an IRQ loader supporting multiple active drives, this would be it.
I guess it comes with a (hiscore) saving feature, too.
I think MagerValp's uload could also fit your bill.
Bitbreaker's Bitfire does not support multiple drives, afaik, but i think i've heard of somebody adding a hiscore saver lately (possibly on Plus4, so some backporting might be required).
As for saving, i've had that on the list for a while now, but alas... same for multiple active drives support, but that's a tough one with the 2bit+ATN protocol.
In any case, make sure that there is a fallback to KERNAL calls. You want to have those if not running the game from those pesky floppy drives. :)
Well, 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. I initially wanted to just use your loader, cuz I remembered it can SAVE with kernel, but it requires a drive reset and loader reinstalation... might be to slow for how often I want to write to the disk. I'll check out the loaders you mentioned, thanks. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting GolaraWell, I want to write more than just a small file with a high score. "Hiscore saver" doesn't necessarily mean small files, but that the tedious DOS job of file allocation and management with all the annoying pitfalls is sidestepped.
It implies replacing data in existing files, regardless of their size. After saving, the file will be the same size as before.
So in the end, you'll have a number of "save slots" of individual static sizes on the data disk.
Quoting GolaraI wanted to make a game using 1541 like hard disk, with a lot of swapping. Are you quite certain that the 1541 is suitable for that job? Will an REU be an option? =)
Quoting GolaraI initially wanted to just use your loader, cuz I remembered it can SAVE with kernel, but it requires a drive reset and loader reinstalation... might be to slow for how often I want to write to the disk. The saver item on the TODO list just got a somewhat higher priority. :D |
| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
Quote: Quoting GolaraWell, I want to write more than just a small file with a high score. "Hiscore saver" doesn't necessarily mean small files, but that the tedious DOS job of file allocation and management with all the annoying pitfalls is sidestepped.
It implies replacing data in existing files, regardless of their size. After saving, the file will be the same size as before.
So in the end, you'll have a number of "save slots" of individual static sizes on the data disk.
Quoting GolaraI wanted to make a game using 1541 like hard disk, with a lot of swapping. Are you quite certain that the 1541 is suitable for that job? Will an REU be an option? =)
Quoting GolaraI initially wanted to just use your loader, cuz I remembered it can SAVE with kernel, but it requires a drive reset and loader reinstalation... might be to slow for how often I want to write to the disk. The saver item on the TODO list just got a somewhat higher priority. :D
Well yeah, REU would probably do, but who has a REU in their setup (not emulated). Besides, it's fun to try make something never done before. I'm not making GTA that will constantly load stuff in the background. I'm trying to make a small RPG but I just want a file with quest status, who I talked with etc. That's why I also thought loading by sector or track would be benefitial. I can have say 256 bytes for one town, that's 256 variables, should be more than enough.
Don't want to say more or someone will implement it better than me before I even finish a draft and i'll be sad |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting GolaraWell yeah, REU would probably do, but who has a REU in their setup (not emulated). Practically everybody with a 1541U, and that's quite a few.
Quoting GolaraI just want a file with quest status, who I talked with etc. Is that really swapping with everything or just automatic background saving of game state?
Quoting GolaraThat's why I also thought loading by sector or track would be benefitial. I can have say 256 bytes for one town, that's 256 variables, should be more than enough. Sounds like a bunch of small "hiscore" files. =D But i'd advise against low-level block addressing. Keep it on file level (and with KERNAL fallback), for the sake of compatibility with non-1541 drives. |
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
The release / standalone version of Covert Bitops loader doesn't save on its own, it just provides function for you to reinit fastloader after any Kernal IO.
But in my recent games I have used replacing of already existing save files from within the drivecode, as was recommended. That loader doesn't exist as standalone version, you'd have to rip it out from the game/framework code. The filename API is based on 8bit numbers, so max. 256 unique files. No track/sector access. The most advanced version so far is here, with also SD2IEC support (it has dependencies into the rest of the framework, so ripping it out isn't exactly trivial):
https://github.com/cadaver/c64gameframework/blob/master/loader.s
It's a 2bit timed protocol, so it imposes limits on your interrupts and sprites. |
| |
MagerValp
Registered: Dec 2001
Posts: 1055 |
Gee if there was only a game on github with full source that you could use as a template... :D
Writing an rpg is tons of fun but you'll struggle to implement all the mechanics and creating content long before you run into technical limits of the loader. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: Gee if there was only a game on github with full source that you could use as a template... :D
Writing an rpg is tons of fun but you'll struggle to implement all the mechanics and creating content long before you run into technical limits of the loader.
For Eye of the Beholder I did disk I/O after about 1 year of coding. :) |
| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
Quote: For Eye of the Beholder I did disk I/O after about 1 year of coding. :)
Yeah, but I want to make a real-time action rpg like legend of zelda. |
| |
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: 1153 |
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: 1153 |
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: 2839 |
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: 1055 |
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: 1153 |
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: 2839 |
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: 466 |
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: 1055 |
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. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
If you're going in the 2-drive direction, one could also put content on both disks (and still save state on one of them), then either have more capacity or more speed with a RAID-0-like setup. =) |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
MV, you pretty much nailed it.
Nontheless, I will always prefer stuff that runs on a plain c64 system over anything in need of "steroids" (as Golara calls it;)). So "messes with the crackers" would ideally be interpreted the way that it introduces a new kind of scoring system for cracks, i.e. by using a metric that measures the amount of addendums needed and lessens the overall score accordingly.
I'm no cracker in any way, so what do i know:) |
| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
Quote: MV, you pretty much nailed it.
Nontheless, I will always prefer stuff that runs on a plain c64 system over anything in need of "steroids" (as Golara calls it;)). So "messes with the crackers" would ideally be interpreted the way that it introduces a new kind of scoring system for cracks, i.e. by using a metric that measures the amount of addendums needed and lessens the overall score accordingly.
I'm no cracker in any way, so what do i know:)
HCL called it that in Treu love, but I like it and it stuck with me :P |
| |
Scan
Registered: Dec 2015
Posts: 110 |
Interesting topic! I'm currently (not so active) working on a puzzle game and I for now am using the Krill loader to select a puzzle. I don't mind if the load takes a few seconds (happening when browsing backwards due to the caching mechanism of track 18), but for me the one thing it lacks is having the possibility to save the state whether a certain puzzle is solved or not. I know it is possible to write some sort of plugin or use kernal calls and then reinstall the loeader, but the first solution is beyond my knowledge and the second will probably halt the IRQ music player. |
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
Another option, which was discussed in an earlier game-loader thread here: Sending data from C64 to drive can be done in a way that doesn't need to disturb interrupts, if you reimplement the IEC protocol byte send. This would allow writing new files or arbitrary sized files, which save-routines within drivecode typically don't allow, and then reinitializing the fastloader.
In theory, implementing the EOI-flag (last byte of transmission) correctly needs precise timing, but in practice drives seem to tolerate you sending every byte as EOI, since you finish with Unlisten anyway. |
| |
MagerValp
Registered: Dec 2001
Posts: 1055 |
Quote: MV, you pretty much nailed it.
Nontheless, I will always prefer stuff that runs on a plain c64 system over anything in need of "steroids" (as Golara calls it;)). So "messes with the crackers" would ideally be interpreted the way that it introduces a new kind of scoring system for cracks, i.e. by using a metric that measures the amount of addendums needed and lessens the overall score accordingly.
I'm no cracker in any way, so what do i know:)
If you look at who actively cracks games, all of them do tape and single file cracks. Most crack disk games. Very few crack cartridge releases. Even fewer would touch a cartridge release that does saving to flash. Include a hidden trainer menu in the official game release and you've basically won :D |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Golara, Scan: Alright, alright. Next loader update (to be released soon) won't have the saver plug-in yet, but i'll prepare the custom drive code stuff for it and put the saver in the #1 spot of the TODO list for further releases. :) |
| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
Quote: Golara, Scan: Alright, alright. Next loader update (to be released soon) won't have the saver plug-in yet, but i'll prepare the custom drive code stuff for it and put the saver in the #1 spot of the TODO list for further releases. :)
awesome |
| |
Scan
Registered: Dec 2015
Posts: 110 |
That would be awesome! Remind me to buy you a beer at next X ;) :P |
| |
tonysavon
Registered: Apr 2014
Posts: 24 |
Quoting KrillGolara, Scan: Alright, alright. Next loader update (to be released soon) won't have the saver plug-in yet, but i'll prepare the custom drive code stuff for it and put the saver in the #1 spot of the TODO list for further releases. :)
That would be amazing and it would grant you my gratitude and more beer.
For my game Planet Golf I had to uninstall and reinstall the fastloader all the time to save hiscore and progress in game. After months of looking for a better solution that's all I could come up with, and saving is also quite slow! I miss the blazing fast AR/6 save routines :-P |
