Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 23 Mar 2010
Offline Last Active Jun 04 2016 06:49 AM

#5008130 SSAO and skybox artifact

Posted by on 07 December 2012 - 09:07 AM

When dealing with shaders, ALL code is executed, including ALL branches, all function calls, etc. The ONLY exception for this is if something is known at compile time that will allow the compiler to remove a particular piece of code.

This is how all graphics cards work, AMD, NVIDIA, etc. So, your additional cost is of the if statement, and in your example, you are adding an extra if instruction. This is a zero cost on gpus. If you want to read on it, check out vectors processors and data hazards.

If you somehow split our shader up and added an if statement to the middle thinking that it would speed up your code, you would get NO speedup. because ALL paths will be executed.

#5007288 Question about glGenTextures

Posted by on 04 December 2012 - 08:56 PM

All gentextures does it get you a valid Texture ID. It doesn't actually create a texture for you. So, you would Usually,

GenTexture //get an ID
BindTexture //sets the active texture for work
Fillorcreate the texture stuff here

GenTexture should only be called when you want a NEW texture ID. If you are just updating a texture, or want to bind it for work, use the ID that you got from your GenTexture call when you created the resource.

#5006312 Drawing text causes incorrect geometry rendering

Posted by on 02 December 2012 - 11:10 AM

Like Erik said, the drawing function changes states, so you can use the

draw text inside here

This will make sure your states are changed back to what they were before the draw text call.

#4951342 Allocating memory problem (terrain)

Posted by on 21 June 2012 - 07:42 AM

You can also do away with most of the the position of the grid, as well as the texcoords. You can generate the actual position of the verts in the vertex shader by supplying an offset that you pass in for each chunk drawn. Create a stream of two floats( x and z) and make it go from (top left) 0, 0 to (1, 1) on the bottom right. Then when ypu draw it in the shader, you can compute the texcoords from it and you just scale the grid up its full size with a multiplication, then add the offset to each vertex and you have placed you4r grid correctly. To get the correct hights, you create a seperate highstream for each grid and pass that in for each drawing operating as well.

In the end, you reuse the x,z grid mentioned above for all grid patches, since its always the same. Resuse the same index buffer for all grids since its also the same. The only differences will be your extra data. You will need a highstream for each grid, and your normals + tangets.

This is very breif as I am heading off to work, but hopfully you get the idea on reducing a decent amount of vertex memory.

#4949179 Sending data questions

Posted by on 14 June 2012 - 09:37 AM

A pointer variable is really either a 32 bit or 64 bit number --depends on whether you build your application as a 32 bit or a 64 bit. So, when you send that structure --assuming a 32 bit build-- you are sending a total of 64 bits, 32 for m_data and 32 for m_id.

The number that the pointer holds is a memory address. If you want to send a variable length array, you can, but you need to do your own packing.

also , use unsigned shorts, which are 16 bits. You will likely not need 32 bit packet ids
unsigned short int packetid = 45;// best to use an enum for packet ids so you can reference them with words
std::string npcname = "big bad monster";
unsigned short int sizetosend = npcname.size() +sizeof(packetid) + sizeof(unsigned short int)*2;// 2 is for the size of the string 2 is for the m_id variable, 2 is for the size of the payload
char* data = new char[sizetosend];
memcpy(data, &packetid, sizeof(packetid));
memcpy(data+sizeof(packetid), &sizetosend, sizeof(sizetosend));// size of the payload so on the other side, you can copy the data correctly
memcpy(data + sizeof(packetid) +sizeof(sizetosend), npcname.c_str(), npcname.size());// there is no null terminator being copied in here to save a byte <img src='http://public.gamedev.net//public/style_emoticons/default/tongue.png' class='bbc_emoticon' alt=':P' />
sendto(socket, data, sizetosend, 0, (sockaddr*)&address, sizeof(sockaddr));

#4931211 mvc and c++

Posted by on 14 April 2012 - 09:57 AM

The model view controller works for web site design because thats all there is. In c++ programming, there are many more ways to seperate code than the MVC route because you are not just developing a web application.

You can seperate code based on input, network, graphics, logic, threading... on and on

Segregation of code is done in c++ to make compilation faster, reduce coupling between classes, keep cpp files as small as possible to make maintining easier, and to create logical relationships between child and parent classes. There are other reasons I am sure, but I would suggest to not think of web programming paradigms as a way to program a c++ application. The two might be somewhat related, but in general they are not.

#4930952 Smooth animation and frame transition

Posted by on 13 April 2012 - 07:56 AM

I wrote an animation extractor for assimp that is free to use, check it out http://nolimitsdesigns.com/game-design/open-asset-import-library-animation-loader/

It precomputes all the animations so no work is done at run-time, which means its fast. Hopefully that will help you out.

#4929023 One time events VS periodic events

Posted by on 07 April 2012 - 06:50 AM

If you are sticking to sending updates at 50ms itervals, then it would make your program simpler if you stuck to sending all data out on the intervals. What difference would 50ms make in sending out information about something that "just occured?" Now, you need to synchronize sending between different threads (assuming your program is threaded).

Keeping code as uniform as possible helps alot down the road. I don't see a 50 ms difference as causing any problems for players. My vote would be to keep the 50 ms sending of all data.

#4903868 Assimp mOffsetMatrix broken?

Posted by on 17 January 2012 - 08:52 PM

