Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 16 Jan 2012
Offline Last Active Yesterday, 08:36 AM

Posts I've Made

In Topic: Using VBOs for dynamic geometry

05 July 2014 - 02:31 PM

You don't actually need to invalidate the VBO when using GL.BufferData(). Inputting new data already does everything you need. If you want to use the invalidating you need to use GL.MapBuffer(). More on the subject here -> http://www.opentk.com/doc/graphics/geometry/vertex-buffer-objects.

Also if you are rendering the buffer that you just updated then the potential speedup of using multiple buffers goes to waste seeing as the drawarrays has to wait for the datatransfer to complete before starting to do the actual rendering in wich case you might aswell use a single buffer. You need to update the data of the buffer that is going to be rendered next frame instead. Besides multibuffering VBO:s isn't usually going to give you much anyways as the bottleneck is most of the time somewhere else.


Most times when gfx programmers talk about double or triple buffering what they mean is that they have two or three "screens" to wich they do all the rendering and in case of double buffering they swap the buffers after all rendering to the current frame has been completed. And in triple buffering they swap the two background rendering buffers after rendering is finished and swap the currently not in use rendering buffer with the displayd buffer when the monitor has finished presenting the buffer.


Be careful of overoptimization. What you should do is set yourself a goal fps. And only start optimizing if you get below that fps. Anything above it shouldn't matter at all. If you want 60+ fps, you add a feature and your fps drops from 200 to 120 just shrug it off and continue adding the next feature. And always start with the easiest optimizations first as they are more likely to take less time to implement and over half the time it will get you above the target fps.


Edit: oh and before you start to optimize anything profile the damn thing thoroughly so you avoid using tens of hours optimizing the part that takes 0.01% of the actual process. Use http://msdn.microsoft.com/en-us/library/system.diagnostics.stopwatch.aspx to measure the time it takes on "your" end of the process on different parts of the program. And GL.BeginQuery(QueryTarget.TimeElapsed,...); and GL.EndQuery(QueryTarget.TimeElapsed); to measure the time it takes for the driver and the gpu to perform the tasks that were issued between them.

In Topic: Using VBOs for dynamic geometry

01 July 2014 - 10:17 AM

Creating a pool and resizing is a good idea. However there is another problem I'm facing when I use VBOs:

I'm currently using a List to store vertex data and render them as described above. This is very comfortable, because I can add/remove vertices from the list every frame. The downside is that rendering a huge amount of vertices takes ages. So VBOs are much faster for rendering, but a lot of flexibility is taken away, because now I need to use arrays to store vertex/index data. With VBOs I have to build a new vertex/index/normal buffer whenever the geometry changes and in my case, this can happen every frame. I know that this is not a VBO/OpenGL problem per se, but maybe someone has good ideas to solve that.

Your code looks like c# so I'm assuming you haven't looked at the list.ToArray() function wich is almost free so you can GL.bufferdata(list.toarray,count). Also you don't need to generate new buffers. Just update the old ones.

In Topic: Fantasy Guild Management Sim

22 April 2014 - 08:35 AM

Have you ever tried the ogre battle series. It had an intresting take on the combat where you couldn't directly control any of the characters but nstead you chose the strategy they used. For example you could set the strategy to kill lowest hp first, party leader first, strongest attacker first etc. Then the combat just happend on its own.


I suppose management games aren't that popular but I certainly would play a fantasy guild managament game.

In Topic: 2-D game, rectangular hitboxes, and diagonal movement hit detection

22 April 2014 - 07:37 AM

For some reason I can't see the attached image? So sorry if this is of no help.

I'm going to assume all of your BG blocks are in a uniform grid(aka each and every block is exactly n pixels apart and there can be empty block between that are each n pixel wide)

You can march through the grid by doing the following.

From the corner that is closest to the direction you are moving(bottom right if you are moving down and right, top right if you are moving up and right etc,) take x distance to the the next block in the grid and divide it by x speed to get the time it takes to hit the next block and do the same for y axis. Then see wich time was shorter and move in both directions at once using speed*timetoreachnextblock and you have now arrived to the block you would hit first. If you hit something solid then do what usually happens when hittin solid things and then continue with adding the timetoreachnextblock to a timeused variable and repeat until the timeused reaches 1 frame.

This way when you hit a block your hitbox will always be at the border of the block and you will also know wich side it hit. This makes it really easy to figure out where the hitbox needs to be moved next.

In Topic: Will Steam the platform make Steam the OS viable?

10 April 2014 - 02:23 PM

I tought the steam-os was completely 100% free linux distribution based on ubuntu running on everyday pc hardware. As long as a game has linux support it will run in steam-os. And seeing that linux/crossplatform gaming is on the rise it doesn't even need the steam platform to be a viable os.


If you are talking about the steambox then its another matter. Seeing as that is just a normal pc with a preinstalled linux. Steam platform has almost nothing to do with it since it will run just fine even without steamos. Since both the steam platform and the steam-os can run without the other just fine the only real difference between other linux distros and steam-os is that steam-os has all the drivers and dependencys the steam platform and its products need pre installed.

The real question is wether it is viable to sell a pc with a preinstalled free linux in it. And even that simplifies to "Is a linux os a viable replacement for windows in everyday use?"

My answer would be yes. Sure the way linux handles software distribution is radically different from windows and can be hard to get into but nowdays there are very few things you can't do with a linux that you can do with windows or mac.


Anyway this is mostly guessing as there are no previous attempts of this scale to use as comparison to make any solid prediction.