Jump to content

  • Log In with Google      Sign In   
  • Create Account


PunCrathod

Member Since 16 Jan 2012
Offline Last Active Jul 20 2014 10:20 AM
-----

#5164930 Using VBOs for dynamic geometry

Posted by PunCrathod on 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.




#5164059 Using VBOs for dynamic geometry

Posted by PunCrathod on 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.




#5148731 Fantasy Guild Management Sim

Posted by PunCrathod on 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.




#5122165 measuring latency

Posted by PunCrathod on 08 January 2014 - 08:14 AM

I know that in order to apply 'smoothin out' algorithm (client side prediction, extrapolation), one has to take into account the latency factor. But it kinda dazzled me as to whom should calculate it and how it is generally measured.

 

1. Who gets the burden?

-Do the server do the calculation and tell the client overtime?

-Do the client do it (since it is him who needs to be smoothened)

-Do the server and client each has their own pingtime?

 

2. How would one calculate it?

right now I simply use the simplistic ping approach (e.g., send "ping" message and teh server quickly throw back the reply).

however, it was too simplistic and pingtime was generally change overtime (they sure are very random). Thus the second question. But if we use the average pingtime, it sometimes won't be correct, right? plus if I have to use average pingtime, that means I have to already have several ping results at hand. What if the game has just begun? should I spend my time calculating pingtime first?

 

3. How was it generally used?

Example scenario:

-client send message that he just pressed "move forward" button. In order to hide latency, he directly moves his avatar forward locally.

-by the time the message reaches the server, however, it's already too late. perhaps by 100 ms. then the server should simulate as if player pressed the button 100 ms ago, thus the server must do "extrapolation" by 100 ms. CMIIW.

-client stopped pressing forward key, thus he sends "stop pressing forward" message to server.

-the server gets the message 100 ms later, oops that means our player is moved too far by 100 ms, so his position must be corrected by 100ms

(pos = pos + vel * -0.1). as such, the server send a position update message to player

-the client received the message, assume it's late by 100 ms. but since this is corrective position, the client simply stick his current position to the server's corrective position. He might also use interpolation (so it looks like sliding over rather than snapping) to alleviate graphical jerkiness.

 

So am I right on number 3?

 

4. bonus question. I recently have a chat with some gamedev over IRC, we were discussing minecraft. I threw a question regarding its networking, and some fellow said that the send rate is very low (a particular guy even said that it's only 5 TIMES A SECOND!! WTF!!). that means it sends every 200 ms. now I wonder about its update rate. since minecraft is kinda "physics"-is, I bet they use at least 30 fps update rate. But since I can't get a look at their sources, I can't confirm my curiousity. Do any of you guys know about this? thanks a lot.

 

Those are my questions, I hope you guys could help this confused guy. Anyway, thanks for your time reading this blocks of text.

1. This depends on where and why do you need it. For smoothing out latency in a fps you propably would calculate latency in the server since it needs to know where each client was when one pressed the trigger to see who got shot.

 

2. There are a few ways. Easiest being just to measure how long the server or client takes to respond to a simple short message.

 

3. There are quite a few things you could use the latency for. Movement prediction and correction is perhaps the most common use.

 

4. Minecraft suprisingly doesn't have that much physics in it. And as far as I know its network update rate depends on the servers tickrate so with a lot of mods it can be as low as once in every 2-10 seconds. The tickrate is capped at 20 meaning it would update 20 times a second at most. But the update rate is not that important in a game like minecraft. A 5hz rate would be more than enough. For example battlefield 3 and 4 updates 10 times a second and its a twitch shooter where life and death depends on a few milliseconds. This is exactly where latency corrections and such come into play to smooth things out.




#5117566 Is GPU-to-CPU data transfer a performance bottle-neck?

Posted by PunCrathod on 17 December 2013 - 08:05 AM

And do you need to use doubles? Computing your v expression with doubles is slower than with floats (the double division will be really slow) and also converting it to float takes some time.

 

 

You don't really need to worry about doubles or floats. As long as your memory bandwith does not run out doubles are almost always as fast as floats on a 64 bit processor as they are both usually calculated with the same alu using the same 80bit registers. Granted with 1 million 3d points you have 3 million doubles and thats about 24 megabytes and there goes your bandwith. If all the data could fit in L3 cache(or L4 if you have it) then you propably would not get much of a difference in performance without using some fancy stuff like SSE(wich can infact process double the amount of floats than doubles in one cycle). But in this case even with SSE you wouldn't get much of an improvement as your bandwith is already holding you back.

 

 

Maybe you could sort on GPU and keep the sorted array on GPU and use it as an indirect parameter to your rendering, perhaps as an index buffer. That way, you wouldn't have to stall at all.

 

 

This is propably the best bet on getting a million particles sorted inside a reasonable amount of time. Just as a comparison a game that I'm making with a couple of friends has a particle system that has two textures containing the particle data. One for reading and one for writing and swapping them around after rendering. Granted it's only in 2d and no need for sorting but since all the data is kept on vram all the time its blazing fast and we can have 5 million particles without any noticeably decrease in performance(less than 1ms difference in frame time between 100k and 5mil particles with a nvidia gtx 660). And as op said in the first post the shader did the job in less than 1ms too so the best solution would be to figure out a way to avoid transferring all the data between cpu and gpu.

 

We actually did ours by having three different shaders. One that "rendered" new particles in the particle data texture, one that updated the data between frames and one that rendered them to a framebuffer to be displayed on the screen. So the only data that needed to be sent anywhere was a list of particle emitters active during a frame sent to the first shader and the rest was just a few draw calls. I believe they call this approach ping-ponging. I'm not too familiar with how it works as my two friends do most of the rendering code in our project but I hope this gives you the motivation to try something similar yourself.

 

However if your particles interact with the rest of the simulation then it gets complicated and I have no idea how to make that happen.




#5114960 Offset mass angular/linear velocity?

Posted by PunCrathod on 06 December 2013 - 03:25 PM

It seems you are looking for rigid body collisions.

 

1. This gets complicated real fast. Reading a book on physics is a good start but if you don't want to read a book you can take a look at this http://www.myphysicslab.com/collision.html

Just be avare that there are a lot of vector math and physics related terms and if you are not familiar with them this will propably not help you much.

 

3. As long as your objects arent bolted down to an axel then yes. Objects always rotate around their center of mass.

 

4. This one is also a lot of complicated math involving a lot of vectors. The link in #1 mostly covers this if you can read all the scientific terms and know vector math.

 

Seeing as you are only 14 my advice is to pay close attention in math and physics classes at school. It may sometimes seem boring but when you start to understand all of it and you get your first physics simulation program working it gets fun real fast.




#5098774 How do I use multithreading?

Posted by PunCrathod on 04 October 2013 - 11:05 AM

Boolean flags aren't atomic (so you have to know details of the platform and ensure there's enough padding that other mutable data won't be too close to the flag), and there's no ordering guarantee that the changed flag won't become visible to the main thread before the star system data is actually committed to RAM (which creates a potential race condition where the main thread sees the flag is true, but reads the star system data before it's been written/completed). As you mention, this then requires memory barriers (both compile-time and run-time varieties) to be inserted after writing to the flag and before reading from the flag (not mentioned above). If you're writing that kind of low-level synchronization code though, you really need to understand why those 4 barriers are required, which is not a suitable beginner task.
Beginners should instead use pre-made synchronization primitives, like critical-sections/mutexes, or a higher level parallelism library.

