Why WHDLoad for new games?

[mcgeezer]

Originally Posted by meynaf

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.

So in other words.... write OS only compatible games...

I'm sick now of having this argument, it's like the 3rd time in a short space of time and plenty of people have presented arguments why it's not ideal.

Signing off.

[meynaf]

Originally Posted by jotd

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.

Yet whdload can not touch the disk without these horrible black screen swaps which also destroy the music. That alone completely invalidates any benefit. Yes, really. And don't tell me that it does not always happen : to avoid it, you have to use heaps of memory and not forget to quit, otherwise what you saved will not be written back on disk (and hope the file will not be larger or new).
The solution isn't whdload. It is to not turn off the OS at first place (or do it only on the lowest specs machine).
The mere reason why whdload exists is to have old broken software run on any machine.

[meynaf]

Originally Posted by mcgeezer

So in other words.... write OS only compatible games...

I'm sick now of having this argument, it's like the 3rd time in a short space of time and plenty of people have presented arguments why it's not ideal.

Signing off.

Killing the OS isn't ideal either. Nothing is.
And there is a big difference between being just OS compatible and using it for everything.
Of course you can do both from same source but that's another story.

[roondar]

Originally Posted by meynaf

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.

Actually, it really kind of does. If you can't prove a program is bugfree, then assuming it may be so anyway because you can't know is, quite frankly, absurd. You may as well accept that invisible unicorns may be responsible for the electromagnetic force as that is equally unprovable and thus 'unknown'.

[malko]

Originally Posted by roondar

[...] You may as well accept that invisible unicorns may be responsible for the electromagnetic force as that is equally unprovable and thus 'unknown'.

Really ? I thought 'unicorns' were only cooking the ice creams
[ Show youtube player ]

[meynaf]

Originally Posted by roondar

Actually, it really kind of does. If you can't prove a program is bugfree, then assuming it may be so anyway because you can't know is, quite frankly, absurd.

Nope. I didn't write you should assume software is bugfree.
The only reasonable thing to do is to not assume anything at all.

It is also absurd to assume a program isn't bugfree and WILL crash your system.
You can however suppose that a well tested program is reasonably bugfree and for all practical purposes, it's enough.

Originally Posted by roondar

You may as well accept that invisible unicorns may be responsible for the electromagnetic force as that is equally unprovable and thus 'unknown'.

Now, THAT's absurd.
If you can have an alternate explanation and it is simpler - i think we do - then Ockam's razor is enough.

[meynaf]

Originally Posted by malko

Really ? I thought 'unicorns' were only cooking the ice creams

In some way, it can be proven.
The presence of a unicorn, even invisible, should be detectable by other means. You can't touch it, then no unicorn. Done

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

[Predseda]

If I remember correctly, Adrian from Mutation was looking forward to the future WHDLoad of his Wiz as he has some troubles in coding HD installation for his own game. So sometimes even the authors of the new games appreciate WHD installs.

[malko]

Originally Posted by meynaf

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

C'est juste
Mais ça reste une chocolat CH
(enfin... sous mains DE)


You're right
But it's a CH chocolate at the end
(well... own by a DE company)

[meynaf]

Originally Posted by Predseda

If I remember correctly, Adrian from Mutation was looking forward to the future WHDLoad of his Wiz as he has some troubles in coding HD installation for his own game. So sometimes even the authors of the new games appreciate WHD installs.

It is always enjoyable to have someone else do your work at your place...

[roondar]

Originally Posted by meynaf

Nope. I didn't write you should assume software is bugfree.
The only reasonable thing to do is to not assume anything at all.
It is also absurd to assume a program isn't bugfree and WILL crash your system.

Who said anything about crashing? I said 'bug', not 'crash'.

Anyway, given the number of variables that exist, the real world results of pretty much all programs having known bugs and the entire testing profession assuming they'll never find all bugs in a program, it's far more absurd to me to take the position that we should assume nothing in regards to programs and bugs.

You can however suppose that a well tested program is reasonably bugfree and for all practical purposes, it's enough.

