Quote:
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.