@Karlos

Thanks man! But I have good news!

Erased my WarpUP and Warp3D and re installed the ones that were on CD of WO. It now works!

I have two small issues now:

Although I have made full install I am not able to ehar music just sound FX, the CD is in the drive but as far as I understood the program search for CD on scsi.device however I use atapi.device -unit 2-, but besides this a full install suppose to copy the CD tracks on the hard disk, is this correct? Anyway is there anyway to get music as well?

Second: installing the odler WarpUP I lost my datatypes, I am not able to view JPG anymore -my wallpaper is JPG so I get an error, so I checked-is there a way to fix this, have not checked with any other files. I do not remember how to fix it it was ages since I sued 3.9 and I am bakc again somekind of lost :)

Thanks!

Last edited by Morphix on 06-Jun-2012 at 01:33 PM.

_________________
Peg1, Peg2, Efika,
Amiga 500, Amiga 600, Amiga 1230,
Amiga 1200PPC, Amiga 4000PPC,
CDTV, CD32,
Sam 440EP, AmigaOne XE,
MacMini PPC, PowerMac G4

@Karlos

>You will notice that the text background is dark blue rather than transparent
about this bug just see my post here for the cause
http://www.amigans.net/modules/xforum/viewtopic.php?post_id=67309

>I have just implemented W3D_DrawElements()
Nice
BTW I was never able to use W3D_InterleavedArray() + W3D_DrawElements() with my Sam440 on Os4/Warp3D v5
Sometime it works then it crash next time : very weird
Here my source & binary just type 'e' to use DrawElements and 't' for DrawTriangle
http://thellier.free.fr/Cow3D4.zip

Alain Thellier

Ah wanted to ask:

Quote:

The problem is due to the fact that in V4 Warp3D, a fake additive blending mode was added to the P2 driver for MiniGL/Heretic 2, which requires that textures are configured a particular way to leverage. Unfortunately, WO2097 detects the mode but can't use it properly, resulting in the dodgy trails. However, this issue has been fixed in OS4.1 since W3D_Permedia2.library v 52.24 (21.2.2011), but you do have to read the release notes to be aware of how to use it. You need to set ENVARC:Warp3D/Permedia2/wipeout/DisableAdditiveBlending to "on" Notice the executable/process name in the path. That's a feature of the P2 driver in OS4.1, you can provide per-application driver settings in addition to global ones. The per-application settings always override the global one where the application name (or process name) matches. You don't want to set this one globally as it will interfere with later titles. On the subject of Warp3D V5 Permedia2 settings, for Wipeout2097 you can also use: ENVARC:Warp3D/Permedia2/wipeout/DisableFBClear "on" ENVARC:Warp3D/Permedia2/wipeout/EnablePatchedZ "on" That should give you a small FPS boost. The first setting turns W3D_ClearDrawRegion() into a No-op. It seems that either the draw buffer is cleared by a graphics.library call, or that every pixel is overwritten at some stage regardless. Not clearing the buffer not only saves on the memory blockfill time but also prevents the various register caches associated with 3D primitive rendering from getting invalidated during drawing. The second setting reconfigures the Z buffer to use patches, which allow faster Z testing. At present, this interferes with software access to the Z buffer, but Wipeout2097 doesn't use any anyway.

Are those settings for 4.1?

I guess so....

Update:

Have replace my datatypes on Classes and Devs with some 68k versions however it would be cool if the Warp datatypes to work with older WarpOS (4) if someone is aware of any fix / solution I may be your guest :)

Last edited by Morphix on 06-Jun-2012 at 01:37 PM.

_________________
Peg1, Peg2, Efika,
Amiga 500, Amiga 600, Amiga 1230,
Amiga 1200PPC, Amiga 4000PPC,
CDTV, CD32,
Sam 440EP, AmigaOne XE,
MacMini PPC, PowerMac G4

@Morphix

Those settings are for the Warp3D V5 Permedia2 driver in OS4.1. I haven't tested it, but theoretically it should work under OS4.0 too.

Last edited by Karlos on 06-Jun-2012 at 01:38 PM.

_________________
IBrowse/AWeb user? amiga.org - classic browser edition

@thellier

