Why WHDLoad for new games?

[jotd]

Originally Posted by meynaf

I don't need a 68040 to know my code will work on it.

sorry but that's either presomptuous or stupid. Or both.


If you don't test something it has a chance to break, even if you're very good and you are extra careful.

[roondar]

Originally Posted by meynaf

That's nitpicking.

No, it's not. You assumed you knew what I meant and then when I corrected you, you call it nitpicking instead of accepting that you, as so often in our discussions, are just wrong.

This is cherry picking.

No, it's not. The vast majority of bugs that actually cause issues (serious or otherwise) fall in this category.

And the others are ?

• known good environment
• clean takeover of system, even if the process for that changes down the line
• all chip memory available rather than whatever the OS gives you
• ability to deal with new hardware and OS versions even if they don't exist at the moment yet (and so can't be tested)
• single interface to the end user, regardless of program used

Oh sorry ! You're observing ? Then i have to tell you observing isn't proving. So observe if you want, but don't pretend it's a proof - as it's not.

My observations are in support of my claim, which makes them more proof than you've yet given for the opposite. Which is, errr, nothing so far. Not to mention I already gave you proof in a variety of forms, you just don't want to accept it. I've now also given you reasons to accept that proof, by pointing out that the real world confirms what I'm saying via observation and these observations, by necessity, disprove your point.

Totally 100% just plain WRONG.
I am not assuming anything about you. Supposing, maybe. Questioning, certainly. But not assuming. YOU are the one assuming things about ME here.

Oh, really?

"What you don't see here is that not all bugs have equal importance and the ones that can do the most damage aren't the ones that escape detection." == an assumption about what I do and do not see. It's also dead wrong as I do see the difference between types of bugs.

"but don't pretend it's a proof" == an assumption. It's also dead wrong, I gave proof and support for it. You gave a philosophical argument which is easily disproven by simple observation and is thus worthless.

"This strongly suggests you're talking about crashing. " == another assumption. And as always, a dead wrong one.

Again, whdload will not magically make your code work. Some other guy has to take the burden of making it work.

And where exactly did I hold the position that WHDLoad will magically fix code? Right, nowhere.

You needn't consider all possible configs to build code that will work everywhere. Just write clean code that doesn't do horrors.

This is 100% dead wrong. There is no way to guarantee that even remotely.

I haven't said i didn't appreciate it for what it does.
It's a great tool. It's just that sometimes it's not the right tool for the job. Like every other tool.

The suggestion here is to use the tool for exactly that which it is intended to do. The developer manual even outright asks Amiga developers to use WHDLoad for new games.

Originally Posted by Minuous

@roondar:
The 68040 was certainly supported by Commodore. Just because you didn't have one is no reason to write buggy code.

Too bad then that I have literally not mentioned the 68040. Nor did I say anything about writing buggy code by design.

[Minuous]

Too bad then that I have literally not mentioned the 68040.

The 68040 is one of those processors you were talking about here that is more than a 68030:

Originally Posted by roondar

*) if it has more than a 68020 or perhaps a 68030 I don't care about it and likely never will.

[meynaf]

Originally Posted by jotd

sorry but that's either presomptuous or stupid. Or both.

It is neither. Just knowledge about cpu incompatibilities - and it's not much as normal code isn't affected.

Originally Posted by jotd

If you don't test something it has a chance to break, even if you're very good and you are extra careful.

The reasons why something can break on 68040 but not on 68030 are known so i can know for sure that my code will work.

Originally Posted by roondar

No, it's not. You assumed you knew what I meant and then when I corrected you, you call it nitpicking instead of accepting that you, as so often in our discussions, are just wrong.

And now that's bad faith and personal attack.
I have proven you wrong and you can't accept it, ok, but don't start doing name calling.

Originally Posted by roondar

No, it's not. The vast majority of bugs that actually cause issues (serious or otherwise) fall in this category.

Nope, unless you're locked in a "fail silently and keep going" environment.

Originally Posted by roondar

• known good environment
• clean takeover of system, even if the process for that changes down the line
• all chip memory available rather than whatever the OS gives you
• ability to deal with new hardware and OS versions even if they don't exist at the moment yet (and so can't be tested)
• single interface to the end user, regardless of program used

