pouët.net

i want to watch (conspiracy) intros ! :E

I got back to the 56 something drivers, and it seems to work fine. Now, I should send that email to nvidia...


I'll pass the D3D comment...

Navis, this wasn't really a joke.

In the past I've used GL often, but switched to D3D due to ATi driver problems. And I must say, I am completely happy now. Both ATi and nVidia D3D support is rock solid.

As I have seen, you use Cg for your effects, so there is no problem using this with D3D as Cg has a D3D runtime if I remember correctly.

Okay, you don't get the latest funky extensions, but all fun-stuff is there, RTT, MRT, etc. and no extension loading, hehehe. And using D3D is simple as eating donuts.

Cheers, E1.

E1, no problem.

I use D3d some times at work myself, with HLSL. Well, I suppose it is ok NOW, took them how many years to sort out this clumpsy API. (in version 8? in 98..).
For this reason, just like many other people, I started early with opengl.

I never had opengl specific problems - my ATI problems were down to pixel shader bugs.

(but ofcourse it is never late to discover a new one :-))

Navis: actually, i'd say that it's opengl that is just starting to become okay now. i mean, d3d has had proper render-to-texture support for 7 years. and in these days FBOs are finally here. but then you've got all the other issues with gl that still has to be resolved, like geometry instancing... i guess i'm still sticking with d3d for most personal projects for a couple of more years.

so then, are you a homophobe or just a neonazi?

Oops, sounds like skrebbel is a homosexual jew after all ;)

skrebbel, both.

shift, but not for long! my rabbi said i had to choose, and then http://www.hetracil.com solved all my problems!!

Hi, still struggling with this one. No idea how to solve it yet. found this :

http://graphics-api-opengl.mp1home.com/ChoosePixelFormat-delay-takes-15-seconds-to-execute-on-Windows-125381.html

But it doesn't make any sense. Does it ?

D3D started to kick some serious ass with D3D7. Then glide was out of the picture... (OpenGL was never in)

Ok, a lame question. What is the best method for making simple "copper" bars with OpenGL; with GL_LINES or GL_QUADS? I'd like to use lines but I have problems making them lie next to eachother without overlapping or having the background shine through.

why would you need lines? just use textured alphablending textures goddamit.

but please, DO NOT release it.

GL_QUADS for sure.
You may also want to disable lighting, blending and z-buffer tests to speed up the thing.

To eventually obtain gradients inside the bar enable polygon smoothing assigning the different colors to each vertex and then letting the gfxcard to do a linear ramping of the RGB values.

If you want to achieve more complex gradients you can split the bar in more little quads or you can even use a (1D or 2D) texture.

Also, since you probably are drawing in 2D remember to properly call 'glOrtho()' on the projection matrix with (i.e.) your screen resolution to ensure you can have pixel-precise control of your primitive drawing positioning
(This is probably the cause of your overlapping/gap problems).

For a deeper overview on using glOrtho() you could look here.

But just don't, we've seen enough "oldschool" stuff.

c64 doesn't have copper so coders just can't do real copperbars... but there's a great solution - line drawing!

@ Broderick: Thanks for the tips, I'll try and keep that in mind.

Hehe, I promise I won't release anything until I have something more besides copper bars :)