Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 05 Mar 2004
Offline Last Active Oct 03 2015 02:28 PM

#5255410 vector push_back creates error when multi threading

Posted by iMalc on 03 October 2015 - 02:33 PM

And ideally, you pass the mutex as a parameter.


Statics/globals are the enemy of multi-threading, and having that singular mutex pretty much ensures that you are not, in fact parallelising much of anything.

Or the better option would be for this doit function to be a member function instead, and the mutex is a member variable.

That way the caller can't pass in the wrong mutex.

#5222884 C++ cant find a match for 16 bit float and how to convert 32 bit float to 16...

Posted by iMalc on 13 April 2015 - 02:08 AM

I use a branchless table-driven implementation by Jeroen van der Zijp (http://www.fox-toolkit.org/ftp/fasthalffloatconversion.pdf) which some time ago I wrapped into a class to make it as convenient as a regular float.


The conversions in both directions are two-liners, and the combined size of all of the lookup tables is less than 10K.


It's probably nearly functionally identical to Aressera's


Edit: Bah, Jeroen van der Zijp's original link is now not working for me.


Edit2: Christian Rau has since produced an even more complete version here, which is clearly also based on Jeroen's work, but is more complete than mine, with template meta-programming to avoid unnecessary conversions and such:


Probably best just to use that one.

#5221508 Unused param

Posted by iMalc on 05 April 2015 - 01:57 PM

Unless I'm in the situation where the parameter is used in only debug or only release build, I tend to just comment out the parameter name.


I've also seen people just mention the variable name in the function body on a line by itself, without any cast.

#5216801 is it possible to prevent a proggram(specialy a game) to get decompiled

Posted by iMalc on 16 March 2015 - 02:42 AM

My take is that generally in the best case you're only going to be able to completely stop someone who is only as good a hacker as yourself.


But ... yes with the right outside help you can do better.


Still, there's always going to be someone out there with better hacking skills that whoever you learn from.

From them, your best defence is to make the reward not worth the effort. Sadly, that is not easy.

#5200335 Getting Rid of "char*"

Posted by iMalc on 27 December 2014 - 05:24 PM

Let's pretend it is an issue. How do you think you would solve it?

Actually, let's not pretend it's an issue, that's exactly what causes premature optimisation.

Here is the procedure to "solve it".


First prove it is an issue, via profiling. You've either done that and not posted results, or you haven't done that. Either way there is more work required at this step.


After that, your first attempt at a resolution should be to see how you can use strings less. E.g. if profiling showed that you had a bottleneck when comparing your string object IDs, then perhaps you could switch to using enumerations instead of strings. Or, if you're getting too many string copies, perhaps there are some critical places where the string is passed by value instead of const-reference.


The next thing to do is to look for a replacement that already exists. That may be in the form of a more-specialised part of the same library, or a whole other library. There is plenty that you can research.


Next, in considering whether to write your own replacement, you need to understand that in proceeding down the path of making your own, you are assuming that you can do a better job than the expert standard library writers. You are then assuming that you are in the top few percent of all C++ coders. Most people like to think that they are in the top few percent of C++ coders, but obviously most aren't. The experts are those who have first learnt to use existing tools very effectively (e.g. strings). One must learn why all the parts of the string class work as they do, in order to not fall into traps that others have already solved.


The final thing to understand is that even when there is a bottleneck, and even when you've done your best to optimise all related code as much as you can, there is always going to be a bottleneck somewhere. It's even possible that no matter what changes you make to a program, string handling could be such an unavoidable bottleneck (although that is generally unlikely, depending on what the program does).

#5190633 Is optimization for performance bad or is optimizating too early bad?

Posted by iMalc on 01 November 2014 - 03:10 PM

I should note that there is sometimes a bit of a misconception about premature optimisation.

Avoiding premature optimisation doesn't mean that you ALWAYS just start with the simplest thing that could possibly work. For example, say you are starting out writing what is planned to be a very good chess AI.

You do your research and discover that other people have already studied this area and determined that the only way to get things fast enough is to use bit-boards. Starting out using bit-boards, which is more complex that a straightforward solution, is thus not a premature optimisation. It's an informed need for optimisation, and the only known way to get the required performance.


You either profile then optimise, or you research then optimise, or both.

#5171825 Interrupt handling very slow

Posted by iMalc on 06 August 2014 - 03:51 AM

Generally when the problem appears to be that the Windows message queue mechanism is too slow, that is usually not the case at all.

It can only deliver you the next message when you request it, and you normally only request it when you are finished dealing with the current message. So basically your own slow message processing slows down the receipt of further messages.


One mistake I've come across when processing Windows messages is when you only allow at most one Windows message to be processed each time around your main loop, seemingly giving maximum time to the rest of your drawing code. In reality what happens is that this slows the program down horribly. You should endeavour to process ideally all messages before doing any other stuff in your main loop. Although this may be counter-intuitive, it actually makes a world of difference. Give Windows more attention and promptly process its messages, and your program's performance will be greatly rewarded.


Those are not interrupts and no you do not need a mutex there. In fact the term "interrupts" doesn't have much applicability at all in a Windows program. The terms that you need to be familiar with are synchronous / asynchronous, blocking / non-blocking, or single-threaded / multi-threaded.

You can confirm this for yourself by placing a breakpoint within the HandleInterrupt function, and when the breakpoint is hit, examine the Call Stack window. When you can look back through the call stack of the same thread and find the original GetMessage or PeekMessage call, then what your application is doing is entirely synchronous, or blocking.

#5154160 Most efficient way to write identical data to 2 memory locations simultaneously

Posted by iMalc on 16 May 2014 - 06:40 PM

This sounds similar to the problem of drawing the screen bitmap in one thread and transferring that to the graphics card in another.

When you don't want either thread to have to wait for the other, then the general solution is to use triple-buffering.

Have a read of this and see if it might be what you are looking for:



#5153726 Karatsuba algorithm

Posted by iMalc on 15 May 2014 - 01:41 AM

I implemented that algorithm , but found that the numbers had to be pretty big before it was a win. About 700 bytes IIRC. It would be good to hear how well it works for you.

In case you want to compare notes, my three variations of bigint libraries are here: http://homepages.ihug.co.nz/~aurora76/Malc/Useful_Classes.htm

#5148485 Using C++

Posted by iMalc on 20 April 2014 - 11:50 PM

So I have recently watched several videos on C++. I understand the basics, but how can I apply this into developing a game? 



Let me help put that into perspective for you...


You've just watched several videos on how to use a hammer, and now want to build your own home.

#5148481 C++ std::move() vs std::memcpy()

Posted by iMalc on 20 April 2014 - 10:52 PM

The obvious example that comes to mind, is when the object contains a pointer to one of its other members. I have just been using production code that has exactly that.


The other thing you should not overlook is that memcpy-ing may do most of the job for some types, but it doesn't in itself suppress destruction of the object where the data came from, which you would need to also do to avoid double-deletion. std::move on the other hand, gets implemented to null out pointers from the source location as necessary, causing subsequent destruction to be safe.

#5143168 Random Arbitrary Precision Numbers

Posted by iMalc on 29 March 2014 - 07:13 PM

Okay, here is a rough draft of my new article, comments welcome:


#5142960 Random Arbitrary Precision Numbers

Posted by iMalc on 28 March 2014 - 05:44 PM


one that generates a random number modulo a specified number

Then it isn’t very random. Modulus is absolutely the wrong way to give a range of random numbers from 0 to N, as it favors lower numbers.

This explains why:

However do not use a while loop to generate an unbiased range of random numbers as he suggested; by definition that could be an infinite loop, or at least be severely (order of seconds) slow. Imagine that the range of rand() is 0-268,435,456 (which RAND_MAX is allowed to be by the standard) and you looped until it picked a number below 3.

The correct way is:
unsigned int Rand( unsigned int _uiMax ) {
    double dRand = static_cast<double>(rand()) / static_cast<double>(RAND_MAX);
    return static_cast<unsigned int>(dRand * (_uiMax - 1.0)); // Remove “ - 1.0” to be inclusive instead of exclusive.
L. Spiro


That doesn't produce an even distribution either. That still results in some numbers being more likely than others, but the bias isn't with all the numbers at one end. Rather it might result in every third value being more likely, for example.


It is absolutely not right to call that the "correct" way. It is a way sure, but it by no means a panacea.


The rejection method actually does completely remove bias, not just smear that bias around.

In fact if there were a correct way to do it, it would be the rejection method, which yes involves a while loop. For such a technique to cause an infinite loop, the PRNG you are using would have to be braindead useless, to the point that this attempt at removing bias is futile.


If you do some analysis on how many times a generator is expected to loop around when using the rejection method, you'll find that the number of iterations follows the power law, and realistically the chance of looping much at all is completely insignificant, especially if using a 32-bit generator or larger.

Here is a previous post I have made explaining the issue very clearly:



Ah what the heck, I'm finally starting to write that article on random number generation that I've been meaning to write for a long time. I shall explain everything fully in there, including precisely why the floating point technique used here is actually pretty darn awful. I'll link it in this thread when I'm done.

#5128352 Bit mask math

Posted by iMalc on 03 February 2014 - 02:00 AM

Surely this is more readable?!:

id &= ~(NX::COLLISION_ID_IsPickable | NX::COLLISION_ID_IsHighlightable);
if (id == 200)

#5127156 Generating random points in a sphere

Posted by iMalc on 29 January 2014 - 02:49 AM


Might also make sense to switch over to a spherical coordinate system.  Pick a random value from 0 - 360 for X, 0 - 360 for y, and a random value from 0 - radius for z. Then convert that to the cartesian coordinates.



It's just what I would do, you don't necessarily have to.


How do you pick those random values so the resulting distribution of points in the sphere is uniform? That's precisely what this thread is about. If you do the naive thing you just described, you'll end up with too many points near the center of the sphere and too many points near the poles, or something like that (not sure what "x" and "y" are in your post to know for sure).


Indeed, a spherical coordinate system would create clustering due to the effects of gimbal lock. The same solutions to that problem can be used to overcome this (vector algebra / quaternions)


But yes ultimately the simplest, and quite efficient solution is the rejection method where you try again if the point is outside of the radius. Do a squared-radius check of course, to avoid square roots inside the loop.