• 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.
Sign in to follow this  
Followers 0
Myopic Rhino

OpenGL
Looking for authors - submissions closed (Updated 4/27)

44 posts in this topic

Update (4/27)

I still have a few people to respond to (in particular those who submitted for terrain or particle systems), but submissions are now closed. I got a lot of great responses and only regret that I can't have everyone write. This is going to be an excellent book.

Background

Kevin and I have been working on a book called More OpenGL Game Programming, which is a direct follow-up to Beginning OpenGL Game Programming and an indirect sequel to OpenGL Game Programming. The first part of the book will cover advanced OpenGL topics not covered in our previous books, and the second part will cover (mostly) graphics techniques that are useful to game programmers. The intent is to present the "standard" way of doing fairly common things, rather than introducing new techniques or covering niche topics. We feel that there is a big gap in the books available at this level, and hope that this will be useful to people who have a basic understanding of 3D game development and want to move to the next level.

The Problem

We've been working on this book for almost a year, and haven't been able to find much time to work on it. The problem is that many of the topics we want to cover require that the author either already have pretty extensive knowledge of it, or have at least several weeks free to dedicate to research. When you have more than 20 topics that fall into this category, it becomes pretty daunting. But rather than cancelling the book, or trying to scale back the content, we (or rather, I, since Kevin opted to drop out) decided instead to find (many) additional authors, each of which will cover a single topic (or in some cases, small number of topics), presumably which they already understand fairly well. Rather than have this be a "Gems-style" collection of unrelated articles, however, I have a table of contents that I'd like to follow, and I'll be adding "glue" to make sure all the sections flow together as naturally as possible.

Where you come in

So the point of all of this is that I'm looking for authors. You'll be fully credited for your work, as well as paid (haven't worked out the exact terms yet, but it'll be on the order of $10/page, to be paid once the final draft from you is received). If you're confident in your technical knowledge and skills, but not confident in your writing ability, don't worry; I'll be acting as editor for this, and there will be additional editors as well.

Table of Contents (Updated 4/8)

