Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

102 Neutral

About johnnyk

  • Rank
  1. Hello, for our next game I want to make an indie-style MMO, and I've spent some time scouring the interwebs for information about programming a modern MMO but have been having trouble finding any large stores of information that's been created in the last ten years. Can anyone recommend good books/articles/blogs on the topic? The kind of questions I want to answer: - What technology options are out there for creating a server/client architecture? Scaling/virtualized servers, cloud computing, etc. - What programming techniques are used to create networking architectures of potentially thousands of players? What algorithms and libraries are used for this kind of thing? - What middleware is out there for MMO development? Thanks in advance, and I'll continue searching and post anything interesting I find here.
  2. I need an s-curve function, such that: f(0,p) = 0 f(1,p) = 1 Where 'p' is the power coefficient and denotes how steep the curve is. Slope at 0 and 1 should be 0. I was using just a section of a sine curve, but I dont know a good way to control the 'steepness' of the curve using a coefficient like I want to. Anyone know what function it is that I want?
  3. Hi all, we're starting our port to XBox from PC and having a hard time getting out boost libraries to build on the 360 platform. Specifically, we need to build these libs: - Boost Graph - Boost Threads - Boost Filesystem Has anyone has success with this? Is it even possible?
  4. johnnyk

    Trajectory equation

    Thanks guys, very helpful. I went ahead and dusted off my algebra and solved those equations myself, solving for t then substituting into the other equation, then solving for v. I got the same result as luca, except a -2 term instead of a 2 (probably an oversight on my part). Thanks again! I'll try it out in my game.
  5. johnnyk

    Trajectory equation

    I need a trajectory formula: Given the initial launch angle, the relative position of the target in x AND y (not the same horizontal plane), and gravity, how do I determine the initial launch speed? I've been playing around trying to manipulate equations from here but no luck: http://en.wikipedia.org/wiki/Trajectory_of_a_projectile If you can help thanks much! -John
  6. Quote: To restart the simulation, nothing needs to be done. Just restart it. If any changes are needed in renderer, they are sent as usual deltas (coordinate adjustments, new objects and similar) as messages to render system. Yes, that is the nice way to do it, and we could probably change the engine to do that. There are parts of the Renderer that reference global data though, like a loaded font texture for example, and some events (like changing to a level that doesnt use that font) might unload that global data. Of course, theres no reason the render thread cant 'own' that font data and handle the loading and unloading of it itself, and we should probably change the engine to work that way. I'm not familiar with ASIO but I will give it a look. Quote: Codeka: You don't need to hold the mutex for the entire time the render thread is running, it's just to protect access to the condition variable. That wouldnt work though because I need to ensure that 'DoRender' does not run after the call to 'notify_all' until whatever is notified has finished. Yes basically the problem I'm dealing with is handling global, system-wide events that occur while the game is running, like switching to a new level, and I need to pause the render thread at a safe point while that transition occurs. If I reduce my dependence on global data that will be much cleaner, but in the meantime I was hoping to just pause the thread.
  7. Quote:Original post by KulSeran And I'm sure you are going to say that defeats some purpose of having the render thread running all the time. But think about it. What good is it to push the SAME frame twice? The only time the render thread needs to be running is when there is something for it to do. And the simplest case is that you have a thread running input that waits on frameDone, updates the camera matrix and UI, then signals the renderer to continue. In a a more complicated case it would also check buffers and set other state for the renderer if the threads are ready with other visual data changes. IMHO, the main point of having a render thread is just to hide the time spent alphasorting, culling, and otherwise preparing the frame for the graphics chip. Not to have it constantly sending the same data to the GPU as fast as it can. Yes, that makes sense and looks right, but this isnt a case of a sim thread thats feeding a renderthread (I have that handled separately outside this example). What I'm trying to do in this specific case is just stop the render thread so I can do some system-level event (like display properties of an object in the level editor, or restart the physics simulation). These events dont happen every frame, so I cant make the render thread 'wait' for one to occur before continuing.
  8. Quote:Original post by Red Ant I can't offer a solution to your problem. In fact I'm not sure I've even understood what the real problem is, but allow me to point out something that's wrong with your code. *** Source Snippet Removed *** Thanks Red Ant, thats a good point, that could be causing the counter to increment too many times. I updated my test code by surrounding that with a mutex in each thread, however the problem occurs just the same. #include <boost/thread.hpp> #include <boost/thread/condition.hpp> #include <boost/thread/mutex.hpp> //------------------------------------------------------------------------------ boost::mutex mutexPauseRequest; boost::condition_variable conditionPauseRequest; boost::mutex mutexProfileData; bool fStartingLock = false; int iFramesWeRenderBeforeGivingUpLock = 0; //------------------------------------------------------------------------------ void DoRender() { boost::this_thread::sleep(boost::posix_time::milliseconds(1)); } //------------------------------------------------------------------------------ void RenderThread() { for(;;) { boost::mutex::scoped_lock lock(mutexPauseRequest); DoRender(); mutexProfileData.lock(); if (fStartingLock) iFramesWeRenderBeforeGivingUpLock++; mutexProfileData.unlock(); conditionPauseRequest.notify_all(); } } //------------------------------------------------------------------------------ void DoSomethingWhichRequiresBlockingTheRenderer() { mutexProfileData.lock(); fStartingLock = true; mutexProfileData.unlock(); boost::mutex::scoped_lock lock(mutexPauseRequest); conditionPauseRequest.wait(lock); //Do stuff fStartingLock = false; } //------------------------------------------------------------------------------ void main() { boost::thread *pThread = new boost::thread(&RenderThread); boost::this_thread::sleep(boost::posix_time::milliseconds(250)); DoSomethingWhichRequiresBlockingTheRenderer(); }
  9. Thanks for your help Quote: There's a condition variable, and its associated mutex. Each frame, the rendering thread locks the mutex, calls notify_all() on the condition variable, then releases the mutex. Under normal circumstances, notify_all() has nobody to notify, and the function returns immediately. It doesn't even have to yield(). The code you posted suffers from the same problem my original code did though - we want the thread running 'DoSomethingWhichRequiresBlockingTheRenderer' to be signaled when the Render thread is at it's stopping point, but it cant even let the condition know it needs to be notified without locking the mutex. Thus it has to wait until it can grab the mutex from the Render thread, which takes ages. Try this test program I wrote: #include <boost/thread.hpp> #include <boost/thread/condition.hpp> #include <boost/thread/mutex.hpp> //------------------------------------------------------------------------------ boost::mutex mutexPauseRequest; boost::condition_variable conditionPauseRequest; bool fStartingLock = false; int iFramesWeRenderBeforeGivingUpLock = 0; //------------------------------------------------------------------------------ void DoRender() { boost::this_thread::sleep(boost::posix_time::milliseconds(1)); } //------------------------------------------------------------------------------ void RenderThread() { for(;;) { boost::mutex::scoped_lock lock(mutexPauseRequest); DoRender(); if (fStartingLock) iFramesWeRenderBeforeGivingUpLock++; conditionPauseRequest.notify_all(); } } //------------------------------------------------------------------------------ void DoSomethingWhichRequiresBlockingTheRenderer() { fStartingLock = true; boost::mutex::scoped_lock lock(mutexPauseRequest); conditionPauseRequest.wait(lock); //Do stuff fStartingLock = false; } //------------------------------------------------------------------------------ void main() { boost::thread *pThread = new boost::thread(&RenderThread); boost::this_thread::sleep(boost::posix_time::milliseconds(250)); DoSomethingWhichRequiresBlockingTheRenderer(); } It uses the technique you described and counts how many frames it has to wait before it receives the lock (in variable iFramesWeRenderBeforeGivingUpLock). For me, in debug this is always <= 1, and in Release, it can get as high as 200 - 200 frames before it gets the lock.
  10. Thanks for the help guys :) Quote: Are you positive it's not blocked on the m_mutexSim mutex instead? (ie the render loop ran 27 times before m_mutexSim got released) ? Thats a good point, and I put log calls in for the sim thread to check and then.. the problem stops occurring at all. The log calls must have changed the timing of the functions enough to make it lock/unlock like I wanted it (damn Heisenberg principle..) I wasnt satisfied with that though for a proper solution so I took the approach suggested of using conditions. I added a 'm_iThreadPauseRequest' variable that gets incremented when a pause is requested, then waits for 'm_fRenderThreadPaused' to be true before it continues, using a condition. The same condition is then used by the render thread to wait until the pause request is decremented back to 0. This works, but it sure bloated up the code a lot, and it doesnt feel like a very elegant solution, theres more variables and complexity now. Ideally this behavior should be wrapped up in some kind of object, but I'm not sure how it would work. Is this what people were suggesting for using conditions? Or did you have something else in mind? Heres the code: //------------------------------------------------------------------------------ void ThreadManager::RunRender() { m_fRenderThreadPaused = false; for(;;) { { if (!m_fRunning) { m_fRenderThreadPaused = true; return; } m_funcDoRender(); boost::mutex::scoped_lock lock(m_mutexPauseRequest); while (m_iThreadPauseRequest > 0) { if (!m_fRenderThreadPaused) { m_fRenderThreadPaused = true; m_conditionPauseRequest.notify_all(); } m_conditionPauseRequest.wait(lock); } m_fRenderThreadPaused = false; } } } //------------------------------------------------------------------------------ void ThreadManager::LockAll() { if (!m_fCurrentlyMultithreading) return; assert(IsWindowsThread()); //Set a pause request and wait till it is fulfilled boost::mutex::scoped_lock lock(m_mutexPauseRequest); m_iThreadPauseRequest++; while (!(m_fRenderThreadPaused && m_fSimThreadPaused)) m_conditionPauseRequest.wait(lock); } //------------------------------------------------------------------------------ void ThreadManager::UnlockAll() { if (!m_fCurrentlyMultithreading) return; assert(m_iThreadPauseRequest > 0 && m_fRenderThreadPaused && m_fSimThreadPaused); boost::mutex::scoped_lock lock(m_mutexPauseRequest); m_iThreadPauseRequest--; m_conditionPauseRequest.notify_all(); } And the header boost::mutex m_mutexPauseRequest; boost::condition_variable m_conditionPauseRequest; bool m_fSimThreadPaused; bool m_fRenderThreadPaused; int m_iThreadPauseRequest; Thanks again all -John
  11. Thats the problem, thats exactly what I'm doing and the render thread doesnt wait when others are waiting, it just keeps running. See the log from my first post, it loops 27 times before it decides to give up access..
  12. So how would I go about interrupting a thread with a condition, then? Conditions require me to lock a mutex before I can call wait on them, and that's the problem I'm already having. What I need is code that says "at this point check if there are any other threads that want to lock this mutex, if so yield to them, if not continue." Seems like a basic operation, but I'm not sure how to do it.
  13. I have some code that needs to halt my render thread (I'm using boost threads) and it's not behaving, I think I'm not using the objects correctly but unsure where I've gone wrong. Heres the lock code: void ThreadManager::LockAll() { Log("Locking All"); m_mutexSim.lock(); m_mutexRender.lock(); Log("Locking All Done"); } I'm using a boost recursive mutex: ThreadManager.h ... boost::recursive_mutex m_mutexRender; ... Here's my render code, on a separate thread: //------------------------------------------------------------------------------ void ThreadManager::RunRender() { for(;;) { { boost::recursive_mutex::scoped_lock lock(m_mutexRender); if (!m_fRunning) return; m_funcDoRender(); Log("Running Do Render"); } boost::this_thread::yield(); } } So what I expect to happen is 'LockAll' gets called, and attempts to lock the render thread. The render thread then gives up the lock in the yield() call. However, this doesnt happen. Here's what appears in the log: Log: ------------------- Locking All Running Do Render Running Do Render ...(27 times) Running Do Render Locking All Done The render thread renders 27 more frames before it yields! It does eventually yield but theres a long noticeable delay in the game. So what am I missing here? Why wont the 'lock' call grab the mutex straight away when the render thread releases it? [Edited by - johnnyk on November 22, 2009 11:36:08 PM]
  14. Using MSVC 2005. Ok, I'll try that. Anything else thats helpful? Do these 'dev' builds usually link to debug or release runtime?
  15. Hello, I'd like to create a build that has the speed of release and the lack of safety checks, but still retains the ability to step through code, set memory breakpoints reliable, etc. This is to solve two problems: 1. to make a general build I can use to both test gameplay and debug code and 2. to track down a nasty release-only threading problem I'm having trouble with. Whats the best way to create this? I'm thinking I'll copy my 'release' config into a 'dev' config, then turn on a few debug project settings. Anyone have suggestions as to the best settings to turn on? Thanks much for your help -John
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!