Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 20 May 2009
Offline Last Active Sep 11 2015 04:10 PM

#5227589 Best engine for developing a 2D roguelike

Posted by laztrezort on 06 May 2015 - 03:51 PM

Have you looked through the rogue basin articles (http://www.roguebasin.com/index.php?title=Articles) yet?  There are quite a few tutorial/articles for writing an RL in various languages, such as C#: http://www.roguebasin.com/index.php?title=C_Sharp


I've never used those libraries (except for libtcod mentioned above many years ago), but I did roll my own using OpenTK as the rendering backend, using the aforementioned libtcode as an API inspiration.  An older version of my lib can be found here if you're interested (at least until Google Code goes away): https://code.google.com/p/sharprl/.


Note that all of this assumes you are going for a more "old school" roguelike (ASCII or simple tile art, etc.).

#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.

#5076729 Patent trolls attacking small indie developers

Posted by laztrezort on 10 July 2013 - 04:45 PM

The problem is the trolls know the cost/time it takes for someone to get it to court where it can be ruled invalid is huge.  So that's their leverage, it will cost you more to fight it than to simply give in and settle.  Even though they know full well the patent would get blown up at trial.
That's why they are trying to pick on smaller game developers.  They have even less resources at their disposal to fight, so make easy victims.

The tactic of going after smaller businesses seems to have become mainstream lately.  Reading many articles about his, such as here, it is even rampant outside of the software industry.  Too me it appears to be nothing more than extortion that is somehow legal.  It's amazing to read about the various tricks (shell companies to hide their interests, playing the courts, etc.) these companies get away with.


It appears you did the right thing in not just immediately rolling over, and even better alerting others about the issue, but it seems like only patent law reform is going to help keep this type of thing from happening. There has at least been a lot of talk about reform - not sure about action.

#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