Look for something called WipeLoader if you haven't tried it already. It is mentioned here in this package:
https://morph.zone/modules/news/article.php?storyid=610

This is something I have yet to try myself! I'm kinda reminding myself here to try it! hehe

Get WipeOutLoader here:

http://bigfoot.morphos-team.net/files/

credits go to bigfoot. Wipeout works like a charm.

I'm using a BVision and i have no problems with WipeOut. Maybe there is an incompatibility with the voodoo cards.
When you say 3D update you mean the update for the MOS 3D package? Afaik, this can not be used with the PUP version of MOS due to the lack of gfx drivers.

The patch is required for Radeons and voodoos. Was it really stable
with the voodoo5? With my Radeon7000 it does start succesfully w/o
that patch, but then slows down heavily, maybe it has been the same
with the voodoo5?

Anyway, the patch should solve the probs (I wish there was a patch
available to solve *my* probs with the phantom class ).

I loaned Wipeout2097 from a friend. Works in full speed in 1280 x 1024 x 24 ... the second track is a BITCH to beat

Hi Folks !
@hooligan : what is your machine and cards inside ?

@AmigaMancer : I got 50/60 fps with a V5 PCI on peg1G3, and 12/22 fps on V3 Pci on 1200GREX/OS3.9.
You should take a look about the 3D updates script, there is a Voodoo section for MOS PuP.

Whatever, I was well setted in 16 bits mode.

I hop to try the BigFoot patch tonight.

For some reason the computer locks up when I`m on the second track, maybe 15 seconds into it, then I have to turn the computer off and back on. It`s got a Radeon 7000 card. Any Ideas anyone?

[ Edited by Nitro on 2005/9/28 13:13 ]

@CLS2086

Pegasos 2, 256mb ram and Club Radeon9100.

Hi,
@hooligan + Nitro : you are in the MOS for Amiga Classic section, not Pegasos .

I put the newest files of the new MOS PUP release on my 1200, but no more luck. I tried the Bigfoot patch, no more luck (especialy with FFS and a same name directory ).

So I investigated a bit farer on my Peg1
No more luck, still have gray windows with "application is mediating" or black screen with mouse cursor only.

On my peg1, I tried to install linux on a new hard drive, damn the installation start on the 2nd CD drive (an old 2-2-6), restart the install on a DVD 16/40x, but i forgot the mem=254m option so the install hang...

I replug my old hdd with MOS 1.4.5 (no 3D update, no bigfoot patch) but i did not replug my old 2-2-6, and mysteriously, Warp3D and WipeOut are fully reworking....

I was too tired to check that on my 1200 which is equiped with 2 SCSI drive (1 DVD + 1 CDRW). I suppose this might be the solution.

Strange isn't it ??

[ Edited by CLS2086 on 2005/9/29 10:18 ]

Quote:
Ok, i have a question: How do you define how many fps you are getting when there isn't a fps switch for the game? (same for BlitzQuake)

Quote:
There is not a BVision driver atm, so i can't use it.

As explained in the manual... you must press the DEL key to switch the FPS counter OFF/ON.

Ooops..right. Sometimes i'm too sloppy. :D

on my PEG1 G3 with an AGP Voodoo3-3000 I got 22/37 FPS in 640x480

Hi,
So i still try to understand what happen on my 1200 with MOS PUP
here is the snooplog of it :
here
I can see some calls to voodoo4 driver.
Is Voodoo 3 and 4 unified or not ? I don't think so, because during the boot there is a realy separate section for voodoo4 and voodoo3.

I tried the demo called : Yellow Rose of Texas, and it seems to work but it's very grey and turn around 3 fps...

Ps : My machine : A1200+BPPC@224(PPCbus=64)+SCSI+256Mb+GREX+Voodoo3+last MOS PUP...

[ Edited by CLS2086 on 2006/3/24 22:57 ]

[ Edited by CLS2086 on 2006/3/24 23:01 ]

Hi,
I also add some more logs :

WipeOut2097 - OS3.9

I also tried to install MOS - FReeSpace2 (it took nearly 2 hours...), same things, black screen with cursor
FreesSpace2 MOS

I hope this might help...

Hi guys, I lost my ftp password and cant get another, sent to many emails ...

get it .

Ps: I have issues with this two games in my old voodoo3 3000, not tested yet with my voodoo3 2000 but I guess the problem is still here, if I get the 3D package I will try later this titles and see wath may change.

[ Edited by DDJ on 2006/3/26 18:02 ]

Hi,
I updated to the last PowerSdl lib but no more luck...