You don't need to protect the flag. A memory barrier in the generating thread just before setting the flag to true is all that's needed. The data is then quaranteed to exist before main thread sees that the flag is set to true. If you are advanced enough to be thinking about pregenerating the gameworld in advance during runtime then understanding this should not be a problem for you.

I'm not saying you shouldn't study how memory barriers etc work but a background worker thread isn't that complicated. I just think its arrogant to claim someone can't possibly comprehend multithreading at all if he hasn't been programmin for 10 years and hasn't learned the inner workings of whatever platform they are targeting. Where I studied programmin a few years back background worker threads were considered beginner stuff.


#5098719 How do I use multithreading?

Posted by PunCrathod on 04 October 2013 - 05:16 AM

Threads are not so hard people make them to be. If I understood right about what you want to do this is the easiest multithreading case there is. Correct me if I'm wrong.

You want to have another thread generate your starsystem while your main thread is handling the game. Without the additional thread you would do a small portion of the generation between each frame and the performance is not good enough for you.

There is no data racing or any other complicated stuff going on if you generate the starsystem in a single thread and make sure you do not access the starsystems data from anywhere until the generation is complete. This kind of threading does not take that much effort to get it right and will increase your games performance quite a bit. You only need to have a threadsafe way to tell the main thread if a starsystem is still being generated. You also can use n generation threads to generate n starsystems at the same time.

My tip is to not use any global variables to manage the threading as those get complicated rather quickly. Have a "generated" flag that's defaulted to false and set it true after generation is complete in your starystems class or struct or whatever you use to store your starsystems in memory. You may add a memory barrier to after the starsystem is generated to make sure all threads have the same data.

This way you'll have a full thread generating the starsystem as fast as possible without any need for complicated threadmanagement stuff. A lot of people are trying to scare people away from threads because they don't understand it themselves. Granted there are a lot of complicated stuff to do if you want to multithread realtime simulations but a simple background thread to generate the next part of the gameworld before the player is close enough to interact with the part is a simple task.

You seem to have managed to get a thread going. Just try and put the code to generate a starsystem into the thread and see what happens. If something gets broken and you can't figure out why then come back here and explain what and how and someone will propably be able to help. Multithreading is not rocketsience.


#5095903 Odd rendering issue; need help

Posted by PunCrathod on 22 September 2013 - 04:47 AM

I am not sure what the problem you are trying to solve really is. But a quick look through your code and I can see what causes the odd behaviour you are seeing. When you go over the buffer limit you stop and clear your screen then render your sprites to the screen. This will cause flickering because you cleared the screen and then render a few sprites and then clear the screen again and then render a few sprites more.


