Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 20 May 2009
Offline Last Active Yesterday, 06:43 PM

#5123377 question about sending ram->vram each frame

Posted by laztrezort on 13 January 2014 - 03:33 PM

Technically, most of the answers to your question depend on what you are doing - but for efficiency, it's better to limit transfering from client to server (or vice versa) as much as possible.


Really, I suggest going through some tutorials, look up "modern OpenGL tutorials" or similar.  Make sure the tutorials are "modern" or at least version 3 or later.  For example, this one http://www.opengl-tutorial.org/ seems good, I believe it was one of the tutorials I skimmed through it when moving from XNA to OpenGL a year or two ago and found it helpful.


After you get the basics, going through the OpengGL wiki is helpful on the nuts & bolts aspects of OpenGL.

#5120829 Performance problems at ~1,000,000 triangles. Am I doing something wrong?

Posted by laztrezort on 02 January 2014 - 09:09 PM

Merging textures into one (or as few as possible) larger textures (usually called a "texture atlas") is a standard technique, precisely so the number of draw calls can be reduced.  You just need to give each vertex an appropriate texture coordinate.  Same thing can be done with other material data - the more you can reduce the number of calls, the better performance you will see.  This is the most important optimization you can probably make at this point.


I believe dpadam450 was referring to the same thing with "batching."  This is basically just putting as many vertices in a VBO as you can, to reduce the amount of state changes and draw calls.  In fact, a good amount of rendering optimization is based around sorting data intelligently into batches.


Million triangles is nothing for any modern hardware - as long as you are not making thousands of separate draw calls.  You will find that the difference in rendering speed between batching vs. not-batching is huge.

#5120787 Performance problems at ~1,000,000 triangles. Am I doing something wrong?

Posted by laztrezort on 02 January 2014 - 04:59 PM

For the OP:


I assume you are attempting something like shown in this tutorial: http://en.wikibooks.org/wiki/OpenGL_Programming/Glescraft_1


If so, go through that and the following pages and see how they handle rendering.  Notice that they build an entire chunk (16x16x16 or whatever) of cubes all at once an put them in a VBO, and draw each chunk with one draw call.  You can optimize even more (and reduce z-fighting and artifacts when you get to doing lighting) by not building faces that are adjacent to opaque blocks.  Only rebuild chunks when something has changed.


Doing what is shown in that tutorial, you can render a very large amount of cubes without any problem.  Unless I'm misunderstanding something, I don't think instancing is going to help at this point.

#5116383 API's or low-level programming

Posted by laztrezort on 11 December 2013 - 08:13 PM

"Professional looking" games can be made using just about any level of abstraction, ranging from DirectX to GameMaker or Unity.  The more critical factor, I think, is having a professional art team at your disposal ;)

#5094021 Your opinion on C# graphical libraries

Posted by laztrezort on 14 September 2013 - 10:52 AM

I am not familiar with alternatives (although I hear monogame is good), but xna is a good place to learn 2d / 3d programming or at least a quick way to get set up.


I would second this for someone wanting to ease into learning 2d/3d.  Contrary to what you will probably hear, XNA is not "dead" - while it is not being updated anymore, it works just fine and there is an enormous amount of tutorials and other resources available.  Furthermore, it nicely primes you for moving on to lower level APIs.  Also - it's easy to get something working quickly, and therefore easy to stay motivated.

#5026178 Sprite batching and other sprite rendering techniques

Posted by laztrezort on 27 January 2013 - 02:45 PM

Just call glBufferSubData once when a batch is ready to be drawn, specifying the count or whatever parameter it is to set the amount of data to upload, and only draw the number of vertices (or indices if using draw elements) you need for the current batch.

The index buffer can be predifined, and will not change.

Here is some C#-ish pseudocode from a project of mine that outlines what I do:
spriteVertex[] vertices = new spriteVertex[BATCHSIZE * 4];
int[] indices = new int[BATCHSIZE * 6];

MakeBuffers(ref vertBufferID, ref indBufferID, ref vaoID);

// fill the buffer with default (0s) on creation
glBufferData(BufferTarget.ArrayBuffer, sizeof(spriteVertex) * vertices.Length, vertices);

// fill index buffer with pre-calc'd values


class TileBatch
  public void Begin(Texture2D texture)
    currentSprite = 0;
    currentTexture = texture;

  public void Draw(Rect dest, Rect src, Color color)
    // if we are out of room, flush (draw) the current batch
    if(currentSprite > BATCHSIZE)
      currentSprite = 0;

    // calc all the vertex attributes for this sprite and store them in our CPU array
    int vertStart = currentSprite * 4;
    vertices[vertStart].position.X = dest.X;
    vertices[vertStart].texcoord.X = src.X;
    vertices[vertStart + 3].position.Y = destRect.Bottom;
    vertices[vertStart + 3].texcoord.Y = src.Bottom;

  public void End()

  private void Flush()
    // set program uniforms and state
    shaderProgram.Texture = currentTexture;
    shaderProgram.mvpMatrix = currentMVP;

    int numberToDraw = currentSprite;

    // upload our CPU vertex data to GPU
    glBufferSubData(BufferTarget.ArrayBuffer, 0, sizeof(SpriteVertex) * numberToDraw, vertices);
    // draw the appropriate number of sprites
    DrawElements(BeginMode.Triangles, numberToDraw);

In use:

MyBatch.Draw(Rect(0,0,32,32), Rect(50,50,32,32), Color.White);


#5025676 Sprite batching and other sprite rendering techniques

Posted by laztrezort on 25 January 2013 - 11:43 PM

The simplest(?) batching method that I understand is using a GL_STREAM_DRAW VBO that gets the vertex data of all sprites with a glBufferData call each frame, possibly using an additional GL_STATIC_DRAW VBO with all the sprites that I know are static and persistent.