File i/o under whdload is at best unwieldy, and this will never change.
That alone invalidates it as the best solution.
List above is nothing in comparison.

Originally Posted by roondar

My observations are in support of my claim, which makes them more proof than you've yet given for the opposite. Which is, errr, nothing so far. Not to mention I already gave you proof in a variety of forms, you just don't want to accept it. I've now also given you reasons to accept that proof, by pointing out that the real world confirms what I'm saying via observation and these observations, by necessity, disprove your point.

And now you do the ad nauseam fallacy.
You just repeat the same thing over and over, it does not make it more true.

Originally Posted by roondar

Oh, really?

"What you don't see here is that not all bugs have equal importance and the ones that can do the most damage aren't the ones that escape detection." == an assumption about what I do and do not see. It's also dead wrong as I do see the difference between types of bugs.

Yes, really. You made broad assumptions and i told it to you.
But maybe you want me to show you how many assumptions you did about me ? Or even where you were directly insulting ?

Originally Posted by roondar

"but don't pretend it's a proof" == an assumption. It's also dead wrong, I gave proof and support for it. You gave a philosophical argument which is easily disproven by simple observation and is thus worthless.

You wrote explicitly it was proven that all software contains bugs. But this is just plain wrong -- what has been proven isn't that.

Originally Posted by roondar

"This strongly suggests you're talking about crashing. " == another assumption. And as always, a dead wrong one.

suggest != assume

Originally Posted by roondar

And where exactly did I hold the position that WHDLoad will magically fix code? Right, nowhere.

Oh yeah ?
How to interpret this then :
"if there is a tool that makes it so that the users of all those machines I personally don't care about can still use stuff"
This implies the tool does the work. It doesn't.
And don't argue on semantics. It is the tool that makes it, written clearly in your text.

But now that you deny your own words, no problem, but then all your arguing about the usefulness of whdload in this area falls apart.

Originally Posted by roondar

This is 100% dead wrong. There is no way to guarantee that even remotely.

Of course there is. It is not difficult to write code that will work on the whole cpu family. Even compilers can do this.
And for the rest, use the OS.

Originally Posted by roondar

The suggestion here is to use the tool for exactly that which it is intended to do. The developer manual even outright asks Amiga developers to use WHDLoad for new games.

How strange, whdload dev manual asks you to use whdload.
Guess what, the OS developer manual asks you to use the OS.

[DamienD]

Originally Posted by jotd

i would say meynaf is your alternate account

What?

[jotd]

forget it. bad joke

[phx]

The thread derailed, as usual, but this fits perfectly to my initial thoughts:

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.


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

I see this list for the first time and I wished the last three issues would have been reported to me! Maybe I even repeated these errors in later releases?

When the author is alive and interested in fixing his games, please communicate! It's an advantange for both sides. I am generally interested in writing code which runs on all classic architectures.

[jotd]

for the 3 last items I agree. But for the first item that requires you to add a "controls" menu that you probably don't have => extra work for you.

In the meantime, if you adapt to cd32 joypad for pause & other meta keys, in a few weeks someone is going to ask you to support vampire buttons too.

But for the 3 last items I agree. For the "defense" of the person who wrote the whdload slave, sometimes authors have moved on to another project and don't have the time to create another release for stuff like that.

[phx]

Originally Posted by jotd

for the 3 last items I agree. But for the first item that requires you to add a "controls" menu that you probably don't have => extra work for you.

Sure. Those are additional features, which a game author may like or not. Probably not, in this case.
I'm just talking about bugs.

[jotd]

Originally Posted by phx

Sure. Those are additional features, which a game author may like or not. Probably not, in this case.
I'm just talking about bugs.

you obviously didn't switch your joystick for a joypad

[saimon69]

Originally Posted by meynaf

Btw. Like we all know in France : C'est la marmotte qui met le chocolat dans le papier alu.

Even in Italy that darn Milka commercial did show up!
[ Show youtube player ]

[roondar]

Right, before I continue - I had a bit of a break and read back what I wrote. Not too happy about the tone I've been using and I do appologise for that. It's not my intention to insult or demean people and if I have done then I do appologise.

I'll try to be less antagonistic moving forward, though I'll also try to round of this discussion as I don't see much changing going forward.

Originally Posted by Minuous