I never said otherwise. I'm just disagreeing with you that "not being able to prove it's correct" means we ought to not make assumptions about program correctness. On the contrary, our inability to prove correctness of even relatively simple programs should make us extremely wary about statements of something being 'bug free'.

Now, THAT's absurd.
If you can have an alternate explanation and it is simpler - i think we do - then Ockam's razor is enough.

Problem is, we do indeed have a simpler explanation: bugfree software is not actually known to readily exist. With that in mind, Ockam's Razor suggests that we should assume bugs in programs exist as that is a far simpler and more accurate explanation for what we actually see in the real world than not assuming anything about the state of bugs in programs.

Anyway, I do feel we're straying a bit too far from the OP's point here. If you do want to continue this, I suggest starting a new thread.

[meynaf]

Originally Posted by roondar

Who said anything about crashing? I said 'bug', not 'crash'.

You wrote : "such an environment is far less fragile than the OS itself".
This strongly suggests you're talking about crashing. Bugs that can't crash don't stress the OS.

Originally Posted by roondar

Anyway, given the number of variables that exist, the real world results of pretty much all programs having known bugs and the entire testing profession assuming they'll never find all bugs in a program, it's far more absurd to me to take the position that we should assume nothing in regards to programs and bugs.

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.

Originally Posted by roondar

I never said otherwise. I'm just disagreeing with you that "not being able to prove it's correct" means we ought to not make assumptions about program correctness. On the contrary, our inability to prove correctness of even relatively simple programs should make us extremely wary about statements of something being 'bug free'.

That ought not make us paranoid about bugs either. A small glitch that occurs once out of 100 won't crash the system and thus require sandboxing.

Originally Posted by roondar

Problem is, we do indeed have a simpler explanation: bugfree software is not actually known to readily exist. With that in mind, Ockam's Razor suggests that we should assume bugs in programs exist as that is a far simpler explanation for what we actually see in the real world than not assuming anything about the state of bugs in programs.

That's possible.
But in any case, assuming isn't proving. So assume if you want, but don't pretend it's a proof - as it's not.

Originally Posted by roondar

Anyway, I do feel we're straying a bit too far from the OP's point here. If you do want to continue this, I suggest starting a new thread.

Well, what did bring us here ? Ah yes, that was that whdload was necessary for you because we can't write bugless code ? If so, you have to know that whdload isn't a magical "fix my bugs" program and someone has to do the hard work anyway. So do it with a hacking program or in the original source, i think i know which i'd prefer.

[roondar]

Originally Posted by meynaf

You wrote : "such an environment is far less fragile than the OS itself".
This strongly suggests you're talking about crashing. Bugs that can't crash don't stress the OS.

That's your assumption, but not what I meant. A non-crashing bug can still cause issues after all.

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.

Of course I see that, I never argued against it.

Anyway, you're wrong to begin with, the most damaging bugs are often the ones that aren't detected until it's too late. Quite big companies have gone bust because of undetected bugs.

That ought not make us paranoid about bugs either. A small glitch that occurs once out of 100 won't crash the system and thus require sandboxing.

There are plenty of reasons to prefer sandboxing for games on systems like the Amiga. My statement about bugs is just one of them.

That's possible.
But in any case, assuming isn't proving. So assume if you want, but don't pretend it's a proof - as it's not.

I'm not assuming. I'm observing. And my observations fit with what I'm saying and they don't fit with what you're saying.

Well, what did bring us here ? Ah yes, that was that whdload was necessary for you because we can't write bugless code ? If so, you have to know that whdload isn't a magical "fix my bugs" program and someone has to do the hard work anyway. So do it with a hacking program or in the original source, i think i know which i'd prefer.

This is the third time you're making assumptions about me this post. For the record, all of your written assumptions about me so far this thread have been dead wrong and I've had to correct you on them every time. Kindly stop making these assumptionist. It's becoming tedious to have to correct you on all of these.