The following is the table of contents. Any topics listed in italics have either already been written by me or are tentatively spoken for by someone. The ToC is still mostly flexible, so even if you're not planning on contributing, if you think that there are topics that need to be added - or removed - I'd appreciate the feedback. Part I – Advanced OpenGL The purpose of this part of the book is to cover advanced OpenGL topics that weren't covered in the previous books. Chapter 1 – OpenGL Potpourri 1.1 – Vertex Buffer Objects 1.2 – Pixel Buffer Objects 1.3 - Multisampling 1.4 - Occlusion Queries 1.5 – User clip planes 1.6 - Disabling VSync 1.7 – Framebuffer Objects (may be better in the texture mapping chapter under render-to-texture) [b]Chapter 2 – Introduction to Shaders Chapter 3 – Low-level Shaders Covering ARB_vertex_program and ARB_fragment_program, and possibly some of the newer vendor-specific extensions Chapter 4 – The OpenGL Shading Language Covering GLSL Chapter 5 – Advanced Texture Mapping 5.0 – Anisotropic Filtering 5.1 – Compressed textures 5.2 - NPOT textures/texture rectangles 5.3 - Floating point texture formats 5.4 - Bump Mapping 5.5 - Displacement Mapping 5.6 - Parallax Mapping 5.7 - Dynamic Light Mapping 5.8 - Detail Maps 5.9 - Projective Textures 5.10 - Splatting 5.11 - Refraction/the Fresnel effect 5.12 - Render to Texture Part II – The Elements of a Game(?) This section of the book will turn to showing how to do the types of things you'd do in a game using OpenGL Chapter 6 - Special Effects 6.1 – Billboarding 6.2 - Particle Systems 6.2.1 - point sprites 6.3 - Shadows 6.3.1 - Static Shadows 6.3.2 - Projective Shadows 6.3.3 - Shadow Mapping 6.3.4 - Shadow Volumes 6.4 - Volumetric Fog (maybe not necessary, since we already covered fog coordinates in BOGLGP) 6.5 - NPR (mainly just toon shading) 6.6 – Glow 6.7 - Reflections 6.8 - HDR lighting 6.9 – Explosions Chapter 7 – Rendering Nature 7.1 – Skies 7.1.1 – Skyboxes 7.1.2 – Skyplanes 7.1.3 – Skydomes 7.1.4 – Dynamic methods 7.2 – Terrain (probably just going to give an overview of various techniques, but focus on a brute-force method using hardware) 7.2.1 - Geomipmapping 7.2.2 - Chunked LOD 7.2.3 - Hardware based 7.3 - Clouds 7.4 - Fire 7.5 – Water 7.6 – Plants/vegetation? Chapter 8 - Working with 3D Models 8.1 – Static models (.obj?) 8.2 – Keyframe Animation (.md3?) 8.3 – Vertex Skinning (.mdl? .md5?) 8.4 - Summary Include 3ds in there somewhere? Chapter 9 – Game Engine Design Primer? This may be too big a topic to tackle in a single chapter, and we may be better off simply explaining design choices that were made for the game in the final chapter. Chapter 10 - Making a Game: Another Time to Kill (I'll probably just write this after the game is finished) Appendix A – ARB_vertex_program reference Appendix B – ARB_fragment_program reference Appendix C – GLSlang reference Additional chapter ideas: Scene management/Visibility determination? Physics/collision detection? Audio (OpenAL/SDL/fmod)? See below for my comments on the updated ToC

What you'll be writing

Chapters 3, 4, and 9 (if we include it) will pretty much require a single author. Chapter 8 should probably be a single author as well. The rest of the chapters can be split up with different authors for each subtopic. The total length of the book is going to be 400-500 pages. That's about 30 pages per chapter (except for chapters 3 and 4, which will be longer), and about 2-8 pages per topic (depending). Whenever appropriate, you should use figures, screenshots, tables, etc., to make the book more readable.

Demos

Each subtopic should include at least one demo. The demo should be straightforward, clearly illustrating the material presented in your section, while still being relevant to gaming. I'll provide a basic framework that you should use so there is some commonality among all the demos. If the demo needs extensions, it should use GLee. To be consistent with the previous books, the demos should be written using Visual Studio and Win32. However, I'd like to be able to provide SDL versions of all the demos as well.

Deadlines

I'll need to receive the first draft from you no later than the end of June. If any revisions are needed after I review the material, you'll need to submit a final draft by the end of July. This book is not shipping with a CD. Instead, the sample code will be made available via the book's website. So the demos won't be due until the end of August. That said, since you'll be writing at least a little about the demo and probably include a screenshot, you should at least have a working demo before you submit the first draft.

Interested?

If you're interested, please email me with the following: * Which of the above topics you want to cover * A paragraph or two summarizing what you're going to cover related to the topic. * A brief bio of yourself (basically, if I don't know you, I need you to tell me enough to convice me that you know what you're talking about and that you're going to be reliable) * An estimate of how many pages you'll need to cover the topic well. * A description of the demo (or demos) that you'll include. You can choose more than one topic if you want, but don't overcommit yourself. It's going to be very important that everyone does what they say they will do. I anticipate that for at least some of the topics listed above, I'll have more than one interested party. If you know people that may be interested in this, feel free to point them to this thread.
0

Share this post


Link to post
Share on other sites
Well I really hope you don't have to cancel this book I am looking forward to it [although I still am having problems learning with the first book mostly my fault and I use Dev-C++].

Once I have learned everthing I can from the first I would hope to get the second to advance my skills.

Good Luck.
0

Share this post


Link to post
Share on other sites
Thanks to the people who have emailed me so far. I'll get back to you soon.

Because of some questions brought up by a couple of people who emailed me, and because the number of responses I've received was smaller than I expected, I want to make a few additional comments.

In order to write for this, you don't have to be an expert in the topic you're writing about (though if you are, it'll be somewhat easier). All you really need is a basic understanding of the topic and a desire to learn more. For most of the topics I've listed, 3 months is more than enough time to research, experiment, and then write about it. I figure that most people here are already researching and experimenting all the time, so the only additional work would be the writing, which isn't too bad.

For your bio, I don't need you to convince me that you're a guru (nor do I expect it). I just need to feel comfortable that you know where to start, and I need to be confident that if I pick you to cover a topic, you'll come through for me. I don't want to have to scramble to find a replacement in 3 months when you don't come through for me.

I have no doubt that collectively, the members of this forum can write about every topic I've listed, so I hope that some of you take advantage of this opportunity. Besides the compensation, I know from experience that having writing credits on your resume is a big plus. If I have to, I know plenty of people in the industry that I can tap to help finish this book, but I think it'd be a lot better to have it be a product of the GameDev.net OpenGL community.
0

Share this post


Link to post
Share on other sites
I had bought GL game programming. A thing which disappointed me is that the book is basically a collection of stuff taken from the net. I hope this does not happen this time. I also found the book rather weak in general and I rarely check it (just the vertex array section).

By the way, I'm not sure of some chapters.
1.4 - Occlusion Queries: I just wanted to say there has been some discussion on opengl.org's forum about these. Odds are it's difficult to make the m work right and this means building a decent test app could be difficult.
The latency introduced could be a performance hamper and for "demo-like" apps this always happens. It's difficult to explain their usefulness in simple conditions without showing this behaviour.
1.5 – User clip planes: I'm not sure those things are really supported, besides NEAR and FAR. Maybe I'm misunderstanding the functionality.
1.6 - Disabling VSync: this must be little. MSDN is rather self-exaplanatory on this.
Covering ARB_vertex_program and ARB_fragment_program, and possibly some of the newer vendor-specific extensions: I'm also a fan of ARB_vp and ARB_fp but I must admit that 1- "plain" ARB_vp is badly outdated 2- ARB voted against low level programming. While I still thing NV holds >50% of the installed base, I hardly believe there's future for ASM-like things. This chapters could be quickly outdated. Someone would say it's badly outdated even now.
5.2 - NPOT textures/texture rectangles: take my two cents, don't even think about RECT textures. They are a mess. I have support for them and they really blow up the complexity, assuming NV_rect or EXT_rect. If you're speaking of ARB_npot, then there's nothing much to say on that topic as I see it.
6.3.2 - Projective Shadows and 6.3.3 - Shadow Mapping: what's the difference? I hope this is referring to PSMs since everyone can get standard shadow maps in a week of work.

I hope you'll find those two cents useful!
0

Share this post


Link to post
Share on other sites
Thanks for the feedback, Krohm. Anyone else who would like to comment on the topics is welcome to do so, as they're still subject to change.

To respond to some of your comments.

The section on occlusion queries is pretty brief and discusses the potential issues with them.

The section on user clip planes just covers the usage of glClipPlane(), and it's less than a page.

Yes, the section on disabling VSync is also brief. Keep in mind that this book, along with BOGLGP, is intended to provide readers with a solid foundation in OpenGL for game programming. As often as people here and elsewhere ask about VSync, I think it's worth spending a page or so on it.

I definitely understand your arguments about the low level shaders. I wanted to include coverage of them because they are supported on a wider range of hardware than GLSL, and because there is a lot of sample code out there that uses them. The coverage would be as brief as possible, and would stress that the reader should stick to GLSL whenever possible.

NPOT and RECT textures are included for the sake of completeness.

When I say Projective Shadows, I'm referring to the classic projective planar shadow technique. It's included because it's simple and still occasionally useful.

Finally, I just wanted to mention that nothing from the original OGLGP was taken from the net. Everything was written from scratch by Kevin and myself. We of course used reference material (notably the spec and the Red Book), but we intentionally avoided reading any online tutorials to avoid the tendancy to plagiarize. Looking back now, yeah, the original book is pretty week, but I think that BOGLGP is a really strong introduction to OpenGL.
0

Share this post


Link to post
Share on other sites
After reading this, I agree with most you replied in your message.

I also wanted to say my previous message reads a bit "too strong", I guess I should have written more extensive descriptions of what I meant to say. Looks like it hasn't been misunderstood anyway.
0

Share this post


Link to post
Share on other sites
I agree with Dave on the subject of ARB_vertex_program and ARB_fragment_program. I was recently doing a spell of development on a laptop, which didn't support GLSL, and only partially supported the ARB_*_programs. Laptop videocards are a lot less powerfull, and you don't upgrade a laptop as often as a desktop computer.
0

Share this post


Link to post
Share on other sites
I have some demos you can include if you would like them, but I doubt I would have time to contribute any writing. I will probably barely have time to clean up the demos and get them presentable. Collectively the demos illustrate vertex buffer objects, floating point texture formats and render-to-texture, simple HDR lighting, billboarding (CPU and GPU), impostoring, sky domes with atmospheric scattering, terrain (normal ROAM and chunked LOD), and volumetric clouds (using 3 different modeling/rendering techniques). I also have a very simple game engine library based on GameDev's Enginuity series of articles, and I have recently ported some of my old demos over to use it to get rid of any redundant code and clean the rest up. Any shaders used in the demos are written in GLSL.

I only use a few third-party libraries like SDL, libjpeg, and Intel's GLSDK. I wrote the rest of the code and have released it under the BSD license, so you (and your readers) can do pretty much whatever you want with it. All of the project files are for MS Visual Studio 6.0. I've never ported it to any other platform, but given the libraries I'm using, I doubt it will be difficult.

Some of the demos, like the one using ROAM, are very old and use out-dated techniques. Still, you don't have to include the ones you don't like. I've already written articles on some of the demos, like the ROAM and atmospheric scattering demos. I haven't written any articles on the others, and I've retained the publishing rights for the source code of all of them except two (I won't send you those). Send me an email if you're interested in seeing them.

Sean
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Krohm

1.4 - Occlusion Queries: I just wanted to say there has been some discussion on opengl.org's forum about these. Odds are it's difficult to make the m work right and this means building a decent test app could be difficult.
The latency introduced could be a performance hamper and for "demo-like" apps this always happens. It's difficult to explain their usefulness in simple conditions without showing this behaviour.


I just wanted to mention that GPU Gems 2 has a chapter on how to make occlusion queries useful (with the normal disclaimer that it's not useful for all scenes). To minimize the number of queries, you use a space partitioning tree and, of course, use other culling methods first. To avoid latency, you avoid waiting for the answer to come back. You take advantage of frame coherence and plod on ahead using the answers from the previous frame (intelligently), and collect the answers at the end of the frame for the next frame. Check the answers, and if anything changed that requires you to render something you skipped, go back and render it. It's a bit more complicated than that, but that's the basic gist of it.
0

Share this post


Link to post
Share on other sites
Firstly, in which language would demos be written? If C++, would STL and such be allowable? I would guess that binding and fancy function objects should be avoided at least, but std::vector and friends would be nice to simplify code. Also, a standardised vector3f class ( or similar, and perhaps more for quaternions or matricies ) might be useful for example continuity. Just in general, what kinds of assumptions are allowed?

On a more topic-specific note, how much detail is needed? Things like sound or particle systems could be 2 page topics or 200 page ones...
0

Share this post


Link to post
Share on other sites
Sean: Thanks, I'll check out the demos. I'm sure that at least a few of them will fit in.

AP: Yes, the demos will be in C++. Basic STL is fine. My main goal is to have the demo code be easily understandable.

As for the detail level... with a book this size covering this many topics, you obviously can't go into excruciating detail. What I've tried to do in my own writing is provide just enough theory for the reader to have a decent understanding of how things really work, and have the main focus be on practice and application, without focusing on too much on one particular implementation. So, for example, with particle systems, I'd probably discuss what problems they are meant to solve, what attributes they might have, etc., and then discuss some different design choices for implementing them, accompanied by a simple implementation that can be extended by the reader.

Btw, I'll post an update later about which topics have been spoken for.
0

Share this post


Link to post
Share on other sites
Yeah, sorry, I still need to respond to everyone who has emailed me, but to be brief: you're pretty much spot on with what I'm looking for in that chapter. I'll send a more detailed response later, but I'm late picking up my daughter [grin]
0

Share this post


Link to post
Share on other sites
Idea: Create a closed WiKi, that you open up to possible Authors, and everyone can chip in a bit, although there will allways be "Chapter Supervisors" of course, to make sure everything falls into place.

I for one, although I don't see myself writing any of these chapters, I can do some assistant work, in researching examples, tutorials, code, etc...

I do feel that there aren't any game programming books out there that really sit down with the reader and guide them through two key areas: Multithreading and plugin designs.

These are areas that are either filled up with myths, or beginners coders just see them as too complex, when they're really not...

In regards to graphics code per se, there should be a book out there with a decent BSP primer, instead of historical snippets like "BSPs where used in Doom...", and a decent intro, backup up by a downloadable demo or library, shouldnt take more than 20 pages, if I'm not grossely underestimating it.

What do you guys think of my thoughts?
0

Share this post


Link to post
Share on other sites
Prozak: I agree as well, but _the_phantom_ is right, both are outside the scope of this book.

Anyway, I just updated the ToC. Most topics have at least one tentative author at this point, but there are still a few topics that need to be covered:

1.6 - Disabling VSync (I'll probably just write about this)
1.7 – Framebuffer Objects (will probably be included in the render-to-texture section anyway - either way I can write about it as well)
3.0 - ARB_vertex_program and ARB_fragment_program
5.7 - Dynamic Light Mapping
5.8 - Detail Maps
6.8 - HDR lighting
6.9 – Explosions
7.1 – Skies
7.1.1 – Skyboxes
7.1.2 – Skyplanes
7.1.3 – Skydomes
7.1.4 – Dynamic methods
7.3 - Clouds

Originally, the skies topic was marked as taken because I have an article that I wrote for another book a couple of years ago that I was going to update, but the article was pretty basic (focusing on static skyboxes), and I think there are people here who are capable of writing about much more exciting techniques (perhaps I could include my stuff as an intro to the basics and someone else could add more on dynamic methods)

In regards to the additional chapter ideas, at this point, it looks like we'll definitely be including a chapter scene management/visibility determination, etc. Someone has offered to write an OpenAL chapter, but I'm beginning to feel that it's a little off topic for the book.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Myopic Rhino
Someone has offered to write an OpenAL chapter, but I'm beginning to feel that it's a little off topic for the book.


Darn! [wink] I think your right Dave, this book would be better just for the OpenGL specifics in relation to Game Programming. I mean it's not about making games with OpenGL, otherwise there would need to be info on the other components such as input, file i/o, etc...
0

Share this post


Link to post
Share on other sites
*OT* being payed per page, what is the targeted font size it will be printed in? :)))))

