Jump to content

  • Log In with Google      Sign In   
  • Create Account

BitMaster

Member Since 08 Aug 2000
Online Last Active Today, 10:29 AM

#5130271 SFML 2.1 Setup Problem

Posted by BitMaster on 10 February 2014 - 06:53 AM

That does not appear to be a problem directly related to SFML. All of the random samples I checked were Windows API functions. You don't seem to be linking to User32.lib. More platform libraries might be the culprit, but linking to that one will probably reduce the number of errors a lot.


#5129310 Ask for Opinion

Posted by BitMaster on 06 February 2014 - 08:23 AM

1. how you read a statement "for" to a logic or human languange? example

Starting from one, add one to i until i is equal to, or greater than, ten.

Actually, no. The loop as given will never run. It's "starting from one, while the value is greater than 9, increment by one".
Edit: actually, not sure about that anymore since I missed the C# part on the first pass.
 

2. what difference a game programming and graphic programming?

 
Graphics programming is a part of game programming.


Not really. A part of graphics programming is part of game programming. There are applications of graphics programming which have (for the time being) no intersection with game programming. Some examples are rendering techniques used for medical purposes or rendering techniques which are very, very far from real-time.


#5129298 C++ SDL - Deleting dynamically allocated objects

Posted by BitMaster on 06 February 2014 - 07:35 AM

MinGW 4.7 onward (if i remember the version correctly) supports most of C++11, if not all of it, and unique_ptr is part of that.


Yes, however std::make_unique requires C++14. If and how much C++14 is supported will depend on what version of MinGW is used. Of course it can't hurt to specify -std=c++14 instead of -std=c++11 and just try it out.


#5129248 c++11 move constructor question

Posted by BitMaster on 06 February 2014 - 01:56 AM

Since Test does not implement an explicit move constructor, it's just copy constructed. And since Test has no members, that's a no-op.


Setting aside the empty-class test case problem, according to this page the compiler should implicitly generate a move constructor. So in my understanding, if the test class contained expensive to copy members (like complex std::containers) the compiler would have generated a move constructor which could have been used.

I'm happy to be corrected though.


#5128720 SFML 2.1

Posted by BitMaster on 04 February 2014 - 07:36 AM

texture coordinates are defined in pixels (they are not normalized (between 0.0 and 1.0f), as people who are used to graphics programming would expect).


Firstly, according to the TheComet's link to the documentation, using pixel or normalized coordinates is a choice. Secondly, since SFML has a strong focus on being a reasonable library for 2D game development, having a default value of pixel-based sounds extremely reasonable.


#5128712 replacing sprintf_s trouble

Posted by BitMaster on 04 February 2014 - 07:01 AM

