Why WHDLoad for new games?
 

I hope nobody feels offended by this question, but I'm asking myself why do WHDLoad slaves exist for games, which have just been released? Sometimes the patch is even released together with the game.

Most WHDLoad- and game authors are EAB members. So why are problems not simply reported, or why don't game authors care about these reports? Maybe the game author doesn't want some issues to be fixed?

For example I would not want to "fix" my trackloader and make the game work on hard disk. But I could imagine there are issues worth fixing.

Well, I worked with StingRay to produce the WHDload slave and I was glad that I did because he highlighted a couple of bugs. For me it was just about offering all options to the player, even though the game runs fine from Workbench there might have been situations that I missed because during the game I wake the system to DOS load a track... WHDload would save my bacon here.

Nice to hear! So it actually works that way. I just wondered, because I never got a bug report from a WHDLoad author in the past (or I forgot about it).

Just out of curiosity: what was the reason not to apply this patch directly to your source?

Because that's exactly the situation which I try to avoid in my games. Never resurrect the OS when I have taken over the system. Dangerous things may happen, so the responsibility for a trashed HD file system is on WHDLoad. :D

The thing is WHDload creates a virtual machine, is well tested and if the patch is done properly then there wont be any issues. I see the benefits of letting WHD handle hard drive and OS related aspects

StingRay notified me of a couple of things during the development of the slave, one thing it did pick up was a fault in your replay code using a0 instead of a6 (but I think you fixed this already).

All bugs found were fixed in the final game, there was only a couple - related to an incorrect write to floppy disk CIA stuff and to BEAMCON0. UAE dbg didn't pick these up and neither did enforcer.


Yup, everyone kept telling me the dangers... hence ... release a WHD which knows the ins and outs of this stuff.... but also people like the quit key stuff the WHDloads provide.

I've more or less resigned myself to only creating either fully OS or fully non-OS stuff.

Which means that for me, going the WHDLoad route would be a very useful way to sidestep having to deal with exactly the issues McGeezer is pointing out. Because I'm frankly not too confident about my abilities regarding the whole stop-start OS stuff mid program.

:great

Fair enough. Thanks for the details.

If you followed your statement from the first sentence then there would never be any stop-start OS stuff. ;)

whdload MMU setup will detect all wrong accesses to unknown memory, it can snoop registers for missing blitwaits, ...

less interesting when you have WinUAE but the "wrong access" part is more flexible in whdload.

Personally I'll be using it also to develop my own games now. And maybe after the game runs properly I'll switch to some less compatible but okay OS loader just to avoid the memory overhead (whdload needs to save chipmem and flashes when files aren't preloaded because of OS swaps)

About "new games" that could be fixed by their authors, yeah, that's true. But sometimes the original authors don't want for instance to add a second button for jump, trainer, ... and whdload provides that.

Also some games need "no startup" to run because of maxed out chipmem. Whdload doesn't need that. And I'm not talking about creating a routine that starts/stop the OS and doesn't leak memory, and handles MMU translation tables, caches... of all processors 68000/010/020/030/040/060...

If I can flip this one a little bit....

Without WHDload... how then does a developer keep the system off but utilise high-score saving to any medium (hard drive/floppy).

It feels to me like the Amiga OS needs some sort of gaming mode function to safely abstracts storage reads/writes from the rest of the system.

If the answer is... only write OS compatible code then we've had that argument recently already and neither the purist OS devs or gaming dev's won the argument.

Indeed, which is why I pointed it out ;)
One can but hope :)

There are people (like me) that just do not play games if they can not be run from harddisk. And I do not like Gotek and similar ADF solutions. Maybe I am in a minority, but I am glad for WHD installs for new games. And even if there are games, that have their own hd install script, it is worth for people who use WHDLoad launchers such as iGame.

Interesting. I already asked myself why there is no framework for game developers based on WHDLoad? But one disadvantage is higher memory usage? Then how can WHDLoad fix games which use up all Chip RAM? Probably not at all, because WHDLoad usually runs on systems with 2MB Chip and an MMU? So another disadvantage of a WHDLoad-based frame work would be the CPU requirement?
(Sorry, if some questions sound stupid, but I never used WHDLoad myself.)

Floppy is easy. You write your own trackloader. It's well documented in the HRM. But hard drives and other storage devices, like NVRAM, are impossible to support.

Something like an extended lowlevel.library? Maybe this would even be possible for higher end Amigas, but probably not an option for stock A500.

No, I agree with you that it is not. You can do that for specific types of games and/or when the hardware requirements are big enough. But not for a 7MHz 68000 action game.

I've said all this before but... I disagree with that.

I always use Native installs over WHDLoad :agree

Unfortunately due to the way in which WHDLoad works; sometimes crazy amounts of RAM are needed, plus the flashing of screens / when saving is quite annoying.

Indeed if you are less than 4mo-8mo of fast memory.
Big games can cause OS swap...
If not just use Preload tooltype to remove OSSwap when you have enought of fast mem.

But without whdload's slave you lost all slave features:
Bug fixes, second joystick button support, clean return to OS , compatibility with fast CPU & AGA, trainer...

Yeah sure, but native installs also have bug fixes / patches / trainers etc..

...and I have installed a load of games, maybe over 100, that will never see WHDLoad versions due to size / complexity etc.

I know some people only play games that have a WHDLoad version. These people are limiting themselves IMHO and missing out on some very good games indeed.

Bug fixes, second Button support, clean return to OS , compatibility with fast CPU...color palette fixes, highscores, full CD32 pad support, trainer etc. ;)

There are a lot of good reasons. But i agree partially, some games are very OS friendly and don't need necessarily a WHDLoad patch expect for the mentioned convenience stuff.

Only if you activate this feature (NoWriteCache). Normally, WHDLoad will save to disk when it exits. Maybe you noticed flashing while saving because the save file doesn't exists already. This happen in the past when slave author forgot to add save files with install. However, after first save to disk there is no flashing if you don't activate NoWriteCache feature.

@DamienD

I'm sure that no one write WHDLoad install for these "maybe over 100 games", because it is without sense. This is rather talk about games which don't have proper "native" (trainers?) installers.

I'm using WHDLoad, but only when it's needed. When game is working properly from HD installed with own installer (or via assigns) I see no sense to use WHDLoad for them*. But there are games which are not working well or not working at all without WHDLoad. And we are talking about real hardware, not emulation when You can have individual configuration for every game.

*Ok, maybe when WHDLoad adds something (more buttons support, saving, fixing bugs...)

It would seem to me that including WHDload for that gaming mode abstraction layer would be a good thing to include in the next OS release... i for one would support it with my games.