pouët.net

Now, this is the lamest thing to happen ever in my 10 years as a scener. Honestly. The GeForce is NOT the GUS, the GUS was a unique card, with "scener" style, and Gravis actively supported the scene.

Fuck NV_xxxxxxx.

fuck vendor_xxxxxxx.

ogl demos using vendor_xxxxx without arb fallbacks is like, bad demos. no matter what they present. stupid assholes :)

And we all know the rules for BP was done for letting the german demos take the top places.

don't meantion the war.

I have to agree about the Nvidia-only nonesense. Silly me always thought the idea of API's such as OpenGL or DirectX was to eliminate dependancy upon a specific manufacturer of graphic chips.

And let me mention that I have a GF3, so this is no "angry for not being able to watch them" post. I would think equally of ATI-specific crap, but it doesn't seem so prevalent.

The idea that "OpenGL is merely a GetProcAddress() wrapper" is enforced by this vendor-specific nonsense. I have never wanted so much for Microsoft to have succeeded removing OpenGL from the planet.

Some more points about the GUS:
Many demos still had support for other cards, or would run without sound at least... Only very few demos would actually just refuse (I believe The Real Thing, by Capacala is one), or worse: crash.
And yes, the GUS was unique... it was way BETTER than the other soundcards.

A GeForce is not even better than a Radeon, and still I cannot run GeForce-demos if I have a Radeon, even though my Radeon has all the hardware-features, and more.

OpenGL and DirectX were once about eliminating dependency yes... then OpenGL allowed extensions and nVidia thought this would be a good opportunity to try and create a monopoly (I guess that's some of the 'technology' that they bought from 3dfx? anyone remember glide?).
It doesn't really help that OpenGL evolves extremely slowly, so you pretty much HAVE to use vendor-specific extensions in order to keep up with Direct3D (actually, you should just code Direct3D anyway, saves a lot of problems).

So anyway, I have a issues:

- Like the early 3d accelerated demos, made with glide, your nVidia-specific demos will soon be lost forever, because nobody will have the hardware to run it anymore.
- How about having compo rules against vendor-specific code?
- How about not disclosing the actual hardware in the compomachine? Instead, just state eg. 'Radeon8500/GeForce3 class accelerator'.
- How about forcing incompatible demos into the wildcompo? After all, that's what it is. How can you compete with generic code against hardware-specific code? That's unfair!

I thought Windows put an end to the compatibility problems of the DOS-age... But I guess it's 'oldskool' to have stuff that doesn't work.

Oh, and if you really think that nVidia will be popular forever, you're quite naive, I guess...
ATi has a good technological lead at the moment, and will cut deeply into nVidia's marketshare in the next few months.
And who knows what will be the big 3d brand a year from now? Your guess is as good as mine (Does anyone remember that VooDoo-monopoly? Boy was that gone fast :)

I completely agree that vendor-specific demos (except perhaps tech demos ;-) ) are lame, but why the heck do you blame OpenGL for it? 95% of the problems I see are due to bad coding, not use of some nVidia extension...

OpenGL extensions are about deliberately choosing not to support a large part of the scene (I am quite sure that the people with a card capable of watching a GeForce3-demo are a very small group).

The other stuff is bugs, due to lack of skills or clues or time or whatever, and can be (and should be, and often is) fixed in a final version. I don't mind that as much.

It's the deliberate sabotage that annoys me the most. The unwillingness of people to include all sceners.

By the way, most problems I have on the Radeon 8500 are indeed caused by OpenGL and its extensions. I don't blame OpenGL itself... There are plenty of OpenGL demos that work fine (for example VIP2, Lapsus, Variform, any Haujobb stuff, Planet Loop...). If you write a demo that works on most hardware, and you choose to use OpenGL, that's fine by me. If you use OpenGL for some stupid reason like "But I need C APIs, C++ scares me", or "Micro$oft is ev0l", or whatever... then no, I do not approve of the use of OpenGL.
Fact is that Direct3D-demos are just more compatible in practice (not to say that Direct3D is perfect, but it would at least make it easier for demos to run on other hardware with the same featureset).

Tech demos are fine, as long as you treat em as such. They are basically wild demos (and often they are released in divx-form or similar aswell :).

