Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 17 Sep 2001
Offline Last Active Aug 17 2013 07:29 PM

#4965923 Draw objects in real time

Posted by on 03 August 2012 - 01:04 PM

so is there way to make moving objects in real time, and if possible draw them from that thread instead of glutDisplayFunc

This is not possible because all rendering has to happen within the thread of the OpenGL context. First you need to ensure that the access to the data received from the network thread happens in a synchronised way. Otherwise all kinds of funny effects may occur due to concurrency issues.

You can achieve this by various methods such as employing the producer-consumer-pattern (the network thread would represent the producer role and your rendering thread would be the consumer role).

The term "real-time" must be treated in a relative way when dealing with network communication, due to the fact that network connections are prone to lag for various reasons. You can compensate for this by using motion vectors and prediction algorithms instead of absolute object positions.

Take for example a car. Instead of updating the car's position on the server side and transmitting its updated position, you can instead transmit a movement vector along with the current velocity. This way you can update the car's position on the client side in real time while waiting for updated information (like vector or velocity changes) from the network. In order to keep things synchronised you can also throw in a full state after a certain number of packets to force the client side to update the actual position, for example.

Note, however, that it's far from trivial to achieve satisfying results - a good real time solution can be quite a challenge.

#4963986 Learning Open GL Advanced Features

Posted by on 28 July 2012 - 09:29 AM

My honest opinion on this is that as long as you don't actually need a feature that is not present in OpenGL 2.0, there's absolutely no point in using the later versions just because they are shiny and new. Keep in mind that - for various reasons - even today most game titles are build on the D3D9/OGL2 feature set.
Whether the newer OpenGL versions are supported on Windows XP depends on the graphics card drivers, not the OS (as opposed to DirectX). I only know about ATI/AMD cards and their drivers offer OpenGL 4.0 on Windows XP since late 2010. I'm fairly sure the same is true for NVIDIA. Most Intel cards, however, are stuck with OpenGL 3.2 at best.

#4963974 Obscuring the game code

Posted by on 28 July 2012 - 08:51 AM

I wouldn't worry too much about people reverse-engineering your code. The ones that like to do this will find a way no matter what you do. It is true that .NET assemblies can easily be decompiled into fairly readable C# or VB.NET code. Even professional code obfuscation software can only do so much to avoid this. The question is - why are you so worried about anyone being able to read your code? The suggestion to rewrite parts of your game in C++ doesn't seem practical, btw. It requires a considerable amount of resources that are basically wasted because skilful people will easily be able to reverse engineer these parts, too. You basically only delay them for a bit.

Worrying about your game code "being stolen" is just like worrying about your game's artwork being "borrowed" by others. The only definite way to protect your code and game assets is to never actually release them to the public ;)

IMHO the following discussion might be useful regarding the topic:

The article about writing your own executable packer mentioned in the link above is no longer available, so I took the freedom of finding and attaching it, just in case you are still interested in protecting your code.


Attached Files

#4963936 Basic Game Loop

Posted by on 28 July 2012 - 07:05 AM

Another method that doesn't require fiddling with the Windows API would be to use an event instead:

[source lang="csharp"]using System;using System.Diagnostics;using System.Threading;static class P{ static void Main() { var stopwatch = new Stopwatch(); var timer = (int)Math.Round((1f / 60f) * 1000f); var wait = new ManualResetEvent(false); while (true) { stopwatch.Reset(); stopwatch.Start(); //start update world //end update world wait.WaitOne((int)Math.Max(0, timer - stopwatch.ElapsedMilliseconds)); Console.WriteLine(stopwatch.ElapsedMilliseconds); stopwatch.Stop(); } }}[/source]

This approach will work with a millisecond resolution only, but I seriously doubt that a higher resolution would be required anyway... especially given the fact that Windows is not a real-time OS and won't allocate thread execution time slots at a significantly higher resolution anyway :)

#4963909 Do I need accessors and mutators for every class variable?

Posted by on 28 July 2012 - 04:47 AM

In addition to what was already said, my very concise answer to your question would be: No.
I won't go into any design/architecture points because that wasn't your question, so here's a little check-list that might be worth looking at:
• is the class variable used outside the class it is defined in?
No: make it private. End of list.
• Is the class variable only used by derived classes?
Yes: make it protected
• Is the class variable only used for read access outside the class?
Yes: make it private and declare a read-only accessor. End of list
• Are there any constraints on the contents of the variable, i.e. range checks, consistency issues, etc.?
No: make the variable public. End of list.
Yes: make the variable private and declare a mutator that checks for/enforces the constraints.

While OO-purists would point out that having public class variables is a sign of bad design, I tend to think more practically. C++ is a multi-paradigm language for a reason and I personally see no point in debates over stylistics.

Oops, I just noticed that Alpha_ProgDes wrote exactly this Posted Image

#4961435 Interfaces vs Abstract Classes as a module boundary.

Posted by on 20 July 2012 - 01:55 PM

I wouldn't vote for either interface or abstract class per-se.

In case the module boundary is simply a contract that defines the required properties and operations, interfaces are very suitable, espacially due to the single inheritance restriction mentioned tstrimple. I would argue against the notion that adding methods or properties breaks existing code when using interfaces, though. The safe way of doing so would be to actually define a derived interface.

Personally, I prefer interfaces with some kind of (optionally) abstract default implementation added to the mix. I don't consider base functionality to be "clutter", since - provided said functionality is carefully chosen - it greatly helps with code reuse and avoids code duplication,

In summary I prefer interfaces to define the basic contracts along with (abstract) base classes that provide a basic implementation. That way not a single style is forced upon developers. I regard "pure" abstract classes rather useless, though, in contrast to empty "marker" interfaces, which can be useful and don't hurt anyone except some pedantic "code quality tools".

#4075580 Mouse Cursor hiding / controlling (c++ windows)

Posted by on 07 October 2007 - 11:56 AM

Set the hCursor member of the window class to NULL to hide the cursor inside your window. You can use ShowCursor to show and hide the cursor at any time. Use SetCursorPos to modify the cursor position.