What I don't get is why you need to render only a few sprites at a time in the first place. Modern machines(even mobile ones) have more than enough memory and power to render all the sprites at once from a single vertexbuffer as long as you are not drawing many thousands of them. If you have some other reason to batch your rendering like this then the only solution is to not clear the screen every time you render a few sprites.


Clear only when you need to. Wich is never if you have somekind of background that fills the entire screen that you render at the beginning of each update. And by update I don't mean when you render a few sprites but when you render all of them.


#5091521 Moving diagonaly how to calulate from horizontal and vertical speed

Posted by PunCrathod on 04 September 2013 - 04:15 AM

If you want to move diagonally at the same speed as vertically or horisontally you need to use 1/sqrt(2) as a multiplier. As an example you want to move up and right at the same time you would increase the units y and x coordinate by speed/sqrt(2) and while moving vertically or horisontally just increase y or x by speed without the multiplier. But if you want it to take as long to move diagonally as it would take to move horizontally and vertically in sequence you propably don't want to allow diagonal movement at all. Also if you are using limited hardware like mobile devices usually are. You should calculate sqrt(2) at the start of the program and use the precalculated value as calculating square roots can be demanding. Especially if the device does not have hardware floating points. PS. 1/sqrt(2)=sin(45degrees)=sin(PI/4radians)~=0.70710678118654752440084436210485


#4967131 How to have a Sprite follow the player?

Posted by PunCrathod on 07 August 2012 - 02:32 PM

I'll assume you are using c# and XNA. You should use Math.atan2(x2-x1,y2-y1) instead of atan(dx/dy) so you don't have to worry about special case dy=0 and don't have to find wich side the target is. Also what I like to use in cases like these I like to use the following code.
targetangle=Math.Atan2(target.x-this.x,target.y-this.y)//get the angle to the target

turnangle=targetangle-currentangle;//get the difference between the current angle and the target angle

if(turnangle>2*Math.PI)//make sure to wrap the angle between 0 and 2PI
    turnangle-=2*Math.PI
if(turnangle<0)
    turnagnel+=2*Math.PI

if(turnangle<Math.PI&&turnangle>Deadzone){//Check wich side you should turn to get to your target.
    turnright();
}
else if(turnangle>Math.PI&&turnangle<(2*Math.PI)-Deadzone)
{
    turnleft();
}

This should always turn to the direction that is closer to the target. Deadzone is the amount of radians(you get radians from degrees with degrees/360*(2*PI)) the seeker can be off course before it starts to correct its course and should always be between 0 and PI radians(0 and 180 degrees) for this to work correctly.
If there are any errors in the code or elsewhere I blame the late hours.


#4963395 Is widescreen only resolution ok?

Posted by PunCrathod on 26 July 2012 - 12:39 PM

1920x1200 resolution is usually refered as a 16:10 widescreen not 14.4:9

But anyways it is a good idea to allow both windowed and fullscreen on any resolution the user wants. What I usually do is just make the ui elements for a completely square resolution and put different elements x pixels from certain border of the window...For example you could set the HP/MP/Portrait 20 pixels from the left border and 10 pixels from top border. And another part of the interface 20 pixels from right border and 10pixels from top and so on.

This way if the user has wider than square resolution(most likely) the gap in the center between the ui elements just gets a little wider. You don't have to strech anything and it will still look ok. Ofcourse to make it even better you could allow the user to move the ui elements around either by holding down a key and drag&drop or some kind of menu or somesuch system.

If you desing the ui like this with every element positioned relative from two borders you only need to make one desing that fits the most narrowest aspect ratio and it automatically scales to wider ones.

Edit: And as far as I can tell most AAA games that I have played do it exaclty like this.


#4903498 Best Resolution for 2D games

Posted by PunCrathod on 16 January 2012 - 11:21 PM

If you can desing the game so that it doesn't matter how wide the player can view. Then allow the user to specify any x,y resolution and just scale everything for y. This way you don't have to lock the window/screen aspect ratio and your sprites still keep their own aspect ratio. You can flip this to work for the other axis too no problem. But if the "field of view" is important then you most likely should either lock the aspect ratio or just post a disclaimer that in non x:y resolutions graphical distortions may occur.


#4903479 Question about collision detection implementation

Posted by PunCrathod on 16 January 2012 - 09:35 PM

Collision groups is the way to go. This way you can quite easily check collision only for those cases that really matter and skip the rest. Also I would imagine that you have nested for loops for all the groups. In cases where you have a list of objects that can collide each other(enemy-enemy) the most important optimization is to not check the same collision twice. easiest way to make this not happen is to make the inner for loop start from i+1 where i is the outter for loops iterator.
Also in a 2d sidescroller if you don't have active stuff outside of the screen you can skip all non active objects in the collision detection and you should have nothing to worry about. If you have 10-200 objects on the screen at the same time you don't really need any fancy optimizations like cell divisions and such.


PARTNERS