pouët.net

that was a typo, i meant 13h.

I think you don't understand the difference:

· some use D3DXCreateBox (or any kind of mesh). It all fail then they argue you must update your d3dx9. (the case of Texel)

· others simply code their own box, and if you have installed your drivers, that it's obvious you have done, everything works. Then the exe is bigger ..

Why don't we ask watcher to install glut or SDL if your fucking OpenGL intro don't work ? The answer: not because it comes in Windows out of the box. This is stupid.

I've seen very elegant demos, with an exe very thin, joining the D3DX with the demo. May be they could be 64K intros, but simply they have decided to be more elegant and honest.

And regarding honesty. If d3dx comes with windows, why C# / .net intros are not accepted ? May be because .net library is "very big" ?

Finally thoughts: things are accepted regarding to the most people opinion, not for coherence for past opinions.

Anyway, Rudebox is a good DX intro :P

All this DLL thing with intros, whether to use D3DX or SDL/GLUT is IMHO a gray zone, and nobody is really satisfied with it. Fact is, the demoscene adopted a set of rules as standard, and everybody kinda live with it. And for whatever reasons, those rules allow D3DX and disallow SDL/GLUT/.NET. I didn't make those rules, and it's not in my authority to change them. Feel free to write a manifesto and start a revolution if you're so annoyed of people using D3DX. But then weigh carefully between beginning to see "true 4k intros" and stop seeing "better looking 4k intros", where applyable.

Aeko, afaik, the only way to compile an hlsl shader in a 4k intro with directx is to use functions inside the d3dx_*.dll. d3dx is not just an utility dll that a d3dx coder could get rid off easily (unless you are precompiling your code with fxc.exe...)... d3dx is part of directx runtime, point.

For coherence SDL/GLUT/D3DX debate, as xTr1m said...

For the .NET stuff, well, i do know well .NET&its internals, and i don't think it's not accepted because it would give you a bunch of functions that would save you a lots of things in a 4k... If you know how to instantiate a .NET VM and call some clr functions from a c program, you should realized yourself that the cost of all thoses calls are not worth the small gain... not to mention that if you want to embed an assembly inside your 4k.exe, you have almost 1kbyte yo 2kbyte taken, even using crinkler... (and well, apart the VM, the .NET framework is mostly a bridge over standard windows functions, not worth to use a bridge, when you can call directly dll functions...)...

and some could also complain 256b intros use DOS routines instead of direct hardware interaction...

as modern os that become more and more complex / features bloated, this is difficult to give precise opinion.

where is the limit between os native function calls, 3d api (opengl/directx) , custom librairies (like glut), or files that are "supposed" to be installed (gm.dls, windows media files)

.net versioning is a pain in the assemblies.

Native c# and a nice optimizing compiler would be awesome, though :-)
C++ is so... outdated!

Gargaj: Link me beautiful

Also, Jcl, yeah, a language that's in active development driven by most major industry players and is used eg. for roundabout 100% of comsole and non-casual PC titles is outdated. That sounds logical. ;)

omphaloskepsis?

Ou yeah !

Link me beautiful

I mean (maybe I misunderstood COM)...
Why should calling the exact same function in d3dx9_33.dll be any different from calling it in d3dx9_31.dll, or calling the same function in X3DAudio1_6.dll be any different than calling it from X3DAudio1_4.dll

If a function has the same name and the same arg types/return type, then why should it matter?

Especially for noobs to the scene (like myself) who are like "why should I update my directx9!? I HAVE DIRECTX11!!!1111"

uhm ... maybe because the actual implementation of that function changed??? (bugfix e.g.)

Aren't "non-member functions" and "COM" disjunct sets?

_kb: I think Jcl refers to the overall syntax and backward compatibility of C++. If you consider C# a modern programming language (and I admit, it's so much fun and refreshing to code in C#), you could call C++ dated... even if new stuff is being added and it's been worked on, the old stuff still remains.
I've now been working as a coder on the same company since over 3 years... In the first years we did C++/DirectX9, to the deepest level (everything templates gave us, smart pointers, and so on, unmanaged, no third party library involved). Now our new project is .Net4/Silverlight4 based, so I was forced to learn C#. And now I'm just so thrilled, I wouldn't want to use C++ anymore if I could avoid it.

