Jump to content

  • Log In with Google      Sign In   
  • Create Account

Lodeman

Member Since 21 Jun 2013
Offline Last Active Yesterday, 05:49 PM

#5184628 LOL - I wrote a poem about OpenGL

Posted by Lodeman on 02 October 2014 - 02:01 PM

I have mixed feelings about this.




#5174923 Resources on level editor creation?

Posted by Lodeman on 19 August 2014 - 11:06 PM

The book "Game Coding Complete: Fourth Edition" has a section that covers setting up a C# level editor for 3D. It shows how to interface with your game engine .dll file (which was made in C++), how you can place objects, etc. I drew from this setup myself and it's worked out well so far!




#5167796 New Earth RPG

Posted by Lodeman on 19 July 2014 - 08:11 AM

Your chickens must lay at least 0.73 eggs per day.
Any less will greatly infuriate your target audience.




#5167057 Help with a really basic indie game!

Posted by Lodeman on 15 July 2014 - 03:32 PM

This reminds me of that cookie clicking game.
A totally unserious game, but still cleary made with an odd form of love for the cookie.

 

You indeed need to specify what sort of help you're looking for though.
Either way good luck with that goofy cat!




#5139525 Debugging Graphics

Posted by Lodeman on 16 March 2014 - 01:26 PM

Don't forget the glValidateProgram function, call this right before you do the drawcalls and write away the output somewhere.
Useful for if your shader linked correctly, but doesn't produce expected output (eg. a black screen of doom).




#5137520 OpenGL performance tips

Posted by Lodeman on 09 March 2014 - 06:59 AM

You should be sorting by texture as a second criterion if shaders match (which would seem to always be your case).


In both cases, setting textures and shaders should be done only through custom wrappers that keep track of the last shader/textures set and early-out if the same is being set again.
And not just shaders and textures but every state change should be redundancy checked. Culling on/off, depth-test function, nothing should be set to the same value that it already is.

 

Ah yes, currently I sort per "mesh". So for example I'll have a few pinetree variants, and I'd first go over pine variant 1 and draw all those instances, then variant 2 etc... As they do share textures, it would indeed be a good move to sort per texture instead of per mesh.
The custom wrapper is also a great suggestion, will make work of that too.

 

A bad render queue is worse than no render queue at all. Did you time it?
Make sure you are taking advantage of per-frame temporal coherence with an insertion sort on item indices.
Do not sort actual render-queue objects and do not use std::sort().

 

I do suppose my current queue, based on per mesh-sorting, is inefficient. To clarify, my current renderqueue is essentially a map<int MeshID, vector<MeshInstance>>
As for how I construct it per frame, I use an octree to do frustum culling. For any mesh instance that falls in the view frustum, I check if it's mesh type is already in the render queue. If so I append the instance to the corresponding MeshInstance vector,if the Mesh type is not yet in the queue, I add a new MeshID to the map.
This queue worked well back when I was only testing instances that didn't share any textures (1 pinetree variant, 1 house, 1 bush, etc...definitely gave a performance boost as opposed to just switching between meshes randomly, I did time this), but is now outdated. So yeah, I'll look into improving this by sorting per texture.

 

Is your shader optimized? Are you reducing overdraw with a render-queue check on depth (following matching shaders and textures)?
Are you doing something silly such as recreating or copying over vertex buffers that are in use each frame?

I am only calling this each frame: glBindVertexArray(s_MeshBuffer.VAO);

So not recreating or copying over buffers.
As for reducing overdraw, could you elaborate on that? I'm not familiar with this.

 

 

No. Use permuations, breaking shaders reasonably between run-time branches and compile-time variants.

Could you also elaborate on this? Currently all my scenery requires the same shader code. They have the same lighting calculations, calculate an optional bumpmap (I use a uniform boolean to check if a bumpmap needs to be sampled),  sample the diffuse texture, sample shadowmaps.
I'd like to have some examples as to when one would really distinguish between using another shader program, or just having a boolean to check if a certain functionality is needed.

 

