Why WHDLoad for new games?

[mcgeezer]

Originally Posted by Bruce Abbott

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

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.

Those who have coded on the platform for 30 odd years
appear to have zero compassion or empathy for those coming back to the platform after 30 years.

If all dev's wrote perfect code day in, day out from scratch then we wouldn't have any bugs in software at all. In fact, let's just do away with patching all together and version numbers and let the perfect software
roam free.

Thankfully most developers (except a handful who seem to frequent this forum) do make mistakes when writing software/games, leading to the need to release patches for their software.

Even the best developers make coding mistakes leading to patch releases, so as a game dev myself how thankful I am that the guys writing the WHD slaves can create a patch quickly to fix and enhance certain things in a game without me having to go back and re-release stuff.

WHDload isn't doing any harm to the Amiga, so there's no problem to fix.

[jotd]

@mcgeezer I would have patched SIESMIC MINDS if you left that in

WHDload isn't doing any harm to the Amiga, so there's no problem to fix.

I don't see how a program that is not a virus is doing harm to a machine. People who don't want to use it, just don't use it. But then don't request "dos fixes" or "aga fixes" because they're really a waste of time (except for very few exceptions like CDTV compilations...).

[meynaf]

Originally Posted by mcgeezer

Those who have coded on the platform for 30 odd years
appear to have zero compassion or empathy for those coming back to the platform after 30 years.

If all dev's wrote perfect code day in, day out from scratch then we wouldn't have any bugs in software at all. In fact, let's just do away with patching all together and version numbers and let the perfect software
roam free.

Thankfully most developers (except a handful who seem to frequent this forum) do make mistakes when writing software/games, leading to the need to release patches for their software.

Even the best developers make coding mistakes leading to patch releases, so as a game dev myself how thankful I am that the guys writing the WHD slaves can create a patch quickly to fix and enhance certain things in a game without me having to go back and re-release stuff.

WHDload isn't doing any harm to the Amiga, so there's no problem to fix.

And one day someone will release a 'fix' for one of your games without asking you and break something in the process but YOU will receive the bug report.

[jotd]

Originally Posted by meynaf

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

someone asked for a slave. I created it (not too much work), added a trainer, removed LMB=>quit (annoying) (all of those are optional!) and then I noticed the typo.

The file is packed with cranker or equivalent, that doesn't have any depacker so DOS patch / trainer is not as easy as with uncompressed or PP/RNC packed games you have to write a LoadSeg loader first.

[mcgeezer]

Originally Posted by meynaf

And one day someone will release a 'fix' for one of your games without asking you and break something in the process but YOU will receive the bug report.

Yes God forbid this could happen, it's not exactly the end of the World is it.

As soon as you establish they're using the WHD version you can either say (1) It's not supported under that version/any WHD and/or (2) Contact the slave author to fix it.

[mcgeezer]

Originally Posted by jotd

@mcgeezer I would have patched SIESMIC MINDS if you left that in

I even registered the domain... I wanted the ground to swallow me up after you showed me that

You did fix other typos though...

"

fixed typo in title ("LEGENDARDY" => "LEGENDARY")"

[modrobert]

Originally Posted by Bruce Abbott

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

Source code always helps, even when patching in WHDLoad. When the developer/author(s) of a game or demo decides they don't want a feature or fix support for certain hardware, or they turn inactive, then what? A source fork handled in a repository elsewhere?

Originally Posted by Bruce Abbott

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 a very efficient and system friendly sandbox providing max compatibility with optional patching at launch, to me this is an elegant method as media is not patched directly/permanently.

Besides, take any library, like MUI for example, many developers use it, and now you have dependencies as a user, how is that any different?

If a developer makes an OS friendly game which can run from the hard drive, and is compatible with most hardware then there is no need for WHDLoad. If someone still wants to make a slave for it, to add some feature, does it matter? It's all optional to use. The developer can add the feature as well, so many choices and all beneficial.

Originally Posted by Bruce Abbott

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.

Originally Posted by Bruce Abbott

Perhaps, but ProAsm, BAsm and PhxAss don't accept it. Since these are the only assemblers I use...

First time I encounter a fellow assembler programmer who relies on "point and click".

CLI or Shell...

whdload game.slave

Too hard for you?

[meynaf]

Originally Posted by mcgeezer

Yes God forbid this could happen, it's not exactly the end of the World is it.

As soon as you establish they're using the WHD version you can either say (1) It's not supported under that version/any WHD and/or (2) Contact the slave author to fix it.

Not the end of the world but an annoyance and a waste of time.

Also imagine someone released a patch and now you want to make a new version including all fixes made. So you do your release and now the whd patch does not work anymore - it's of course not necessarily the slave author who will receive the reports for that.
At the end : more work for everyone. For what benefit ?

[modrobert]

Originally Posted by meynaf

Not the end of the world but an annoyance and a waste of time.

Also imagine someone released a patch and now you want to make a new version including all fixes made. So you do your release and now the whd patch does not work anymore - it's of course not necessarily the slave author who will receive the reports for that.
At the end : more work for everyone. For what benefit ?

