• 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
JavaCoolDude

OpenGL
OpenGL GUI anyone? Updated on 11/17/05

207 posts in this topic

haha yes OpenGUI is good. when i thought of this working with openGL. i came up with OpenGUI. it just makes sense, such as OpenAL for audio, or OpenTNL for networking. and OpenGUI would of course for gfx user inteface. the word OPENx usually gives people an impression that its OpenGL releated.
0

Share this post


Link to post
Share on other sites
OpenGUI has already been used http://www.tutok.sk/fastgl/
0

Share this post


Link to post
Share on other sites
Forgive me, but the word "Open" usually indicates to me that it's an open source implementation of something closed; OpenBSD, OpenMOSIX, OpenSSH, OpenMotif (for those old enough to remember), etc.

Hell, OpenGLUI would even better express that it's a UI and using OpenGL, but that even sounds like letter soup to me.

Who knows?
0

Share this post


Link to post
Share on other sites
OpenGLUI or plain GLUI sounds good to me, ciroknight, sorry for the delay in responding to your email, do you mind if I answer your suggestions right here?
I'd like to have a max number of people reviewing them to make sure we're on the right track.
BRB, I need to clean up my place [wink]
0

Share this post


Link to post
Share on other sites
Don't mind at all, spent most of the day reading harry potter (shameful secret someone my age)...

I just sent an email because, well, it is your code.. kinda a politeness thing.
0

Share this post


Link to post
Share on other sites
Quote:

If you've read my earlier posts, you'll see that I've been maintaining
two different path ways of doing the move to TinyXML:

1) Modifying the IOXMLObject and the XMLParser class to make calls
directly into TinyXML. This is ineffecient (ends up with functions
that's entire purpose is to call other functions), but it effectively
hides TinyXML from the user, and is very unobtrusive to the project as
it stands.

2) Replacing both classes with a class called XMLArbiter; XMLArbiter
accesses TinyXML once per session, running through the entire XML
file, grabbing all of the objects, and loading them into STL
containers. While this approach takes more memory, it allows for a lot
more flexibility within the project; for example with this setup it
should be entirely possible for the object to check to see if the file
has been modified, and if it has, reload the file, and immediately had
the new information available for the GUI. This would be helpful for
the editor type program we discussed on the forum. The disadvantages
are that this class is not small; it's a monolithic solution to the
problem, and if, for example, we want to add more GUI elements, you'll
have to modify this class to be able to deal with it. One way to deal
with that, of course, is to make the interface pluggable, but I think
that the configuration files should be small enough not to warrant
doing this. (How the (&*#^$ could a configuration file be heavy enough
to warrant this?!)


Quite frankly I’m more lenient towards the second solution, if you don’t have something pretty far advanced I would also like to attempt porting the project to using TinyXML myself.

Quote:

<With the latter, I've went ahead and made some simple modifications to
the XML format the window loader would be using;
===GUIConfig.xml===
<config>
<Window visible="true" name="Window a">
#top/bottom are just temporary names, don't ask me what they really
#should end up being. I'm sure you can find a more technical name ;)
<position topx="" topy="" bottomx="" bottomy=""/>
<color type="bgcolor" r="" g="" b="" a=""/>
<color type="fontcolor" r="" g="" b=""/>
<color type="bordercolor" r="" g="" b=""/>

<texture type="TEXTURE_2D" path="opengl.jpg"/>

While I totally dig the new color tags, I’m opposed to the way the position and dimensions of widgets is handled.
See in my approach a position that ranges from 0.01 to 1 implies that the current widget anchor point will be placed within the parent panel according to that ration. For example 0.5 coupled with anchor point set to “CORNERLU” implies that the widget upper left corner must be position in the center of the parent panel at any given time.
Also the dimensions and positions of widgets are not always fixed, I have this set of functions “pack” that scans through the children of a panel and adjusts their position dimensions. Combining the “position” and “dimension” tags will create a heck lot of confusion therefore for now I would like to stick with the old convention

Quote:

<panel>
#panel should adhere to the same system as window.
#positions of panels should be relative to the window.
<position topx="" topy="" bottomx="" bottomy="">
<color type="bgcolor" r="" g="" b=""/>
<color type="fontcolor" r="" g="" b=""/>

<texture type="TEXTURE_2D" path="panelbg.jpg"/>


</panel>

<tabpanel name="Hah">
<panel name="Panel 1" index="1">
<position topx="" topy="" bottomx="" bottomy="">
<color type="bgcolor" r="" g="" b=""/>
<color type="fontcolor" r="" g="" b=""/>
<texture type="TEXTURE_2D" path="panelbg.jpg"/>

<button callbackName="TP1Button1">
<color z = "255" x = "0" y = "0" />

<text string = "Blue Button" />
</button>

<button callbackName="TP1Button2">
<texture type="TEXTURE_2D"
filename="buttons/buttona.png">
<texcoordsdesc xstart="" xend=""
ystart="" yend="" type="BUTTON_FACE"/>
</texture>
</button>
</panel>
<panel name="Panel 2" index="2">

</panel>
#etcetera.
</tabpanel>

</Window>

<Window visible="true" name="Window a">
</Window>
</config>

==(Fonts.xml)==========
<fontlist>


</fontlist>

==(guitextures.xml)=======
<textures>
<Texture filename="texture.png" type="TEXTURE_2D"
mode="modulate" mipmap="true">
<TexCoordsDesc xStart = "201" yStart = "2" xEnd = "233"
yEnd = "34" type = "SLIDER"/>
<TexCoordsDesc xStart = "167" yStart = "2" xEnd = "199"
yEnd = "34" type = "CHECK_BOX"/>
<TexCoordsDesc xStart = "131" yStart = "1" xEnd = "165"
yEnd = "35" type = "CHECK_BOX_MARK"/>
<TexCoordsDesc xStart = "1" yStart = "1" xEnd = "65"
yEnd = "66" type = "RADIO_BUTTON"/>
<TexCoordsDesc xStart = "66" yStart = "2" xEnd = "130"
yEnd = "66" type = "CHECK_RB_MARK"/>
<Wrap s = "REPEAT" t = "REPEAT" />
<Filter mag = "LINEAR"
min = "LINEAR_MIPMAP_LINEAR" />
</Texture>
</textures>
========================
Of course, the above is only a quick example of what the new layout
would look like. Personally, I really don't like chain-loading XML
files to get the whole interface, and this will be helped by having a
GUI editor tool, and the interfacing being consistant and reliable.
Making everything a child of "config" instead of a child of "panel"
removes the requirement that everything is a panel. Adding "window"
allows for the ability to close and restore the windows at leisure. I
also think it should be possible to move the initial textures (the
ones that draw widgets) to their own file. Font's should follow the
same; "game.xml, fonts.xml, guitextures.xml". This makes it more clear
to the developers. You can include the fonts and guitextures in the
initial file as well, but I think there's enough to warrant moving
them outside (well, maybe fonts and guitextures can be combined to
"guielements.xml" or something).

Adding a window class is part of my plans for future releases. Actually I have a beta version of this GUI package that implements them and allows the user to drag em around in the main rendering canvas.
It’s a pretty neat thing I must say.

Sorry I have to go now but I will come back later to address few other points
0

Share this post


Link to post
Share on other sites
Quote:
Original post by ciroknight
Forgive me, but the word "Open" usually indicates to me that it's an open source implementation of something closed; OpenBSD, OpenMOSIX, OpenSSH, OpenMotif (for those old enough to remember), etc.

Hell, OpenGLUI would even better express that it's a UI and using OpenGL, but that even sounds like letter soup to me.

Who knows?


yeah actually openGLUI doesnt too bad, nor does GLUI. i would go for openGLUI, makes you think of opengl more.
0

Share this post


Link to post
Share on other sites
Yeah, you can take OpenGLUI name, since I have OpenGL GUI, OpenGL GUI @ http://openglgui.sourceforge.net, so there will be no problem mistaking those two :)
0

Share this post


Link to post
Share on other sites
Well then.. I'd say we'd better jump on our "OpenGluey" mess and get ourselves an SF project tonight; I'll check my code in so you can see how far I've gotten (a long way, but I've still got a long way to go, too). I can have a better estimate later after I get everything in.

Oh, and HellRizzer, thanks for the heads up; I was wondering if that project was still alive.. You're free to jump on to help us out as well, if you so choose... we're using a much more liberal license (zlib), so that might be a turn-on or a turn-off depending on how professional you are, but I thought I'd at least lend out the hand.

By the way, I was kinda wondering how we wanted to do nesting; the way I have the XMLArbiter class implemented right now, it's possible to put a tabpanel inside a tabpanel as deep as you want to go, as long as they all belong to a window object, and as long as they all belong to a panel object, even if that panel is just the previous' tabpanel's first panel. Same goes for an ordinary panel object. Should we put an arbitrary stop on how many layers deep an object can go?

Also, I've been working on a list of elements we should have by Feature Freeze for version 1.0, and I'll post that when I upload my source to the CVS server later tonight. Lots of wild ideas for that one :-).

And has anyone built the latest source under linux and noticed that the letters are oddly fuzzy, or is that my graphics card being stupid again?
0

Share this post


Link to post
Share on other sites
go for openglui definetly then, if glui has been taken. might want to take it soon before someone else takes it lol.
0

Share this post


Link to post
Share on other sites
how do you change the GUI while running the program. like from GUI.xml to GUI2.xml, but deleting the first one??
0

Share this post


Link to post
Share on other sites
Hey JavaCoolDude,

2 questions, 1 comment.

Comment-
Love your work, looks fantanstic. I have been playing with GLGOOEY, but Im thinking yours is cleaner and simpler.

Question 1)
Can your panels/windows be made to be dragable or are they already?