Pretty much, just process and store the vertices CPU side until ready to draw. Then send the proper state and the vertices to the buffer and draw.

Use glBufferSubData though - from what I understand, glBufferData destroys & re-creates the buffer each time with an overhead cost.

Would sprite batching be significantly more performant than my unit-quad VBO approach?

Probably - reducing the number of separate draw calls is generally a very effective optimization. If you are having performance issues, this would definitately be the first thing to try.

With a simple batch similar to above, written in C# and using OpenTK, and without any real optimization, I can easily get many thousands of sprites on the screen each frame with plenty of both CPU & GPU to spare for other tasks.

#5024148 Dungeon generation method

Posted by laztrezort on 21 January 2013 - 08:32 PM

Just spit-balling here:

Looking at your example, it looks like a rectangle based generation (BSP tree or other) - but with random regions (leaf nodes) joined together. Perhaps you can get the same affect with a second pass over a BSP generated dungeon, joining random regions (within size constraints)?

Also, I'm not really sure if this is applicable here, but it might be worth experimenting with: http://doryen.eptalys.net/articles/dungeon-morphing

Perhaps you could "lerp" a type of pseudo-random noise with a BSP dungeon to get something like this.

#5016995 Small Novice Dev Group looking for advice.

Posted by laztrezort on 03 January 2013 - 12:17 AM

My opinion:

C# (and later, XNA) would be a fine place to start. Between the tools, the language and the amount of info available, C# is fairly enjoyable to work with. XNA itself also lends itself to relatively quick development.

I do not know of any specific beginner books (see below for a link), but generally it is advised to ignore all those "Learn XXX in YYY days" types of fast-track books - get the basics of the language down first. No need to jump straight into graphics, maths etc. before learning general programming concepts and a bit about the specific syntax & usage of C# itself. Your first game(s) will likely be text-based and very simple.

There is a huge amount of info, tutorials and sample code available for C# and XNA, which will come in handy as you progress.

And, of course this site is also a great resource, there are some very helpful people here. Here you might find a starting point for beginner books ideas: http://www.gamedev.net/topic/626106-c-books/

There are many other "getting started in C#" threads here if you poke around some.

It sounds like you have realistic goals, which will help greatly in not becomming discouraged too soon. So you are already on the right track.

Good luck!

#5009300 creating random rectangles to cover a grid

Posted by laztrezort on 10 December 2012 - 09:50 PM

The simplest way I can think of (that I've personally used in the past) is to use Binary Space Partition - where you split the rectangle down recusively until you have the desired number of sub rectangles.

This describes the method as used in procedurally generating a 2d dungeon:

#4980942 C# List<T>.Find

Posted by laztrezort on 17 September 2012 - 10:56 AM

Wild guess, but do you have the required using statements?

using System.Collections.Generic;
using System.Linq;

#4980161 What is the optimal way to store a tile based world in an array?

Posted by laztrezort on 14 September 2012 - 02:10 PM

What I have done in the past, is store an identifier in each cell, which can be used to lookup data about that terrain type from a database of terrain types. Then use the terrain data to draw, check movement, or whatever else.

Something like this (pseudocode):

class Tile
	 int TerrainIndex;
class TerrainType
	 Image image;
	 bool IsWalkable;
List<TerrainType> TerrainTypes...
DrawTile(Cell cell)
	 Image img = TerrainTypes[cell.TerrainIndex];

Thinking of cells as "just data" in this way should eliminate the need for switch cases or messy inheritance. This also allows you to keep the terrain data separate from implentation, say in a text file, that can be tweaked outside of diving through layers of code.

Differentiate between "static" and "dynamic" data. Static data can go in the database, it will not change on a per-cell basis. Dynamic data (state) can change from cell to cell, thus needs to be stored for each cell. Example of possible static data: movement blocking, sprite image, flags such as causes_damage or is_transparent, etc. Examples of possible dynamic data: per cell light level, damage level, etc. There is no hard rule for which belongs where - it depends on the gameplay, how the rendering is set up, etc.

#4980039 floating point precision problem

Posted by laztrezort on 14 September 2012 - 07:03 AM

I was wondering if using decimal here would be preferable?

AFAIK, Decimal is used mainly for financial calculations - i.e. I believe it works best for base 10 numbers in a relatively limited range, and even it will not be infinitely precise of course.

Here is an article with some basic tips on using floating point: http://www.codeproje...int-Programming

#4979805 What are the most important things that should make me consider moving to C++?

Posted by laztrezort on 13 September 2012 - 12:48 PM

I'd agree with Telastyn, except for maybe adding "just for the sake of learning it" to the list. Keep in mind that going from C# to C++ you will generally see a massive reduction in productivity. This is even ignoring the time it will take to pick up C++. The only time I have seriously gone back to use C++ in the last 6 or so years is when someone paid me to - and they paid me by the hour.

Going from XNA to DirectX, you will see yet another massive reduction in productivity. This is not meant to discourage, but keep this in mind if your goal is to get a specific project finished, you will need to choose for yourself depending on what your goals are.

#4978470 The "best" OpenGL/.NET wrapper?

Posted by laztrezort on 09 September 2012 - 09:50 PM

As far as I know, there are only two viable choices, Tao and OpenTK. Recently I threw together a minimal 2D rendering backend using OpenTK, at the same time learning (modern-ish) OpenGL. Can't say I had any issues with the wrapper, although be aware there are newer nightly builds available.

I looked briefly at Tao, but it looked a bit too thin of wrapper for what I wanted, and doesn't look updated much anymore.

From the OpenTK homepage they claim it supports the latest versions of OpenGL, though I only used a small subset of OGL, and have so far only built/tested under Windows.