The 68040 is one of those processors you were talking about here that is more than a 68030:

I can see why you thought this is what I meant, but the statement about processors unsupported by Commodore really wasn't about the 68040. Sorry if that is what it read as, I was refering to 68060/PPC/Vampire.

And now that's bad faith and personal attack.
I have proven you wrong and you can't accept it, ok, but don't start doing name calling.

I don't really think what I did there was name calling, but if you have perceived it as such, I am sorry.

Anyway, I don't agree that you've proven me wrong. And even if I were to grant you the mathematical evidence is lacking (which I'm not convinced of), it still doesn't really change the reality that bug-free software doesn't really seem to exist. I agree I got overboard in my argumentation about that, but I was trying to make a point in full, rather than just stick with one example and be done with it.

It's sometimes hard to argue a point. I was considering adding more forms of evidence, but decided against it because I honestly feel this has gone too far as is.

Nope, unless you're locked in a "fail silently and keep going" environment.

It seems to me that your definition of bug and mine might be different. To me, all of the many software related problems/issues/sometimes even disasters that happened over the past decades show very clearly that bugs that are not obvious or only trigger rarely are actually a really big problem, whereas the bugs that immediately cause a crash are the 'nice' ones - because they let you know something is wrong straight away.

I'm guessing here, but it seems that this may have been caused by the topic drifting so much from 'bugs in Amiga software' to 'bugs in general'. For the record, I'm talking about the latter.

File i/o under whdload is at best unwieldy, and this will never change.
That alone invalidates it as the best solution.
List above is nothing in comparison.

In my opinion, this list outweighs unwieldy file IO. But opinions vary and I respect that.

And now you do the ad nauseam fallacy.
You just repeat the same thing over and over, it does not make it more true.

No, I really didn't. I tried to support my argument by adding more points and some evidence, I did not repeat any of that (at least, I don't think I did) until just now when I tried to rephrase my point to make it clearer.

Yes, really. You made broad assumptions and i told it to you.
But maybe you want me to show you how many assumptions you did about me ? Or even where you were directly insulting ?

As written above, any perceived insult was not intended and I do apologise for that. I wrote in a too aggressive tone.

You wrote explicitly it was proven that all software contains bugs. But this is just plain wrong -- what has been proven isn't that.

The assumption on your part I was talking about is that I'm supposedly "pretending". I take issue with that, because saying that I'm pretending comes across to me as saying I'm being disingenuous. I'm really not.

suggest != assume

It actually kind of is, or at least that is how I interpreted that.

Oh yeah ?
How to interpret this then :
"if there is a tool that makes it so that the users of all those machines I personally don't care about can still use stuff"
This implies the tool does the work. It doesn't.
And don't argue on semantics. It is the tool that makes it, written clearly in your text.

But now that you deny your own words, no problem, but then all your arguing about the usefulness of whdload in this area falls apart.

The very same post also says "it is not about fixing my bugs" and points out I'll do my best to avoid compatibility issues. Both of which are equally relevant.

Of course there is. It is not difficult to write code that will work on the whole cpu family. Even compilers can do this.
And for the rest, use the OS.

I think you're missing my point. I'm not saying you can't write code compatible with the wider 68K family. I'm saying that you can't guarantee your program will work on all possible Amiga configurations that fit the minimum specs for your program (of which there likely are tens of thousands) unless you actually test on all of them. This would be absurd - so compatibility issues may exist, despite your best efforts.

How strange, whdload dev manual asks you to use whdload.
Guess what, the OS developer manual asks you to use the OS.

That is a red herring. My point is that WHDLoad is a tool intended for the very use we're talking about here, so it is proper to use it.

[alpine9000]

My games have two “versions”, a trackloaded A500, kill the OS version, and a version that tries as hard as it can to keep the OS fully functional. This is lots of extra work in (mainly) testing. I can see the appeal of only developing the base A500 version and letting the experienced WHDload patchers do their work (if they feel so inclined). It’s a win-win really, as the developer can save time and just focus on the game, and it seems some people actually enjoy doing patches,

It’s not really an option for me as I have networking code, so really need to keep the OS up and running, but I don’t think it’s a big deal if people go the WHDload route?

[jotd]

if you have 90% of your games running with whdload you want the 10 other % with whdload.

