Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


BitMaster

Member Since 08 Aug 2000
Online Last Active Today, 04:43 AM

#5237049 delete file on Windows

Posted by BitMaster on 27 June 2015 - 01:25 AM

Again:

If you want a string containing "\\" you need to use "\\\\" in the source. If you want a string containing "\" you need to use "\\" in the source.


"\\\" in C++ is completely broken though. It means a string containing a \, followed by " and then the string ends without being ever probably terminated, hence the compile errors.


#5236875 c++11 lambdas: best practices for 0 dynamic heap allocation?

Posted by BitMaster on 26 June 2015 - 12:57 AM

The lambda itself will not allocate anything dynamically. If you store the lambda somewhere (for example an std::function<>) it might have to allocate memory (depending on the size of the lambda and std::function's implementation details). Note that if you transfer the lambda somewhere using a template, like


template <typename Functor> void doSomething(Functor f)
   { ... }
this will not require any dynamic memory allocations either (unless of course something you captured by value requires requires dynamic memory allocations for its copy construction).


#5236724 delete file on Windows

Posted by BitMaster on 25 June 2015 - 07:19 AM

(G:\\...)


If that path is actually contained in the string, it is most likely wrong. You have to escape the backslash when you write the string in the source file (unless you can use one of the nifty string features in newer C++ versions) not in any string. Also note that a lot of Windows functions can deal with '/' instead of '\' as the path separator.
Edit: To make it slightly clearer:


std::string test1 = "G:\\test.txt";
// test1 now contains the string "G:\test.txt"
std::string test2 = readFromMyFile();
// if test2 now contains "G:\\test.txt" then this is wrong for further file operations
Assumining the readFromMyFile function just does a straight forward read, the file (or similar source) has to contain a line like
G:\test.txt
End Edit.

Also, note that DeleteFile returns 0 if there is no error. If there is an error you need to call GetLastError to retrieve a more detailed error code.


#5235249 comparison between signed and unsigned integer

Posted by BitMaster on 17 June 2015 - 01:16 AM

You explicitly force the compiler to convert a GLuint into an int and then compare it to another GLuint. Not only is the cast completely pointless, it is also the source of your warning.

Edit: also, if you need to cast get into the habit of using proper C++ casts like static_cast or reinterpret_cast, not pure C casts which do not convey any intent and are difficult to find.


#5235103 Why do you need the .h .cpp AND .lib files?

Posted by BitMaster on 16 June 2015 - 06:58 AM

It was probably a mistake to post a question like this in "For Beginners". While well-meaning I fear the posters so far did not get the actual question you are asking and go into details which I believe from your post you already know.

To answer that: Usually you should not need to add implementation files if you are already linking the static library. In fact, that will result in linker errors because there are two definitions of the same function. What exactly goes wrong in your case, I cannot say. One possible scenario is that the project you downloaded was initially intended to build its own 'libyaml-cppmd.lib' and link it directly. Maybe you broke that configuration. Maybe it was already broken when you downloaded it. Maybe it relies on having a specific environment variable set or a path added to the global linker settings. Maybe the dependency between targets just got broken.


#5235030 Slow down when using OpenMP with stl vector per thread

Posted by BitMaster on 16 June 2015 - 01:10 AM

The function resize() is equivalent to -- and sometimes implemented as, calling pop_back() a bunch of times. Reserve the space first. You have potentially just caused n reallocations to trigger, and potentially just triggered n! (n factorial) moves.  Most standard library implementations use bigger buckets, but some of them only allocate in very small increments, a few memory-conscious implementations only increment by one by default.


First, I think you meant 'push_back', not 'pop_back'. And then, are you certain about that? I just checked the documentation and the promised complexity is 'linear in the difference between the current size and count', not 'amortized linear' as would be expected when using a bunch of push_backs.


#5234910 glDrawArrays significantly better than glDrawElements

Posted by BitMaster on 15 June 2015 - 10:53 AM

As the wiki article I linked says:

The first way is to call glBufferData​ with a NULL pointer

is enough for basic orphaning, no buffer mapping required.

Second, as Spiro already mentioned, unless the data you are rendering can make good use of indiced calls it's just dead weight. If your indices are more or less (0, 1, 2, 3, ..., n) it's just an extra step of indirection without any benefit. Are you actually able to significantly reduce the number of vertices by using the indexed calls?


#5234847 glDrawArrays significantly better than glDrawElements

Posted by BitMaster on 15 June 2015 - 02:44 AM

Yes the VBO is updated every frame, but I'm confused why this is being considered created every frame. The memory is already allocated for the VBO buffer and that memory size does not change. I'm just updating it


That in itself it part of a problem. Uploading new data into a buffer object usually forces the driver to artificially synchronize. One simple way to avoid that is by explicitly orphaning the old buffer as described here.


#5234469 float value increment in a loop?

Posted by BitMaster on 12 June 2015 - 11:00 AM

               for( float f = 0.3; f< MaxValue; f=f+0.3){
                          .....
                }


Compiles fine on MinGW 4.9.2.

Edit: since the 'Java' bit was retroactively added:
for( float f = 0.3; f< MaxValue; f += 0.3f)
should probably do it. The actual error message would help though.


#5234055 Assimp 3.1.1 and FBX

Posted by BitMaster on 10 June 2015 - 08:50 AM

Googling for 'OgreMeshUpgrader download' leads me to this page with 'Ogre Command-line Tools (1.7.2)' which, according to the description, should contain the tool.


#5233870 IDEs vs editors

Posted by BitMaster on 09 June 2015 - 01:09 PM

However, more and more projects have begun using CMake so it can't be that bad. tongue.png

[...] Guess what, CMake's support for packaging Mac application bundles haven't been maintained in years.


I have a different story to tell. We needed Mac packages (obviously in a hurry) we could distribute to clients. With no real MacOS knowledge I was able to get some decent packaging going with CMake within a day or two (which included some bug fixing/compiler appeasement because the application was never built on Macs that way). Someone else then needed a bit more time get the automatic signing in. However, when all was said and done we could generate several individualized packages with a single make call.

I freely admit CMake is far from ideal, but my work project was developed on two different platforms (without CMake) by different people and getting all changes synchronized was annoying (to use a polite term). It's now built on four different platforms plus a fifth for some tools and background infrastructure (with CMake). Dealing with CMake is a tiny price to pay to avoid practically all of that platform chaos.

Personally, I'm using it for my hobby projects at home too. I'm having far more success getting CMake to generate decent custom build steps than I had with MSVC alone (easier to recycle and extend them as well). Also, I like not nailing myself down to one IDE/compiler. I have been breathing MSVCs nearly all my C++ career and it certainly made me pick up some annoying habits. Using a different compiler certainly made me realize a lot of them and improve.


#5233491 software rendering win32

Posted by BitMaster on 08 June 2015 - 02:09 AM

I just checked Wikipedia for 'GDI' and the only valid reference points directly to the well-known and not really helpful Windows API. Googling for 'GDI' also finds only the above (and some completely different things). Additionally, I have personally never heard of using 'GDI' as a stand-in for just any abstraction of output devices. That is like talking about a Model T when you actually mean cars in general. It's bound to cause misunderstandings and ultimately annoys people when they finally understand what you really mean.


#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 */ });
   // ...
}
else
{
   // 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.




PARTNERS