You don't give nearly enough information to stimulate a meaningful answer.

 

I'm afraid that's because I don't have sufficient OpenGL monitoring yet, I was first trying to make things "work" before sufficiently considering performance. Definitely on the todo list though. Mainly my purpose for this thread was getting general performance improvement tips.
 

To sketch a bit of context, this is the type of scene I'm rendering:
Polygon count for the scenery isn't anything out of the ordinary (although I can't atm give a number), texture sizes depend on the asset, but for example both the bark texture on the tree and the texture on the rocks are 512*512.
Scenery does not have LODs yet (another item on the infamous todo list), terrain however does (terrain performs decently on its own).

eeib.jpg

 

Thanks for the feedback so far.
Cheers!




#5137496 OpenGL performance tips

Posted by Lodeman on 09 March 2014 - 02:28 AM

Hi all,

 

For my engine I need to render a bunch of different meshes, including an alpha pass.
Currently the way I do it is fairly straight-forward:

 

- I have one big vertex and index buffer in which I load in all my mesh data. During the render phase I use this to "instance" my geometry.

- I have frustum culling to neglect scenery that doesn't need to be drawn

- During the update part of the game-loop, I create a render-queue, which sorts the meshes so they can be drawn more efficiently

 

- At render-time, I bind the large mesh-buffer one time before drawing any meshes

- Drawing is done by going through the render-queue. I bind the correct texture_2D_Array for the mesh and I draw the mesh with glDrawElementsBaseVertex. Thus I just pass in the correct index to draw a certain mesh, using one and the same buffer (instancing)

- I disable the buffer at the end of the render loop

- After all opaque objects were rendered, I do the alpha pass in a similar way, also using the big buffer. Although in this case I cannot sort them mesh per mesh, since they are sorted by depth.

 

- I use one and the same shader-program for drawing all these meshes, and only one sampler2DArray at texture index 0. The array contains a diffuse map and an optional bumpmap.

 

I'm finding that with the current setup I'm not quite getting the performance I'd like to get. Therefore I'm hoping to receive some tips on how this sort of mesh-rendering problem is usually tackled by more experienced programmers. For example, is it common-practise to use just one shader-program for rendering all meshes? Or is there a much more efficient way that would remove the need to always re-bind the correct texture when switching between meshes?

 

Any suggestions are very welcome!

Cheers!




#5137489 confused about tangent/bi-tangent in 'normal' mapping...

Posted by Lodeman on 09 March 2014 - 01:43 AM

The TBN matrix consists of an orthonormal basis between the the tangent, bi-tangent and the normal.
You COULD pass in all three to the shader, however it's unnecesarry as you can calculate the bi-tangent as the cross-product from the tangent and normal (orthonormal basis is really the clue here). Therefore it is enough to send in normal and tangent to the shader, and let the shader calculate the bi-tangent.

 

So in conclusion, both are right.

 

Here's the reference I used when implementing normal maps: http://ogldev.atspace.co.uk/www/tutorial26/tutorial26.html




#5135461 Large textures are really slow...

Posted by Lodeman on 28 February 2014 - 02:46 PM

Just adding this in for clarity.

 

Make sure you aren't sending in the uniform for the sampler2D each frame. Just send it in the first time you need it.
I know you said the texture isn't updated every frame, but uploading and updating can mean two different things, hence why I want to make sure this is clear!

 

Cheers




#5113951 Building a Game Engine

Posted by Lodeman on 03 December 2013 - 12:13 AM

Here's the libraries I'm currently using:

- GLM for all sorts of math: matrix, vector, quaternion. I don't see a good reason to move away from it if you're already using this. It offers alot of useful functions.

- Assimp for loading in models (chose the .ase format for now), works very smoothly.

- BulletPhysics for...physics.

- FreeType for font rendering.

- TinyXML2 for saving and loading XML files (data-driven programming).

