How to do 3D graphics development on the Amiga?

[EntilZha]

It should be *part* of the OS.

Initially, this was the only part of the OS we would be doing, until fate (and other factors) decided otherwise ;-)

[Rogue]

Yeah, that closed source, in-house developemnt only, non-standard low-level library, successor to Warp3D, wich suffered the same limitations.

The same applies to Direct3D. OpenGL is all nice but the ARB has a way of being a bit slow when it comes to making decisions.

Besides NOVA won't be so low-level anymore (including a full 3D pipeline, shader language etc).

The other problem with a general-purpose OpenGL implementation is that some things are not really working, or require a myriad of different code paths to achieve. A recent project we're doing on Linux requires access to the depth buffer. You can of course use a pixel transfer function, but these happen to be extremely slow on some cards, meaning you will need to have all the cards to test and invent other methods for others. With Warp3D we don't have this problem.

Also, the "as little as needed to run Quake" attitude, wich is perfectly ok from Hyperion point of view (MiniGL suit their needs), is not going to make that API broadly accepted for general purpose 3D use.

That goes for MiniGL. Warp3D is as limited or complete as e.g. Glide, and was never intended to be more than that. General OpenGL is/was too slow for the classics; MiniGL made Quake 2 playable on the 060.

The reason for this "articifical limitation" in MiniGL was simple - there was a goal that I wanted to achieve, and that was a fast, thin OpenGL-lookalike API on top of Warp3D that was sufficient for our ports. We never intended to do anything else. StormMesa was for anyone that did want more than that.

We're just too busy on fighting on the speed of AGP busses (as if it could make ANY pratical difference) to see where the competition is going... light years ahead.

Quite right. A Mesa port all in itself will not be the answer to that, though - you'd have to write those hardware drivers too (unless you want to port DRI too). However, you will still see a big performance gap between Windows and Linux.

We have a plan for the future, which I am not going to get into here, that we hope is going to amend this situation. Until that time any solution is going to be an interim one, but that is the best you can do at the moment. This interim solution will consist of Warp3D and Mesa at the moment, and may be NOVA, Mesa or something else (in one or the other combination) in the longer run.

[Rogue]

That is what I'm talking about. If Amiga wants to live in the past, by all means ignore advanced 3d hardware.

I would love an Amiga comeback, but for the general market, it will never happen without full, unapolagetic support for 3d.

Sorry to say so, but this is not about "wanting to live in the past". Currently it is being enforced.  You need to go with what you can get, and that generally excludes anything of NVidia's offering for example.

[EntilZha]

I for one would rather have all printer/usb/etc stuff done before 3D things.

Yes, but luckiy, those aren't done by me  :-D

[Rogue]

i had expected someonmne from hyperion to join in this discussion but they havent....sort of weird

You know, there's this big project that we're working on that is taking quite some time ;-)

[EntilZha]

Yeah, that closed source, in-house developemnt only, non-standard low-level library,

You mean glide ? Or DirectX ? (SCNR)

Mesa is dead on Amiga, while it's alive and kicking on other systems.

LOL! Mesa is a tremendous piece of software, but it's state management sucks dead hamsters through a garden hose. Compare the perfomrmance of Linux and Windows on the same platform, with any official driver (nVidia or ATI).

o see where the competition is going... light years ahead.

Nobody is denying that... but then, if you don't start, you never get anywhere... your stance seems to be to stick your head into the sand and surrender to "the evil empire" ?

"super puper 3dapi"?!? have a look at this:

or www.opengl.org ?  :-D

[Crumb]

@hairy:
First of all, I don't care if it's closed because it's updated and bug-fixed faster than the other open source options. There are no Amiga programmers that can waste their time porting slow unix sources to Amiga. I prefer native implementations even if they are incompatible. The GTK Windows implementation is damn slow for example (just check a simple program like xchat... the version that doesn't use gtk is quite faster) even on a 600Mhz machine. It's so easy to complain about other people work... if you think that opensource is the best option do the ports yourself, don't force people to do what you want instead of doing something useful and doing it yourself. If Hyperion decides to make something they are free to do that because it's their product and they are the company with more experience in 3D APIs on Amiga (And they know most of APIs because they work porting programs and games).

nVidia and ATI have propietary GL extensions, go to attack them.

