Jump to content
  • Advertisement

josiahpeters

Member
  • Content Count

    5
  • Joined

  • Last visited

Community Reputation

102 Neutral

About josiahpeters

  • Rank
    Newbie
  1. josiahpeters

    SIMPLE OpenGL rendering question?

    Could you post some code on how you are rendering the blocks? Are you drawing each vertex separately like below? glBegin(GL_TRIANGLES); // Drawing Using Triangles glVertex3f( 0.0f, 1.0f, 0.0f); // Top glVertex3f(-1.0f,-1.0f, 0.0f); // Bottom Left glVertex3f( 1.0f,-1.0f, 0.0f); // Bottom Right glEnd(); // Finished Drawing The Triangle If so you could speed your framerate by looking into Vertex Buffered Objects. If you are already doing VBOs try looking at this Wikipedia article on [font=sans-serif][size=2]hidden surface determination to get an idea of some of the more common algorithms.[/font]
  2. josiahpeters

    Level/Scene Editor Woes

    So this is a lot of code still, but it might make things a little more bearable. I'm going to try wrapping my unmanaged class with managed properties and see how this goes. At least it compiles, I haven't tried it with my windows form app to see if it actually works but this makes me feel a little bit better. Since I have already written a small code generator, I can try an implement this on a single class and if it works adjust my generator to spit out code for all my other classes. At the very least that would save most of the typing. class PxVec3 { public: float X; float Y; float Z; }; ref class ManagedPxVec3 { PxVec3* vec; public: ManagedPxVec3() { vec = new PxVec3(); } ManagedPxVec3(PxVec3* _vec) { vec = _vec; } property float X { float get() { return vec->X; } void set(float value) { vec->X = value; } } property float Y { float get() { return vec->Y; } void set(float value) { vec->Y = value; } } property float Z { float get() { return vec->Z; } void set(float value) { vec->Z = value; } } }; Does this seem like a terrible plan? *EDIT* I have experimented with a PropertyGrid and it seems to work. The unmanaged data gets manipulated directly! Now on to wrapping my head around this more. At the very least I can call something like this: Vec3* vec3 = new Vec3(); propertyGrid1->SelectedObject = gcnew ManagedVec3(vec3);
  3. josiahpeters

    Level/Scene Editor Woes

    I have been working on an EntitySystem engine for the last couple of months in C++ and OpenGL. They are described in a few places: T-Machine post, Ember (In ActionScript), Entity Systems Wiki. I've gotten to the point where I can run around on a height map, jump up and down, interract with physics. My next goal for the project was to create a level editor. I really wanted to use .NET Windows forms because they're fast and have a lot of functionality. I also have most of my experience in C#. I started off using C# with the idea that I would just write everything to a file and have my game engine read that in. I started getting frustrated by the amount of code I would have to re-do. I would essentially have to write serialization code for C# and C++ as well as duplicate the rendering code in C# and C++. I ditched that after a few hours of setting up OpenGL and thinking there had to be a better way. I started looking at Managed C++ and .NET Forms with C++. At first it was not bad at all, the syntax was a little confusing but I got around that. I had OpenGL rendering on my form and things were looking snappy. .NET Windows Forms has a really sweet control called PropertyGrid. It basically uses reflection to automatically display a list of editable properties for an object. Example classes: [TypeConverter(ExpandableObjectConverter::typeid)] ref class ManagedTransformComponent : public ManagedComponent { public: property ManagedPxVec3^ Position; property ManagedPxQuat^ Rotation; } [TypeConverter(ExpandableObjectConverter::typeid)] ref class ManagedPxQuat { public: property float X; property float Y; property float Z; property float W; }; ... PropertyGrid makes it look like this (the right side): The problem that I am running into again is duplcation of code. My engine is written in regular C++. The level editor is written in Managed C++. To handle the back and forth I've written Managed copies of each of my classes. I've also written static methods on each managed class to convert itself back and forth between managed and unmanaged. After fine tunning the code a little bit at a time and then having to copy it to every managed and unmanaged class I wrote a little code generator that reads a list of classes and properties and generates my Managed classes with methods to convert between the two sets of classes. Even with those capabilities I still havent figured out or decided how to take Managed objects and values and update the OpenGL view at the same time. I have a pretty good feeling that I am going about this all wrong. I want to write my game engine in C++ and I really enjoy .NET Windows Forms, is there a better way to bridge a level editor in between? Would it make more sense to create some sort of API for my engine that I can call from C#? Should I be doing something different entirely? I've gotten to a point where I can't wrap my head around how to integrate all of this into a level editor and its really frustrating me. I literally couldn't fall asleep last night because my brain would not stop thinking about it. There was a similar post on here but most of the suggestions were to use Qt instead. Is it really worth all the time I'll have to spend tolearn using Qt? What do professionals do for their editing tools?
  4. I had not seen this yet, thanks! *EDIT* So I decided to do a few things differently. First of all I was coding my input callback all wrong. Before I was calling glfwGetKey(GLFW_KEY_LSHIFT) inside of each key callback, see below: void GLFWCALL OnKeyPress(int key, int action) { if(glfwGetKey('W') ) { eventData data(eventType::CHARACTER_MOVE, moveableCharacter); EventSystem->TriggerEvent(eventType::CHARACTER_MOVE, &data); } } Instead of looking up the key in the call back like I was doing, I am now using the key code provided by the callback, as below: void GLFWCALL OnKeyPress(int key, int action) { switch(key) { case GLFW_KEY_SPACE: state = JUMPING; stateOn = action; break; case GLFW_KEY_LSHIFT: state = SPRINTING; stateOn = action; break; case 'W': state = MOVE_FORWARD; stateOn = action; break; case 'S': state = MOVE_BACKWARD; stateOn = action; break; case 'A': state = MOVE_LEFT; stateOn = action; break; case 'D': state = MOVE_RIGHT; stateOn = action; break; } } That article helped me wrap my head around not having the input system drive my character directly. There was a little too much typing to do to implement their system, so I went with a simpler approach. On each keypress I pass a character state and a bool value of whether the state is on or off. This gets fired as a MOVE_CHARACTER event. My character system then updates the state for the character, turning on or off different states. Meanwhile my update statement reads the various states and whether they are on or off and does the moving of the character depending on the states. This means I can be jumping, sprinting, moving forward and strafing left all at the same time. I still intend on following through with reading character mappings from a file and mapping them to various actions, I'm just not there yet. That article was very useful, thanks for that again!
  5. Hey everyone, this is my first post after lurking and reading for a while. I am a web programmer and started learning graphics / game programming with C# and XNA a while ago. I have never released anything but have made a few useless "tech demos." I have been learning C++ recently and decided to tackle making a little game with Open GL. I am using GLFW as my window library and things have been going relatively smoothly thus far. My question is about how I am handling input. Right now I fire an event to my character system telling it to move the character every time a keypress is detected. This works great for one key being held down. It also works for two keys being held down. However once I let go of the second key while the first key is still held down, GLFW stops calling back my keypress call back function each frame until I let go of the key that is held down. Example: 0 seconds - Hold W key to start walking forward keypress function is called back, w has a value of 1 5 seconds - W key is still held down still walking forward keypress function is called back, w has a value of 1 10 seconds- W key is still down, now hold Left Shift Key down still walking forward, but now at 2x speed because of the shift key being down keypress function is called back w has value of 1, shift has value of 1 15 seconds - W key is still down, let go of the shift key - no longer moving forward keypress function is called back w has value of 1, shift has value of 0 - indicating key was let go 15.1 seconds W key has been down the whole time no movement since letting go of the shift key no callbacks on my keypress function 20 seconds W key has been down the whole time no movement since letting go of the shift key no callbacks on my keypress function 25 seconds let go of W key keypress function is called back w key has a value of 0 - indicating key was let go Below is some code from my callback function that GLFW calls on a keypress: void GLFWCALL OnKeyPress(int key, int action) { if(glfwGetKey(GLFW_KEY_LSHIFT) ) { eventData data(eventType::CHAR_SPRINT, moveableCharacter); EventSystem->TriggerEvent(eventType::CHAR_SPRINT, &data); } if(glfwGetKey('W') ) { eventData data(eventType::CHAR_FORWARD, moveableCharacter); EventSystem->TriggerEvent(eventType::CHAR_FORWARD, &data); } // ... more of the same } First, is this how GLFW is supposed to work and am I going about this all wrong? Should I be manipulating the character through triggering events or should I have a character state that gets altered by the events such as WALKING, IDLE, RUNNING, etc... Or, is this a bug in GLFW? TLDR: GLFW reports a keypress event for the W key each frame it is held down until I press a second key while still holding W down. A keypress event is reported when I let go of the key but nothing happens in between. Thanks for looking at this!
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!