Hello & Happy New Year 2014

Wazp3D for Morphos is NOW on Aminet
It use TinGL as hardware renderer so people without Goa3D drivers will benefit from it
Certainly you will be disapointed as there are not much progs that works with it
And there are lesser progs that run 100% perfect

One of the major issue is the perspective-texturing that dont works because TinyGL dont support glTexCoordPointer(4,...);

Alain Thellier - Wazp3D
http://thellier.free.fr/Wazp3D.htm

Quote:

Yeahh, great. Happy New Year thellier.

Hi Thellier and thanks for your work!
A question: I run the Wazp3D config program, doing some settngs and close the window. Nothing is saved in Envarc and nothing could be loaded from there. So when I try WipeOut, for example, a window appears with a "Loading Wazp3D.cfg" message but nothing more happens. Is it a normal beta behaviour? Thanks!

Thanks Alain!

@Intuition

wipeout dont works = i dont know why as it works with wazp3d/os4

wazp3d-prefs change the parameters INSIDE the wazp3d library
then when the prog end (ie w3d_destroycontext) then a wazp3d.cfg file is saved
that will be used next run

this way of working ensure to never save a crashing config

Alain

Thanks for answer Alain!
The real problem is not WipeOut is that Wazp3d.prefs doesn't save any configuration file and so it won't load anything at start. And so will do the library. The only way I managed to save a config file was to launch prefs, run the cow demo and when I stopped demo it saves a configuration file (!!) which I put in Envarc:

thellier,
Quote:
As I told you on meta-morphos forum, warpup libs are no usual libs. You can not simply rename an amigaos/morphos lib to make a warpup one... The whole ABI is different, amongst other things. I guess all this must be explained somewhere in the old warpup docs from the 90'... The poweropen and systemv ABIs were even documented in the old morphos sdk for more than 10 years (and google knows about them anyway, as they are not some amiga creation)...

As to why it works on hyperos... I imagine you also didn't write a proper warpup lib there... so I expect its powerpc.library has some kind of hardcoded warp3dppc.llibrary -> warp3d.library wrapper doing all the hard work for you. You tell me :)


[ Edited by Henes 05.01.2014 - 00:37 ]

So warpup programs can't use ABox API MorphOS libraries? Is the stock warp3dppc.library a warpup binary? I'm not having a go, but I couldn't tell, because the official libraries are encrypted.

@BSzili

Morphos 1.4.5 binaries aren't encrypted.

Quote:
They can and they all (directly or indirectly) do.

Quote:
It is a morphos native binary... respecting warpup abi and api.
Same for powerpc.library and itix's rtgmaster.library (and I just noticed this one is opensource so it could really help wazp3d if alain can't search/read/understand warpup docs himself).

@zukow
Thanks for the tip. I grabbed the 1.4.5 ISO, and the warp3dppc.library is a "normal" MorphOS library there. I must have misunderstood something.

@Henes
I get it now, I'll dig into wup.c/wup.h.
http://aminet.net/package/driver/video/rtgmaster_mos

[ Edited by BSzili 05.01.2014 - 14:10 ]

WarpUp libraries are built like any native MorphOS library but must use function prologue and epilogue to switch r2 and ctr in PPC calls.

@itix
I created the glue functions using your macros:
Code:
The problem is that struct ETask no longer seem to have an EmulHandle field, so this doesn't compile with the latest SDK. Has the EmulHandle field in ETask became private?

Quote:

It indeed is private. I think new code was supposed to use NewGetTaskAttrs() and NewSetTaskAttrs() with TASKINFOTYPE_EMULHANDLE. However after some checking it seems that NewGetTaskAttrs TASKINFOTYPE_EMULHANDLE doesn't always return the raw tc_ETask->EmulHandle value and thus it likely cannot be used as a direct replacement here.

Anyway, this somewhat hackish solution should work:

Code:

Then use TASKEMULHANDLE instead of SysBase->ThisTask->tc_ETask->EmulHandle.

