Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 12 Mar 2005
Offline Last Active Today, 10:32 AM

#5258585 Using a physics engine on the server

Posted by on 22 October 2015 - 05:01 PM

But, due to latency, the server will always be ahead of the clients, right? So when the server receives an input with tick count 15 (from client A), it might actually be at _simulationTickCount 30. What does it do in that case? Furthermore, another client, B, which has more lag than client A sends his tick count 15 at 30 server tick rate... What should the server do?

For this type of game, yes: the server lives in the future relative to the clients, or the clients live in the past from the server.


The server needs to operate basically on a sliding window.  When something comes in, the server needs to validate it both with normal validation rules for bounds checking and such, and to make sure it makes sense at that point in time. If it makes sense that a player was at a location and fired at a recent time, it can insert the event back into the simulation and work forward from there. If the time is too far in the past or there are other problems, the event could be discarded or replied to with a failure of some type. If validation shows other oddities like the player being in the future, logging and triggered responses can also be appropriate.


It certainly adds complexity to projects, but done well and coupled with local animations and audio it makes the gameplay experience that much nicer for competitive games.  Especially in systems where projectiles take actual real time to fly through the sky and the simulator accounts for that, it can provide even more realistic experiences.

#5258542 When you Fix your timestep Do you need to change the physics

Posted by on 22 October 2015 - 11:35 AM

When you Fix your timestep Do you need to change the physics?

m_vVelocity += (acceleration)  * timedelta;
//update the position
m_vPos += m_vVelocity * timedelta;

You need to verify that everything still works. That may or may not require changes.



All the forces are small and applying timedelta makes them even smaller like values of V3(0.0003, 0.001, 1.023);

Any time you start working in small slivers you can experience floating point problems.  Catastrohpic cancellation and accumulated floating point error are common issues.


The exact solutions vary based on your implementation details and the specific piece of code.  


Beware of mixing big things with small things, as you only get about six decimal digits of precision.  As a rough example, adding one to a value in the millions can result in no change to the large value.  Shifting that some decimal places, adding 0.0003 to a number in the hundreds probably will not move that floating point value.


Always stay aware of scale, as sometimes a tiny sliver means you are adding the width of a hair or the width of an atom.  A few months ago someone was posting an issue on the forum where they were struggling to understand why their code was having problems, when probed for details he revealed a five-digit order of magnitude difference.  He was applying forces that made changes on the micrometer scale, the scale of hair width or fingernail width, and expecting visible results on the screen centered on a two-meter figure. 


Always be aware of accumulated error; while a floating point number may be precise within six digits but that quickly accumulates. It is often good to make a big change then interpolate across it. It is usually less good to accumulate a large number of those same tiny steps. When you multiply and accumulate the tiny numeric error thousands of times it can make the accumulated numbers totally worthless.

#5258374 please help me teach yourself game programming in 21 days

Posted by on 21 October 2015 - 12:32 PM

While I don't have the CD for such an old book, I do have two side-notes that are closely related.




do not ask people to provide you with something that might break copyright laws

That is correct.  


When book stores have old books, rather than return them to the publisher they rip off the covers and typically destroy the CD.


Sometimes people get their hands on the books marked as destroyed.  Book resellers know better than to accept books without a cover since legal repercussions can be severe, with a six-figure fine per book that could bankrupt the small business. However, sometimes these books make the rounds to a family member or a friend-of-a-friend who is interested in the subject in a well meaning -- but unlawful -- shift.  


Then those people ask all over the Internet for the missing contents of the out of date, out of print book.




I don't see this as a completely unreasonable request that someone ought to be slapped down for.

Taken alone, perhaps not.  


We've recently been hit by a series of posts (purposely not giving other account names out of respect against retaliation) by one or two people who picked up a bunch of old game development books, about 15+ years old, and is begging for copies of the CD, and also asking questions about getting the book's ancient code from both pre-standard compilers and from early C++98 compilers to work on modern C++11 and C++14 compilers. 


Those posts have ranged from polite and similar to this one, just asking for the disc contents, to somewhat abusive demanding strangers on the board fix compiler problems stemming from decades-old compilers.


Those posts are probably the reason michael1978 is taking the ratings beating.


#5258002 Does calling ~myclass() (destructor) deletes the object?

Posted by on 19 October 2015 - 04:16 PM