How about looking at this as a distribution media/option?

So you release a new game from your own website, make a post in the forum about it. Without doing anything else you get a bunch of more users who found your game through whdload.de and then get the media from your website and play it that way. The only drawback is that you sometimes have to ask users to report bugs somewhere else.

[meynaf]

Originally Posted by modrobert

How about looking at this as a distribution media/option?

So you release a new game from your own website, make a post in the forum about it. Without doing anything else you get a bunch of more users who found your game through whdload.de and then get the media from your website and play it that way. The only drawback is that you sometimes have to ask users to report bugs somewhere else.

A bizarre way of seeing things, a site distributing games that forces the use of a specific tool. Instead, better have a site referencing games regardless of the way they are made.
But yes, the point is somehow valid. Would bring some indirect benefit.
I doubt of its efficiency though. Making PC versions should bring more users (probably, i wouldn't know which forum to post it on).

[mcgeezer]

Originally Posted by meynaf

Not the end of the world but an annoyance and a waste of time.

Also imagine someone released a patch and now you want to make a new version including all fixes made. So you do your release and now the whd patch does not work anymore - it's of course not necessarily the slave author who will receive the reports for that.
At the end : more work for everyone. For what benefit ?

I actually have this very scenario with Turbo Sprint, there's a few small fixes that I need to do that have been reported.

So I contact the WHDload author (who in this case is StingRay) and notify him what the changes are. Benefits...not much work at all for me, and WHD author gets a heads up so not much time for them. Maybe your definition of a lot of work differs from mine though.

[roondar]

I actually feel that the idea of a game 'sandbox' environment, like WHDLoad, makes a lot of sense. Not only because it lets you actually use the HW in ways that best fit low-end machines, but more importantly, because such an environment is far less fragile than the OS itself.

Theoretically, all these things can be fixed by writing bugless code. But in practice, that won't happen. Worse, bugless software of any complexity can't happen, as was mathematically proven decades ago.

[modrobert]

Originally Posted by meynaf

A bizarre way of seeing things, a site distributing games that forces the use of a specific tool. Instead, better have a site referencing games regardless of the way they are made.
But yes, the point is somehow valid. Would bring some indirect benefit.
I doubt of its efficiency though. Making PC versions should bring more users (probably, i wouldn't know which forum to post it on).

Yes, not efficient considering the work done (time spent), that's for sure, but I think it makes sense in an enthusiast community. Was just thinking about how great HOL is for Amiga game info, reviews, manuals, and more.

A question for the WHDLoad Team:

If a developer clearly states that they don't want a WHDLoad slave for their project, would that be honored?

I'm not sure what the policy is, but doubt a slave would be made, at least while the developer is still active.

[meynaf]

Originally Posted by mcgeezer

I actually have this very scenario with Turbo Sprint, there's a few small fixes that I need to do that have been reported.

So I contact the WHDload author (who in this case is StingRay) and notify him what the changes are. Benefits...not much work at all for me, and WHD author gets a heads up so not much time for them. Maybe your definition of a lot of work differs from mine though.

Happy that it works for you, but maybe one day you'll have a not so kind slave author or one who got fed up / lacks time / whatever and you'll end up with old versions in the wild, that you have no control on.
In any case, that's still more work than just doing your thing alone. Or maybe you have the slave author do your debug work at your place ? Not a bad move indeed

Originally Posted by roondar

I actually feel that the idea of a game 'sandbox' environment, like WHDLoad, makes a lot of sense. Not only because it lets you actually use the HW in ways that best fit low-end machines, but more importantly, because such an environment is far less fragile than the OS itself.

It does not fit low-end machines. High-end, rather.
But yes, whdload can be seen as a fine debugging tool.

Originally Posted by roondar

Theoretically, all these things can be fixed by writing bugless code. But in practice, that won't happen.

In practice, it does not matter at all. If you can afford running whdload (i.e. switch off the OS), there is no program currently running that would suffer from a system going off.
In addition, bugs that can lead to a global system crash aren't the ones that will go inconspicuous (esp. for years). Bugs that remain "forever" are minor glitches which depend on specific conditions to trigger. Or at least, they should be.
And this can be returned : if bugless software does not exist, you'd rather not add whdload's bugs to your own. As more software just means more bugs.

Originally Posted by roondar

Worse, bugless software of any complexity can't happen, as was mathematically proven decades ago.

Mathematically proven ? Just that ? I want to see it. Where's the proof ?

[mcgeezer]

Originally Posted by meynaf

Happy that it works for you, but maybe one day you'll have a not so kind slave author or one who got fed up / lacks time / whatever and you'll end up with old versions in the wild, that you have no control on.
In any case, that's still more work than just doing your thing alone. Or maybe you have the slave author do your debug work at your place ? Not a bad move indeed

As the author of the slave is here in the thread I'm sure he can answer for himself.

but then there's nothing stopping me from creating or taking over the slaves myself, but then of course you'll say "well just add the functionality into the game" which results in us going round in circles.

I think you're clutching at straws in an attempt to try and present a problem here that really just does not exist. Plenty valid reasons have been put forward already to use WHDload with new releases. The downsides are just not washing with me.

[roondar]

Originally Posted by meynaf

It does not fit low-end machines. High-end, rather.
But yes, whdload can be seen as a fine debugging tool.

I meant that using WHDLoad for higher end machines allows you to write code that fits low-end machines better.

Mathematically proven ? Just that ? I want to see it. Where's the proof ?

Godel's Incompleteness Theorem means you can't prove a program is 'correct'. Also, the Halting Problem means you can't prove your program will not halt/crash. There's probably more, but those two by themselves are more than enough.

More to the point, there has been a lot of research into proving correctness of programs and the end conclusion still is: it's really, really hard, requires you to define what correct means fully and even then only is able to prove it fits your chosen definition of 'correct', which can't be proven to be correct thanks, again, to Godel.

Professor Gernot Heiser did this for a 7500 line kernel. It took him and his six man team five years of full time work to get to the point where it was proven to work according to his definitions. But, as I pointed out, no one can prove that the definitions used for program correctness themselves are correct (due to Godel) so even he didn't actually prove his program was bug-free.

[meynaf]

Originally Posted by mcgeezer

As the author of the slave is here in the thread I'm sure he can answer for himself.

but then there's nothing stopping me from creating or taking over the slaves myself, but then of course you'll say "well just add the functionality into the game" which results in us going round in circles.

I think you're clutching at straws in an attempt to try and present a problem here that really just does not exist. Plenty valid reasons have been put forward already to use WHDload with new releases. The downsides are just not washing with me.

Then just go this way. When you'll hit the downsides, you'll finally see them. Else indeed we're going in circles.

Originally Posted by roondar

I meant that using WHDLoad for higher end machines allows you to write code that fits low-end machines better.

That's clear now.
But you can write code that fits low-end machines without being broken for high-end ones.
And I fail to see in which way whdload could be better than doing that at source level.

Originally Posted by roondar

Godel's Incompleteness Theorem means you can't prove a program is 'correct'. Also, the Halting Problem means you can't prove your program will not halt/crash. There's probably more, but those two by themselves are more than enough.

More to the point, there has been a lot of research into proving correctness of programs and the end conclusion still is: it's really, really hard, requires you to define what correct means fully and even then only is able to prove it fits your chosen definition of 'correct', which can't be proven to be correct thanks, again, to Godel.

Professor Gernot Heiser did this for a 7500 line kernel. It took him and his six man team five years of full time work to get to the point where it was proven to work according to his definitions. But, as I pointed out, no one can prove that the definitions used for program correctness themselves are correct (due to Godel) so even he didn't actually prove his program was bug-free.

There is a logical error here. Absence of proof isn't proof of absence. IOW That you can't prove something does not in any manner prove that it's not true.
So you cannot prove a program is bugfree, certainly - however that does not imply there are actual bugs in it. You just can't know.

[jotd]

If a developer clearly states that they don't want a WHDLoad slave for their project, would that be honored?

I would comply, until developer goes bust / dies

okay, now to try to counter the trolling that's going on here (not in that particular remark above which is a legitimate question!!), now just to be objective, I'll take an example of what whdload brings:

cdtv machines have hardware that trigger interrupts. It sends what can be seen as spurious interrupts to programs that turn off the OS.

a few examples:

- whdload detects cdtv.device, turns it off, then on on exit. It also has custom pre-post scripts that you setup once and for all.
startup/end script has been improved for years. Each game may have a very good startup/end process it cannot compete with one single program mostly dedicated to that.

- whdload has plans to add read joypad support, with Vampire support for extra buttons (extra reg DFF222). Should have appeared earlier, but how many programs will support those buttons without whdload? (and without a patched lowlevel library if ever those programs use it which isn't 100%, not even 50%)

- whdload can introduce delays when reading/writing on slow devices.

- whdload support all CPUs, has no memory leaks, triple checks all stuff on startup, frees everything on exit, has centralized options and customizable startup/stop scripts...

All those features are centralized in whdload.


now can we stop the trolling about whdload? I guess not.

[mcgeezer]

Originally Posted by meynaf

And I fail to see in which way whdload could be better than doing that at source level.

I'll ask then the same question to you like I asked the others.

You have a game that has a requirement to load and save files to storage while having full access to the system - i.e. banging the hardware.

How would you then tackle using DOS library calls (game loading/saving) so your game supports CD32/hard drives and floppies?

[meynaf]

Originally Posted by mcgeezer

I'll ask then the same question to you like I asked the others.

You have a game that has a requirement to load and save files to storage while having full access to the system - i.e. banging the hardware.

How would you then tackle using DOS library calls (game loading/saving) so your game supports CD32/hard drives and floppies?

Bang the hardware only when strictly necessary and after having got access to it thru the system. You OwnBlitter, allocate channels thru audio.device, get timers with ciaa/ciab.resource, etc.
Then DOS calls will be extremely easy and, nice bonus, will never make these black screen flashes. Your game will be able to use any hardware (such as a serial mouse) that your OS can, even if it needs weird drivers. It will of course use a lot less memory than with whdload.