[ Edited by Piru 09.01.2014 - 15:36 ]

Thanks, for the time being I'll probably go with your workaround. Doing 3 New*TaskAttr() calls per function might add too much overhead. Then again, maybe it doesn't make much difference, we'll see when Wipeout 2097 is up and running with Wazp3D.

@BSzili

Just compiled your latest change : Wazp3D still not workking with Wipeout and others....

Alain Thellier

Quote:

I ve heard MOS 4.6 will have SAM460ex support AND Radeon4000HD driver.
Nice and I am really waiting just for it

Should I be AmigaOS happy with 2D driver or MorphOS happy with GOA, REGGAE and yes W3D ...

> I ve heard MOS 4.6 will have SAM460ex support AND Radeon4000HD driver.

I hope this will already come with 3.6 ;-)

> MorphOS [...] with GOA

Goa3D doesn't and won't work on Radeon R300 and beyond.

Quote:

Ah, nice whowoff I am ex-AmigaOS user Well, it will not come with AOS 4.1.6
either, so yes, all bets on MorphOS 3.6

But looking forward to experience MOS 4.6 as well.

P.S. Will it mean just 4000/4200HD model, or some wider varity based
on same chips?

Quote:

Doesn`t is enough, please no won`t work ... is there some serious
reasons since chips should be kind of backward compatibile?

[ Edited by vox 16.01.2014 - 11:35 ]

>>> I ve heard MOS 4.6 will have SAM460ex support AND Radeon4000HD driver.

>> I hope this will already come with 3.6 ;-)

> it will not come with AOS 4.1.6 either

AmigaOS 4.1.6 has been released more than a year ago. And OS4 has Sam460ex support and a 2D driver for Radeon R700 for 3 years.

> looking forward to experience MOS 4.6 as well.

Has there anything in particular been announced for this?

> Will it mean just 4000/4200HD model, or some wider varity based on same chips?

As you know, "R700 support" was the statement that was reportedly given on the Pianeta Amiga show last year. AFAIK, there is no HD4000 model, and HD42x0 models are R600-based. So I guess it should be HD43x0 models and above, but I have no inside knowledge whatsoever, only what has been stated in public for everybody to read upon.

>> Goa3D doesn't and won't work on Radeon R300 and beyond.

> please no won`t work ...

The MorphOS Team made it pretty clear that there will be no Rave3D for R300 and up, so no Goa3D (which relies on Rave3D) either. But as soon as Wazp3D will run hardware-accelerated via TinyGL, you won't need Goa3D anyway.

> is there some serious reasons since chips should be kind of backward compatibile?

It's been explained there by a MorphOS Team member:

https://morph.zone/modules/newbb_plus/viewtopic.php?topic_id=9256&forum=49&start=4

No one can say when the SAM460 port will be ready, and an HD4XXX driver has not been mentioned.
It is not impossible, but the original work centered around the use of an X1300 video card.

If things remain evolutionary, we should see an R400 driver (for support of the X800XT video card in G5 Power macs), and eventually an R500 driver (for X1300 video cards in the SAM460 and for later support of the X1900GT).

Who is to say what 3.6 will include?
Until its released, unless its mentioned prior to that release, its all speculation.

Quote:
At every new generation, Radeon chips are not "backward compatible" with their ancestors.

> No one can say when the SAM460 port will be ready

There're estimates by the developers at least:

https://morph.zone/modules/newbb_plus/viewtopic.php?forum=11&topic_id=8931&start=106

> an HD4XXX driver has not been mentioned.

https://morph.zone/modules/newbb_plus/viewtopic.php?forum=38&topic_id=9764&start=30

Quote:

Software based rendering is NOT a solution.

Every new generation of Radeons is NOT backward compatibile? Phew, AMD doesn`t know how to do the job.

Please let me know when things go official about this project NAOMO and things speed up. I am really waiting just for it.

I can buy X1550 LP card if really necessary.

If you are referring to Wazp3D, it has an OpenGL backend too.