Question 2)
Could your panels be made to play a quicktime (.mov) or any other type of movie format?

Im working on a project that requires a movie/flash to be displayed in a portion of a panel. One example is the left corner of the panel 200x200 runs a movie and the other portion of the panel has controls on it.

Thanks for your time!

Brian

0

Share this post


Link to post
Share on other sites
Question 1)
Can your panels/windows be made to be dragable or are they already?


I experimented with that for a bit in an unreleased version and I came accross some issues caused by the way I'm packing the widgets tightly into the parent panel.
I might give it another go sometime later (after SIGGRAPH)

Question 2)
Could your panels be made to play a quicktime (.mov) or any other type of movie format?


Sure thing, after you load your GUI frame into your program, seek your target Panel (or textured button for that matter) by using the function, getWidgetByCallbackString. After getting a pointer to your widget, simply use the setTexture function where your argument is a Texture object playing your movie.

[smile]
0

Share this post


Link to post
Share on other sites
just wondering, if you can release the source code for the lib files. i want to see if i can port this code to the psp or the ps2. also can you post a sample of how to play movie clips in the gui frames. and what file formats can be played?
0

Share this post


Link to post
Share on other sites
I don't have the source for the png libs, you can google it out though.
Same goes for the tinyxml stuff.
I guess I can write a quick demo that plays an mpg or wmv file into a GUI panel, let me see what I can do :P
0

Share this post


Link to post
Share on other sites
cool let me know when you got a sample up. Also. for this gui. if i wanted for say get this gui to read txt from a file can that be done? such as a dialog box where you usually see in an rpg, or a game. with mutiple lines of talking.
0

Share this post


Link to post
Share on other sites
Very cool project.
Grats to JCD.

I changed 0.8 a bit so the combobox uses a slider control to scroll entries instead of them going past the bottom of the window when there are too many and wrapped all the IO in Hans Dietrich's XUnzip (http://www.codeproject.com/cpp/xzipunzip.asp). Had to recompile glpng since it uses STDIO and doesn't accept a buffer pointer. Works great now loading everything from a zip to memory and not using any temp files for the PNGs. Makes redist 4 a small win32 app a lot cleaner.

Currently working on merging parts of SXMLEngine with it to try and get FireText into the modded 0.8.

Overall it's a really nice project. Needs a TextArea though. Is it up on SourceForge yet? All the names suggested all sound the same, nobody will ever google it they'll just find someone else's project. It should go up as sxml_gui or some unique sounding name that wont be confused.


0

Share this post


Link to post
Share on other sites
Sorry for the lack of updates everyone; I'm truly busy at the moment and I can barely squeeze some time in to check my email let alone do any side work.
Anyone can feel free to setup a sourceforge project and put all of the files we had so far up there, like I said before all my work is for this community [smile].
I should be releasing a new demo tomorrow which would be my very last GL project, after that I will try and give this GUI package a little more attention, at least till we get to the 1.0 version.
Implementing a text area seems like a neat idea, I'll look into that :)
0

Share this post


Link to post
Share on other sites
My computer back home is broke, I'm putting a new rig together sometimes tomorrow night. Please wait until then, thanks for your patience [smile]
0

Share this post


Link to post
Share on other sites
not sure how relevant this is to this thread, but for you guys doing UI in openGL it might be worth to look at our gui we did for vsx ultra (which is free).
this is my own thoughts on how a gui for this type of program should be and is most likely not applicable on other kinds of software.. although we've done quite a few widgets, buttons, labels, edit boxes, code editor with syntax highlighting etc.

Vovoid VSX Ultra

when the framework is a bit cleaner and so on we might release the code for the UI..
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 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
    • By afraidofdark
      I have just noticed that, in quake 3 and half - life, dynamic models are effected from light map. For example in dark areas, gun that player holds seems darker. How did they achieve this effect ? I can use image based lighting techniques however (Like placing an environment probe and using it for reflections and ambient lighting), this tech wasn't used in games back then, so there must be a simpler method to do this.
      Here is a link that shows how modern engines does it. Indirect Lighting Cache It would be nice if you know a paper that explains this technique. Can I apply this to quake 3' s light map generator and bsp format ?
  • Popular Now