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!


Member Since 08 Aug 2000
Online Last Active Today, 05:16 AM

#5195835 Crash with <unable to read memory> error

Posted by BitMaster on 02 December 2014 - 01:38 AM

Back in the days when Zahlman was the 'For Beginners' moderator he had a signature that said (paraphrased) "If you post in For Beginners and your code contains 'char*', you have a bug". I'd say nowadays that can be extended to any raw pointer.

I would not say raw pointers are outdated but between std::shared_ptr, std::unique_ptr and boost::intrusive_ptr I would be very hard pressed to find an active reason to use raw pointers with any kind of lifetime management. In cases where some kind of resource management does not fit into the established pattern I would strongly suggest writing a compact RAII wrapper which deals with that exact problem.

The only time raw pointers with any kind of lifetime management matter to me in my professional life nowadays is when I descend into the abyss (that is, the code written a decade or more ago by people who thought C++ meant C with a tiny bit of classes).

My current hobby project uses raw pointers but not in any way regarding lifetime management.

#5195646 NULL vs nullptr

Posted by BitMaster on 01 December 2014 - 01:30 AM

For interaction purposes with C, there is absolutely no need to use NULL. nullptr works fine. As a matter of fact, a C++11 compiler should define NULL as nullptr, instead of 0 (see here).

#5194768 Quick C++ question on pointers

Posted by BitMaster on 26 November 2014 - 08:16 AM

If you allocated anything using new, you have to delete it later (either directly or by using a smart pointer like for example std::unique_ptr or std::shared_ptr), otherwise it leaks. Whether or not a pointer is involved is irrelevant. You can use new without explicit pointers and you can use pointers without using new.

#5193786 How access to resource in DLL from SFML

Posted by BitMaster on 20 November 2014 - 06:18 AM

PhysicsFS has documentation for the whole library available as well as a quick tutorial write-up. What exactly is causing you problems?

#5193738 Runge-Kutta in a large solar system

Posted by BitMaster on 20 November 2014 - 01:52 AM

The first thing that came to my mind when I read the OP's post in the context of game development was Alien Legacy. It did simulate a solar system with all bodies orbiting correctly inside their respective system ('correct' in this case means in regard to it being 1994 and me being a lot younger). I'm not sure about the exact time scale but if you cranked up the speed weeks or months passed within seconds, so doing that while watching the system map allowed you to actually observe the path of the planets around the sun.
That said, if I would implement something like that I would probably neglect a physics simulation of the solar and instead go with an idealized analytical description of all the bodies. Unless of course I planned to allow using bigger bodies (like moons upwards) as weapons later on...

Darn. Now I'm not getting Alien Legacy out of my head. And it's not even available on GoG. I hope I have a copy from way back then stashed away somewhere...

#5193683 Problem setting up SDL with Dev-C++

Posted by BitMaster on 19 November 2014 - 03:24 PM

Not sure if this is still the case or not but I believe Dev C++ has been abandoned.

Looking at his post the OP does not appear to be using the horrible useless Bloodshed Dev-C++ but one of the newer forks. I don't have exactly a high opinion of them but too little experience to make a definite recommendation.

And Glass_Knife, the IDE you are looking is called QtCreator (not QTCreator).

#5193211 Implementing Region Colours on a World Map?

Posted by BitMaster on 17 November 2014 - 02:55 AM

You have 256^3 visible colors, since normally the alpha channel isn't used. Still more than plenty, though.

While true on desktop systems, if you ever need to port to mobile systems you often only have 16 bits (usually RGB 5/6/5) for colors there. And although that should still be enough, according to the groans I heard across the office on some mobiles the mapping from values you set to the actual colors you read back is not as straightforward as it should be on all of them, so you might have to leave a more generous gap.

#5192813 Problem with first boost::serialization app not a good start.

Posted by BitMaster on 14 November 2014 - 02:27 AM

Is it possible you are linking other libraries which link to the debug runtime when you build release (or the inverse)? Alternatively, is your project somehow set up weirdly? The problems you appear to be having seem to be general library linking problems with C++ with respect to the runtime, nothing specific with Boost. If a program links to both the Debug and Release runtime (as that warning suggests), things are most likely going to go to hell somewhere.

Maybe your preprocessor definitions don't match what you are actually building? Usually MSVC should deal with that, but if you added preprocessor symbols by hand things might get wonky. In that case try disabling Boost's automatic linking and link the correct library by hand or better yet, start from a clean workspace.

Do you have a minimum sample project which shows the problem?

#5192418 Why don't you use GCC on windows?

Posted by BitMaster on 12 November 2014 - 08:31 AM

I do use GCC on Windows. Do I win something?

If there is an actual price involved I would like to point out I was first to say "I do" in this thread. ;)

#5192384 Casting Pointer to Derived Type

Posted by BitMaster on 12 November 2014 - 02:18 AM

Again, the pros do not use RTTI and exception handling, even if it's only in debug builds. If you want to ignore the collective wisdom of all the top developers in the industry, you do so at your own peril.

Just for the record, the primary reason I downvoted this is your abrasive personality in this thread and some other places I noticed you recently. An attitude like "I'm awesome, so every turd I drop is pure gold and you do not need anything else" really bugs me.

