When suddenly.....OpenGL 4.0 !

http://www.betanews.com/article/In-a-more-complicated-gaming-world-OpenGL-40-gets-simpler-smarter/12
68348226

http://www.opengl.org/registry/

Direct link to spec with changes marked.

After a very quick look these are the main differences I see:

-Added tessellation shaders. They make it easier to support level-of-detal rendering where objects look good when they are near and they have less polygons when they are far away to save computation. See also.

-Added support for double-precision data in the shaders. This will allow for more accurate computations -- not sure how much this will be used in games.

-Per-sample shading. This will improve antialiasing - making edges look smoother.

There are quite a few changes in there. Some of them seem to be targeted to make it easier to port Direct3D games/apps onto OpenGL. A potential boon for developers.

Also, DirectX sucks

http://blog.wolfire.com/2010/01/Why-you-should-use-OpenGL-and-not-DirectX

Yeah the problem is I've had great trouble finding a good openGL tutorial and still haven't found one to learn OpenGL. There are tons of Direct3D tutorials out there though.
Plus by learning Direct3D one usually also gets a glimpse at DirectSound DirectInput and so on.
If I would learn OpenGL I would have to learn how to receive input, or give sound output seperately.

>>2
Just outputting sound and getting input is likely hundreds of times easier to learn than how to make a 3D engine, besides you'd usually make abstraction layers on top of the raw APIs.

>>3
I can see that, still I haven't found an in-depth tutorial about OpenGL that has been updated after 2007. I would be really thankful if you could point me to a book or tutorial, but every book out there is said to be useless for someone new to graphic APIs.
I can usually learn other stuff with older tutorials, like ANSI-C from a 1992 K&R, but graphical stuff? I dunno...

>>1
I don't think it's an argument to say "do not use DX10/11, because 50% of all the gamers are still using Windows XP (which only supports DX9)", but to claim on the other hand "OpenGL is ultra portable, you know, for the millions of gamers who actually use linux and/or mac".

>>4
Red/Orange/Blue Book(s) or maybe some tutorial like NeHe's ones.

>>6
Half of the people reviewing these books say they are just reference guide not good for a beginner. NeHe is really old as are other tutorials...

>>5
gamers
linux
mac
Oh hi Valve fanboy, I didn't know it was you.

This will be the downfall of Valve. They're putting all this money into porting they're games and Steam, but nobody will buy it on MAC.

>>8
neither on linux.

but it would be nice not having to use wine for gaymen.

>>7
Blue book would be a reference, but the Red and Orange Books are just programming guides.

>>1
We do know that the patent for OpenGL is owned by M$ right?

>>8
that's because pretty much anyone who would play it on a Mac already bought it for Windows and gets the Mac version for free.

>>12
Stop trying to ruin my biased popular assertions with your useless facts!

So what higher level library should one be using to get around the same functionality as Direct3D offers?

I'M NOT ALLOWED TO HAVE MY OWN THREAD ;_;
========================================

#!/bin/bash

# Adjust this depending on connection bandwidth
LOLITROLU=50

while [ true ]; do

a=0

while [ $a -lt $LOLITROLU ]; do
let a=a+1
curl --max-time 60 --user-agent "Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3" http://www.*.com/topics/1 > /dev/null &
done

sleep 60

>>14
Hax my anus, faggot!

>>14

Look here:

http://www.loc.gov/index.html

>>15
Cross-platform development is laudable and smart, except for bash scripts.

I find it odd that very few mention PS3 uses OpenGL ES, as does the iPhone/Tampon. The Wii & DS use their own library I think, but even if they do, it's very similar to OpenGL.

Then again, if anyone was going to write a truly cross-platform and cross-system game, they should probably just use an existing library like the UT3 engine.

I'm a bit torn; on one hand, it's pretty easy to learn and use; take a course on computer graphics, read through the core specs, and off you go.
On the other hand, the API kind of sucks. I'm talking about the «bind this, bind that» stuff. It's just a way to hack multi-X support to everything they only supported one each of in the beginning, and it sucks for making generic engines. Vertex buffer objects add even more annoyingly roundabout binding and enabling/disabling to your code. Where's my object-oriented redesign?

>>19
The DS is very GL-like, basically a tiny OpenGL subset. No idea about the Wii, but I'm sure it's the same deal, only much more complete.

(__)_) <--- Ass
m-'.'-m <--- Moses

>>20
You can write an object layer on top of it. The fact that no one really does this leads me to believe no one really wants it.

>>23
See EXT_direct_state_access.
Quoth Carmack: ``This should have happened a long time ago.''

Too bad about there's no sign of it reaching the core spec.

>>24
I can see why he'd want it, and I could see why it may never arrive. If you think about it, it would probably see hardware implementation as a form of implicit encapsulation that does exactly the same thing as before, only with the added overhead of performing the command expansion on the GPU. That's not to say there is no benefit, but there's probably not much benefit in actuality.

(I'd still vote for having it in.)

FOLLOW THE NEW GNAA TWITTER AT http://twitter.com/Gary_Niger

>>39

T(1) = 1
T(N) = T(N-1)+T(N-2)+T(N-3)+...+T(1)+1
when you try simple substitution you should realize a pattern that only the functions to the left can spawn (1) function seen to the right. i.e: T(N) can only spawn 1 T(N-1) call; therefore, we can start to notice that the coefficients of each call T(M) for some M < N should be 2^(N-M-1). i.e: N = 5, M = 4 T(4) coefficient should be 2^5-4-1 = 1


T(N) = (2^(1-1))T(N-1) + (2^(2-1))T(N-2) + ... + (2^((N-1)-1)T(1) + 1
simplifing T(1) coefficient
T(N) = (2^(1-1))T(N-1) + (2^(2-1))T(N-2) + ... + (2^(N-2)T(1) + 1
T(N) = (1)T(N-1) + (2)T(N-2) + ... + (2^(N-2))T(1) + 1
Since the coefficient equates to the number of times we'll call T with argument M for some integer we can see that this is a simple series:
   
   /  (n-1)        \
  |   ____          |
  |   \             |
  |   /___   2^(x-1)  / + 1     = total number of calls for Input N
   \    1          /

Using some math, you should be able to reason the series to become simply:
  (2^(n-1)-1)+1
=> 2^(n-1)

Therefore: O(2^(n-1))


is that a good enough proof?

/prog/ will be spammed continuously until further notice. we apologize for any inconvenience this may cause.