Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 16 Feb 2000
Offline Last Active May 18 2016 08:31 PM

#5210886 Disassociate mouse with its position

Posted by on 15 February 2015 - 04:02 PM

Someone can correct me if I'm wrong, but I believe that DirectInput is depreciated. It's been a LONG time, so I may be thinking of something else.

Yes DirectInput is actually deprecated as it really was just another layer sitting on top of RawInput, so you would definitely not want to go that way.

#5170226 I'm A Programmer, Not An Artist

Posted by on 29 July 2014 - 09:29 PM

You mentioned that you are using Unity, you should check out the asset store as there is actually a ton of free content that you could use to start building out your game.

#5162473 Game content source repository?

Posted by on 23 June 2014 - 10:40 PM

Perforce. I don't think there is anything out there that is going to touch it for this purpose.

#5136013 Large textures are really slow...

Posted by on 02 March 2014 - 11:48 PM

On PowerVR chips simply using discard even once in a single shader will disable a lot of optimizations hence the larger than normal performance hit. For devices using PVR you want to optimize your geometry as much as possible avoiding overdraw, and at the same time remember that alpha blend is nearly free due to the way the TBDR renders, whereas rejection using discard or depth testing is costly.

#5135937 Large textures are really slow...

Posted by on 02 March 2014 - 05:42 PM

Alpha testing, the ancient silly way ("enable(GL_ALPHA_TEST)"), is deprecated (ie. not to be confused with not supported) - it should be done in shader directly (ie. "discard").

It cuts down bandwidth from areas that are hard or impossible to efficiently reach with the geometry approximations - in short, it might be worth experimenting with (although "discard" might be slightly costly [with no depth test] on amazingly-badly-engineered-garbage-hardware ... to be fair, i do not know if mobile devices do qualify for that title or not. So, might be of no use to you, but i thought i clarify the alpha test anyway).

discard is actually destructive on nearly all current mobile chips and should be avoided at all costs, especially if you are targetting mobile devices that are a few years old. There is always a better way (performance-wise) even if some are slight asset hacks. Also null blends are vastly cheaper than using discard at least on PVR chips.

#5135285 Game engine with realistic water?

Posted by on 27 February 2014 - 11:16 PM

The reason I mentioned C4 is because it actually has a ton of water simulation that you're not going to find in any other engine that I've seen (I.e. actual wave simulation that affects objects in the water). Also regarding the river creation and painting tools those will be included in version 4.0, which they're showing a preview of at GDC is year.

#5134683 Game engine with realistic water?

Posted by on 26 February 2014 - 02:31 AM

You could look at the C4 Engine which has quite an in-depth and featured water simulation system.

#5001644 Which engine to use ?

Posted by on 16 November 2012 - 03:41 PM

You don't need an engine for any of those games at all, you could just build the games without having to worry. When you start getting into 2d graphics you could just use something like SFML.

#4997530 Drawing game area

Posted by on 05 November 2012 - 05:19 AM

You need to google for "terrain rendering" and you will find many different algorithms with various tradeoffs and specialized for various implementations. They generally get the needed data from a heightmap and build a triangulated mesh which can also account for LoD, etc... although there are other implementations such as the voxel terrain system in the C4 engine.

#4997253 Understanding the concept of Smart Pointers

Posted by on 04 November 2012 - 12:25 PM

The main point of the pointer classes is to control ownership.

If the object is the sole owner of an instance you should use std::unique_ptr<>
If the instance can be owned by many objects you should use std::shared_ptr<>
If the instance is used by another class but is not owned you should use std::weak_ptr<> (the pointer is not owned and may not be valid)

Regarding when to use them it really depends on your overall architecture. For most things I return references and use shared_ptr<> sparingly as I like to have ownership clearly defined, and for things like handles I keep a weak_ptr<> to the subsystem.

#4996724 Moving from Java to c++

Posted by on 02 November 2012 - 07:14 PM

I do not think the manual memory management is going to be a "horror".

I agree as realistically if using C++11 and RAII properly there shouldn't be much worry about memory management/leaks at all. As mentioned above there are also good tools for tracking things down if needed.. although using std::unique_ptr, std::shared_ptr, and std::weak_ptr effectively really makes things quite simple. I actually find memory management easier in C++11 than using garbage collected languages as the pointer classes are safe and I still control their actual point of destruction... imo it's a win-win.

#4996542 Question on boost::shared_ptr

Posted by on 02 November 2012 - 08:41 AM

You have to lock a weak pointer which turns it into a shared pointer for the duration of the scope. For example std::shared_ptr<ObjectManager> manager = m_objectManager.lock();

#4996510 Good community / team / chat or anything really for newbies to collaborate on...

Posted by on 02 November 2012 - 06:16 AM

The classified section under "Hobbyist Projects"

#4996292 I Need Help.

Posted by on 01 November 2012 - 01:48 PM

Ah thank you, I have heard from somewhere that C++ was easy

Make sure you never listen to the person that gave you that advice ever again!

#4996275 Question on boost::shared_ptr

Posted by on 01 November 2012 - 01:05 PM

Note that if you create multiple shared pointers to the same raw pointer (as noted above never to do) they will each hold their own reference count therefore deleting before the other is out of scope. That is what you should always construct shared pointers with either shared_from_this() in the class or make_shared() elsewhere.