Now, moving on, especially after reading frob's post the impression I get this is solely about console considerations. To be honest, I'm getting rather tired of stuff being only valid for consoles ruining people's day on non-console systems and I'm talking both about the actual programming as well as unnecessarily limiting gameplay decisions.

Yes, there is a lot of money to be made on consoles. But consoles also cover only a very limited selection of genres and as it happens, aroundish 99% of what gets published on consoles is of no to little interest to me. What does interest me hardly ever makes it to consoles, because the average console audience is not very interested in it, because the people interested in the genre are less likely to have a console and because playing these kinds of games with a controller is not very optimal.
I don't want to go into ideological battles here, so let's just say there is a market outside of consoles sufficiently large to make a decent living from. That's one part of the argument.

The other part is, unless you are part of a big studio, you will never write on consoles (at least not in C++ where a decision of "RTTI" or "no RTTI" could actually be made). Yes, consoles are very different beasts with specific requirements. But should I ever work on one I will have to read a lot of documentation and best-practice guidelines about it anyway (much of it is usually hidden by NDAs before I actually work on one), not to mention the studio's own coding guidelines.
I would expect from any decent programmer to be able to modify their coding behavior depending on constraints like this. In my mind, if "we don't have RTTI on this platform" is too much for people to handle, they are really not people who should be working on the project.
This forum is called "General Programming". It's not called "Console Programming", there are specialized places for that (usually inaccessible to the public because of the aforementioned NDAs and stuff). I would have no problem with people contributing additional information from their own experience how something is extremely inadvisable from their own console experience. But what I read very frequently is people taking their console experience and steamrolling it over normal (game) development.
There is a a whole ecosystem of non-console game development out there. Your profits are not measured in hundreds of million of dollars, but neither are your costs. Also, you can actually work on the platforms involved without jumping through very expensive and often unreachable hoops.
Completely ignoring this reeks to me as ignorance at best and actual malignancy at worst.

#5192230 Help with advancing my skills

Posted by BitMaster on 11 November 2014 - 02:09 AM

#include <cstdint>
// ...
std::cout << sizeof(std::int32_t) << "\n";
This will always print out 4. If your platform cannot support 4 byte ints it will at least refuse to compile instead of doing something creative.

That said, it's a bad idea. If the assets are on the user's computer, they have access to them. What they do with them in private is really their own problem and if they do something unwanted publicly you do have legal means at your hand.
Besides, doing wonky things with your assets is more likely to cause yourself problems later on than inconvenience a skilled attacker. If you still want to hide your assets, I'd rather change the file extension or pack the resources into some archive format (that actually has benefits apart from the elusive idea of hiding them).

#5192225 Casting Pointer to Derived Type

Posted by BitMaster on 11 November 2014 - 01:12 AM

Then why did you feel the need to downvote me? The huge advantage of boost::polymorphic_downcast is that it verifies the type in debug builds (always a good idea to assert things which should be true there) and is a static_cast in non-debug builds.

#5192062 Casting Pointer to Derived Type

Posted by BitMaster on 10 November 2014 - 09:19 AM

Personally I would probably aim to use something like boost::polymorphic_downcast in such a situation.

#5192034 Why don't you use GCC on windows?

Posted by BitMaster on 10 November 2014 - 07:11 AM

I'm seeing here lots of mentions of MinGW without much acknowledging of MinGW-w64. This is important because vanilla MinGW is stuck in the pre-XP era and won't even be able to build a lot stuff made for Windows XP (and I hope you don't need DirectX because getting that to work is close to impossible), not to mention how SDL2 doesn't even work properly on it (I had to disable threading before I could get MinGW-w64 set up). Seriously, code should start including checks for vanilla MinGW and throw out an #error when detected (I just added that yesterday to my game).

Out of interest, what exactly are you referring to here? I have used both the original MinGW and its alternative (definitely in a post-XP era) and never encountered any problems like that (although I never tried DirectX with it). The biggest problem vanilla MinGW has in my opinion is the slower flow of features (as in MinGW was stuck at gcc 4.7.x when 4.8.x was already available for the other MinGWs).

One problem with all MinGWs is the issue of std::thread in C++11. Either you have to live without them (not a severe problem, especially if you use Boost anyway) or you get the standard library with POSIX threads (which works but makes the whole standard library on Windows slower than it could be). However, this seems to be a problem soon to be in the past, apparently the upcoming release at MinGW builds at least will have an implementation using native Windows thread primitives.

The biggest problem I always had was that a lot of libraries assume you'll be using Visual Studio on Windows, period, even if they use GCC on Linux instead. That's kind of ironic since MinGW(-w64) is basically half of each of those (Windows API but GCC toolchain). But yeah, enjoy messing with makefiles and such when you stumble upon one of those. I think the situation improved over time but still, take that into account. Though every time I see somebody defending Visual Studio over MinGW it's because of the IDE (I don't have any issues with using Code::Blocks but then again I don't use most of the advanced features either...)

With the libraries I wanted to use, the worst I had to do was use msys and fall back to the *nix build system. So far, that has worked even for the more annoying libraries and all it does it adding the constant cost of setting up msys once.

#5191273 How access to resource in DLL from SFML

Posted by BitMaster on 05 November 2014 - 01:28 AM

You would have to use Windows API function (probably LoadResource and LockResource) to get access to the memory containing the resource and can then use loadFromMemory.