pouët.net

uhm, the argument was: no version changes, because it was well designed. D3D was no competition these times, OpenGL was used for high end workstations and such stuff, DirectX just sucked.

Now its different, OpenGL for the game market, D3D for the game market. and now theres even that strange vertex and pixel shader stuff. i'm sure it will die, in ten years nobody will talk about that anymore, its a hack into the scanline renderer + gouroud shading principle, its a workaround.

Actually, Godog is one of my all-time favourite demos...
Anyway, let's not go from one extreme to the other.
Not all demos have to work on all PCs.

But demos running on only a particular brand of hardware, well no... We want something in between... Basically "if the hardware is technically capable of doing it, it should work on it". Which means that a demo that runs on GF3, should (in most cases) run on R8500 and Parhelia.
Also, if only a part of your demo requires extra features, you could always make a workaround, so that the entire demo works without the features aswell... Like for example, if you use some vertexshaders, make a fallback for software emulation... And if you use pixelshaders, well you could at the least render the object without any shading at all... or with only textures or such...
And well, if you can use the fixed pipeline for a task, don't make shaders for it :)
Basically really simple yet sensible stuff, imho.

what's the problem with coding for specific hardware?!?! i really dont get it... people are jealous that they can't watch the brilliant kolor demo, and other people can, or what? i can't either, but i'd say, if a non-standart hardware gives you certain possibilities, USE IT.

that's why there are demos for the c64 supercpu, or demos for amiga ppc, or only for a certain version of a zx spectrum, or whatever crazy shit. so what? i'm happy with seeing this stuff on the party bigscreen and having it as mpeg, and i don't care about the possibility to watch it a trillion gazillion times on my home hardware. it's not fucking communism, why should a coder care for some "chance equality" for his product. if some people can't see it, well, bad luck for them. they should wait for a video version, but stop bitching about "i can't see it on this i can't see it on that".

dipswitch: stop doing drugs, or atleast read the thread before start bullshitting, you really have no point in your post, fucking lamer.

Scali, please send me a couple of ATI cards so I can test them and provide workarounds to driver bugs and fix my bugs. If not, please have a cup of STFU, we ship buggy demos because we don't have the hw or time to test them. I test my stuff on all computers I can find, it's not my fault that 95% of sceners have NV or that NV breaks legal stuff with each hardware release.

s/hardware relase/driver release

s/hardware release/driver release

bitboys to the people!

Mac: calm down, I was not talking about bugs. That happens. I was talking about deliberately using vendor-specific OpenGL-extensions.

hehe, we can go on forever :)

when is a extension 'vendor specific' and when is it just a case of driver/hw capabilities..

ps1.4 only ATI until gffx. does that mean noone should use it before?

GL_NV_occlusion_test, only nvidia until CATALYST3 or so.. ( and even proposed as a core in opengl1.5), and I think 3dlabs has it too.

GL_EXT_vertex_program.. only ATI from the beginning..and then matrox got it. then it become osolete when an ARB extension took its place.. can we use it or not? (matrox havent still managed to get the ARB version in their drivers..)

Already explained it above, read.



For all those who are still clueless about DX: there is only ONE shader-'extension'. This 'extension' supports multiple versions. But the versions are aimed at hardware functionality, not the bare hardware itself. If hardware has the functionality, it works.
With OpenGL this is not the case. That's why it's taking so long to get ARB extensions for pixel/vertexshaders and vertex/indexbuffers. And the extensions that exist at the moment, are too hardware-specific, so they can not be supported by other brands, because the hardware simply is too different.
Is it clear now? or are you OpenGL-people retarded? You must be, you sure sound like it. Why does a Direct3D programmer such as myself have to explain what the problems with OpenGL are? Get a clue. Also, get a clue about Direct3D, and realize that you should be using that instead.

I do know DX that well. i just meant, since ps1.4 only was supported by one brand it was at that time a very vendor specific feature ( even if there later could come more vendors that handle it) and the same really goes for ALL extensions in Opengl.. if you build a HW that can handle ATI_vertex_buffer, then you are allowed to put that in your driver, if you want to.. And i just pointed out that it happens, and thus a extension with a vendorname in it doesnt mean that it is for that vendor only.

read the thread again ( puh ) an i still cant find where you draw the line that says that an extension is vendor specific or not..

Uhh...this thread is so full of crap. Who gives a fuck about portability? Who gives a fuck on which card a thing runs or runs not? Since when is demo-coding about producing stuff, that runs on as many hardware as possible? Pff..dont get it.

Vendor-specific == no indication that future hardware of other vendors will ever have support for it (either because of physical differences in hardware, or because of strategic or practical reasons).
You must be retarded if you can't figure that out.

