• Content count

  • Joined

  • Last visited

Community Reputation

735 Good

About nfactorial

  • Rank
  1. I wouldn't do it that way at all, it'll be full of security holes if you're accessing the database directly from the client.   However, mysql ( would be the immediate replacement for sqllite. There are other options, but mysql is a reasonable first step up from sqllite.   As I said, I wouldn't recommend doing it this way. Instead write a simple server application that performs the necessary database queries in response to messages from the client, so that people don't have direct access to the database.   n!
  2. The first thing that jumps at me is that your class cLoadStreamDataMenuSystem is not aligned. And the address it's complaining about is also not aligned. Try ensuring your cLoadStreamDataMenuSystem begins on an aligned memory address.   [edit] Reading back, your class holds a pointer to a matrix rather than an instance. So that's probably not the direct issue, but make sure the OrthographicProjection matrix is aligned. It does seem to be complaining about alignment to me (due to the address ending in F8, which is not 16byte aligned. The typical alignment for vectors and matrices)..   n!
  3. RefCount and Manager

    There is no *should* here, it is an option of-course. But it is entirely dependent on how you structure the management of these resources.   I'm neither for or against reference counting, I think it's a fine solution for many things but it isn't the only solution.   For example, lets say we have some resource manager objects that manages a list of resources and destroys them all in its destructor.   We can have:   Scene     TextureManager     ModelManager   When a model asks for a texture it goes through the scenes texture manager. When the scene is destroyed. All models are destroyed and all textures, no reference counting necessary.   Simply following the same method we can extend it further with a hierarchy:   Application    TextureManager    ModelManager    Scene         TextureManager         ModelManager   The lifetime is simply controlled by the containers lifetime, at it is not possible for something higher up the hierarchy to access something lower down. It is a simple alternative, it is not a complete solution. More a quick overview to show why it isn't *necessary* for reference counting. But please don't take this as a "you shouldn't" use reference counting. It's a decision you can make as a developer.   n!
  4. RefCount and Manager

      No, you don't need to maintain a lock at all. If it has 0 references, then there is nothing referencing it, so nothing else could actually gain access to it for the lock to protect against.   This logic doesn't work sorry, another thread cannot suddenly raise the reference back to 1. Because there is nothing else referencing it for that to be possible.   n!
  5. RefCount and Manager

    You don't need a lock for a reference count, you can just use atomic operations (such as InterlockedIncrement etc. on windows, other platforms have similar).   I feel a 'manager' implies you don't need a ref-count, as the manager would manage the lifetime.   However, whether a ref-count is good or necessary for you is entirely down to what you're doing and the behaviour you desire. There's not really any complete answer without more detail.   n!
  6. c# assigning new int to void*?

    The simple answer is you don't, and you shouldn't. Even in C++ you shouldn't do it this way, though you can.   There are many alternatives:   As someone else mentioned you can make your class a generic, and have the type declared as part of your class. One issue you will get then is that you can't simply make a collection of your objects. To solve that you can use inheritance, by having an ObjectVariableBase which has everything but the value. Then derive a generic from that with the actual variable type. If you want methods specific to the type, then deriving a specialised implementation is also an option (ObjecVariableInt, ObjectVariableString etc).   Another option in C# is to use a dynamic method to access the value. However, I feel that's a little advanced for what you're trying to do here.   You shouldn't give single letter variable names in the constructor, give them proper names. As ChaosEngine shows in his code, call them 'name', 'description', 'value' or whatever your preference is, just not 'a', 'b' and 'c'.   n!
  7. You should have unit tests for all the issues you list. That would eliminate packing/unpacking/applying from your list immediately at the very least.   n!
  8. My first suggestion in to not have complex behaviour in a constructor (in C++) as there's no way to handle fatal errors nicely. If you have complex initialisation then I'd put it in an Initialize method (though, others dislike that also so it depends on your point of view). I would consider std::string initialization 'complex' in this case as it requires a memory allocation.   Please don't pass around std::string's by value.   As to your query, it is hard to give a definite answer as you haven't included the exact code you're using (for example, you initialize a Name variable in your initializer list when no such variable is defined in your class object). So it would just be speculation.   If you make the changes I mention above, it'll probably be easier to see what is wrong.   n!
  9. undefined reference to `SDL_main'

    Sounds like you're not linking to the appropriate library.   n!
  10. Tips on FileLoader code

    I wouldn't, in any way, have a file loader class allocate it's buffer the way your code is doing it.   1) Code may not want the entire file in memory. 2) Code cannot control where the memory is allocated from.   You could, of-course, change the code to take an allocator object of some description. But I personally prefer the buffer pointer to be handed to the read operation.   For similar reasons I wouldn't try to hide the Read method away, but also wouldn't provide async and non-async operations into the same object, which confuses the API and can lead to incorrect usage. You could make the read* functions protected, give the object a protected constructor and derive 'AsyncFileReader' from it or take another route.   I personally prefer the route of obtaining a stream object and the user creates operations using that object. Allowing them to wait on that particular operation. For example (pseudo code): InputStream *stream = OpenInputStream( uri ); if ( NULL != stream ) {       StreamOp *op = stream->Read( myBuffer, dataLength );       if ( NULL == op )       {           // Error       }       else       {           // Move into wait state       } } else {      // Unable to open stream } I actually don't think non-async operations are necessary at all, if someone wants to stall they can just call the operation->Wait() method for development purposes though nothing should be loaded like that in the end, and even then it should be frowned on as it's much harder to patch code to be async down the line.   [edit] I can think of many, many different ways of implementing the above code, so please don't take it that I'm suggesting it should be done exactly like that. n!
  11. What is the point of blocking sockets?

    Blocking sockets wake when they have data available, if you use blocking sockets you will usually have that on its own thread. The benefit you get is immediate response to incoming data. The alternative is to check the socket every n seconds (where n is the delta of your polling, if you poll at 60fps for example then n will be 16.66r-ms. This may seem a negligent amount of time, and for many application it is.   However, if we take into account a simple PING operation, the PING response could have an added latency of up-to 16ms in the worst case (in the given example).   It is entirely up-to the developer if the added latency is acceptable or not and choose which direction they wish to take, but blocking sockets can lead to (relatively) much more responsive network processing. Whether that's a requirement or not is down to what you're doing and how you implement it though, really.   n!
  12. DX11 HDR implementation

    Your output will always be 8-bits per channel on current displays. You don't get more colors by using a wider display surface. What you *do* get is higher resolution in the math you are performing. But the final result displayed on your screen will be 8 bit per channel.   HDR rendering allows you to go beyond the 0..1 range in your lighting, but *not* on your display.   It sounds like you would be more interested in tone mapping, which HDR pipelines use to remap the high dynamic range back into the displayable 0..1 range. Whilst typically used with HDR, it can still be applied to non-HDR rendering also.   John Hable (who used to work at Naughty Dog) wrote some articles you may find of use:   n!
  13. As Hodgman says, every engine I've worked with does not use new and delete directly. Instead they define their own macro. Such as MY_NEW (using Hodgmans example).   So code then becomes: MyObject *myObject = MY_NEW MyObject(); Where MY_NEW would be defined something like: #if defined( _DEBUG )     #define MY_NEW    new( __FILE__, __LINE__ ) #else     #define MY_NEW    new #endif //defined( _DEBUG )
  14. Some simple games I started out with are Space Invaders, Pong, Columns and Tetris. They provide a simple intro to a lot of programming concepts and are not heavy weight, certainly clones of these games can be written quickly. I would consider a Mud (networking + multiple players) or anything with 'physics' a bit too heavy as an 'introduction' and more suited to a 201 or higher course.   n!
  15. Make sure you render the sky with the depth buffer from your scene enabled. But it should be done as Hodgman describes.   n!