Jump to content

  • Log In with Google      Sign In   
  • Create Account


Satharis

Member Since 18 Oct 2007
Offline Last Active Jun 28 2014 06:45 PM

Topics I've Started

Negatives to Triple Buffering?

19 April 2014 - 11:38 PM

So both via Google and forum searching I've come up on wildly varying information about triple buffering and its impact, I'm trying to figure out what the legitimate information is.

I've read everything from it causing input lag(I don't see how it can) to even John Carmack tweeting that it is horrible and causes "lag and jitter" but again I don't see any reason why that would be. From an implementation standpoint it should always give higher FPS with vsync enabled(unless you're at the max fps for your refresh rate) correct?

I've also read conflicting information on whether D3D supports it, despite the fact dx11 and dxgi seem to be able to use more than one backbuffer and have different swap methods.

Guess my question is if there is any actual lag and what would cause that, along with how much of that is just misinformation.

Unique_ptr and emplace_back.

14 December 2013 - 06:11 PM

I was wondering if this code is leak safe:


m_clients.emplace_back(std::unique_ptr<Client>(new Client()));

Logically I see two throw points, new can obviously throw with bad_alloc, and I -believe- the unique_ptr constructor can throw, but I'm not entirely sure about that. I'm not sure if the allocation ends up a no-op with a certain combination of setup like this. As far as I know something like just new Client() can leak, since it would involve a copy operation, but I'm not totally sure.

 

I can't seem to find any information on the order of operations when you pass a constructor to variadic templates like this. For instance I wasn't sure if it say.. called new and -then- passed the address to emplace_back, and I wasn't sure if emplace_back could throw at that point either. In which case it would never even get to constructing the object.

 

m_clients is a vector<std::unique_ptr<Client>> for those wondering.

 

So basically, is it leak safe? Why is/isn't it?


Static const & member arrays

03 December 2013 - 08:11 PM

So, kind of a two part question here.
 
//HEADER

private:
    static const unsigned int RECEIVE_BUFFER_SIZE;
    static const unsigned int SEND_BUFFER_SIZE;

    static char m_receiveBuffer[];
    char m_sendBuffer[SEND_BUFFER_SIZE];

//CPP FILE

const unsigned int Connection::RECEIVE_BUFFER_SIZE = 8192;
const unsigned int Connection::SEND_BUFFER_SIZE = 8192;
char Connection::m_receiveBuffer[RECEIVE_BUFFER_SIZE] {};
This is probably me just not really understanding the basis of how static is compiled but;

1. Given the above code, my understanding is that m_sendBuffer needs a size definition at compile time so that other files including the header have that information available. Is there any way for me to create a member array like that without new or without placing the definition of the size in the header file?

The only reason I ask that is because std::strings are another common thing I use for header constants, but they take up memory so as far as I know I have to define them inside the cpp file. I find it a little annoying to have to place the int constants in the header and the string constants in the cpp file, so I was searching for a way to have both in the cpp file. Is there no option besides the two I listed?

2. Regarding the static, I don't really get the behavior of what it is doing. Why can I declare it without a stated size while the member array requires it? I technically can remove the line where it zero initializes the receive buffer in the cpp file and it will compile just fine. So what are other files seeing? What is that line with a stated size actually doing? I know arrays are just pointers but wouldn't that mean it essentially is pointing to unallocated memory?

I'm mainly just trying to figure out what the actual behavior here is doing and if terrible things happen if I remove the definition of m_receiveBuffer, which still happily compiles.

Keying a value to a class

10 April 2012 - 08:49 PM

So I'm writing a relatively simple state manager, it has a single member pointer to a base State class and a ChangeState function. Changestate(in a perfect world) checks if the new state is the same as the current one and disregards it, then it tells the pointed to object to clean itself up and then deletes it, that's all fine and dandy. The question I have is when I get to creating the new state, right now I'm using an enum for the list of states(declared in the header) so to create simplicity one would just have to edit the list to add/remove states.

Problem is when I get to the actual creating a new object for the game state, I would prefer not to use a switch or if/else block because that would mean having to hardcode each class to create, depending on what the function receives as a paramater. I'm wondering if there's a better way to implement this or a way to create a "key" or something I could pass to the function and then it simply uses that as a basis for which class to create with the pointer.

Is there an elegant way to do this?

Game State Management

25 March 2012 - 01:42 PM

Recently I've been pondering what the best implementation of game states(or really a game state manager) would be for a game developed in C++. I mention C++ specifically due to the fact it adds the options of OOP and pointers into the mix of possibilities for design, I was curious what other people's opinions are on the topic.

Really I just kinda sat down and pondered, "What does a game state manager have to do?" I came up with the few following points:
  • Redirect program flow from the game loop, either by branching into switches or using a function pointer or some other method.
  • Encapsulate the different things that need to be loaded or updated in a subset of the program into "game states" how these objects are updated can vary as well.
  • Provide a way to control which states are loaded/unloaded and be able to swap between them with relative ease/efficiency.

Given those few guidelines I was wondering what opinions are on different aspects of traditional game state management. Is using a singleton game state manager the most effective way to control? Is a stack the best way to control game states? There is of course good points to using a stack such as: an efficienct way to track which states are loaded and to unload them as they pop, a simple way to designate an "active" state, at the top of the stack, without having to jump to an "active" state in an array each iteration of the game loop. There are negatives too though, for one a function pointer is usually what you need to reroute the "flow" of the program to the top state, a stack also can present problems in situations where you may want to jump from one state to another, not neccesarily in a hierarchy.

My idea thus far was to have states as a class inheriting from a base, a game state manager would be used with a pointer to the current state to redirect program flow. An interesting idea I heard before was to use the stack as an "efficient" container for states, in that you could have two forms of access: one is to simply push and pop and states will unload when popped and load when pushed, thus giving simplicity to hierarchial menus. The second point was also having a sort of "jump to" method, which would clear the stack and push a new single state ontop, this lets you have the efficiency of keeping states loaded where need be but also being able to "dump" the stack when you need to move to an unconventional state.

/textwall

PARTNERS