Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 06 Apr 2010
Offline Last Active Nov 25 2011 01:41 PM

Posts I've Made

In Topic: Online Rpg Database

17 November 2011 - 12:40 PM

Obviously you don't want to let your client access the database directly, since that will cause all kinds of potential security problems.

You might want to let the client be authoritative on position, since if movement has to go through the server before it's displayed on the client, it will feel very laggy. Whenever the player (client) moves, just let him send a "my position is x,y,z" to the server. As Ravyne points out, you don't need to save the position every time it changes, but you still need to save it on a certain interval. These database writes can be batched for all clients, for better performance. It's not enough to only save the position on log-out, since then information will be lost if the server crashes. A save interval of 5-10 seconds will probably work fine.

Note that this is just for position. For more important updates like "player looted Sword of Doom" you want to save it to the database immediately. Players tend to get grumpy if their epic gear disappears.

If you're scared that people will hack the client and cheat with the position (they will if your game becomes popular), you probably want to do some "sanity" checks of the positioning data on the server.

In Topic: GUI positions as percentages of window resolution

21 April 2011 - 10:42 AM

If you want inspiration from a more advanced system, take a look at wxWidgets: http://wiki.wxwidgets.org/Beech:Using_custom_dialogs_with_sizers

The basic idea is to store your GUI controls in a hierarchy of "sizer" objects. These sizers can be configured to behave in different ways, for example if you want your "OK" button to be in the lower right corner regardless of scaling. Your GUI will basically fit and resize itself automatically. Look at the wxWidgets page above for a better description.

This approach has the benefit of scaling very good with localization (i.e. text being larger or smaller in different languages, or maybe even need right-to-left display).

In Topic: Partial Thread Synchronisation

21 April 2011 - 09:53 AM

Again, best to just do the right thing and wrap your shared data up in a critical-section/mutex to avoid these problems (unless you've got a good reason not to).

Yes yes, I agree with you 99%. My only caveat is that critical sections and mutexes can be quite heavy if overused. Atomic variables with InterlockedExchange()/whatever are often more efficient. Also, the best way to deal with synchronization is to avoid having to do it :)

Good point about remembering the volatile keyword when needed, that fixes one potential bug in the code base I'm working on now :P

In Topic: Partial Thread Synchronisation

21 April 2011 - 09:11 AM

Are you aware of the memory visibility issues that doing so could entail? For instance, the OS might decide that thread A should move g_terminated to some kind of cache and then access that for increased speed. Meanwhile, thread B (whose version of g_terminated resides in RAM) modifies g_terminated. However, it is not aware that thread A has moved its version to a cache, so thread A never gets to see the changed value of g_terminated.

I'm pretty sure cache coherency is ensured on all modern multicore system?

It's not guaranteed which order the caches will be notified if you change a variable like in the above example, but they'll all know it eventually. If thread A is just waiting for thread B to set a bool to true, it will get the new value eventually when the cache is updated.

Some quick googling led to this: http://en.wikipedia.org/wiki/MESI_protocol

In Topic: Partial Thread Synchronisation

21 April 2011 - 06:38 AM

EDIT: By the way, you can't (reliably) have threads communicate with each other like that:

while ( !g_terminated )

Any and all concurrent access to shared data must use some form of sychronization, or else the results are undefined. Each time you want to inspect or alter the value of your g_terminated variable, you must first acquire some kind of lock (read up on critical sections ... use the msdn online documentation). Otherwise all kinds of weird things can happen, such as one thread changing the value of g_terminated but the other thread never seeing the change.

In that specific case, what could go wrong?

If the child thread is simply checking whether g_terminated has been set to true, I can't see how it could cause synchronization problems. If someone was reading the value, doing something with it, and then setting another value - then we'd have a synchronization problem.

From Interlocked Variable Access (Windows) on MSDN:

Simple reads and writes to properly-aligned 32-bit variables are atomic operations. In other words, you will not end up with only one portion of the variable updated; all bits are updated in an atomic fashion. However, access is not guaranteed to be synchronized. If two threads are reading and writing from the same variable, you cannot determine if one thread will perform its read operation before the other performs its write operation.

Busy-polling a variable might be a bad idea for other reasons, like hogging up excessive CPU resources.