Regarding the chromatest stuff, that's interesting. The Permedia2 has upper and lower chromatest bounds but the R200 doesn't IIRC. Will need to look into that one.

I'm almost done with a big refactor of that driver so that it can use the same per-application environment overrides that the Permedia2 one does. That will simplify the task of getting the driver working better with problematic applications without affecting well behaved ones.

_________________
IBrowse/AWeb user? amiga.org - classic browser edition

@thellier

From your linked post:
Quote:

In fact WipeOut 2097 use W3D_SetChromaTestBounds() but it use it on ALL textures ... even on non transparents ones (...stupid) Also i am not sure if wipeout enable chromatesting ?!!? should do SetState(context,W3D_CHROMATEST,W3D_ENABLE); Also it call W3D_SetChromaTestBounds() with false parameters W3D_CHROMATEST_EXCLUSIVE (=only texels outside the specified range are drawn, others are rejected) from 0 0 0 0 to 255 0 0 0 Does that really works on some real Warp3D ???? In fact the error is here: In RGBA format solid-black is 0 0 0 255 not 255 0 0 0 (argb format) So wipeout was meaning "exclude pixels from transparent black to solid black" ==> do transparency where tex is black

Hmm, that seems like an attempt to optimize transparency to me. If you pick one specific colour to be transparent (eg black), you can simulate 1-bit transparency for formats like RGB565 without requiring an alpha channel or blending. As well as allowing a bigger colour gamut for the texture (you lose one colour instead of half of all possible colours), it can be achieved without any need to read from the framebuffer, unlike alpha blending.

I need to check but I suspect that the colour order of the values given to this function could have changed or at least been a bit more vague in the past.

_________________
IBrowse/AWeb user? amiga.org - classic browser edition

Guess what?

The default Permedia2 register format for chroma testing is ABGR and I can tell you now, the driver doesn't do any transposition on the input value.

It would seem that perhaps the game is using the format that worked on Permedia2 but then fails on later drivers.

Must... fix... before... 10pm....

_________________
IBrowse/AWeb user? amiga.org - classic browser edition

Drat, it's more complex than that. It seems that the parameters passed to the function are trying to chroma key out black, regardless of the alpha level as both lower and upper values are passed, spanning the entire alpha range.

The Radeon doesn't have a lower and upper boundary, instead it only has one chromakey. I've added environment switches to control whether the lower or upper value is used and whether to byteswap the colour values first. I've also added a force chromatest mode if either of these other vars are set. So far, however, the texels that should be rejected are still being plotted.

Last edited by Karlos on 06-Jun-2012 at 10:21 PM.

_________________
IBrowse/AWeb user? amiga.org - classic browser edition

@Karlos

Quote:

On the plus side, I have just implemented W3D_DrawElements() for non interleaved arrays (was completely missing) and fixed a bunch of line rendering issues for that driver :)

That's a good news for sure, however since latest OS4.1 Update 4, WipeOut 2097 does not work anymore under my Sam440 Flex + Radeon 9250 PCI, it just crash badly with an ISI error at startup

Almost with update 2 and 3 i was able to do my test with the game, even if at the time the game was indeed unplayable because the usual freeze after some seconds ..

I really really hope that one day all that problem will be fixed in a way or another, maybe for the next Update 5 !

_________________
BACK FOR THE FUTURE

http://www.betatesting.it/backforthefuture

Sam440ep Flex 800 Mhz 1 GB Ram + AmigaOS 4.1 Update 6
AmigaOne XE G3 800 Mhz - 640 MB Ram - Radeon 9200 SE + AmigaOS 4.1 Update 6

@Karlos

1) Keep in mind that WaRp3D specs WANTS lower bound. & upper bound as a 32 bit RGBA value (not ARGB,BGRA,etc...)

2) also as wipeout specify an incorrect upper bound 255 0 0 0 (should be in RGBA format 0 0 0 255 = solid black) then wipeout shadow will NOT works on correctly well written drivers

3) as chroma keying is mainly used with textures that have no alpha then lower bound. & upper bound alpha values may be ignored

4) as chroma keying is mainly used with a black key
so the driver can simply do as default "ignore black pixels if chroma activated"

if (fragment != black) /* if source visible ? */
copyfragmenttobuffer();

