Why WHDLoad for new games?

[Galahad/FLT]

Originally Posted by 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.

Not me, that is likely Oids

[roondar]

Originally Posted by meynaf

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.

I respect that, but if you're coding for low end machines (like I'm interested in), doing things that way is a sure fire way to not get the performance you want. Nothing is free and on a 7MHz 68000, OS overhead costs are not insignificant*. The way I see it, it's all a matter of what you're targetting.

Now, technically, I don't need WHDLoad to achieve any of my goals. I could simply kill/restart the OS at the beginning/end of my program and avoid any file IO during the programs runtime (or not run with the OS at all i.e. trackloader or some such thing). Then, if I'd absolutely want the maximum performance, I could even program a "1MB A500" code path and a "faster machine" one (though I don't actually see myself doing that - so far I aimed at keeping my code compatible across the processor range).

But, WHDLoad does offer a well known and commonly used method for running hardware hitting programs of harddisk and contains several features I personally find appealing for the kind of progams I'm interested in actually making. As such, I wouldn't see it as an odd choice to make a WHDLoad slave (or if I can't figure that out, asking for someone to make it for me) for new programs. YMMV

*) I measured the OS overhead to be around 20% of a frame while idling on A500. But when even the smallest thing happens (such as pressing a key even without the system outputting it to the screen while no programs are running at all), those numbers went way up. Losing over 80% of a frame to the OS doing background stuff was not uncommon on A500 in these circumstances.

[meynaf]

Originally Posted by 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.

You'll have to be a little more precise... Perhaps you've just run some 68020+ program on 68000 (ok, i should check and bail out, i'm too lazy...).

Originally Posted by roondar

I respect that, but if you're coding for low end machines (like I'm interested in), doing things that way is a sure fire way to not get the performance you want. Nothing is free and on a 7MHz 68000, OS overhead costs are not insignificant*. The way I see it, it's all a matter of what you're targetting.

Now, technically, I don't need WHDLoad to achieve any of my goals. I could simply kill/restart the OS at the beginning/end of my program and avoid any file IO during the programs runtime (or not run with the OS at all i.e. trackloader or some such thing). Then, if I'd absolutely want the maximum performance, I could even program a "1MB A500" code path and a "faster machine" one (though I don't actually see myself doing that - so far I aimed at keeping my code compatible across the processor range).

But, WHDLoad does offer a well known and commonly used method for running hardware hitting programs of harddisk and contains several features I personally find appealing for the kind of progams I'm interested in actually making. As such, I wouldn't see it as an odd choice to make a WHDLoad slave (or if I can't figure that out, asking for someone to make it for me) for new programs. YMMV

I still prefer the idea to have specific code to handle OS friendly vs max performance.
Anyway, not my problem : i code mostly, if not only, for 020+ because i find ol' 68000 too limited.

Originally Posted by roondar

*) I measured the OS overhead to be around 20% of a frame while idling on A500. But when even the smallest thing happens (such as pressing a key even without the system outputting it to the screen while no programs are running at all), those numbers went way up. Losing over 80% of a frame to the OS doing background stuff was not uncommon on A500 in these circumstances.

That looks very high, too much for even bare 68000. On my A1200/030 i get 0.5% lost to OS, which is quite acceptable. 20% is what i had with my 6502 eons ago.

[roondar]

Originally Posted by meynaf

Anyway, not my problem : i code mostly, if not only, for 020+ because i find ol' 68000 too limited.

Agreed, but then it's not the coder who chooses WHDLoad's problem that you don't really like WHDLoad as a method either

That looks very high, too much for even bare 68000. On my A1200/030 i get 0.5% lost to OS, which is quite acceptable. 20% is what i had with my 6502 eons ago.

I went back and checked it. I was wrong about the keypress being 80%, it's closer to 50-60%. Anyway, this post has some screenshots I made showing the overhead in WinUAE (obviously in 68000 cycle exact mode): http://eab.abime.net/showthread.php?...66#post1423466

As you can see, about 20% of a frame when idle, about 50-60% when pressing a key.

[meynaf]

Originally Posted by roondar

Agreed, but then it's not the coder who chooses WHDLoad's problem that you don't really like WHDLoad as a method either

I didn't say it was. I am just expressing an opinion, i'm not asking them to change

Originally Posted by roondar

I went back and checked it. I was wrong about the keypress being 80%, it's closer to 50-60%. Anyway, this post has some screenshots I made showing the overhead in WinUAE (obviously in 68000 cycle exact mode): http://eab.abime.net/showthread.php?...66#post1423466

As you can see, about 20% of a frame when idle, about 50-60% when pressing a key.

There are ways to gain some % back, f.e. by raising the task priority, calling CloseWorkbench(), or even doing Disable/Enable pairs around time critical code...

[roondar]

Originally Posted by meynaf

There are ways to gain some % back, f.e. by raising the task priority, calling CloseWorkbench(), or even doing Disable/Enable pairs around time critical code...

Sure, but we both know that these tricks won't get you back the majority of the time you lose, just a small part of it.

[meynaf]

Originally Posted by roondar

Sure, but we both know that these tricks won't get you back the majority of the time you lose, just a small part of it.

That depends how hard you try. And rare are the programs which need 100% all the time.

[roondar]

Originally Posted by meynaf

That depends how hard you try. And rare are the programs which need 100% all the time.

Right, well... That's a topic for another day. Suffice to say our opinions here differ as well

[jotd]

20% is what i had with my 6502 eons ago.

leaving a key pressed on the Oric sped up all operations by about 20% yes!!... go figure.

So basically you're saying that if you disable the OS during the game (and use it to load files, etc...) then the game will be 20% faster on slow configurations?

That's interesting, because I have a big performance issue on my Bagman remake. I should probably take over all vectors instead of using stoopid system interrupt vectors.

[meynaf]

Originally Posted by roondar

Right, well... That's a topic for another day. Suffice to say our opinions here differ as well

Assuredly

Originally Posted by jotd

leaving a key pressed on the Oric sped up all operations by about 20% yes!!... go figure.

That's keyboard membrane scan done in 100hz interrupt. Do simple SEI in your code, and gain 20% speed

Originally Posted by jotd

So basically you're saying that if you disable the OS during the game (and use it to load files, etc...) then the game will be 20% faster on slow configurations?

That's interesting, because I have a big performance issue on my Bagman remake. I should probably take over all vectors instead of using stoopid system interrupt vectors.

That's not me saying it's 20%, i'd have bet on much lower numbers. If it doesn't work, blame roondar
But yes, temporary disabling the OS might be a better idea than killing it altogether.

[Wepl]

Originally Posted by jotd

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

Since 18.3 delete operations are cached if the file is preloaded. It will only marked as deleted in the cache and on exit deleted. If the file is written again after the delete and the size does not exceed a previous length it is written to the cache and no osswap will occur.
So there should be no need to patch delete operations anymore.

Originally Posted by modrobert

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.

If there is a request to remove an install from the webpage with good reason I would remove it. A good reason could be actively sold for example. There are no clear rules and such requests didn't happen yet.
I myself would create installs for active developed games only in consultation with the original author. Nevertheless I tend to release all on the webpage as I don't like to spend time on checking such topics.

[jotd]

Since 18.3 delete operations are cached if the file is preloaded. It will only marked as deleted in the cache and on exit deleted. If the file is written again after the delete and the size does not exceed a previous length it is written to the cache and no osswap will occur.
So there should be no need to patch delete operations anymore.

Good to know, I overlooked that. But there's still the issue when the games writes 1 byte at a time. Kickemu "IOCACHE" doesn't seem to do the job.

[Retroplay]

Originally Posted by Wepl

A good reason could be actively sold for example. There are no clear rules and such requests didn't happen yet.

Idk how many people actually read the (revised) OP in the WHDLoad upload threads, but I made it clear that no new commercial titles will be added to the fileserver.

New commercial titles for sale
These will not be added unless they become freeware at some point
Inviyya
Reshoot R (AGA)
Turbo Sprint (AGA)
Wiz (AGA)

[jotd]

at least for Turbo Sprint and Wiz, those games don't have any protection whatsoever so whdload doesn't help cracking them or anything.