Super Mario 64 for MorphOS

[Cowcat]

@samo79

Any news?

Not really other than a hard drive partition unvalidated with all my devel stuff.
Not a big deal but annoying long backups.

Did you try the whole ReWarp/ReWarp3dppc ?

Other than that not much I can do besides recoding again from ground up, trying to keep the minimum changes to be compatible among different computers, while at the same time not having access to them.

Not my intention to arrange code to support screensavers: None of my warpos programs have to care about that running on MOS (and I have the screensaver enabled).

I wonder why not an OS4 port has been done yet.

[samo79]

Originally Posted by Cowcat

Did you try the whole ReWarp/ReWarp3dppc ?

Yes, it works on Sam440 with ReWarp, however some textures are broken

Originally Posted by Cowcat

Not my intention to arrange code to support screensavers: None of my warpos programs have to care about that running on MOS (and I have the screensaver enabled).

Well, it will not be too much invasive, eventually that code could be inserted via a simple ifdef that could be activated only in case the game will be running under AmigaOS 4 +

Originally Posted by Cowcat

I wonder why not an OS4 port has been done yet.

In theory yes, but so far no one has done it yet. :-)
Where can i find the latest source of the WarpOS version?

[Cowcat]

Where can i find the latest source of the WarpOS version?

It is not published yet, but given that is a hacked port it should be most useful my MorphOS sources/recipes on github: After all it uses basically SDL2.

The WarpOS port uses my homebrew minigl and SDL1 solely for the sound part.

MOS -> sm64ex stable
WOS -> sm64ex nightly + changes from different ports + my own shit.

[Luigi Strada]

Originally Posted by Cowcat

@samo79

You found it

The texture problems are related to the sources used and those aren't the same as the MorphOS port.

Depending of the system running, this issues appear more or less: Warpos version on MOS all is fine except for the Mario front face that had to be changed to not look wrong for the Amiga version.

I know someone tested an earlier version on OS4 and more problems showed up (swirl of coloured vectors, etc).

Pictures, videos, whatever could help but I don't have access to other machines to test.

Hi Cowcat & samo79
I tried SuperMario64 WOS B2 on my A1200PPC Blizzard 603e @230Mhz and Bvision (Permedia2 GFX), you see the result in the Video, from OS4.1fe side it works apart from the texture problems mentioned by Samo79, while from OS3.9 side with Warp3D doesn't work, is there something missing to run it?
[ Show youtube player ]

Thank you.

[Cowcat]

from OS4.1fe side it works apart from the texture problems mentioned by Samo79, while from OS3.9 side with Warp3D doesn't work, is there something missing to run it?

Game works with Voodoo gfx cards for OS 3.9 on real Amigas and WinUAE warpos-mediator emulation.

No idea for Permedia: Adding some stack (like 2000000) on the OS 3.9 before start and having SnoopDos can tell more about what happens. Check sm64 configuration file for options (windowmode, sound, etc).

Curious behaviour for OS4 Classic on real hw: Permedia driver seems to work better than OS4 WinUAE emulation with mediator-voodoo ( it works "ok" with Wazp3D but some issues there ).

There's nothing special going from one gfx card to another from the perspective of the game and in fact expects too much from drivers to sort out issues.

For example: Some textures get stretched (like trees or Mario facefront) on Voodoo gfx and also on Wazp3D while as I see on the video, trees are not affected with Permedia on OS4.

Still trying to figure out how to get around those problems: A ground zero "non hacked" sources bring an Amiga classic binary that has sound but garbage textures moving around, so quite a few things needs to be done to have a proper display and that may affect different gfx drivers one way or another.
Even a 68k port could eventually be released but it's another battle too (built already but not working).

[thellier]

Perhaps you can find out what happen for "textures get stretched" with WaZp3D built in debugger
you can in Wazp3D-Prefs set
Enable debugger+ [Step] Update
it will make Warp3D stop at frame refresh
then Debug Points
this will give you the list of points drawn on the screen during a frame then you can search if there are some weird UV values that may cause problems on some drivers

Alain Thellier - WaZp3D author

PS: sorry I dont have an Amiga here to describe precisely how to debug

[Cowcat]

@thellier

Not sure about UV values but it might be some clamp/wrap issues here and there: You can simulate the problems changing texture clamp param by wrap param on a PC version and they look as the Amiga version.

As a side note I checked Wazp3D for AmigaOS4 and the problems increase with more repeated textures: Seems that by default filtering is not enabled or not even compiled in library. Example: On Amiga-OS 3.9 with Voodoo driver you have trees stretched left and right but with OS4 Wazp you have another one stretch on top of the trees. The same happens with OS3.9 if you change display filter settings on menu game to NEAREST.

Can't check Wazp3D for warpos because it doesn't exists of course. Maybe I'll try with MorphOS.

[thellier]

You are right : Wazp3D can only do "repeat texture" clam/wrap method
I never implemented W3D_CLAMP as it needed several tests per pixel (so slooow) but just W3D_REPEAT that is more straightforward