i think i know why i did it like this. It seems that if i wanted to copy a texture from one to another i shouldn't call glDeleteTextures in destructor. ...

Object lifetimes are critically important to game engines.  They absolutely must be completely correct or your game will suffer serious problems.


They are not a thing that you can guess at.  It is part of the reason C++ is generally a bad recommendation for a first or even second programming language.


Object lifetimes and memory management are perhaps the hardest aspects for beginning programmers to implement, which are commonly cited reasons beginners should go to languages like Python or C# that handle most of that for you as you are learning.


If your programming skills are not yet to the point where you can manage these object lifetimes in c++, out of concern for your own sanity I strongly suggest you move to an established engine that handles that work for you (such as Unreal that uses C++) or that you spend more time mastering the C++ language.  Once you've got a good feel for how items move through the pipeline, how the entire life cycle can work, then try to implement it in the harsh, unforgiving environment of C++.

#5257918 Stencil buffer not working on Android NDK implementation

Posted by on 19 October 2015 - 10:15 AM

Care to post the likely-offending code?  We could try to psychically guess it is in line 374, but that probably isn't right.

#5257915 Problems writing a BMP exporter

Posted by on 19 October 2015 - 10:09 AM

Please don't edit discussion topics as "solved".  As these are discussion boards rather than StackExchange-style question/answer boards, there may be other solutions or discussion that can follow that won't happen if you edit topics that way.

#5257829 Need help with a simpe movement bug

Posted by on 18 October 2015 - 05:13 PM

Are you using Unity's FixedUpdate() function, or Update() function?


Update is used for non-physics objects and user input. It is called irregularly, and deltaTime may be nearly any value.  Use it if you need something to happen every frame, no matter when that frame actually hits.  Be careful about doing motion here.  While it is more smooth (the function happens each frame) it is less regular with different results on every device.


Any time you are working with physics manipulation you should be using FixedUpdate(). While the results still won't be identical between machines (Unity does not make that guarantee) at least with FixedUpdate() you'll have more consistent results between machines. You'll also want to use Time.fixedDeltaTime for the step. The built-in physics system triggers immediately after FixedUpate(), so it is especially important to make any physics-based changes here.  These are more regular and more dependable, but different from each frame's update.

#5257156 Architecture for Isometric Style Game

Posted by on 13 October 2015 - 07:45 PM

Your objects' relative sorted positions should be fairly consistent frame-to-frame, right? In that case, use a sorting algorithm that works quickly with already-mostly-sorted data (like insertion sort).

For an isometric game the ordering is going to be *EXTREMELY* consistent frame to frame.  Whatever is inside the frustum may change, but the process of rendering is walking a grid.




There was an approach that worked extremely well when hardware was based on tile-based rendering, but tends to degrade quickly on today's hardware.  An isometric world is just a regular grid.  You traverse the grid so the most distant row's sprites are drawn bottom to top.  Then you draw the next closest row drawing the sprites bottom to top.  SO if a tile has three sprites on it you draw the bottom sprite, the next higher sprite, and the highest sprite.  You can go right to left or left to right based on whatever traversal pattern works easier for you, always working from graphically back row to the graphically front row, each tile bottom to top.


That worked amazingly well back when graphics cards were designed for tile-based sprite rendering because ultimately you were passing a simple array of sprite indexes. 


These days when graphics cards are designed for point-cloud soup, those same tile-based sprite rendering calls that worked before tend to quickly saturate the modern system's data bus.  You may end up making 5000+ or 8000+ or 10000+ individual draw calls for all those tiny little tiles, and it degrades performance.




So as an alternative these days, one magical solution is to either pre-render the static section of the world into large images or to render sections of the world at run time, and use a fun tool called a "depth image".  


A depth image is basically a snapshot of the depth buffer.  You render the isometric screen as a static 2D image and also capture the recorded depth at each point of the image.  Then when it comes time to render you make a single draw call that does all the background (ignoring the depth test) and another call that writes the values to the depth buffer. After you've got your background static sprites rendered in one large block, you can then draw your dynamic sprites, whatever for or five or ten small images you need. 


This gives you a small number of draw calls for the big background of static tiles -- perhaps four or six draw calls if you broke the mega-image into pieces -- plus the five or ten or whatever you need for your dynamic items.  


We'll call that roughly 20 draw calls versus 8000 draw calls.  A little more work up front, but far more efficient for the frame-to-frame rendering of isometric worlds.