With Monolith MorphOS (software), I got 7 fps with 0 objects and 3.5 fps with 50 objects.

As Stefkos told me yesterday I did a GeteRamDebugLog.

Here is an extract :

Packet Result1: $1c4e2759
Packet Result2: $d1
-----
GetMsg: Packet $7133cc5c from Task $71765014 Workbench
Packet 26 $1c4e2759 $1c4cf340 $fffffffe $000000c0
**************************************
ActInfo:
GetVolInfo: DiskType $0 BlockNum 9a24 BlockSize 800
**************************************
Packet Result1: $ffffffff
Packet Result2: $d1
-----
GetMsg: Packet $7133cc5c from Task $71765014 Workbench
Packet 15 $1c4e2759 $1c4cf340 $fffffffe $000000c0
**************************************
ActUnLock:
**************************************
Packet Result1: $ffffffff
Packet Result2: $d1
-----
GetMsg: Packet $7133ca1c from Task $71765014 Workbench
Packet 8 $00000000 $1c4cf2a6 $fffffffe $000000c0
**************************************
ActLock: Lock 0x0 Name 0x7133ca98 Mode -2
ActLock: [] 00008a8871341edc7133cac000000000
ActLock: File to lock: <>
ActLock: Lock ACCESS = -2
ActLock: namelen=0, do a duplock
CreateLock: Searching for locks from 0x00000000
CreateLock: Access outstanding is 0
CreateLock: Creating the lock 719d9d54 for key=23
CreateLock: Task=7128d224 Vol=1c025777
CreateLock: New Lock
CreateLock: fl_Key =23
CreateLock: fl_Access =fffffffe
CreateLock: fl_Task =7128d224
CreateLock: fl_Volume =1c025777
CreateLock: fl_FileSize =-1
CreateLock: fl_DirFileKey =0
CreateLock: fl_DirFileOffset=0
CreateLock: fl_ParentKey =0
ActLock: Lock created at 719d9d54
**************************************
Packet Result1: $1c676755
Packet Result2: $d1
-----
GetMsg: Packet $7133cc5c from Task $71765014 Workbench
Packet 26 $1c676755 $1c4cf340 $fffffffe $000000c0
**************************************
ActInfo:
GetVolInfo: DiskType $0 BlockNum 9a24 BlockSize 800
**************************************
Packet Result1: $ffffffff
Packet Result2: $d1
-----
GetMsg: Packet $7133cc5c from Task $71765014 Workbench
Packet 15 $1c676755 $1c4cf340 $fffffffe $000000c0
**************************************
ActUnLock:
**************************************
Packet Result1: $ffffffff
Packet Result2: $d1
-----
LIB_InitResident: Resident 0x71a22eb8,SegList 0x1c6875b3
LIB_InitResident: Name pciids.library
LIB_InitResident: Flags 0xc8
LIB_InitResident: Version 50 Revision 3
LIB_InitResident: Tags 0x0
LIB_InitResident: AutoInit 0x71a2d3bc
LIB_InitResident: MakeLibrary PPC
LIB_InitResident: MyLibrary 0x71a1d7f4
GetMsg: Packet $7133ca1c from Task $71765014 Workbench
Packet 8 $00000000 $1c4cf2a6 $fffffffe $000000c0
**************************************
ActLock: Lock 0x0 Name 0x7133ca98 Mode -2
ActLock: [] 00008a8871341edc0000000000000000
ActLock: File to lock: <>
ActLock: Lock ACCESS = -2
ActLock: namelen=0, do a duplock
CreateLock: Searching for locks from 0x00000000
CreateLock: Access outstanding is 0
CreateLock: Creating the lock 71a118f4 for key=23
CreateLock: Task=7128d224 Vol=1c025777
CreateLock: New Lock
CreateLock: fl_Key =23
CreateLock: fl_Access =fffffffe
CreateLock: fl_Task =7128d224
CreateLock: fl_Volume =1c025777
CreateLock: fl_FileSize =-1
CreateLock: fl_DirFileKey =0
CreateLock: fl_DirFileOffset=0
CreateLock: fl_ParentKey =0
ActLock: Lock created at 71a118f4
**************************************
Packet Result1: $1c68463d
Packet Result2: $d1
-----
GetMsg: Packet $7133cc5c from Task $71765014 Workbench
Packet 26 $1c68463d $1c4cf340 $fffffffe $000000c0
**************************************

CLS2086,

SnoopDOS logs don't help much, especially not when the output has been localised to French. I asked a French friend, and he couldn't make any sense of it either :)

