I'm Smiling

@Mikey_C

Not to alarm you, but have you double checked?

@tiffers

Quote:No.

For what do you want WarpOS emulation anyway?

Not for WarpOS games, at least 90% of them are too broken to run on AmigaOS4 without problems, especially the ones using Warp3D as well.

With the WarpOS scene demos it's even worse, 90% of them are too broken to even start.

WarpOS applications like FxPaint aren't usable either (at least the demo version, it constantly flushes the caches for the complete 4 GB address space, instead of only the few bytes actually used for passing data between the m68k and PPC CPUs on a real WarpUP system, which makes the WarpOS version much slower than the m68k one, even if you run the m68k version with m68k interpreter and not the m68k JIT. The powerpc.library which was included in Update4 had workarounds for such crap, but that caused other problems).

I have a powerpc.library which works on OS4 Final since over a year, but I haven't found a single WarpOS program yet which would justify a WarpOS emulation for AmigaOS4.

@joerg

Quote:

I wonder why they have such low compatibility. Excuse my ignorance, but is it because of the new memory system? It's a bit weird that they work better on MOS, because they were always Powerup-peoples while Hyperion was Warpos peoples.

@all

Now you know

@Helge

Quote:


Edit: Let me rephrase. WarpOS and PowerUp had their use on the classic, in place of a system that should have abandoned the 68k CPU right away and run exclusively on the PowerPC. It should never have tried to do anything like a "dual-CPU" solution, because you had to use all kind of tricks to get decent speed out of it (see Shogo as an example, it doesn't run on any WarpUp emulation AFAIK).

The bottom line is that IMO there isn't enough software that makes sense to preserve, hence WarpOS support is of no concern.

@Rogue

Quote:Shogo works on OS4 Update4. I only have the demo version, but IIRC other beta testers used the full version successfully as well. Except for the AHI music (the sound effects work, but the background music thread crashes), which was a problem in other Hyperion games as well on OS4, for example Freespace and Heretic II. The ShogoLauncher crashing when searching for CD drives itself (no CDDADEVICE and/or CDDAUNIT tooltypes set) is not WarpOS related, the problems installing or registering the full version probably not either. The intro/animation which should be there when starting the game doesn't work (black screen or flickering, but no crash). But the game itself does work. The first level on Voodoo3 even using hardware 3D with minimal gfx errors, for later parts and on Radeon cards only software 3D is usable.
Shogo is just the only WarpOS Warp3D game in which hardware 3D doesn't even work with a Voodoo3 on OS4.

Quote:For the WarpOS games using Warp3D the WarpOS part isn't the main problem, to make them work the OS4 Warp3D would have to include workarounds for the Warp3D related bugs in the games. Most of the old WarpOS Warp3D games work correctly with hardware 3D on Voodoo cards (Freespace, Heretic II, Payback, Wipeout2097, ...) because they were tested on Voodoo gfx cards, but AFAIK hardly anything works on Radeon cards which weren't supported by Warp3D yet when these games were written.
m68k Warp3D games, IIRC Payback included a m68k binary as well, have (or had, I don't remeber if Payback works with the current Warp3D and only had problems with early versions) exactely the same hardware 3D problems on OS4 and Radeon cards.
The first versions of the OS4 Warp3D.library didn't have a m68k jump table, which is used by WarpOS software as well, and could only be used with AmigaOS4 native Warp3D software, with hindsight it would have been better if it would have been keept that way ...

Except for games, and scene demos which largely don't work anyway, there isn't any WarpOS-only software AFAIK, and with Petunia the m68k versions aren't much slower, or even much faster than the WarpOS versions, for example without special workarounds for it in powerpc.library the WarpOS version of fxPAINT is even slower than running the m68k one with the interpreting m68k emulator on 750 CPUs (on 74xx CPUs it's data cache flushing of the complete 4 GB address space, instead of just the few bytes actually used for transferring data between the m68k and PPC parts, is much less of a problem).

@joerg

Quote:

IIRC, most games use more or less the same code for AHI output. It was a real mess because of the high overhead of context switches.

Quote:

I knew that

I haven't paid much attention to the old-style API when I did the Radeon drivers I have to admit. There are some interferences, especially if you tried to mix them. I wish I had had more time for the Radeon drivers, unfortunately I didn't, because I had some ideas to speed things up...

Quote:

My point exactly.

@joerg

Quote:

Really ??

Please release that !
I think that a lot of people want this emulation, not only me

@samo79

Why?

I can't think of a single useful app that would need this
that hasn't already got a native update or works with Petunia.

Yes a couple of games.. But is it really worth it?

@samwel

Quote:No. Or are there WarpOS-only games which do not use Warp3D?
For most users (Radeon gfx card) most WarpOS Warp3D games wouldn't work anyway, at least not with hardware 3D.

@samwel

WipeOut 2097 and more other games + utility are a good example, at this point my question is: why is impossible to release this library if is it more or less ready ?

Moreover why we must have one feature less regarding MorphOS ...

Just my 2 cents

@WOS convo

Just a note from personal experience.
FroggerNG (WOS) old version V2.05 for registered users does provide (through the linux PPC codecs) the means to playback Intel Indeo V3/4/5 and others than are not supported in MPlayer/DVPlayer undoubtedly because of licensing issues.

Whether you believe such formats are worth supporting or whether the licensing issues are insurmountable is unknown to me.

Some people argue to merely convert all old formats to new codecs that OS4 supports. I personally don't think that's a user friendly solution.

Re:AHI

Yep.

FroggerNG AHI broke at some point.
I substituted audio.device for AHI playback and the "unable to lock" errors disappeared.

Final, however, we know breaks the program further. Please forgive my description. Not meaning to offend. You can say program is broken, so final is not compatible -with- it.

Just my 2 cents.

#6