scali: planet loop not correctly works on my radeon9000:( icon with running trolley not animated. and white, blue, yellow icons in second part too.....

I have NEVER ran into an NVIDIA only demo?!?!

I serously think this subject is FLAWED and Jare an idiot, as the real "special" 3D graphics card is the VOODOO. Now, tell me how many VOODOO only demos there are?

Jare, STFU and learn 3D.

no biscuit and a glass of milk for 33

stefan, you have either a problem with germans or with something else i havent found the truth yet about it. Watch the first two Productions, they were simply the best productions there. Face the Fact!

stefan wrote:

"And we all know the rules for BP was done for letting the german demos take the top places."

"Watch the first two Productions, they were simply the best productions there. Face the Fact!"

Ehm, ok, first one, envmapped flatpolys, jaa, great animations, radialblur.. ok..

ok, second one, oops, non nvidia card detected! (matrox parhelia) ok, no go.


i seriously doubt that the envmapped flatpolys wouldve stood a chance against a demo using radeon technology, jez i do.

ok, fact faced, they use flatnormals, they are heros, jaa.

scali : people can use opengl for whatever reason they like.. ( even it you think its a lame reason like 'i want c style')

Jare : the both api:s borrows lots of ideas from each other, so killing one of them just removes the pressure to make a better version of the one thats still there ( look at opengl, no versionchange for several years, until dx6 came out, and become usefull, after that it has several new versions)

Using extensions is good, but you should provide fallbacks for some cards down the line, thats true for both dx and gl (even if dx doesnt have extionsions, only subversions).. if you used ps1.4 before gfFX you was certain it only worked on ATI 9500 and up ( 2 cards or so), and iirc gf3-4 still have some special texturing modes in dx, so its not a opengl(extensions) vs dx(subversions) problem.. its a fallback problem.

I still think fallback code should be provided, but to demand it from coders that works for free, and for they own pleasure is just wrong.

Maybe the guys can finish an vendor-unspecific version later? ever heard of 'final version'?

i have to say just a fea words:

DirectX


ok no you can spam me like shit :D

i have to say just a few words:

DirectX


ok no you can spam me like shit :D

MazyNoc: the major difference with OpenGL and Direct3D is that if you use an OpenGL extension for ATi shaders, you can be sure that it will NEVER work on anything but ATi cards.
However, if you use ps1.4, sure at first only R8500 had it... But as soon as other cards with ps1.4 came round, they were immediately supported aswell. You can't really blame ATi for the fact that they were a few years earlier with supporting ps1.4 than nVidia.

As I said, fallback should be provided if possible, for both OpenGL and Direct3D... Direct3D just makes it easier.

Also, you didn't get it... the real 'lame' reason is "I don't want my stuff to work on hardware other than brand X".

Oh, and 33, you can't be serious about never having seen an nVidia-only demo, can you?
How about Daydreamer by Fairlight?
Or Raw Confessions by Cocoon?
Or (obviously what started this) Relais by Kolor?

bloated standards are always a good thing. sure.

Scali.. i use to agree with you on several things.. but a vendorname before an extension is in no way a 'vendor only' extension.. its just who invented it.

HP_occlusiontest,
GL_NV_blend_square
GL_NV_occlusion_query
GL_NV_texgen_reflection
GL_S3_st3c
GL_SGIS_generate_mipmap
GL_SGIS_multitexture
GL_SGIS_texture_border_clamp
GL_SGIS_texture_lod
GL_SGI_color_matrix
GL_SGI_texture_edge_clamp
GL_SUN_multi_draw_arrays

part of an extensionlist.. from an ATI card..
and 3dlabs has another set of mixed extensions from different vendors.

Its up to every vendor to implement all stuff they can handle, and are willing to give to their customers.. you really cant blame nVidia to be innovative and thinks of new things first :)

Most stuff that a couple of vendors can handle becomes ARB extensions.. and they arent that lazy to approve them anymore so its not really a problem to use just ARB, or even check the supported openglversion. but its just as easy to still make it nvidia or ati only..
make an opengl program that depends on version, or a dx program that takes certain caps for granted is equal ugly, but still, we dont get paid for our prods.. i put only as much work in it as i think is funny.

