Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 08 Aug 2000
Offline Last Active Today, 08:50 AM

#5233490 What should I do now that I implemented a game mechanic that is not popular a...

Posted by BitMaster on 08 June 2015 - 01:54 AM

The trick is giving people what they need, not what they want.

Your mileage may vary but in my experience the people who are the loudest in game forums are also the ones least likely to have well thought out and reflected opinions. Of course that also depends on the game and actual community, for example a lot of the people over at the official Age of Wonders III forum are markedly distinct from what I'm used to in other games. I still wouldn't blindly implement any change suggested on those forums though, either.

#5231638 graphics programming with C++

Posted by BitMaster on 29 May 2015 - 05:58 AM

Learning how to do something like setting up a window without help is certainly a worthy goal. As is writing your own linked list.

However, think long and hard before using either in actual code to get something done. Working on something to understand it better is one thing, but getting something to production quality is a completely different beast.

Apart from that, SFML (and similar libraries) work on Macs, Windows and Linux (sometimes more). Getting your own code to work on all those platforms is not easy, even if you have access to all those platforms.

Also the "pain in setting it up" in setting it up you are worried about is a key skill. You will need some external libraries at some point unless you never progress far beyond some hello world. Learning to deal with the problems here is important and it gets significantly easier when you learn about the usual pitfalls. It also forces you to learn about some low-level compiler/linker issues which are an often overlooked part of "want to know how things work".

#5231420 Is it advisable to use a scoped_ptr in CreateFrame? (D3DX9)

Posted by BitMaster on 28 May 2015 - 01:11 AM

When I do this
D3DXLoadMeshHierarchyFromX(..., &mRoot,...);
The D3DXFRAME mRoot should be getting a shared_ptr instead, but it still throws exceptions at me when I do so...
probably this object in the CMesh class has to be a shared_ptr as well.
boost::shared_ptr<D3DXFRAME> mRoot;

You seem to have some fundamental misconceptions here. A managed pointer (whether is is boost::scopred_ptr, std::shared_ptr, std::unique_ptr or any other) is not change-type-and-forget replacement. It requires significant engineering to get right. According to the documentation D3DXLoadMeshHierarchyFromX wants a pointer to a pointer to an D3DXFRAME. Not anything else, certainly not a pointer to an boost::shared_ptr<D3DXFRAME> which is (despite similar semantics) a completely different beast (and if you think about casting the error away, that will just blow up; badly).
What you need to do is something like that:

D3DXFRAME* tempRoot = nullptr;
HRESULT result = D3DXLoadMeshHierarchyFromX(..., &tempRoot,...);
if (result is a success)
   mRoot.reset(tempRoot, [] (D3DXFRAME* p) { /* release p in the correct way */ });
   // ...
   // handle error, clean up tempRoot if it was allocated even with the error...
Also note that you cannot just pass the D3DXFRAME* into a shared_ptr (or any other general smart pointer) because as far as I know you cannot correctly free that with a 'delete'. That means boost::scoped_ptr is out, although std::unique_ptr can have a custom deleter. Note that you can forgo the added deleter in the mRoot.reset(...) call if you correctly specialize std::default_delete.

However, these technical details aside, the important points of this thread are that you really need to think about things like ownership. You cannot just throw smart pointers at the problem in the hope it will go away.

#5231299 Nondeterministic access violation (in driver thread?) when creating 12th/17th...

Posted by BitMaster on 27 May 2015 - 12:13 PM

Can you avoid the problem by intentionally staggering the window creation over a longer time (at its simplest by doing a Sleep(100) after every create call)?

#5229856 Another basic array C problem

Posted by BitMaster on 19 May 2015 - 11:34 AM

If you are not writing something that needs to be cross-platform there is no reason whatsoever to not use Visual Studio Community edition. I don't know what wintertime is concerned about above: a "Microsoft account" is just a banal free account that you might even already have if say, you, ever set up an outlook.com or hotmail email address. Anyway it takes about a minute to create an account and is free.

I would not agree with that. I'm using MSVC at work and I'm now using QtCreator with MinGW at home for my hobby. The only thing I miss at home are the debugging tools MSVC has (although QtCreator certainly has become more comfortable since I have started using it). For everything else I need QtCreator (and the compiler with extremely decent C++11/C++14 support) is doing an equivalent or better job.
That said, for someone new to C++ I would still recommend to start out with some kind of reasonable MSVC. It's simpler to find help on the weband especially precompiled libraries.

If you do care about being cross-platform there is still no reason to use Dev-C++ which hasn't been updated in a decade at this point.

While I can agree on the verdict (avoid Dev-C++ at all cost), the statement as given is not completely correct. Bloodshed Dev-C++ has not been updated in more than a decade, but there are two or three much newer forks around (although I think one of them is a bit abandoned again). However, I still would not advise anyone to use any Dev-C++ at this point. Code::Blocks and QtCreator are decent alternatives to MSVC (still not what I would suggest to a newbie, though, as said above).