If you are confident viPrintf is indeed not changing anything (that is, it's missing a const but behaves as it is there), then you don't have any problems. Something like a const_cast should always be properly commented though.

If you are not sure and viPrintf might change some characters then it will (most likely) still work on all compilers and standard libraries although it's technically invoking undefined behavior. If viPrintf tries messing with characters beyond the C string length (for example because it assumes it always has at least 20 characters to work with) then you are in troubles.

If you want to be on the safe side, allocate a new C string of the correct size (plus safety margin as desired), copy the content of cmdstr.str() in there, and pass that C string to viPrintf.


#5128430 c++11 move constructor question

Posted by BitMaster on 03 February 2014 - 08:26 AM

Correct me if I'm wrong, but there's little point in calling std::move on an lvalue (as is the case in your code).
 
It'd make more sense like this:



vector<Test> v;
v.push_back(std::move(Test()));


You are wrong. In your example you don't even need the std::move because 'Test()' is an xvalue as an expiring temporary. The whole point of std::move is to allow moving of what would usually be lvalues.


#5127240 How to create games using Python

Posted by BitMaster on 29 January 2014 - 11:39 AM

Considering you just started, none of those are questions you should be asking. They cannot be answered in a (to you) helpful way either.

 

Start with something small. Like Guess-a-number. The program creates a random number and asks the user to guess it. The program tells the user "right" or "wrong" after each guess, the program ends when the user guessed right.

If you have never programmed anything before, this is a very significant challenge.




#5127224 z-buffer discontinuity in shaders

Posted by BitMaster on 29 January 2014 - 10:12 AM

If you want to do interesting things like edge detection or other postprocessing effects then you must render your scene in a framebuffer object you created. The default framebuffer will not do. Also, you need to render your scene into textures, not renderbuffers. Have a loof at this page for an introduction. If you have any questions after reading that page, feel free to but I'd say most of your current questions are either answered or invalid.


#5127144 Empty Array In Structures

Posted by BitMaster on 29 January 2014 - 01:39 AM

And although itll work in C++ to use a pointer and make it an array later (I think), I still kinda find it funny that you have to go through including the library vector, using vector<your data type here>, Resizing the vector, store the address of the vector into a pointer buffer to be used as an array by static_casting<char *>, load the data into that buffer and possibly put it back into the vector array. Mega fail Microsoft on not keeping it simple.


The point of the vector is to simplify memory management. As Ryan_001 already pointed out, if existing memory just needs to be interpreted in that specific way an empty array works and is simple.

Furthermore, std::vector has absolutely nothing to do with Microsoft or Windows. It's a part of the C++ standard library. It exists on Linux, Macs and smartphones and every other platform with a C++ compiler in the same way.


#5126935 Empty Array In Structures

Posted by BitMaster on 28 January 2014 - 06:51 AM

Ryan_001 already explicitly stated his use case for these structs (namely when working on data provided through memory mapped files). In this context, const makes a lot of sense.

I'd also like to point out that an open array and a pointer are not the same thing. The open array once again works perfectly for his use case, a pointer would not work at all.


#5126931 Graphics card vendor OpenGL drivers: How do you create an OpenGL context?

Posted by BitMaster on 28 January 2014 - 06:27 AM

You could also hand-code each call individually. I think the Rastertek tutorials take that approach. It's an incredible waste of time to do it that way though, especially if you ever have to track down a typo.

 
It's exactly relevant to my learning purposes. I would rather waste my time learning these during my retirement and not having to use the libraries and still not knowing how to do them before I die.


If you want to know 'how it works', you should do it by querying exactly one function by hand. Querying one or querying thousands makes no difference. The concept is always the same. It's just tedious, lengthy and error-prone without gaining even a teeny tiny bit more knowledge.

If you wanted something slightly more interesting, you could write a tool which parses an input glext.h header and produces the querying code automatically, as it is done in GLEW.

Personally, I would not do either because there are so many interesting problems with far more learning opportunities around.


#5126062 Struct versus class?

Posted by BitMaster on 24 January 2014 - 04:09 AM

It should be noted that even assuming structs for POD/serializable constructs were a general convention (as this thread has shown, that's not the case), it would be simply a convention, not something enforced by the compiler.

C++11 offers compile-time checking for exactly this problem though (for example in a static assert). For serializability (excluding padding-related problems) std::is_trivially_copyable is the perfect fit. The whole std::is_pod constraint is an unnecessarily strong requirement for just serialization issues.


#5125818 Struct versus class?

Posted by BitMaster on 23 January 2014 - 02:57 AM

What about a struct containing a pointer to memory it doesn't own, such as a node in a linked list in C?

I said this vitaly SHOULD NOT be done in a struct, not that it cannot be done! Do that to your project in your job, I do not care, and please, do not say what I have said if you obviously cannot understand what I write down actualy,

So you are actually telling us you should not write any kind of linked list in C?

And what about the Windows API? It contains many structs in its headers (it's a pure C API after all). A lot of them contain pointers. DirectX API as well. Well, we all know Microsoft does not really know what they are doing. But, oops, libpng and zlib both have many structs with pointers in them. I could probably find more examples but I started losing interest quickly after that.
 

Do you agree that what compiler can compile is not automaticly good to accept and write? Do you agree upon some culture in coding projects?

I think everyone here (or mostly everyone, there will be always one who says 'no' just because) would answer 'yes' to both these questions in isolation.
However, your problem in this thread is that you first tried to display a common convention as fact and then (when that ran into problems) switched to saying it's much harder and important than it actually is. As Aardvajk already correctly stated, giving too much weight to this convention already fails the moment a simple linked list is needed in C (you completely ignored the different examples I added in my posts).

That's the thing with conventions. They evolve. I subscribed to the POD-idiom of structs in the past as well, but I find it decreasingly useful as time passes and now apply different conventions. I can easily say 'I'm not alone in that' because the C++ standard library does things similar to my own ways.

By the way, I'm not saying here everyone has to do as I do. You can happily follow your own conventions as much as you like. Just don't try to confuse fact and convention in a public forum.
Also, when you argue against something a significant number of people do (including the language's standard library), it helps to have better arguments than screaming "IT AIN'T SO BECAUSE IT'S STUPID". Because, sorry, that's the impression I get when I read your posts.


#5125648 installing mingw

Posted by BitMaster on 22 January 2014 - 08:55 AM

If you aren't comfortable compiling tools from source, I'd recommend against mingw-w64 or TDM-gcc unless you actually need to build 64-bit executables. They are far less commonly used than mingw, and it can be a bit annoying to find precompiled binaries compatible with your specific version if you're missing a certain tool or whatever. Not too annoying of course, but a pointless waste of time if you don't need x64.


Actually, the mingw-w64 project is interesting, whether you care about x64 or not. MinGW is a very safe compiler, but also very boring. It takes relatively long to get new versions of gcc and its standard library. It's also missing all of std::thread so far.
The mingw-w64 project on the others hand offers more recent builds of gcc (the last time I checked 4.8.2 versus 4.7.x) as well as a complete standard library (including std::thread). To be fair, mingw-w64 explicitly states their complete standard library is not as efficient as it could be (because it works over posix primitives instead of ones native to Windows), which is why they offer two versions (one with std::thread and one more efficient without).

While you have to build some libraries yourself when using mingw-w64 instead of MinGW, most libraries are not pre-built for non-MSVC anyway so you don't have to build much more either way. Also, Qt5 for example is only pre-built for mingw-w64 (although the bundled version is 4.8.0 instead of the newest available), not for other flavours.




PARTNERS