Unix != AmigaOS
ports end up being slooow unless you optimize them heavily and make a fork from the main source tree.

If you want something standard you can use MESA. If you don't like it you are free to make your own implementation.

MESA isn't dead on Amiga, it's AmigaOS 3.x what is dead. MESA for OS4.0 will appear with NOVA. Even if it's slower than Warp3D it may be useful to port apps/games.

Many PC games use OpenGL subsets to give faster speeds, for example Quake3 or Half-Life (I don't care if they are old, modern games use their engines)

[Karlos]

Is it me or did it suddenly get pretty busy in here?

[Nightcrawler]

Karlos wrote:
Is it me or did it suddenly get pretty busy in here?

So it did :-D

Nice to see that hyperion are still alive. I was worried for a while that the workload had killed/institutionalized them :lol: .

[Karlos]

The really funny thing is that it all started just after I said they were probably busy to jump in, then went quiet again just as I remarked how busy it was after they did :lol:

[TheJackal]

by Karlos
Is it me or did it suddenly get pretty busy in here?

Yeah, so squish up to make rum for us all. [edit that should be room, but the typo rum is funnier :-D /edit]

by Nightcrawler
Nice to see that hyperion are still alive. I was worried for a while that the workload had killed/institutionalized them  .

I though they where institutionalized? Nice padded cells, Amigas,.. Wonder if there are any nice female nurses? ( I keep asking for them here, but still no luck! )

As to the topic in hand. I have worked with several API's on many platforms, and currently work with people who do as well.

The requirement for an API is not for it to mimick another API (although that can be handy), it just has to be clean, and easy to use. Any decent programmer would be able to write a translation layer to interface the new API with the games general engine interface.

@EntilZha and @Rogue and @hyperion guys in general.

I think you are doing a good job so far and seem technically compitent to provide such services when you get time. (or you get cloned, one of the two!)

However in your "Multimedia" API I would suggest trying to go for something eligant and "future proof", (if there is such a thing) like DX9, since I feel OpenGl has lost its way recently, and seems to be struggling to restandardise itself with all these new extentions.

by Roge
...The other problem with a general-purpose OpenGL implementation is that some things are not really working, or require a myriad of different code paths ..

As you mentioned all the different code paths required on OGL becomes a nightmare, in DX its easier, the effects stuff in DX are quite interesting, even though I've not personally used them.

[Rogue]

As you mentioned all the different code paths required on OGL becomes a nightmare, in DX its easier, the effects stuff in DX are quite interesting, even though I've not personally used them.

Yeah, the different code paths are my biggest gripe with OpenGL. You practically must have all the hardware (or testers available) in order to make use of them. Just compare the different fragment shaders (most OpenGL drivers support ARB_vertex_program now).

Plus, some of these extensions are burdened with copyrights. I think that e.g. NV_vertex_program is copyrighted by nvidia and may only be implemented on NVidia hardware (although Mesa has a special, software-only permission).

I never used the Effects stuff in DX either, but the SDK samples look quite promising. I wonder if anyone is using the D3DX model code - doesn't look that bad either.

[TheJackal]

by Rogue
I never used the Effects stuff in DX either, but the SDK samples look quite promising. I wonder if anyone is using the D3DX model code - doesn't look that bad either.

The closest I've come to using the D3DX lib stuff is for matrix gubbins. As for the model handeling stuff it looks interesting. The x file format is also interesting, as there are many tools out there to convert from to x files.

However if you are developing multi-platform stuff you are most likely going to "roll your own" model format, which can be quite flexable with DX and cards supporting multiple streams.

[serge]

Maybe, my question could be a little stupide, so sorry, but I want know if OS4 will be able to use Warp3D on a lot of GFX cards.

why nobody speaks about SNAP ?

Does snap be able to comunicate with WARP3D ?
Will snap gives to AOS4 the possibility to use 3D functionalities of all the cards supported ? something like 200 cards !!!

[Karlos]

Ages ago, when I was messing about with this old game engine I was designing, my model class didn't actually have any IO support at all (I was waiting to do it later), so I actually had to encode the vertices by hand in some source. Thats why they look (and are) sooo basic :lol:

[MagicSN]

SNAP contains only 2D Drivers. 3D Drivers are needed independently of it. The first "new" 3D Driver
will be for Radeon.

Steffen