| |
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....
|
| |
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. |
| Previous - 1 | 2 | 3 | 4 - Next |