ABOUT WARP3D DRIVERS:
In fact sometime there are some 3D programs that use bad parameters
like GLMatrix that do Src=W3D_ONE_MINUS_SRC_ALPHA,Dst=W3D_SRC_ALPHA
So if the drivers is poor and dont implement those (stupid) parameters then it works
But paradoxally if the drivers is more complete and do the stupid code then it no more works


Alain Thellier

Last edited by thellier on 07-Jun-2012 at 09:40 AM.

@thellier

Quote:

thellier wrote: @Karlos 1) Keep in mind that WaRp3D specs WANTS lower bound. & upper bound as a 32 bit RGBA value (not ARGB,BGRA,etc...) 2) also as wipeout specify an incorrect upper bound 255 0 0 0 (should be in RGBA format 0 0 0 255 = solid black) then wipeout shadow will NOT works on correctly well written drivers

Yep, no problem with that. What I will do is to rework the Permeda2 driver to obey the specification and then add a ChromaTestColorOrder environment variable to allow exceptions. Via the per-application-settings feature, for WO2097, this variable can be set to ABGR.

Quote:

3) as chroma keying is mainly used with textures that have no alpha then lower bound. & upper bound alpha values may be ignored

It seems the R200 driver is more problematic than this. Having implemented the necessary changes to optionally convert the input colour order, the feature still doesn't work properly regardless. I don't have adequate documentation for the R200 with respect to chroma key operation at this time but what I do know is that it apparently doesn't do lower and upper bounds, rather it has a single colour that can be tested.

I discovered that the code required to enable chroma key testing was actually deliberately commented out. Re-enabling it caused massive texture corruption so a bit more experimentation is needed.

Quote:

4) as chroma keying is mainly used with a black key so the driver can simply do as default "ignore black pixels if chroma activated" if (fragment != black) /* if source visible ? */ copyfragmenttobuffer();

Are you suggesting a fragment shader based approach? One problem with that would be that black pixels in the fragment could be the result of colour modulation / blending as well as a black input texel.

_________________
IBrowse/AWeb user? amiga.org - classic browser edition

@Karlos
>Are you suggesting a fragment shader based approach?
Not especially i was just suggesting that if chroma keying is enabled (whith whatever good or false parameters) then just doing "exclude pixels that are solid black" will works for 99% of the progs that use chroma keying

>black pixels in the fragment could be the result of colour modulation / blending as well as a black input texel.
TRUE but it dont happen so much
1) if blending is used then certainly the tex got alpha so chroma-keying will not be used
2) if modulate is done before chroma-keying = not a problem
Also modulate with black then chroma-keying will only make disappear a texture

So certainly the 3dprog will better do a modulate with a transparent-color + blending
= that will allow true fade in/fade out

Alain

@thellier

Well, texture chromakeying is a feature the R200 is supposed to support, so I'll work on that angle a bit more before trying to emulate it some way.

_________________
IBrowse/AWeb user? amiga.org - classic browser edition

@Morphix

Quote:

Morphix wrote: Although I have made full install I am not able to ehar music just sound FX, the CD is in the drive but as far as I understood the program search for CD on scsi.device however I use atapi.device -unit 2-, but besides this a full install suppose to copy the CD tracks on the hard disk, is this correct? Anyway is there anyway to get music as well?

No, the tracks are played as audio by the CD drive - the software has little to do with them other than issuing play/stop commands and leaving the drive to do it. I can't remember now, but aren't there settings in the Wipeout startup screen for the CD drive which tell it where to play the music? Or maybe there are separate settings for cdplayer.library... Actually, maybe make sure you have cdplayer.library installed, then see if there are tooltypes or something which need to be set to tell the software where to find the audio CD...

_________________
http://www.robthenerd.com

Or use the modern implementation of the cdplayer library

AmigaOS4 PPC
http://os4depot.net/index.php?function=showfile&file=library/audio/cdplayer_lib.lha

AmigaOS3 68k - MorphOS PPC
http://aminet.net/package/util/libs/cdplayer_lib_ahi

_________________
BACK FOR THE FUTURE

http://www.betatesting.it/backforthefuture

Sam440ep Flex 800 Mhz 1 GB Ram + AmigaOS 4.1 Update 6
AmigaOne XE G3 800 Mhz - 640 MB Ram - Radeon 9200 SE + AmigaOS 4.1 Update 6

