Why WHDLoad for new games?

[jotd]

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.

I'm one of those, but you're right whdload makes no sense for big games with 40MB+ data (BASS talkie, CD games...) that naturally run from CD/HD.

[DamienD]

Originally Posted by daxb

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.

I never have "NoWriteCache" set.

Try "Test Drive", get a highscore and you'll see what I mean... and this is a very mild example.

Originally Posted by Solo Kazuki

@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...)

Which is exactly what I do... and also believe it doesn't always make sense; but I usually get shot down by the WHDLoad zealots though for this comment.

I only use WHDLoad in extreme cases where there are no bug free disks, or native installs available, or some extra feature that's too good not to have.

[daxb]

Originally Posted by DamienD

Try "Test Drive", get a highscore and you'll see what I mean... and this is a very mild example.

Sorry, cannot test but I had a look into the archive. There is a 136 bytes Highscore file. If this file is used for highscore saving and the only one then there must be a bug or some strange behaviour for this game. I would report it. Maybe it is just a bug.

[meynaf]

Originally Posted by Retro-Nerd

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

For old games i would say : of course.
But this thread is about new games. Which should have these features from day one. It's not as if todays coders didn't know.

Originally Posted by daxb

Maybe you noticed flashing while saving because the save file doesn't exists already.

Sometimes you'll get that annoying black screen flash even if the file already exists. It's when the file to be written is larger than the one on disk (i think).

[jotd]

yes exactly. That's why sometimes I remove the "delete" calls and provide empty big files for savegames. Else it flashes forever

[Retro-Nerd]

It's not as if todays coders didn't know.

Of course, most of them know it. OS friendly is fine. But the extra WHDload slave options, that often aren't included by the coders in their original releases, are nice and greatly appreciated. You can't force them to do all that nice extra stuff in the first place. And sometimes there are indeed graphics/sound glitches (or other issues) in newer Amiga 500 games on faster CPUs/AGA. Stingray had to fix some things e.g. in Solid Gold.

History:
--------

version 1.01 (02.08.2016)
- option to jump with fire added (CUSTOM3, requested by modrobert)
- write to Beamcon0 disabled
- color bit fix
- ECS/AGA register access (Bplcon3/4, Fmode) disabled

[meynaf]

Originally Posted by Retro-Nerd

But the extra WHDload slave options, that often aren't included by the coders in their original releases, are nice and greatly appreciated. You can't force them to do all that nice extra stuff in the first place.

Come on, it's not difficult options to add.
Besides, they should be added in original source code, not by hacking the exe with a patch.

Originally Posted by Retro-Nerd

And sometimes there are indeed graphics/sound glitches (or other issues) in newer Amiga 500 games on faster CPUs/AGA. Stingray had to fix some things e.g. in Solid Gold.

Again, this should be done in original source code.
But maybe it's better to let coders think : oh, i can code like pig, there will be some whd slave to fix my mistakes ?

[modrobert]

I like to have a neat game list (LazyBench integrated in Classic WB) to easily pick WHDLoad slaves from on the hard drive (CF card), game saves in respective directories, and the quit function back to Amiga OS.

Also find the "hrtmon <-> WHDLoad" hotkey integration useful sometimes when experimenting with stuff.

Best of all, the awesome WHDLoad Team making it possible, helping out when there are problems with certain hardware, or bugs, even adding new features.

[Retro-Nerd]

But maybe it's better to let coders think : oh, i can code like pig, there will be some whd slave to fix my mistakes ?

This is a bit provoking. Some really don't care about faster CPUs or AGA and code for Amiga 500 only with custom trackloader. Nothing wrong with that.

[daxb]

Thanks meynaf and jodt! I thought that already but wasn't sure. Maybe I was lucky never "falling" in that situation where save files where growing. I guess there aren't that much games that do this?

[jotd]

I always test savegames to check if the default behavious is bearable. If it isn't, then I try to cache the writes.

Lucasfilm games needs help to avoid infinite swaps. File seems to be written one byte at a time, not buffered, and the file size is over 40k

[meynaf]

Originally Posted by Retro-Nerd

This is a bit provoking. Some really don't care about faster CPUs or AGA and code for Amiga 500 only with custom trackloader. Nothing wrong with that.

I wouldn't say there is nothing wrong with that, but this subject would bring us too far...

[jotd]

emulator users already having different configs don't see the interest of creating another config to run a whdload game instead of creating a config with 1 IPF floppy or crack with trainer .