#5257153 C++ mysql exception

Posted by on 13 October 2015 - 07:27 PM

The message "Table has no partition for value xxx" is fairly self-explanatory, and should make sense immediately if you are familiar with SQL partitions already.


While I could take a more direct approach and ask more about your partitions, (um, perhaps you can SHOW how you CREATE your TABLE and describe your partitions wink.png )  we can also follow ApochPiQ's lead and ask what kind of terms you have searched for already.  :-)

#5257084 Task Scheduling Question.

Posted by on 13 October 2015 - 12:01 PM

Looks like you are confusing threads with multiprocessing and multitasking.  I suppose that's an easy enough mistake to make since many times they are used for that, but threads have many purposes beyond multiprocessing.




The reason for my multi-tasking is that currently Quad Core systems are actually incredibly common. Programming for just a single core isn't quite targeting the common minimum specification. It would be more like targeting walmart computers built in 2005. Plus being mostly a hobby and learning experience, it'd be pretty counter intuitive to dial back a few steps.


Multi-tasking is one use for threads.  There are many parallel algorithms that work extremely well in multiprocessing environments.  They're also fairly advanced and prone to error.  Learning how to write multithreaded code and multiprocessing systems can be useful skills, just be prepared for the complexity it brings. If you thought debugging a single threaded program was hard, it gets roughly exponentially harder for the number of multiprocessing tasks you add.


Now in addition to using them for multiprocessing, you can also use them for organizational purposes.  It sounds like your description was to use them for organization, on a per-component basis.  




So... instead of tasking... you had each character existing as an OS thread. That sounds ridiculously expensive. If memory serves correctly... you had approxmiately ninety somethin lots in the sims. And god knows how many characters.


Threads are not inherently expensive, although they do have a cost. They are not inherently good or evil.  They are an organizational tool to help organize your processing.


Threads can be scheduled, started, stopped, and otherwise manipulated.  That is their power. That is why they work so well for multiprocessing. 


In the case of The Sims 3, there were threads for non-simulation tasks; threads for audio, rendering, and so on. These were there to take advantage of multi-processor systems. Those tasks could take place independently of each other, and independently of simulation.  That is one of many great uses of multiprocessing.


The simulator had its own thread to control the workload.  The simulator owned a series of other tasks for organizational purposes.  One great use of threads is that since they can be started and stopped independently, if one thread crashes you can continue your program.  The simulator in TS3 had a large number of Sims to simulate, each one had a potential of crashing, stalling, or otherwise causing problems to the entire app.  By organizing them in their own individual threads, each one could be started or stopped individually. In the event of a critical error, the data items associated with the thread could be reset to a sane state and their processing restarted.  A very small number of autonomous objects in the game also needed to have their own simulation running, these were created along with the other states. 


Note that like all large games, not all the world is updated all the time.  By using threads to control the workload, and by having the individual objects managed by spatial rules, only a small number of them need to be active at any given time.  While the game world itself may have tens of thousands of game objects, normally TS3 had only a single active lot at a time needing active simulation, plus a small number of neighboring lots that needed occasional simulation. 


Just because it used a large number of threads for organizational purposes does not mean they ran through the system like a stampede of raging wild elephants.  Each was tightly controlled and run individually as an organization tool.  More like a set of tightly-reined stallions being shown through dressage. 


Controlling your threads is an important part of multithreading and multiprocessing design.  You can let them run wild, like a stampede; this is most likely for someone inexperienced, you are unlikely to get good performance.  You can have them running carefully trained for peak performance, like the Grand National or Kentucky Derby. You can have them tightly controlled and methodical, like the Lipizzaner Stallions. 




Er... why do these need their own threads?


One example was a set of gambling objects: an automated poker table, roulette table, and blackjack table. The table had a robotic dealer as part of the game object, shown below:




When sims sat down at the table, the robotic dealer needed to wake up and have all its simulator steps happen. The robotic dealer needed quite a lot of processing and animation, and was best implemented as its own actor in the sim world. When the poker table cleared out and sims were done using it, the robotic dealer would effectively shut itself off, triggering the end of the thread.


These types of objects were the exception rather than the rule. Most of the times the sims themselves went around the world and triggered their own interactions with game objects. The sim's processing thread would call into a game object's interaction and trigger a TV turning on or off, or trigger the lights changing, or trigger whatever else to happen. There was no need for individual components, such as moodlets or traits to have that type of processing.