DirectX makes it easy to support all 3d-cards, OpenGL makes it hard. I hope OpenGL 2.0 will make some difference, but in the meantime OpenGL just can't compete if you want to support all vendors.

coding ARB fallbacks for OpenGL becomes almost impossible once you use vertex/pixelshaders or rely on fast dynamic vertexbuffers.

Those GL-only people should have a look at DX9. Back in the DX5 days there was plenty of reason to hate DX, but after several complete redesigns microsoft finally managed to come up with something really useful.

MazyNoc: I never said that the vendorname means that the extension is vendor-specific.
I only said that many extensions ARE vendor-specific.
Especially shaders and vertex/indexbuffers, as chaos already mentioned... They more or less have to be vendor-specific, because they work at a low level, and are tied closely to the hardware.
ATi cards simply don't work the same as nVidia cards, so it is hard for either of them to be compatible with the other (which is painfully obvious when you try to run DX9-stuff on a GeForce FX by the way).

Also, when was the last time nVidia was innovative? ATi's R9800Pro blows the GeForce FX away, featurewise.

And as I've already said before: It's not about OpenGL only. I agree that a Direct3D program that takes (too many) caps for granted is equally ugly.

Still the facts hold:
- Many OpenGL extensions only exist on hardware of one vendor.
- It's easier to make compatible shaders/vertex/indexbuffers and workarounds on Direct3D than it is with OpenGL extensions.

In practice it's painfully obvious that Direct3D demos are more compatible than OpenGL ones.
It seems that it cuts both ways... OpenGL users must put in more effort to make their stuff compatible anyway, and it seems that some of them put less effort into it altogether (Kolor clearly didn't even TRY to support any other vendors).

Scali : Raw Confessions is based on a Direct-X engine and works fine on Radeon cards.

chaos, Scali .. arb_vertex_program, arb_fragment_program and arb_vertex_buffer_object should be what your looking for. nothing vendor specific, and supported on the cards that can handle it ( and some more )

and nvidias innovation.. i meant extensionvise - ati 22, and nvidia 40..

The day i make demos for a living, and not just for fun.. then i start thinking about making paths for more gfxcards :)

I dont want to make this into a standard ogl/dx war, but i still dont think that an opengl developer needs to put more efford into making it compatible.. if you dont use pixelshaders ( fragment programs) you have nearly the same functionallity in opengl1.4 as you have in dx8.1 ( havent checked dx9 yet), and with nearly i mean that some stuff dx does better, and some is in favour of opengl..

btw, i had more problem with dx demos than opengl once.. but then again i have an nvidia gf3 in my computer.

"Many OpenGL extensions only exist on hardware of one vendor."

wrong. just check the extensions provided for a Nvidia card here:

http://www.delphi3d.net/hardware/index.php

for example, on the geForce3, the huge majority of extensions is EXT, which means not vendor specific. The EXT is provided for compatibility with older applications, as most of the EXT stuff has been standardized with each of the opengl 1.1, 1.2, 1.3 and 1.4 versions.

One of the shits about OpenGL is that there is no standardized mechanism for texture shaders, it is vendor specific. latelly, the ARB_fragment_program appeared, but it is equivalent to DX9 ps 2.0, which means it is not useable yet, because i guess very few demo watchers have a brand new geForceFX or ATI Radeon 9500+.
But if you are looking for an equivalent to DX8 pixel shaders under opengl, there is only vendor specific stuff.

About checking DX9, i know it is better for compatibility. But it isn't portable to other platforms than m$ ones "Windows" or "XBox". All in all, making an OpenGL demo compatible is really harder than making a Direct3D demo compatible. after vendor specific extensions, the coder has to face driver bugs.. which are really annoying for matrox hardware for example.

Another problem about OpenGL, standardized way to get "fast dynamic vertexbuffers" has existed since 1 month now, and the extension string is appearing only in the latest beta drivers from nVidia. pitty.

OpenGL 2.0 could be a solution to solve all these problems, but we don't know yet *which* hardware will support it. Radeon9800 will. I wish more hardware will too. We'll see this summer, as it is planned to be released at siggraph 2003, this summer. drivers supporting it should be released soon after I hope.

Scali : Raw Confessions by Cocoon runs brilliantly on my 9700 :)