(ignore me)
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Myopic Rhino
Prozak: I agree as well, but _the_phantom_ is right, both are outside the scope of this book.

In regards to the additional chapter ideas, at this point, it looks like we'll definitely be including a chapter scene management/visibility determination, etc.



Someone just has to sit down and tackle that issue, the lack of decent tutorials on the subject is appaling.

Thank you for taking my thougts on the subject into consideration.

*...goes back to finishing his own Lua tutorial...*
0

Share this post


Link to post
Share on other sites
Sounds like a good idea! It provides non-professionals with the chance to show their potential and knowledge through a book that addresses many in the industry.

A few questions:

Does this work as a competition - everybody submits and article and you choose the best or combine them or do you pick an author which will do the work?

Can the articles include pictures? How many? Generally I see books refrain from using too many pictures.

How long should one section of a chapter be?
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Ilici
Does this work as a competition - everybody submits and article and you choose the best or combine them or do you pick an author which will do the work?
No, not exactly. I'm going to choose the author in advance based on a brief proposal and summary of what they want to cover. I'll also take their bio (or if they are active here, what I know about them from the forums) into account when determining whether or not I think they can deliver what they say they will. There are some people here (including you) that I would automatically approve, no matter what they wanted to write about.
Quote:
Original post by Ilici
Can the articles include pictures? How many? Generally I see books refrain from using too many pictures.
Yeah, they really *should* include pictures. I'd like to see at least one figure every 2-3 pages, though more isn't bad if it's appropriate for the topic.
Quote:
Original post by Ilici
How long should one section of a chapter be?
Depends on the topic. 2-8 pages should be enough for most of the topics listed here, though a few will be longer (and a couple can be a page or so). That's assuming minimal code listings.
0