#5229820 Triangulation

Posted by BitMaster on 19 May 2015 - 08:31 AM

A combination of this and this should probably get the job done.

#5228774 Casting Problem

Posted by BitMaster on 13 May 2015 - 06:46 AM

Yeah, I think I quoted that too lazily to make sufficient sense.

Still, mentioning the perils of over enthusiastically writing your own copy constructors in a thread by someone obviously very fresh in C++ is not a complete waste of time...

#5228764 Casting Problem

Posted by BitMaster on 13 May 2015 - 06:12 AM

IInitiationSettings& GraphicsFactory::createInitiationSettings(const char* title, bool vsync, bool fullscreen, int width, int height){
	return OxygineInitiationSettings(title, vsync, fullscreen, width, height);
Please remember, that your object exists only temporary and you need a copy-constructor on the calling site to keep it (not a reference).
Therefor this will not work in my opinion:

What happens if you change your code to this:

IInitiationSettings& GraphicsFactory::createInitiationSettings(const char* title, bool vsync, bool fullscreen, int width, int height){
	return *(new OxygineInitiationSettings(title, vsync, fullscreen, width, height));

Certainly true, but you do not need to provide a copy-constructor (actually, in most cases it is harmful to do one by hand) since the compiler will generate one for you (provided all members can be copied).

#5228760 Casting Problem

Posted by BitMaster on 13 May 2015 - 06:05 AM

Does not work, I still get access violation..

If built with suitable debug symbols, what does the stack trace of your debugger look like at the crash point?

#5228759 Casting Problem

Posted by BitMaster on 13 May 2015 - 06:04 AM

I don't think that will work at all. dynamic_cast can, by definition, fail to convert types. If it fails it returns a null-pointer. If you are certain a cast should always work then you should use static_cast, not dynamic_cast.

So either
OxygineInitiationSettings* settings = dynamic_cast<OxygineInitiationSettings*>(&initSettings);
if (settings != nullptr) ...
OxygineInitiationSettings* settings = static_cast<OxygineInitiationSettings*>(&initSettings);

#5228708 Trouble with if statment in shader and loading array of mat4 to uniform

Posted by BitMaster on 13 May 2015 - 01:11 AM


I'm not sure but are you allowed to do a branching read like that? Since the branch depends on the current fragment, don't you have to read both textures branchless into temporary variables first?

#5228586 Different GCC Versions Resulting in Different Output

Posted by BitMaster on 12 May 2015 - 09:31 AM

I never blamed the compiler for the behavior, I was merely saying that was the favorite bug I had come across so far.

Uninitialized variables can be a bitch to find, but having compiler issues is very, very common.
At the moment we have had a guy working for two weeks to get code that runs perfectly on the old SDK, and doesn't run at all on the new SDK working.
All the issues he has found so far have been compiler issues.


Calling these compiler issues shifts the blame on the compiler in my understanding.

#5228519 Different GCC Versions Resulting in Different Output

Posted by BitMaster on 12 May 2015 - 05:10 AM

The optomising away behaviour is exactly what is happening.
The compiler is saying "what a load of bollocks, cannot possibly happen" and throws it away.
Sadly that isn't the case, it can and does happen.

I think we all have done things at some point we aren't proud of and which relied on various levels of undefined behavior. However, I would say what makes people annoyed with you here is that you have the arrogance to blame resulting problems on the compiler. Sometimes you have to do nasty undefined things to get something extremely important finished in time.
But if you need to do that, you sure as hell do not change compiler versions during your project lifetime. And if you do, you gracefully accept that you might have to fix all of your undefined behavior without blaming your tool.

It has to do with dynamic objects with multiple class inheritance in a multi-threaded environment.

Nothing in that list really explains or excuses what I have seen above. Out of interest, what kind of library/middleware are you talking about? It might be useful for an early discard decision.

#5228309 Passing an Object Constructor as Default Parameter : Bad Idea?... Not working...

Posted by BitMaster on 11 May 2015 - 12:28 AM

So problem solved: It just wasn't using the latest value of the default parameter for every run of the program. Think I've experienced similar problems before...
Why does this sometimes happen when you don't have to manually rebuild for most code changes and it automatically knows to use the latest versions of the altered files?
You'd think any minor change would be important and that the compiler would make sure to account for everything all of the time.

As I guessed in my first post, your dependencies are not properly set up. For example when using MSVC you need to place all relevant files (anything that might get changed at some point) in the project file, especially headers. You also have several options to modify/disable dependencies between files in the project but unless you modified the settings there you should be usually good.

#5227376 Passing an Object Constructor as Default Parameter : Bad Idea?... Not working...

Posted by BitMaster on 05 May 2015 - 02:33 PM

The code as you have posted it should be working as intended. Something else must be going wrong, although with what little information is given I'm at a loss to what exactly. If I were forced to guess I would put a little money on a dependency screwup though.