If you have 10% of your games running with whdload, it's not the same thing.

I developped a script generator to create AGS menus. Guess what: it scans whdload slaves and creates scripts only using whdload commands. If I had to support normal HD running scripts it would mean creating the script manually for each game, assigns, ... with a possibility that the game crashes because not enough mem.

But I'm not playing CD or big HD games. More focused or arcade.

[meynaf]

Originally Posted by roondar

I don't really think what I did there was name calling, but if you have perceived it as such, I am sorry.

Anyway, I don't agree that you've proven me wrong. And even if I were to grant you the mathematical evidence is lacking (which I'm not convinced of), it still doesn't really change the reality that bug-free software doesn't really seem to exist. I agree I got overboard in my argumentation about that, but I was trying to make a point in full, rather than just stick with one example and be done with it.

It's sometimes hard to argue a point. I was considering adding more forms of evidence, but decided against it because I honestly feel this has gone too far as is.

Let's just say we can't agree. It's not the end of the world.

Originally Posted by roondar

It seems to me that your definition of bug and mine might be different. To me, all of the many software related problems/issues/sometimes even disasters that happened over the past decades show very clearly that bugs that are not obvious or only trigger rarely are actually a really big problem, whereas the bugs that immediately cause a crash are the 'nice' ones - because they let you know something is wrong straight away.

I'm guessing here, but it seems that this may have been caused by the topic drifting so much from 'bugs in Amiga software' to 'bugs in general'. For the record, I'm talking about the latter.

You're talking about the latter, I'm talking about the former (even if i probably didn't explicit it, or even if i indirectly seemed to suggest otherwise).
Anyway, bugs in software have caused some havoc during history, that's clear, but it is what's the most visible. Like plane crashes. Programs that just work are kinda invisible, no breaking news about them. And i've seen some which have worked during 40 years without a single issue.

Originally Posted by roondar

In my opinion, this list outweighs unwieldy file IO. But opinions vary and I respect that.

Looking again at your list, i remarked something i didn't see before. All your points are coding related. Mine is player related - i've never really used whdload for anything else, preferring coding under OS.
So for a game programmer, your list indeed outweighs unwieldy file IO.
But for a player, it clearly does not - at least for me as a player.

Originally Posted by roondar

No, I really didn't. I tried to support my argument by adding more points and some evidence, I did not repeat any of that (at least, I don't think I did) until just now when I tried to rephrase my point to make it clearer.

This is how it has been perceived. But let's just stop that.

Originally Posted by roondar

As written above, any perceived insult was not intended and I do apologise for that. I wrote in a too aggressive tone.

What a relief. I admit that i lack diplomacy skills and when things get hot, i don't know how to handle it.

Originally Posted by roondar

The assumption on your part I was talking about is that I'm supposedly "pretending". I take issue with that, because saying that I'm pretending comes across to me as saying I'm being disingenuous. I'm really not.

Disingenuous ? I wasn't thinking that !
Anyone can inadvertently make a logical fallacy.

Originally Posted by roondar

It actually kind of is, or at least that is how I interpreted that.

Seems we just interpret things differently.

Originally Posted by roondar

The very same post also says "it is not about fixing my bugs" and points out I'll do my best to avoid compatibility issues. Both of which are equally relevant.

Then you just took a shortcut that led to a misunderstanding. This happens.

Originally Posted by roondar

I think you're missing my point. I'm not saying you can't write code compatible with the wider 68K family. I'm saying that you can't guarantee your program will work on all possible Amiga configurations that fit the minimum specs for your program (of which there likely are tens of thousands) unless you actually test on all of them. This would be absurd - so compatibility issues may exist, despite your best efforts.

Why would there be compatibility issues ? I'm using the OS and not doing SMC.

Originally Posted by roondar

That is a red herring. My point is that WHDLoad is a tool intended for the very use we're talking about here, so it is proper to use it.

No, it was just me telling (or unsuccessfully attempting to tell) that you're not required to trust a dev manual - or if you do, you have then no reason to not use the OS.
I find it strange whdload authors ask new games to use it. It is clearly not the original purpose.

[jotd]

I find it strange whdload authors ask new games to use it. It is clearly not the original purpose.

yeah, who does that? I certainly don't. I use it for my Supercars 2 AGA but I think that I'll get rid of it / propose an alternative in production.

[mcgeezer]

Originally Posted by jotd

yeah, who does that? I certainly don't. I use it for my Supercars 2 AGA but I think that I'll get rid of it / propose an alternative in production.

Indeed, it’s the other way around. I asked if a slave could be written for Turbo Sprint in conjunction with release.

Others are going the same route.

[roondar]

Originally Posted by meynaf

Let's just say we can't agree. It's not the end of the world.

Agreed

What a relief. I admit that i lack diplomacy skills and when things get hot, i don't know how to handle it.

You're not alone, I have a similar problem when things get hot.

Why would there be compatibility issues ? I'm using the OS and not doing SMC.

I'm not really talking about your code as much as the unknown state of the systems that will end up running it. There's a lot of variables that can impact this (perhaps more so on Amiga with it's OS architecture being what it is). I've personally had perfectly OS legal software that didn't do any strange stuff fail on some of my Amiga's, but not others.

The wider point would be that compatibility across a wide range of devices (even if they are ostensibly compatible with one another) is well known to be an extremely tricky subject.

I find it strange whdload authors ask new games to use it. It is clearly not the original purpose.

I'm pretty sure I read that in the docs, IIRC there have also been some posts about it where WHDLoad devs pointed out how useful it would be to do this (I particularly remember this being brought up in a thread about keyboard reading). To me it actually makes a lot of sense to go this route, but I respect your opinion might differ.

But perhaps it's not clear what I meant: I actually mean the route that McGeezer took, where he made a non-WHDLoad game and arranged for a WHDLoad slave to be ready on release. I fully understand this may not have come across in my posts though, sorry it wasn't clear.

[meynaf]

Originally Posted by roondar

I'm not really talking about your code as much as the unknown state of the systems that will end up running it. There's a lot of variables that can impact this (perhaps more so on Amiga with it's OS architecture being what it is). I've personally had perfectly OS legal software that didn't do any strange stuff fail on some of my Amiga's, but not others.

The wider point would be that compatibility across a wide range of devices (even if they are ostensibly compatible with one another) is well known to be an extremely tricky subject.

I've never had any real compatibility issues. Only "compatiblity" reports i had were a 040 machine that was rarely used and had random hardware failures, and a cd drive where my picture viewer failed due to maxtransfer problems...

The most common case we could face isn't true compatibility issue, but simply a random error triggering more often on some configs than on others.
But, believe me, if you've successfully tested your code under winuae jit, you can be reasonably sure it will not fail on other accelerated machines.
In addition, all OS / hardware stuff i use is in include files i reuse over and over. I pushed the concept so far that if someone could rewrite them for another 68k platform, all my code would suddenly work on it too

Originally Posted by roondar

I'm pretty sure I read that in the docs, IIRC there have also been some posts about it where WHDLoad devs pointed out how useful it would be to do this (I particularly remember this being brought up in a thread about keyboard reading). To me it actually makes a lot of sense to go this route, but I respect your opinion might differ.

I value whdload as a debug tool and perhaps this is what the docs authors meant when they recommended its use...

Originally Posted by roondar

But perhaps it's not clear what I meant: I actually mean the route that McGeezer took, where he made a non-WHDLoad game and arranged for a WHDLoad slave to be ready on release. I fully understand this may not have come across in my posts though, sorry it wasn't clear.

I have nothing against using whdload on own projects (i just find it pointless).
But hell doors open when a slave is released without asking original game author first.

It's fine for me if someone makes whdload slave for one of my programs and tests it in this environment, like this can be done with tools such as enforcer.
But doing special versions (not only whdload, but also adf), i don't like it.
And releasing patches in my back, it's a big no.

All my games multitask fully. You can pause the game, start some internet download in the background, or whatever. You can quit them all cleanly and without any leak due to my internal resource tracking. If you have special hardware such as serial mouse/keyboard requiring unusual drivers, it will work just fine. All disk i/o happens normally, obviously.
Don't tell me a whdload version would have an edge over that. Nope. Definitely not.
If you want to have a reason why i don't like the idea of whdload for new games, then it's that one.

[jotd]

one of the ST ports I tried crashed after the "FTL" logo. Not sure if it was one of yours or Galahad. Didn't try with whdload.