I belive your are mutliplying in the wrong order. When I load the matrix from assimp on the init function, i transpose everything in the copy. Then, after the copy is finished, I build the skeleton. In your code . .

GlobalTransform *= parent->mTransformation;

Then, you transpose afterwards. Right handed and left handed matrix operations are backward from each other. Try transposing all your matrix before you do any calculations., otherwise, change the order of mutiplication to be backwards, i.e
GlobalTransform = parent->mTransformation * GlobalTransform ;

#4903613 Assimp mOffsetMatrix broken?

Posted by on 17 January 2012 - 07:56 AM

you can download my ASSIMP animation exporter, maybe that will help you out

#4879255 Difference between Hardware vertex processing and Software vertex processing?

Posted by on 01 November 2011 - 08:55 AM

Hi there,

Can someone tell me when is better to use Software vertex processing instead Hardware vertex processing?

Thank you,


The software processing will allow you to run directx 11 on a directx 9 compatible card. because all the actually work is offloaded to the CPU.
Hardware processing is where all the work is done on the GPU.

software processing is VERY VERY SLOW and is never really used, except if you want to test a feature that is not supported by your current video card.

#4857328 Full screen quad without vertex buffer?

Posted by on 03 September 2011 - 08:11 PM

This is the DX code implementing what MJP said. You should be able to convert it to opengl. Remember, opengl has their texcoord (0, 0) at the bottom left, where directx is top left.

struct VSQuadOut{
	float4 position : SV_Position;
	float2 texcoord: TexCoord;
VSQuadOut VSQuad(uint VertexID: SV_VertexID){// ouputs a full screen quad with tex coords
	VSQuadOut Out;
	Out.texcoord = float2( (VertexID << 1) & 2, VertexID & 2 );
	Out.position = float4( Out.texcoord * float2( 2.0f, -2.0f ) + float2( -1.0f, 1.0f), 0.0f, 1.0f );
	return Out;

#4857327 Terrain Normals computed in VS and issues with patches

Posted by on 03 September 2011 - 08:09 PM

You can precompute your normals from your heightmap on the CPU before hand, then use that on the GPU and just read them as simply as you read the heights.This will allow you to take care of any problem areas around where seams are located.

#4854066 Synchronizing server and client time

Posted by on 26 August 2011 - 08:40 AM

The server sends timestamps to the client, and the client attempts to sync with the servers time.
Here is how it should go ( there might be a better way)

Player A sends to server a request to fire a gun (no timestamp)
Server receives the request and does its necessary checks to ensure the request is valid. If everything is valid, the server then sends out player A shot a gun and attaches a timestamp to with it.
all players receive the gun fire event with the timestamp the server sent (which was when the server actually received the command, not when the player sent the request)

This actually will lead to a less jerky simulation because instead of having to play an event that occurred possibly 500 ms ago (which would be possible for laggy players), the event plays for an even that occured yourroundtrip/2.

In other words, you dont want the entire server at the mercy of laggy players (where events are received at a delay of 200 ms in the case of a laggy connection ). The server should continue blindly and if a request(command as you put it) is received, the server should treat it as happening then. Think of how your simulation would run if the server was running commands based on a laggy player. Imagine getting a few laggy players together and having them run around each other trying to fight, or collide. All the information would be running 200 ms in the past. The server would be freaking out trying to decide what to send out because the information is all interlaced and it would receive commands in the past which could be very bad and lead to very jerky simulations.

Basically, the server would have to hold all information being sent out to sync with the laggiest player otherwise, there would be many correction events that can occur with a player telling the server when he or she moved, or shot a gun. Player A (who has a bad ping) might tell the server that he moved forward 500 ms ago, but player B (who has a good ping) told the server that he shot at player A 30 ms ago. So the server receives player B's packet with the info and the server decides that player A should be dead. But then 470 ms later, the server receives a packet from player A saying that he was moving for the past 500 ms, which means that player B never actually hit player A.

The synced time on the client is used when the server sends the clients events that have occurred. The client will always be running in the past just behind the server by a time of roundtrip/2 ms. Our job as programmers is to try and guess the events that occur between the updates that we receive. If we guess wrong, we have to correct it. In most cases a wrong guess is a position change, in which case you can slowly adjust a players position over time instead of jerking the player into the correct position.

#4849875 Efficiently rendering ordered GUI objects

Posted by on 16 August 2011 - 08:41 AM

Alot of items in GUI rendering have to be single draw calls to keep ordering correct. You have to sort the GUI so that the order of draw calls is correct. This is not very hard because usually all the controls are stored in a window, and each window is a layer. So, you dont really need to sort things like, buttons, text boxes, check boxes, etc because they should all be contained within a window. So, as long as you maintain a list of children of a window, you simply ensure the windows are layered correctly, then draw each window in back-to-front order. You can batch all the children of each window into a single draw call too. So, if you have 8 windows, you should be able to do 16 draw calls. This is how I organized my UI. If you want free floating controls that are not part of an actual window, that is easy too because you can cheat. Just create a window and make sure the background of that window is not drawn. So, when you place controls within it, they are drawn, but the actual background of the window is not. Now, you have free floating controls.

There are a few special cases where you will have to do a few extra checks, like on the textbox caret, which has to be drawn last. But, you can do this by keeping exactly one caret for your entire GUI and just drawing that after everything else is drawn --thus ensuring that it is over the top of the textbox. Another special case is for listboxes when they are opened. These have to be drawn last as well if they are open to make sure they layer over the top of any other controls.