...because it feels dated.

@psonice: WU is seperate from most product groups. Getting ANYTHING other than a security patch into WU is a right royal pain in the ass, as it should be.

Somewhat on/off topic:

I recently installed win7, and tried some old stuff.
FR-08 runs, but it seems like the framerate is very uneven, not rock solid FPS as you would expect a fast system to have.
Could this be win7 related, or does it have problems with fast computers (multicore?) altogether? Haven't run it for a while, so the problem might have been there before my win7 install...

Really off topic:
C# has been the only program language I have been using as of late the few times I actually program. There is a very severe problem with it: There is no good way to separate definitions and relationships from the implementations.

What little good C++ code I have seen, virtually all the magical "object-oriented" stuff is kept in the header files. What is in the CPP files is basically straight C.

Random citations:
http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918
http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918

kb: my bad, there verb should have been "feels" as in outdated :-) Not saying it -is-, of course

for me @lx has absolute leading.

OpenGL intros: you need to download 80 MB of drivers (for having extensions and therefore an intro)
DirectX intros: you need to download 100 MB of drivers and DX (+20 MB for DX) to have CompileShader() and therefore an intro (as he said, you NEED D3DX for compiling a shader).

So in the end the difference is 80 vs 100 MB...

The rest is all stupid details that go nowhere. GLU has spheres and nurbs, D3DX has cubes and fonts, so what, they are the same thing!

It's true that D3DX has matrix, quaternion and mesh processing functions (even skeletal animation), but nobody that I know (but Stiletto) has exploited them so far, so no point there.

The only difference is that on top of the driver with some DX intros you also need to download 20 extra MB (or 3 MB if you pick directly the DLL (google d3dx9_41.dll , pick the first link, http://www.dll-files.com/, and download it, that's what I always do).

I can believe we are still discussing this issue... I mean, it's...

gbnd: for windows update perhaps, although that updates random crap like movie maker now and IE so I don't get why not DX too... But what about 'microsoft update' that is supposed to handle general MS updates?

Seems like some stuff has automatic updates, and other stuff (arguably closer to the core OS in the case of DX too) is totally manual - so I still think MS is to blame here, DX updates should be delivered as part of the patches :)

Because DirectX is (or, "was") not meant to be for democoders, it's meant to be included as a redistributable on game CDs/DVDs and it's easly mergeable on any setup tool you can think of.

So there's basically no need to update it through MS-Update, if a game needs it, it'll come with it.

About the off-c#-topic, quintix, i don't really see the severe problem you are talking about the separation between definition/implementation : you could easily define an assembly which contains only interfaces and a dynamic factory loading transparently implementations from external assemblies, no?

And about .NET and 4k intros, it's a false coding legend to believe that .NET would give you an invaluable advantage. Currently, by far, the most powerful tandem in a 4k is the shading language coupled with a tiny(asm)/versatile synthesizer. There is nothing in .NET that could compete with one line of glsl/hlsl functions to produce an impressive effect on the screen... not to mention also that .NET is lacked of some critical components for a demo (e.g. apart from Silverlight4, there are no realtime audio support in the whole .NET API). I'm also a huge fan of .NET programming, it's sometimes difficult to go back to c++, but .NET is probably worth for a big demo and a good companion to produce some really cool prototyping/gui/demotools.

JCL: That kind of makes sense, but DX comes as part of the OS and not all software that uses it is a game or comes on a cd. How about we find some security issues with DX so the updates get pushed out?

Or perhaps what we need is 4k intros that bundle the relevant dx installation? ;)

psonice: that's why i said "was"... downloadable content has only recently became popular (at least, when talking to DX-games and stuff)... actually, before valve's "steam" it was quite difficult to actually find any kind of downloadable games (at least, "mass-media" downloadable games, not geeky stuff :-) ).

They will probably start changing their mind about the distribution method, but with something that big, in companies like microsoft, it usually takes time and tons of paperwork and ahead-studies... it's not like they can just say "hey, include it on ms-update" and be done with it the next day :-)