some emulator users have only one config, from where they run all games (and it's even more the case with real amiga users). There whdload comes in handy.

[mcgeezer]

Originally Posted by meynaf

Come on, it's not difficult options to add.
Besides, they should be added in original source code, not by hacking the exe with a patch.



Again, this should be done in original source code.
But maybe it's better to let coders think : oh, i can code like pig, there will be some whd slave to fix my mistakes ?

It's all well and good saying this as long as you are a fully seasoned games developer who knows all of the ins and outs of the Amiga, sadly that is rarely the case for game developers.

Writing perfect games in assembler is far from easy when you don't know what tools can help you out along the way. Game dev's learn along the way from people here like yourself who kindly offer up free advice and more importantly dev's learn from their mistakes.

So if a game gets released that has a few bugs, the developer can either choose to fix them with the help from the guys creating the slaves or they can release their game unknowingly with bugs and the WHD team can address them.

I'm failing to see the problem.

[StingRay]

Originally Posted by meynaf

Come on, it's not difficult options to add.

I actually didn't want to post in this thread, but reading your comment I couldn't stay silent anymore. So, you are saying that all extra options added by the WHDLoad patches are not difficult to do. I have just one question: How many of these "not difficult to do" options did you add to a WHDLoad patch yet?

But maybe it's better to let coders think : oh, i can code like pig, there will be some whd slave to fix my mistakes ?

You should at least try to remain objective, the way you "discuss" such things leaves a lot to be desired.

Originally Posted by mcgeezer

I'm failing to see the problem.

Because there is none.

[malko]

Originally Posted by Retro-Nerd

[...] But the extra WHDload slave options, that often aren't included by the coders in their original releases, are nice and greatly appreciated. You can't force them to do all that nice extra stuff in the first place. [...]

You are right and I like it as well. In the other hand, sometimes (for commercial games in fact), I think that WHDLoad patcher should not improve/fix at all the new game except if they get some financial retribution from the original coder/team. At the end they help selling the game as well...

[Bruce Abbott]

Originally Posted by meynaf

Come on, it's not difficult options to add.
Besides, they should be added in original source code, not by hacking the exe with a patch.

I agree. Patches should only be used when you don't have the source.

But maybe it's better to let coders think : oh, i can code like pig, there will be some whd slave to fix my mistakes ?

Yes. All new games will be coded bare metal to work only on a specific machine, and every other Amiga will need WHDLoad to run them. Any bugfixes will be applied via WHDLoad. Then WHDLoad will be integrated into the latest OS so nobody who doesn't upgrade to it will be able to run them. This will be called 'progress'.

WHDLoad is very useful for running old games on more modern Amigas. But I don't use it because I can't be bothered setting it up. These days anything that isn't 'point and click' or takes longer than 10 seconds to figure out loses my interest very rapidly. The Amiga was supposed to make such frustrations a thing of the past. You would think that after 30 years that goal would have been achieved.

[meynaf]

Originally Posted by mcgeezer

It's all well and good saying this as long as you are a fully seasoned games developer who knows all of the ins and outs of the Amiga, sadly that is rarely the case for game developers.

Writing perfect games in assembler is far from easy when you don't know what tools can help you out along the way. Game dev's learn along the way from people here like yourself who kindly offer up free advice and more importantly dev's learn from their mistakes.

So if a game gets released that has a few bugs, the developer can either choose to fix them with the help from the guys creating the slaves or they can release their game unknowingly with bugs and the WHD team can address them.

I'm failing to see the problem.

Read what Bruce Abbott said : patches should only be used when you don't have the source. Can't be clearer than that.

Originally Posted by StingRay

I actually didn't want to post in this thread, but reading your comment I couldn't stay silent anymore. So, you are saying that all extra options added by the WHDLoad patches are not difficult to do.

Yes they are not difficult to do. Perhaps i should have added : when you are the game developer or have a source you understand well enough.

Originally Posted by StingRay

I have just one question: How many of these "not difficult to do" options did you add to a WHDLoad patch yet?

None. That wasn't the point.
But f.e. support for 2 button joystick, yes, i added that. Directly in game source code. Five minutes work. Of course all my game ports can quit cleanly - no need of whdload for that. Etc.

But wait. Are you saying this kind of work, while easy in original game source, isn't easy at all in a whd patch ? Then this supports my point : better touch original source when you have it.

Originally Posted by StingRay

You should at least try to remain objective, the way you "discuss" such things leaves a lot to be desired.

How else could i have said it ? I was provocative, sure, but at least the message passed.

[jotd]

better touch original source when you have it.

I have Jim Power source code and I can't rebuild it because it uses native assembly tricks that assemble at such or such addresses (custom overlays). I could assemble one version but it crashed in the middle of a level

=> sometimes it's better to trust the binary!

but of course if the source code assembles ok & runs and you have it, what you're saying is obvious.

plus if you create a whdload patch and the author publishes an update you have all the offsets to fix... that's why I wait for pink/mcgeezer/other to freeze their productions before starting any patch.

Note: Tiny Galaga has a "FIGHER CAPTURED" typo in the game. Should we tell him to release another version for that? well, personally I fixed the typo in the whdload slave.

[meynaf]

Originally Posted by jotd

Note: Tiny Galaga has a "FIGHER CAPTURED" typo in the game. Should we tell him to release another version for that? well, personally I fixed the typo in the whdload slave.

When there is an existing slave for the game, yes, but you would probably not create a new one just for that, will you ?