@Daedalus, @samo79

Thanks!

Will check ASAP!

Last edited by Morphix on 13-Jun-2012 at 08:31 AM.

_________________
Peg1, Peg2, Efika,
Amiga 500, Amiga 600, Amiga 1230,
Amiga 1200PPC, Amiga 4000PPC,
CDTV, CD32,
Sam 440EP, AmigaOne XE,
MacMini PPC, PowerMac G4

@thellier

Just to let you know, the chromakey issue has been fixed, at least for non-multitexture Warp3D apps in the latest R200 driver. Specifically, there are 3 environment variable options available that control the feature:

UseChromaTestABGR ("on" | "off")

This controls the interpretation of the colour order used by chromatesting. The API specifies that they are RGBA format, but games like WO2097 use ABGR. I tracked this down to a bug in the Permedia2 driver (which when the game was ported was the main target) in that it passed the colours straight to the chip, which like the API is expecting RGBA but the register is little endian. This is now fixed in the Permedia2 driver too.

UseChromaTestUpper ("on" | "off")

This controls whether the upper or lower bound is used. The API allows both, which again appears to be assuming the Permedia2 implementation (which supports both lower and upper) is expected, when in fact, the radeon implements single-colour chromatesting only. By default, the lower bound is used unless this option is set, which is fine for WO2097 anyway.

ForceChromaTest ("on" | "off")

This controls whether or not chroma testing should be forcibly enabled regardless of the W3D_CHROMATEST flag. As you described previously, it seems the game uses it without enabling it and it's probably again due to a Permedia driver bug that has gone unnoticed that allowed this to work.

So, for WO2097, you just need to enable UseChromaTestABGR and ForceChromaTest together, and the black texels become transparent again.

Last edited by Karlos on 23-Jun-2012 at 10:16 AM.

_________________
IBrowse/AWeb user? amiga.org - classic browser edition

@Karlos

Quote:

Just to let you know, the chromakey issue has been fixed, at least for non-multitexture Warp3D apps in the latest R200 driver

Great news Karlos, atleast maybe one of the old issue in WipeOut is now fixed
However did you or other devs find the reason why WipeOut 2097 crash at startup on any Sam440 machines since latest update 4 ?

Read here for example:

http://forum.hyperion-entertainment.biz/viewtopic.php?f=14&t=715&p=8816#p8816

Alfkil note the same issue on his Sam440p machine while i can reproduce the same problem on my Flex 800, definitely many ppls have the same bad result on their Sam440/Flex but the game still working more or less fine on the old AmigaOne from Eyetech

As i already told you before (with update 3 and before) the game started but freezed during the race on my Flex + Radeon 9250, now instead it just crash at startup so i can't even test it anymore :-/

I hope you may found some free time betatester for that, btw don't know if you already read but some time ago i did also a quick compatibility list on the Hyperion's forum that you (or others) may find usefull for eventual further test

http://forum.hyperion-entertainment.biz/viewtopic.php?f=14&t=404

Thanks !

_________________
BACK FOR THE FUTURE

http://www.betatesting.it/backforthefuture

Sam440ep Flex 800 Mhz 1 GB Ram + AmigaOS 4.1 Update 6
AmigaOne XE G3 800 Mhz - 640 MB Ram - Radeon 9200 SE + AmigaOS 4.1 Update 6

@samo79

Can you get a stack trace for the crash? The last time you mentioned it, it looked like the powerpc.library was the culprit rather than the R200 driver itself. The game works fine on both my A1200 and A1 in OS4.1 U3 and U4 (especially now the big black rectangles of doom have been eliminated).

_________________
IBrowse/AWeb user? amiga.org - classic browser edition

@Karlos

Sure no problem, the stack-trace log you need are generated (and availible) on one of the tab of the grim reaper window right ?

Hope that a serial cable is not needed because it will become a bit complicated !

_________________
BACK FOR THE FUTURE

http://www.betatesting.it/backforthefuture

Sam440ep Flex 800 Mhz 1 GB Ram + AmigaOS 4.1 Update 6
AmigaOne XE G3 800 Mhz - 640 MB Ram - Radeon 9200 SE + AmigaOS 4.1 Update 6