- I also have my own set of Utility functions that are compatible with these libraries (for example matrix conversions between Bullet and GLM, retrieving Euler angles from Bullet Matrixes, since my rendering uses a different order of rotations, handy functions such as "moveForward(glm::vec3, float amount), etc...).

 

For GUI:

- Windows Forms: I compile my project as a static library, and pop out a .dll file. That .dll file is then read in by a C# application, which in turn uses WinForms for all the GUI stuff for the editor. It's a very handy and fast way to roll out a complex application.

- For "ingame" widgets, I rolled out my own GUI. But I've heard good things about Qt.




#5107272 I'm stuck, haven't gotten any better at programming in months

Posted by Lodeman on 05 November 2013 - 04:01 PM

Watch this:

 

Really, watch it.

 

That is all I have to say on motivation.




#5101930 How do you 'learn' a programming language?

Posted by Lodeman on 16 October 2013 - 02:36 PM

I took a different approach to this.
Reading too much books without doing something you want to do with it can be a source of demotivation.
Therefore, read enough so that you understand the basic concepts such as pointers, vectors, basic data types, object oriented class design, that stuff.
Now take that, and start making a game.

 

As you do this, you will automatically run into problems, which you will then seek to fix. These won't just be design related problems, but some will result as a lack of fully understanding C++. When you tackle this problem, you will learn alot from it. This pattern will repeat and you'll always improve your skills. The most important bit is to never, ever give up. Some problems might be tough, but eventually you will crack it.

 

My starting point was using SDL to make a simple tile-based farming game, I used these tutorials as a reference: http://lazyfoo.net/SDL_tutorials/

Don't expect your first game to be a work of art, both in terms of graphics, nor in terms of game design. But you will learn so much from it, alot of things you shouldn't do.

 

Take it one step at a time, but keep working on something. That's how it worked for me.
Hope this helped!

 

Cheers




#5098900 Guidance for my son...

Posted by Lodeman on 05 October 2013 - 03:49 AM

I think an interesting first step into game programming could be using SDL to program a tile-based game. This would link nicely to the tile-based gameplay he's been used to from RPG maker. To achieve this, first teach him some general programming concepts, read enough C++ tutorials and try to grasp the concept of pointers.
Once that's done, there's plenty of decent SDL tutorials online. One I found particularly useful when I started out with SDL (and C++) was this one:

 

http://lazyfoo.net/SDL_tutorials/

 

Should be a decent foundation to getting acqainted with the game loop and 2D rendering concepts, as well as some basic game entities.
3D game programming would then be the next logical step, but will require alot more time since it relies on more advanced maths/algebra concepts.




#5087121 What language should I choose for beginning game developing?

Posted by Lodeman on 18 August 2013 - 02:58 PM

Hello everyone.


I ask you to give me some advices, based on your experience. What languages you learned? What was useful and you started working with?

What was the biggest barrier and fear?

 

Hi,

 

I've been doing more serious game programming for about three quarters of a year now. I had some Java background, and that was honestly it.
C++ is known for being a tricky language, and it was indeed a bit of a challenge to grasp (and sometimes still throws surprises at you). However it is also the most performant language if you know what you're doing. Therefore I recommend learning the proper game-dev language right off the bat. Along with OpenGL for graphics (unless you're a directX Guru already).

 

The way I started was to first create a mini-project, mine was a simple 2D Rpg styled game, with farming options. It was an ideal project to learn C++ with, and to also already identify design pitfalls. Once I felt comfortable enough with it, and was reasonably satisfied with the features I had, I slowly started to work on my real 3D project.

Some books that I had laying around, or ordered additionally, are:

- Programming an RTS game with Direct 3D (relatively easy to translate to OpenGL)
- Came Coding Complete: Fourth Edition (more of a theoretical work, but has some very good design patterns in it)
A very good OpenGL site that has modern tutorials:

- http://ogldev.atspace.co.uk/

 

The most important thing to do is to not get stuck in over-planning things, jump in and make a game. Your first planning will be a bit messed up anyways, and you won't create the perfect design right off the bat. As you learn more, you'll get more insight into these sorts of things. Then you'll grab a book to complement your experience.

 

Good luck!

Cheers




PARTNERS