I am trying to have my game-objects determine their dependencies before the scheduling pass to the task threads. That is to put data dependencies in the correct order, and all strongly dependent items in the same job. Similar to what was done in Shadow Fall. 

I understand THEIR dependencies, since they were reviewed at length.  Their dependencies were caused by coupled systems -- object updates were too intimately tied to animation and world manipulation.  These could have been avoided (or significantly reduced) by making them either asynchronous or having the tiny simulation job block for a single task as the external simulator ran the blocking operation and other jobs continued.


The question is: what are YOUR dependencies that require it, and can you work around them?  Chances are good the dependencies can be removed with a little thought and cleanup. It is likely less difficult than writing a more complex scheduling and prioritization system for a CRPG simulation.

#5257072 C++ virtual inheritance

Posted by on 13 October 2015 - 11:07 AM

struct C : virtual public A, virtual public B {
C() : A(5) {}

If your virtual base class stores values like that, you are almost certainly picking the wrong pattern for the job.


Virtual inheritance is really useful in a small number of cases. Except for those very few times, it is the wrong solution. Generally the only time it is useful is base classes that are purely utilitarian, mandatory within a wide number of classes, yet useless unless part of another class's functionality; the base must provide the functionality to a tree that requires multiple inheritance, yet must only have a single form of the utility it provides. It is an extremely uncommon requirement.


One of those very rare cases is the C++ ios_base class, inherited with virtual inheritance.  It has IO flags constants (decimal, octal, hexadecimal, left-justified, right-justified, etc), locale information, and stream constants (good, bad, fail, eof).   Note how these are pure utilities, they exist in all types of streams, and are otherwise useless without an actual stream.  No matter the type of stream (input-only, output-only, input-and-output) it still must only have a single instance of these utilities. Having more than one instance of the utilities would be nonsensical; you cannot logically have two states one with "fail" the other with "EOF", or two sets of flags indicating both decimal and hexadecimal formats.  In this very rare case where the design requires multiple inheritance and also shared behavior with a single base, virtual inheritance is needed.


Out of the tens of thousands of classes I've worked with over the years, the number of times virtual inheritance has been the right solution is something I can count on my fingers.  It is a very rarely used solution, but in those rare cases it is important to have.




In your case where you demonstrate feeding a virtual parent class with a parameter, it shows you are not in the very rare situation where virtual inheritance is the right solution.


Since your class is specifying a parameter to the base, that means another class could also specify that type of parameter to the base, with the result that you are constructing the single base more than once. Attempting to construct it more than once won't do what you want for all but one of the places where it happens.  

#5256913 Task Scheduling Question.

Posted by on 12 October 2015 - 01:46 PM

I understand that a lot of implementations uses a preupdate to determine the scheduling. But the only example I could find was Intel's Nulstein, which had unchanging dependencies. At least as far as I could tell.
But how do you go about this preupdate if your game world is mutable? Or is it a matter that every object has three primitive functions to call? PreUpdate, FixedUpdate, OnFrame

My suggestion would be to not use them.  Only have a regular fixed-time update step.  Having a pre-update and post-update add complexity that can generally be avoided with a bit of design.


I don't see what you described as a scheduling problem or dependency problem. 


While games often benefit from having multiple cores and parallel processing, generally the core functionality of the game needs to run on minimum spec, which often means you should be able to perform your work on a single core or dual core machine.  You can take advantage of additional processor if they are present, but you generally shouldn't build your game with the assumption that you can always be parallel.


I've worked on several games where the engine had a pre and post update step, but we found in practice they were almost never used, and those few times they were used tended to be work that could have been accomplished just fine in the main simulation.  In one particular in-house engine (used for a game and three sequels) we ended up disabling the pre/post update steps to recover the sliver of processing time.


What specifically are you attempting to do in your preupdate step?  What is it that you cannot do with one round per simulation step?




I've worked on quite a few games that didn't follow that model, and I don't think it caused problems. I don't think the dependencies are are big as you are making them out to be.  They might be for your specific game implementation, but I can't readily imagine them being so as a matter of course.


The Sims 3 had a thread model superficially similar to yours.  Instead of threading each component, there were several game tasks that had their own threads (audio, rendering, etc) but critically all of the individual Sim characters lived in their own thread. 


We didn't have threads per component, there were lots of components that could be added and removed, just threads per actor in the simulator, and some work threads in the engine. 


The simulator behaved as though everything was serial. The simulator used the threads both as an organizational tool and as a safety tool. If something happened to a thread, either it stalled or crashed, the simulator that controlled the thread would reset the Sim associated with the thread and any objects they were using, then start a new thread setting the Sim to a safe idle position.


Some actions in the simulator threads were immediately run, but much of it was queued, hidden behind the scenes inside the engine and away from the simulator. Requests to move were exactly that, a request. As a wonderful side effect of the "every sim is a thread" model, when there were requests that required a bit of time, the individual thread could be suspended or otherwise worked around if it made a blocking request, the rest of the game could move on.  


With all of that, there was never really a need for pre/post update steps in the simulator for the game. If code needs a delay for time there are many options available, including using clock tools where you can add a timestamp to test against, with both wall-clock times and simulator-clock times available. If you need something to take place in the next update set the alarm for now+1




Basically anything that exists in space and needs to be updated, or has function that is triggered by event. Lights are forced to implement this. Why? Because lights can flicker, may be snuffed out., change color, etc., Can be turned on and off. Concidering the engine is designed for CRPGs where this sort of element is needed. I am not changing it.

I'm not so certain that these need their own threads.  We had similar actions in The Sims. Flickering can be done by an animated texture that is handled by rendering, or by registering a timer with a callback alarm rather than requiring a full thread. Other changes to the light, such as being turned on or off or changing color, are caused be being interacted upon by an actor in the game (using the character's simulation update) or by the player directly (UI thread). 


