• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

Archived

This topic is now archived and is closed to further replies.

wcmike

OpenGL
Why is the OpenGL board so quiet?

10 posts in this topic

I have been unable to decide if I should first focus on learning OpenGL or DirectX (I''m sure you all of heard that). I''ve been reading a lot of posts here and at some other message boards and a lot of people have favored OpenGL over DirectX. This makes me think "Great, I will learn that then." I look here at the forums and I notice that DirectX has tons of more posts than OpenGL. Am I simply talking to a biased crowd? I seriously have heard about an 80-20 ratio of people favoring OpenGL to DirectX. DirectX dominates the GameDev.net forum, however. I''ve been trying to figure out why this is but I have no idea. I really did not want to post this because it is quite a sensitive topic (flame war) but I am clueless. Please tell me why DirectX dominates this board! Thank you for your time.
0

Share this post


Link to post
Share on other sites
Probably because DX can be quite newbie unfriendly by using COM components and such...I personally do not like DirectX because of the reliance on COM, but if that does not intimidate you, I would recommend it over OpenGL. OpenGL has been static for far too long, and it''s starting to be surpassed in features by DirectX, and unless the OpenGL committee releases a new OpenGL library it''s gonna be left in the dust pretty soon here =D
0

Share this post


Link to post
Share on other sites
quote:
Original post by wcmike
Please tell me why DirectX dominates this board!


Maybe, peaple have much more problems with DirectX?

But seriously - OpenGL-only forum is newborn one.
You need to look at "NeHe Productions : Everything OpenGL" for an "old" part (its number of posts is ~50% of DirectX forum).

(btw, in DirectX forum you''ll find questions not only about its 3D part (Direct3D), but also DirectDraw/DirectInput/COM/etc..)
0

Share this post


Link to post
Share on other sites
It is not a critical decision. You can switch between them and use that you have learn with the other API.

If you count all posts here on gamedev would you probably get something like 80-20 in favor of OpenGL vs Direct3D. I think Direct3D has been much more popular the last year so perhaps is it more like 50-50 now?

Some reasons for this:
1. The strength of the MS brand. I think this is by far the most important.
2. You will have some Direct3D tutorials now like nexe and drunken hyena.
3. The API is really much better since they took OpenGL as the ideal.
4. X-Box

The last year was a great year for OpenGL also.
1. Now do you have cutting edge 3D on Mac and linux.
2. OpenGL will take full advantage of the latest and greatest hardware such as nvidias GF3.
0

Share this post


Link to post
Share on other sites
>>Please tell me why DirectX dominates this board<<

could it be youre looking at the total number of posts per group which is about directx 43000 + opengl 300. until last week the opengl forum didnt exist and the directx one was called something like directx + opengl + other apis.
whoops :o i see sergeK has already writtent his

http://members.xoom.com/myBollux
0

Share this post


Link to post
Share on other sites
quote:

about an 80-20 ratio of people



Why not simply say a 4:1 ratio?
0

Share this post


Link to post
Share on other sites
As was previously stated, the OGL board didn''t exist until last week. We have gotten 300 REAL posts in a week, so I don''t think we are quiet. The DX board has gotten just about as many (but we started out at 0 posts, the DX board started at above 60000).

------------------------------
Trent (ShiningKnight)
E-mail me
OpenGL Game Programming Tutorials
0

Share this post


Link to post
Share on other sites
Ok, thanks for the replies everyone.

btw, I said 80-20 instead of 4:1 because I like to think in terms of percent.
0

Share this post


Link to post
Share on other sites
Although you have already heard a bijillion things, here is the bijillionth and first

OpenGL : GREAT! I love OpenGL and use it exclusively... not only is it MUCH MUCH MUCH easier for the beginner, but it is extreamly well made.

DirectX : Although Direct 3D is on my ''things I hate'' list, in reality it is a better API because in OpenGL it ither works or dosn''t... you may have an OpenGL extension on your card, but if someone else dosn''t they are screwed. DirectX however by using the hardware abstraction layer vs the hardware emulation layer can do things even if your computer can''t support them.

So short awnser, yes, OpenGL. Long awnser, DirectX... they both have their pros and cons, but for a beginner DEFINENTLY OpenGL because of it''s ease of use!