No, WHDLoad isn't necessary for me. It's a handy tool which would allow me to get my software available on more Amiga's than I actually personally care about*. It is not about fixing my bugs, but about providing a known-good environment so that users of the machines I don't own and can't physically test on would still have access to my programs. This is extremely useful to have.

*) if it has more than a 68020 or perhaps a 68030 I don't care about it and likely never will. If it has RTG, Networking, USB, etc - I also don't care about it. I don't care about PPC. I don't care about the Vampire. I don't care about OS 3.1.4/3.2/3.5/3.9/4.x.

I'm into the Amiga because of the low end models - as they were back in the early 1990's at the latest. They're all I care about. And I'm fed up with having to consider a gazillion other configurations and downgrading performance on my target machines, just so all of it will run on massively expanded Amiga filled with OS's I don't own, CPU's I don't own and have never officially been supported by Commodore and who knows what else. I'll do my best, I won't deliberately make things not work and I'll use all the compatibility code I know - but 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 I'd release even if my coding prowess may have failed - then I'm 100% in favour of it.

WHDLoad is one of the best things about the modern Amiga. Instead of slagging it off, appreciate what it does. Even if it's not for you.

[DamienD]

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. If it has RTG, Networking, USB, etc - I also don't care about it. I don't care about PPC. I don't care about the Vampire. I don't care about OS 3.1.4/3.2/3.5/3.9/4.x.

Seems we have similar opinions here

[meynaf]

Originally Posted by roondar

That's your assumption, but not what I meant. A non-crashing bug can still cause issues after all.

That's nitpicking.

Originally Posted by roondar

Anyway, you're wrong to begin with, the most damaging bugs are often the ones that aren't detected until it's too late. Quite big companies have gone bust because of undetected bugs.

This is cherry picking.

Originally Posted by roondar

There are plenty of reasons to prefer sandboxing for games on systems like the Amiga. My statement about bugs is just one of them.

And the others are ?

Originally Posted by roondar

I'm not assuming. I'm observing. And my observations fit with what I'm saying and they don't fit with what you're saying.

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.

Originally Posted by roondar

This is the third time you're making assumptions about me this post. For the record, all of your written assumptions about me so far this thread have been dead wrong and I've had to correct you on them every time. Kindly stop making these assumptionist. It's becoming tedious to have to correct you on all of these.

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.

Originally Posted by roondar

No, WHDLoad isn't necessary for me. It's a handy tool which would allow me to get my software available on more Amiga's than I actually personally care about*. It is not about fixing my bugs, but about providing a known-good environment so that users of the machines I don't own and can't physically test on would still have access to my programs. This is extremely useful to have.

*) if it has more than a 68020 or perhaps a 68030 I don't care about it and likely never will. If it has RTG, Networking, USB, etc - I also don't care about it. I don't care about PPC. I don't care about the Vampire. I don't care about OS 3.1.4/3.2/3.5/3.9/4.x.

I'm into the Amiga because of the low end models - as they were back in the early 1990's at the latest. They're all I care about. And I'm fed up with having to consider a gazillion other configurations and downgrading performance on my target machines, just so all of it will run on massively expanded Amiga filled with OS's I don't own, CPU's I don't own and have never officially been supported by Commodore and who knows what else. I'll do my best, I won't deliberately make things not work and I'll use all the compatibility code I know - but 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 I'd release even if my coding prowess may have failed - then I'm 100% in favour of it.

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

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

Originally Posted by roondar

WHDLoad is one of the best things about the modern Amiga. Instead of slagging it off, appreciate what it does. Even if it's not for you.

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.

[jotd]

Originally Posted by DamienD

Seems we have similar opinions here

i would say meynaf is your alternate account

[Minuous]

@roondar:

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

[jotd]

but a lot of coders didnt have one to test or it was so expensive that a few people had one. even tfx has 68030 fpu code but not 68040.

to play games it was common to turn off fastmem or disable the cpu board altogether. when the 040 was on main board you were screwed

[Minuous]

Yes, we are talking about new games though. If the guidelines are followed then there is no reason to expect it not to work across the full range, but anyway it is easy enough to test whatever configuration in UAE.

[meynaf]

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