But even in English, it wouldn't help much. It sounds to me like Wipeout is crashing.

What would be useful would be the MorphOS log of when this happen, preferably without too much useless MorphOS debug enabled (as shown above :)

Not having MorphOS near me ATM, but IIRC edebugflags initresident and ddeebugflags loadseg would be a good start, and then the full log of the crash is needed.

Hi, thanks for your answer.
So I did :

startup hal=roms/hal.com1 kernel=roms/kernel.com1 abox=roms/abox2.com1 module=roms/module.com1 resetlevel=$resetlevel ramdebug verbose debug EDebugFlags="InitResident PCI" DDebugFlags="LoadSeg" sumkick disableled delay=$delay extmodules=extmodules/#? $bootdevice $kickstart

and when WipeOut2097 goes "on PLAY", I got a popup screen with these indications :

----------------------------------------------------------------------
01:23:48 29-Mars-06
Exception 3 <Illegal Data Access at 0xffffffcc>
Task 0x71b97fa8 <Background CLI> Type 13 Pri 0
----------------------------------------------------------------------
SRR0 7228ec20 SRR1 0000f070 LR 71d7d160 CTR 10258ca0 CR 44204042 XER 00000000
GPR[00] 71d7d160 72252088 71ba3a50 71d6c1ac 81080000 71d6c1ac 0000000e 00000000
GPR[08] 00000000 71b10000 71b4c7a8 722b2254 48202044 722620c8 71c75ce0 00000004
GPR[16] 720ead80 719aa370 719aa628 42202042 10109588 719aa628 71d6c160 719b0000
GPR[24] 722521a4 719b0000 722522d0 719b0000 00000001 722b2254 7130b0cc 00000004
SRR0 -> DHO:MorphOS/Libs/rave3d/voodoo3.library Hunk 1 Offset 0x5a78
LR -> MOSSYS:LIBS/rave3d.library Hunk 1 Offset 0x1630
----------------------------------------------------------------------
01:23:48 29-Mars-06
Exception 7 <Program>
Task 0x71b97fa8 <Background CLI> Type 13 Pri 0
----------------------------------------------------------------------
SRR0 00000000 SRR1 0008f070 LR 7228ec30 CTR 00000000 CR 44204042 XER 00000000
GPR[00] 71d7d160 72252088 71ba3a50 71d6c1ac 81080000 00000000 00000000 00000000
GPR[08] 00000000 71b10000 71b4c7a8 722b2254 48202044 722620c8 71c75ce0 00000004
GPR[16] 720ead80 719aa370 719aa628 42202042 10109588 719aa628 71d6c160 719b0000
GPR[24] 722521a4 719b0000 722522d0 719b0000 00000001 722b2254 7130b0cc 00000004
LR -> DHO:MorphOS/Libs/rave3d/voodoo3.library Hunk 1 Offset 0x5a88


I hope it will give you an idea.
Many thanks,
Chris - CLS2086

OK, right...

Can you please do a version md5sum mossys:libs/rave3d.library and version md5sum mossys:libs/rave3d/voodoo3.library and paste the output here?

Also, please add nologserver to the edebugflags, reproduce the crash and use getramdebuglog to retrieve the log and post it somewhere where I can get it (or to bigfoot@private.dk if you don't have some webspace where you can put it)

Hi, so I did it :
fbd154c0308367edad558a6b0a8ca752 rave3d.library 50.6
-> it's the same for the "3d update" of August 2005.

ba67612edb38deb20fe927c411369ff3 voodoo3.library 51.2
-> it's the same for the "3d update" of August 2005.

For the log, it's in your mail
I thought about a stack size problem

***PPC Stack Ptr is not between PPCSPLower and PPCSPUpper
SRR0 -> DHO:MorphOS/Libs/rave3d/voodoo3.library Hunk 1 Offset 0x00005a7c
LR -> MOSSYS:LIBS/rave3d.library Hunk 1 Offset 0x00001630
CTR -> Module Hunk 0 Offset 0x00158ca0

The stack overflow warning isn't valid for WarpOS programs, as they use the 68k stack for PPC code too.

But indeed it _does_ look like a stack problem. The program has 100000 bytes of stack size, but it overflows this by almost 200000 bytes by the time of the crash, and it ends up using the driver code as stack space... So wonderful things happen.

I don't remember what the default stacksize for Wipeout is, and as I still don't have MorphOS near me ATM, can't check. But try upping the stacksize to 350000 or thereabouts and see if that doesn't fix the problem.

Hi, Ok i will try that soon.
But where do i have to set the stack ? by a shell imput ?