There may be a small number of items that require their own simulator thread, but we found in practice nearly everything can piggyback off callback alarms, character simulator updates, or the UI's direct interactions.

#5256905 MySQL applications for a game

Posted by on 12 October 2015 - 12:42 PM

Would MySQL highscores/leaderboards be sufficient to get a financial analyst job or would I need to make a standalone app which relies only on databases?

Depends on the job.


If the job is for a junior developer, or for someone who rarely works with database, or for a position where they are willing to help you learn, then maybe.  But if it is for a job where they expect many years of experience and competency, probably not.


During an interview a good interviewer will ask questions that go deeper, and deeper, and deeper, until they figure out how much you really know.


Normally a technical interviewer will start simple, asking you for the code needed to retrieve a few values, how to insert some values, update, and delete. Then they'll ask harder questions, like some joins, some tabular computations like the best in a list, or code to help with pagination (display 1-10, 11-20, 21-29, ...), and similar. They'll dig deeper asking about indexes and maintaining indexes and using hints. They'll ask about security models. They'll ask about data correctness. They'll ask about isolation levels and concurrency tickets.


And they'll keep asking questions until they really know how much you know.



If you are looking for a job requiring 5+ years of database programming experience you should not expect to get the job if your exposure is writing a high score table one time.


But if they are looking for someone who has had a small amount of exposure and are willing to work with you because you know the rest, then you might be a great candidate.



Just don't lie, because they WILL discover it sooner or later.  Lying is an effective way to either get passed over for the job if they catch you early, or fired from the job if they catch you later. 

#5256457 Do you use friend to avoid security problems ?

Posted by on 09 October 2015 - 06:43 PM

I suppose the original poster might be thinking "security" as in "network security", even though that has nothing to do with C++, maybe more like a SOAP or REST interface.



In that type of scenario when you are concerned about authorized sources, any exposed method can also require an authentication token. Discard unauthorized or unauthenticated commands, either silently or with an appropriate error, based on your usage needs.  


As an example, the APIs for point of sale terminals and credit card readers are publicly available and widespread. The public API for transferring funds through banks, through credit card systems, through PayPal, through other systems can all be found with a few seconds of searching.  Even though the details are public they require proper authentication before any transactions are completed.  


Public availability does not mean insecure.

#5256453 Do you use friend to avoid security problems ?

Posted by on 09 October 2015 - 06:23 PM

For example a public function "Notify" called by all class managed by this class when something change.


I don't follow.


Those needing to be notified can register a callback function. A public add/remove pair can handle any system wanting notifications.


If the object needs to be notified, expose a function that triggers a refresh or update.


Notification in either direction does not require access to private members.  Both can be part of the public interface.