You use those functions as follows:
int yourRandomNumber = randnum(randseed(), 51) + 1;
// randnum will return a value between 0 and 50 inclusively, ie: 0, 1,… , 50, hence the need to add 1
But I don’t like to use them since randseed performs poorly when used inside an intensive loop (with little benefit according to my experience, that is, the number of passes it does doesn’t increase that much the “randomness”); and randnum is not safe since it doesn’t check if the randnums parameter is non zero and, on top of that, there is no action taken for negative numbers since the result of the modulo operation is implementation-defined for them.
In place of those, you can use these (they are not mine, but Isaku Wada’s, 2002):
long randomSeed()
{
static u32 seed = 7; /* Seed value */
if(!seed)
{
seed = 7;
}
seed ^= seed << 13;
seed ^= seed >> 17;
seed ^= seed << 5;
return (seed);
}
int random(long seed, int randnums)
{
return seed & randnums ? (int)(abs(seed) % abs(randnums)) : 0;
}
These will output the same numbers everytime since there is no way to produce real random numbers within this universe that I'm aware of besides, maybe, the rate of atom decaying... Anyway, you can add some randomness to the output by including values that come "from outside the system", like the user input and the elapsed time or the number of clock ticks. For example:
int random(long seed, int randnums)
{
// _accumulatedUserInput is a global variable where you store or accumulate the user input so far
// _ticks is a global variable where you store the amount of clock ticks so far
seed += _accumulatedUserInput + _ticks;
return seed && randnums ? (int)(abs(seed) % abs(randnums)) : 0;
}
Yep, I had to change/fix a bunch of things to get the Linux compilation working again, and those should probably help the compilation on OSX.
I’ve found a site talking about how to compile GCC on OSX, and I may take a look at it myself if somebody doesn’t beat me to it!
Hey Elmer!
I already compiled it on macOS Mojave, but I didn’t really documented the process and it was kind of messy and hackish since I had to even modify one of the config.guess files, among other things. Anyway, I’m still porting our preprocessor before being able to successfully build any of our demos, so, I’m not 100% sure that the compiler is working fine.
I really hope that you guys take a look at using the C++ support in VUEngine since you’re already using an object-oriented design.
Using basic Embedded C++ language features should allow you to make your code a lot more readable/debuggable than using all of those cunning-but-fragile macros.
The plan is to evaluate, in the middle term, if it is feasible given the complexity and memory requirements of the engine. But right now we want to concentrate in implementing a complete game instead of keep pushing developer features. Anyway, thanks to the preprocessor, the code is around 85% based on C++’s syntax (the only missing syntax feature is proper method calling), so, that part of the port should be really easy. The hard part will be, first, to customize the memory handling since I don’t have enough experience on the inners of C++’s compiler and linker so I don’t know if it is possible to instruct it to allocate the virtual tables in specific memory regions or even if they can just be computed at compile time and placed in the ROM area (we load them in DRAM instead of WRAM because they amount to more than 10 KB and they are populated at runtime); and second, to handle the allocation of dynamic objects, although I guess we just have to override the new operator and just use our own MemoryPool to avoid the usage of the heap.
jorgeche
Hi Guy:
I tried to implement a custom abs function based on your findings, but I guess the compiler that I’m using doesn’t have support for the system registers 26-31.
Given that I don’t want to bother ElmerPCFX and I don’t want to go through the whole process of trying to compile the compiler again, I would like to know if there is any way to write the hex op code for the stsr and ldsr instructions in my C code without having to hack the ROM directly.
jorgeche
Attachments:
VirtualChris schrieb:
I deleted it using Robocopy. But what’s weird is that VDBE worked for a while and then stopped because the name got too long. How did it get too long?
I’m not sure about how VBDE’s makefile handles the building of its sample projects, since I only work with the VUEngine, but that makefile is a port of the VUEngine’s so the problem may be related to what I previously pointed. For the moment, just delete the release folder each time you compile until KR1553 can chime in.