CodeSmith the Pixel Pusher
www.cs.trinity.edu/~csmith8
0

Share this post


Link to post
Share on other sites
DirectX = Direct3d DirectDraw DirectInput DirectSound DirectPlay

OpenGL = OpenGL
0

Share this post


Link to post
Share on other sites
Now keep in mind that I''m a dumb idjit who''s never read proper books on anything in his whole life, :D but I''ve been having a tough time figuring out what exactly it is that D3D8 does that OpenGL doesn''t.

Vertex buffers are neat and all, but how are they different from display lists? And which of the two are harder to implement? (I spent all of 10 seconds reading about, understanding, and then implementing display lists in a testbox (much props for NeHe :D (nested paranths are fun)))) Locking textures? glTexSubImage.

The one thing I do see is the fact that D3D8 emulates things with software, but to my knowledge, that''s only when using the reference driver, which isn''t usually (pronounced: ever, except when testing ) the best way to go. (it''s entirely possible I''m full of it in this regard, and many others though :D )

So.. uh.. how''s D3D8 better again, if it offers pretty much the same functionality, and is arguably as simple? (I find it harder, but I''ll assume that the reverse is possible, depending on the individual using it)
0

Share this post


Link to post
Share on other sites

  • Similar Content

    • By mapra99
      Hello

      I am working on a recent project and I have been learning how to code in C# using OpenGL libraries for some graphics. I have achieved some quite interesting things using TAO Framework writing in Console Applications, creating a GLUT Window. But my problem now is that I need to incorporate the Graphics in a Windows Form so I can relate the objects that I render with some .NET Controls.

      To deal with this problem, I have seen in some forums that it's better to use OpenTK instead of TAO Framework, so I can use the glControl that OpenTK libraries offer. However, I haven't found complete articles, tutorials or source codes that help using the glControl or that may insert me into de OpenTK functions. Would somebody please share in this forum some links or files where I can find good documentation about this topic? Or may I use another library different of OpenTK?

      Thanks!
    • By Solid_Spy
      Hello, I have been working on SH Irradiance map rendering, and I have been using a GLSL pixel shader to render SH irradiance to 2D irradiance maps for my static objects. I already have it working with 9 3D textures so far for the first 9 SH functions.
      In my GLSL shader, I have to send in 9 SH Coefficient 3D Texures that use RGBA8 as a pixel format. RGB being used for the coefficients for red, green, and blue, and the A for checking if the voxel is in use (for the 3D texture solidification shader to prevent bleeding).
      My problem is, I want to knock this number of textures down to something like 4 or 5. Getting even lower would be a godsend. This is because I eventually plan on adding more SH Coefficient 3D Textures for other parts of the game map (such as inside rooms, as opposed to the outside), to circumvent irradiance probe bleeding between rooms separated by walls. I don't want to reach the 32 texture limit too soon. Also, I figure that it would be a LOT faster.
      Is there a way I could, say, store 2 sets of SH Coefficients for 2 SH functions inside a texture with RGBA16 pixels? If so, how would I extract them from inside GLSL? Let me know if you have any suggestions ^^.
    • By KarimIO
      EDIT: I thought this was restricted to Attribute-Created GL contexts, but it isn't, so I rewrote the post.
      Hey guys, whenever I call SwapBuffers(hDC), I get a crash, and I get a "Too many posts were made to a semaphore." from Windows as I call SwapBuffers. What could be the cause of this?
      Update: No crash occurs if I don't draw, just clear and swap.
      static PIXELFORMATDESCRIPTOR pfd = // pfd Tells Windows How We Want Things To Be { sizeof(PIXELFORMATDESCRIPTOR), // Size Of This Pixel Format Descriptor 1, // Version Number PFD_DRAW_TO_WINDOW | // Format Must Support Window PFD_SUPPORT_OPENGL | // Format Must Support OpenGL PFD_DOUBLEBUFFER, // Must Support Double Buffering PFD_TYPE_RGBA, // Request An RGBA Format 32, // Select Our Color Depth 0, 0, 0, 0, 0, 0, // Color Bits Ignored 0, // No Alpha Buffer 0, // Shift Bit Ignored 0, // No Accumulation Buffer 0, 0, 0, 0, // Accumulation Bits Ignored 24, // 24Bit Z-Buffer (Depth Buffer) 0, // No Stencil Buffer 0, // No Auxiliary Buffer PFD_MAIN_PLANE, // Main Drawing Layer 0, // Reserved 0, 0, 0 // Layer Masks Ignored }; if (!(hDC = GetDC(windowHandle))) return false; unsigned int PixelFormat; if (!(PixelFormat = ChoosePixelFormat(hDC, &pfd))) return false; if (!SetPixelFormat(hDC, PixelFormat, &pfd)) return false; hRC = wglCreateContext(hDC); if (!hRC) { std::cout << "wglCreateContext Failed!\n"; return false; } if (wglMakeCurrent(hDC, hRC) == NULL) { std::cout << "Make Context Current Second Failed!\n"; return false; } ... // OGL Buffer Initialization glClear(GL_DEPTH_BUFFER_BIT | GL_COLOR_BUFFER_BIT); glBindVertexArray(vao); glUseProgram(myprogram); glDrawElements(GL_TRIANGLES, indexCount, GL_UNSIGNED_SHORT, (void *)indexStart); SwapBuffers(GetDC(window_handle));  
    • By Tchom
      Hey devs!
       
      I've been working on a OpenGL ES 2.0 android engine and I have begun implementing some simple (point) lighting. I had something fairly simple working, so I tried to get fancy and added color-tinting light. And it works great... with only one or two lights. Any more than that, the application drops about 15 frames per light added (my ideal is at least 4 or 5). I know implementing lighting is expensive, I just didn't think it was that expensive. I'm fairly new to the world of OpenGL and GLSL, so there is a good chance I've written some crappy shader code. If anyone had any feedback or tips on how I can optimize this code, please let me know.
       
      Vertex Shader
      uniform mat4 u_MVPMatrix; uniform mat4 u_MVMatrix; attribute vec4 a_Position; attribute vec3 a_Normal; attribute vec2 a_TexCoordinate; varying vec3 v_Position; varying vec3 v_Normal; varying vec2 v_TexCoordinate; void main() { v_Position = vec3(u_MVMatrix * a_Position); v_TexCoordinate = a_TexCoordinate; v_Normal = vec3(u_MVMatrix * vec4(a_Normal, 0.0)); gl_Position = u_MVPMatrix * a_Position; } Fragment Shader
      precision mediump float; uniform vec4 u_LightPos["+numLights+"]; uniform vec4 u_LightColours["+numLights+"]; uniform float u_LightPower["+numLights+"]; uniform sampler2D u_Texture; varying vec3 v_Position; varying vec3 v_Normal; varying vec2 v_TexCoordinate; void main() { gl_FragColor = (texture2D(u_Texture, v_TexCoordinate)); float diffuse = 0.0; vec4 colourSum = vec4(1.0); for (int i = 0; i < "+numLights+"; i++) { vec3 toPointLight = vec3(u_LightPos[i]); float distance = length(toPointLight - v_Position); vec3 lightVector = normalize(toPointLight - v_Position); float diffuseDiff = 0.0; // The diffuse difference contributed from current light diffuseDiff = max(dot(v_Normal, lightVector), 0.0); diffuseDiff = diffuseDiff * (1.0 / (1.0 + ((1.0-u_LightPower[i])* distance * distance))); //Determine attenuatio diffuse += diffuseDiff; gl_FragColor.rgb *= vec3(1.0) / ((vec3(1.0) + ((vec3(1.0) - vec3(u_LightColours[i]))*diffuseDiff))); //The expensive part } diffuse += 0.1; //Add ambient light gl_FragColor.rgb *= diffuse; } Am I making any rookie mistakes? Or am I just being unrealistic about what I can do? Thanks in advance
    • By yahiko00
      Hi,
      Not sure to post at the right place, if not, please forgive me...
      For a game project I am working on, I would like to implement a 2D starfield as a background.
      I do not want to deal with static tiles, since I plan to slowly animate the starfield. So, I am trying to figure out how to generate a random starfield for the entire map.
      I feel that using a uniform distribution for the stars will not do the trick. Instead I would like something similar to the screenshot below, taken from the game Star Wars: Empire At War (all credits to Lucasfilm, Disney, and so on...).

      Is there someone who could have an idea of a distribution which could result in such a starfield?
      Any insight would be appreciated
  • Popular Now