I noticed this on the internet: http://qrng.anu.edu.au/FAQ.php# The next time I'm doing some work with evolutionary algorithms I might make use of that source of randomness. I think if you want full precision uniform values (doubles) then things start getting tricky. Like given a 64 bit random ulong...

I don't like the restrictions in C like no integer overflows (without special compiler options). Also dragging in a lot libraries I never found to be convenient. It has kind of reached a stage where you are forced to mix and match different languages. Maybe the Processing language for easy graphics ...

I can use FB for another while yet. I just don't want to completely paint myself into a corner. So what other programming language will allow low level programming with easy access to graphics, keyboard, mouse etc? I'll do more research.

Yeh, it looked a bit off for isometric. I just very quickly copied some idea on the internet. I would say you just need to adjust the toIso macro. I'd be more concerned with the correctness of the paint order. I had done it in a different way but that caused some flickering effect that I didn't want...

There is only one calling convention with Linux AMD 64, I didn't stop to think about other systems. Cdecl is necessary for anything else. I like the reduction in typing I get using #define scan(x,n) for x as ulongint=0 to (n) I would guess if you used a few different sprites you would see some probl...

I have been experimenting with some of things you would need for an isometric game. I'm not sure if I got the paint order correct enough to be useful and there are some scaling issues that need to be fixed. Anyway... #include "crt/stdlib.bi" #include "crt/string.bi" #include &quo...

I think Processing is the alternative that is most FB like. I'll take a look at Nim.
What would interest me most is a version of Basic that was orientated toward low level programming while still having reasonable graphics and some kind of easy to use GUI.

FB is kind of too big with too many things in it. A reduced complexity Basic with more graphic commands would be good. I would nearly switch to Amulet except that it has 1 based arrays and a lack of some numeric things I need. http://www.amulet.xyz/ There is also a compiled version of Ruby called Cr...

I think the CVI keyword is meant to be a Single to raw bits function. Allowing you to access and manipulate the actual floating point format.
There are other ways of doing that with pointer casting
dim as single s=1f
dim as ulong x=*cast(ulong ptr,@s)
Or something like that.

I tried the CVS and CVI functions which I hadn't noticed before. On 64 bit linux they seem a bit messed up because they assume 32 bit Integers. I tried replacing the Integer type which is 64 bits in linux 64 with a 32 bit long or ulong and that didn't help. Here's the code I tried from the FB docume...

it's mentioned here that that you can speed quicksort by using subrandom numbers: https://en.wikipedia.org/wiki/Low-discrepancy_sequence
I guess you use subrandom sampling to pick a nice splitting value for the quicksort.

There are better constants you can use in the signflip sub. ' h is a 32 bit signed interger sub associativememory.signflip(vec as single ptr,h as long) dim as ulong i for i=0 to veclen-1 h*=&h9E3779B9 h+=&h6A09E667 if h<0 then vec[i]=-vec[i] next end sub Anyway you don't need to use all the ...

Hash tables are usually the answer to this sort of thing. It's not difficult to make a hash table that accepts 3 input parameters. hash3D(x,y,z)=hash1D(hash1D(hash1D(x)+y)+z) or whatever. Or a Bloom filter based on 3D hashes for space saving.

I wrote the code in such a way that it can be easily translated into C.

There where a lot of papers in the 1970s and 1980s about associative memory. It actually turns out there is an easy solution to the problem: type associativememory veclen as ulong density as ulong hash as ulong '32 bit unsigned integer weights as single ptr 'pointer to 32 bit floats binarize as bool...