conflict with bah.random and brl.random
BlitzMax Forums/Brucey's Modules/conflict with bah.random and brl.random
| ||
I wanted to use bah.random to ensure identical results on any PC but I'm having problems. I don't implicitly import brl.random, but I do require brl.retro which in turn imports brl.basic, and consequently brl.random. Any calls to SeedRnd(), Rand(), whatever, throw up a duplicate identifier error. Without going through the entire code and replacing every call to the random functions with an absolute path i.e. bah.random.SeedRnd(), is there any way to avoid this conflict? |
| ||
IMO its best to just replace Brl.Random with the Bah one. Brucey's version is superior in every way. |
| ||
What happens if you explicitly define the module namespace? e.g. instead of just using: print rand(1,6) (which would conflict thanks to there being two 'rand' functions) try this: print brl.random.rand(1,6) |
| ||
What happens if you explicitly define the module namespace? That works but I'm six months into a project and its a bit of an inconvenience to have to do that, unless its a last resort. IMO its best to just replace Brl.Random with the Bah one As in, permanently replace the whole module? That might work. |
| ||
As in, permanently replace the whole module? That might work. I expect it should just be a case of changing the "Module" line... |
| ||
I expect it should just be a case of changing the "Module" line... I don't tend to faff about with modules very much and I don't mean to sound stupid when I say this, but, what do you mean? |
| ||
Backup your BRL random module... Drop mine in its place... Change the line in random.bmx from : Module BaH.Random to Module BRL.Random Then build-modules, and it should be good to go. |
| ||
Oh, simple as that. I'll give that a crack tomorrow. Off to the bathroom now, then kip. I hope I don't get outwitted by the light pull again. Thx! |
| ||
You can also override the functions in your game:Function Rand:int(Min:int, Max:Int) 'Return brl.rand(Min, Max) 'Uncomment to compare... Return bah.rand(Min,Max) End Function This should be more clean that the module replacement, if your imports structure allows you to. |
| ||
Hello Since Brucey's module is a complete and direct (and better!) replacement for brl.random, I did just that! I have no use whatsoever for brl.random, so it made sense just to throw it out. Works perfectly now, thx! |
| ||
Why is bah.random better than brl.random? Is there some flaw in brl.random? I've not had any problems with it, and I'm using it quite heavily in some procedural gen work I'm doing. Would just like to know before it breaks my project. |
| ||
Is there some flaw in brl.random It does not give the same results on different platforms. With a certain seed, you'd expect the same sequence of random numbers (which makes them sound really random! not...) |
| ||
Really?! Do we have some test code/results showing the state of the issue? I've done a forum search and I can't see any discussion of this or any bug report thread. If this is true then why haven't BRL fixed it? It's a pretty major flaw in the module, no scratch that, it's a show stopping flaw in the module. It renders SeedRnd and RndSeed completely useless. Last edited 2011 |
| ||
It does not give the same results on different platforms As far as I know this has never been demonstrated. What is true is that the random functions involve floating point arithmetic. This makes them sensitive to the precision mode of the FPU. This is the same for everyone when the program starts, but it could possibly be changed by an external library. I know someone found an unexpected example of this long ago with Blitz3D and something called GameCam for capturing in-game videos. That was hard to track down because it depended on which version of GameCam was being used. |
| ||
As far as I know this has never been demonstrated. I seem to remember BRL stating that the Intel ones would give different results than the PPC builds, due to used cpu registeres behaving differently on the two platforms or something... |