Share this post


Link to post
Share on other sites
HI! i think this book is necesary for the OpenGL game dev comunity , i think that is very useful a topic in Editors and tools programing (GTK and MFC) some basic but useful tutorial what do you think?
see u
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0

  • Similar Content

    • 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 DaniDesu
      #include "MyEngine.h" int main() { MyEngine myEngine; myEngine.run(); return 0; } MyEngine.h
      #pragma once #include "MyWindow.h" #include "MyShaders.h" #include "MyShapes.h" class MyEngine { private: GLFWwindow * myWindowHandle; MyWindow * myWindow; public: MyEngine(); ~MyEngine(); void run(); }; MyEngine.cpp
      #include "MyEngine.h" MyEngine::MyEngine() { MyWindow myWindow(800, 600, "My Game Engine"); this->myWindow = &myWindow; myWindow.createWindow(); this->myWindowHandle = myWindow.getWindowHandle(); // Load all OpenGL function pointers for use gladLoadGLLoader((GLADloadproc)glfwGetProcAddress); } MyEngine::~MyEngine() { this->myWindow->destroyWindow(); } void MyEngine::run() { MyShaders myShaders("VertexShader.glsl", "FragmentShader.glsl"); MyShapes myShapes; GLuint vertexArrayObjectHandle; float coordinates[] = { 0.5f, 0.5f, 0.0f, 0.5f, -0.5f, 0.0f, -0.5f, 0.5f, 0.0f }; vertexArrayObjectHandle = myShapes.drawTriangle(coordinates); while (!glfwWindowShouldClose(this->myWindowHandle)) { glClearColor(0.5f, 0.5f, 0.5f, 1.0f); glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); // Draw something glUseProgram(myShaders.getShaderProgram()); glBindVertexArray(vertexArrayObjectHandle); glDrawArrays(GL_TRIANGLES, 0, 3); glfwSwapBuffers(this->myWindowHandle); glfwPollEvents(); } } MyShaders.h
      #pragma once #include <glad\glad.h> #include <GLFW\glfw3.h> #include "MyFileHandler.h" class MyShaders { private: const char * vertexShaderFileName; const char * fragmentShaderFileName; const char * vertexShaderCode; const char * fragmentShaderCode; GLuint vertexShaderHandle; GLuint fragmentShaderHandle; GLuint shaderProgram; void compileShaders(); public: MyShaders(const char * vertexShaderFileName, const char * fragmentShaderFileName); ~MyShaders(); GLuint getShaderProgram(); const char * getVertexShaderCode(); const char * getFragmentShaderCode(); }; MyShaders.cpp
      #include "MyShaders.h" MyShaders::MyShaders(const char * vertexShaderFileName, const char * fragmentShaderFileName) { this->vertexShaderFileName = vertexShaderFileName; this->fragmentShaderFileName = fragmentShaderFileName; // Load shaders from files MyFileHandler myVertexShaderFileHandler(this->vertexShaderFileName); this->vertexShaderCode = myVertexShaderFileHandler.readFile(); MyFileHandler myFragmentShaderFileHandler(this->fragmentShaderFileName); this->fragmentShaderCode = myFragmentShaderFileHandler.readFile(); // Compile shaders this->compileShaders(); } MyShaders::~MyShaders() { } void MyShaders::compileShaders() { this->vertexShaderHandle = glCreateShader(GL_VERTEX_SHADER); this->fragmentShaderHandle = glCreateShader(GL_FRAGMENT_SHADER); glShaderSource(this->vertexShaderHandle, 1, &(this->vertexShaderCode), NULL); glShaderSource(this->fragmentShaderHandle, 1, &(this->fragmentShaderCode), NULL); glCompileShader(this->vertexShaderHandle); glCompileShader(this->fragmentShaderHandle); this->shaderProgram = glCreateProgram(); glAttachShader(this->shaderProgram, this->vertexShaderHandle); glAttachShader(this->shaderProgram, this->fragmentShaderHandle); glLinkProgram(this->shaderProgram); return; } GLuint MyShaders::getShaderProgram() { return this->shaderProgram; } const char * MyShaders::getVertexShaderCode() { return this->vertexShaderCode; } const char * MyShaders::getFragmentShaderCode() { return this->fragmentShaderCode; } MyWindow.h
      #pragma once #include <glad\glad.h> #include <GLFW\glfw3.h> class MyWindow { private: GLFWwindow * windowHandle; int windowWidth; int windowHeight; const char * windowTitle; public: MyWindow(int windowWidth, int windowHeight, const char * windowTitle); ~MyWindow(); GLFWwindow * getWindowHandle(); void createWindow(); void MyWindow::destroyWindow(); }; MyWindow.cpp
      #include "MyWindow.h" MyWindow::MyWindow(int windowWidth, int windowHeight, const char * windowTitle) { this->windowHandle = NULL; this->windowWidth = windowWidth; this->windowWidth = windowWidth; this->windowHeight = windowHeight; this->windowTitle = windowTitle; glfwInit(); } MyWindow::~MyWindow() { } GLFWwindow * MyWindow::getWindowHandle() { return this->windowHandle; } void MyWindow::createWindow() { // Use OpenGL 3.3 and GLSL 3.3 glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 3); glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3); // Limit backwards compatibility glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE); glfwWindowHint(GLFW_OPENGL_FORWARD_COMPAT, GL_TRUE); // Prevent resizing window glfwWindowHint(GLFW_RESIZABLE, GL_FALSE); // Create window this->windowHandle = glfwCreateWindow(this->windowWidth, this->windowHeight, this->windowTitle, NULL, NULL); glfwMakeContextCurrent(this->windowHandle); } void MyWindow::destroyWindow() { glfwTerminate(); } MyShapes.h
      #pragma once #include <glad\glad.h> #include <GLFW\glfw3.h> class MyShapes { public: MyShapes(); ~MyShapes(); GLuint & drawTriangle(float coordinates[]); }; MyShapes.cpp
      #include "MyShapes.h" MyShapes::MyShapes() { } MyShapes::~MyShapes() { } GLuint & MyShapes::drawTriangle(float coordinates[]) { GLuint vertexBufferObject{}; GLuint vertexArrayObject{}; // Create a VAO glGenVertexArrays(1, &vertexArrayObject); glBindVertexArray(vertexArrayObject); // Send vertices to the GPU glGenBuffers(1, &vertexBufferObject); glBindBuffer(GL_ARRAY_BUFFER, vertexBufferObject); glBufferData(GL_ARRAY_BUFFER, sizeof(coordinates), coordinates, GL_STATIC_DRAW); // Dertermine the interpretation of the array buffer glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, 3*sizeof(float), (void *)0); glEnableVertexAttribArray(0); // Unbind the buffers glBindBuffer(GL_ARRAY_BUFFER, 0); glBindVertexArray(0); return vertexArrayObject; } MyFileHandler.h
      #pragma once #include <cstdio> #include <cstdlib> class MyFileHandler { private: const char * fileName; unsigned long fileSize; void setFileSize(); public: MyFileHandler(const char * fileName); ~MyFileHandler(); unsigned long getFileSize(); const char * readFile(); }; MyFileHandler.cpp
      #include "MyFileHandler.h" MyFileHandler::MyFileHandler(const char * fileName) { this->fileName = fileName; this->setFileSize(); } MyFileHandler::~MyFileHandler() { } void MyFileHandler::setFileSize() { FILE * fileHandle = NULL; fopen_s(&fileHandle, this->fileName, "rb"); fseek(fileHandle, 0L, SEEK_END); this->fileSize = ftell(fileHandle); rewind(fileHandle); fclose(fileHandle); return; } unsigned long MyFileHandler::getFileSize() { return (this->fileSize); } const char * MyFileHandler::readFile() { char * buffer = (char *)malloc((this->fileSize)+1); FILE * fileHandle = NULL; fopen_s(&fileHandle, this->fileName, "rb"); fread(buffer, this->fileSize, sizeof(char), fileHandle); fclose(fileHandle); buffer[this->fileSize] = '\0'; return buffer; } VertexShader.glsl
      #version 330 core layout (location = 0) vec3 VertexPositions; void main() { gl_Position = vec4(VertexPositions, 1.0f); } FragmentShader.glsl
      #version 330 core out vec4 FragmentColor; void main() { FragmentColor = vec4(1.0f, 0.0f, 0.0f, 1.0f); } I am attempting to create a simple engine/graphics utility using some object-oriented paradigms. My first goal is to get some output from my engine, namely, a simple red triangle.
      For this goal, the MyShapes class will be responsible for defining shapes such as triangles, polygons etc. Currently, there is only a drawTriangle() method implemented, because I first wanted to see whether it works or not before attempting to code other shape drawing methods.
      The constructor of the MyEngine class creates a GLFW window (GLAD is also initialized here to load all OpenGL functionality), and the myEngine.run() method in Main.cpp is responsible for firing up the engine. In this run() method, the shaders get loaded from files via the help of my FileHandler class. The vertices for the triangle are processed by the myShapes.drawTriangle() method where a vertex array object, a vertex buffer object and vertrex attributes are set for this purpose.
      The while loop in the run() method should be outputting me the desired red triangle, but all I get is a grey window area. Why?
      Note: The shaders are compiling and linking without any errors.
      (Note: I am aware that this code is not using any good software engineering practices (e.g. exceptions, error handling). I am planning to implement them later, once I get the hang of OpenGL.)

       
    • 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