Also, you must be retarded if you don't know that shaders are backwards-compatible BY DEFINITION.
So, even when ATi only supported ps1.4, you could be 100% sure that future hardware would support it aswell. Because if you want to add new shader instructions, you get a new, higher version number, which means you have to support ALL lower versions aswell... So it was already 100% clear that any ps2.0 device from any brand would support ps1.4.
Another difference with OpenGL is that Direct3D shader versions are defined by a board of various manufacturers and Microsoft. This basically ensures compatibility between the different brands. None of the manufacturers will agree with a standard that they know they cannot implement properly.
With OpenGL extensions, the vendor can just make a lowlevel interface to their hardware, and not pay any attention to other hardware at all. So there is no guarantee that it will ever be able to work on other hardware, and often it doesn't... There are exceptions to the rule ofcourse. But these exceptions are mostly the 'smaller' brands needing to implement NV-extensions, not the other way around.

In case it's still not clear, you're obviously too stupid to even be coding, so stop worrying about the problem altogether and get back to your job of cleaning toilets.

who could guess that both NV_occlusion_test and NV_register_combiners, and NV_Vertex_program should become multiple vendor extensions?

i know that all future HW must be backwards compatible.. but if we look at a timeline, then there was a long time where GL_NV_occlusion_test where supported by more vendors than ps1.4 ( and now they are just equal).. just as an example :)

Yes, occlusion test is of about the same level of complexity as ps1.4, I really see your point there.
Anyway, the key is that ps1.4 was to be supported by future hardware BY DEFINITION.
With occlusion test, you basically just got lucky.
Plenty of other extensions were not that lucky.

Okay, to give a retarded example, for retarded people:
If I were to code on ATi's OpenGL extension equivalent of ps1.4, would it work on GeForce FX?

By the way you may be interested to know that one thing which was quite painful while judging for the Scene.org awards was being able to watch all the entries. Amiga demos at least had movie versions, as well as raw confessions and a deepness in the sky, but even that was not too ideal as it takes a lot of time (and even money) to download for some people.

So the less portable your production is, the less chance it'll get judged fairly.

.. future - better - hardware.. i assume some smaller companies will make chips that cant handle 1.4.. or 2.0 for a few month ( maybe years for laptops.) dont foget that only nVidia and ATI has 2.0 compatible cards, and it not that certain that a new card from another vendor will support it right now. If we relly are aiming for 2.0 compatible HW only, then opengl has all the things you need ( arb approved) .. so either dx coders check every caps, and opengl coders make all things opengl1.1 (fallback) compatible ( that should the most :), or both camps can just code for fun instead.. and if pople can see the demo at home its fine.. if not.. well thats life.

oh by the way, I just downloaded the final version of Raw Confessions, and it indeed works lovely on my R8500, unlike the party version... Very good.

MazyNoc: you don't get it.
You're saying what I'm saying, but you think you're disagreeing with me.
As for smaller companies making chips that can't handle 1.4 or 2.0... That's their problem (by the way, ATi already announced Mobility Radeon 9600, and nVidia announed GeForce FX 5200 and 5600 mobile, so laptops will have ps2.0 soon. They already had ps1.4 because ATi has Mobility Radeon 9000 on the market).
My point was not to support old garbage and cheap crap. My point was to support hardware that has the features. It's plain retarded that you can't watch a lowly GeForce3 demo on your new R9800Pro. About as retarded as those glide demos and games that you cannot run.
And I made a sidenote about how missing some features should not necessarily mean that the entire demo cannot be watched (there are already some demos around that run fine, but skip some parts on insufficient hardware, that's nicer than not being able to watch at all).

well dx becomes compatible becourse it aims for the common denominator of the cards.. which is nice in one way, but if you really want to press the limits of a card then its rellay more fun to explore the features.. you can do more with a gf3 than dx lets you.. ok, its on the expence of compatibility, but it can be more fun to develop. i bet the caps in dx doesnt show any difference between gf3 and gf4. But i state that its more difference than just memory and speed, and its a pitty that those gf4 owners never got a chance to see that. but you can emulate those gf3gf4 features on a radeon9800.. so why doesnt the driver developers just do that?

Ofcourse it would be nice if we all could watch all demos, but i dont see that its necessar..

Hum.. and where are all your compatible demos? since you been using DX then I should love to see them all.. i should be able to watch all except the newer once.. :)

Wrong. GF3 supports only ps1.1 and GF4 supports ps1.3, if I'm not mistaken. There might be other caps aswell, not sure of that. But there IS a difference.



Why should they? Hardly anyone uses them anyway, not worth the trouble.