I just realised that ProjectABE doesn’t support the Arduboy2Base::generateRandomSeed() functionality so in the emulator you always get the same level. If you run on device you’ll get a different level each time you start. Maybe something @FManga can fix?
I thought you probably weren’t,
but it’s good to be aware of that issue anyway.
At the moment it looks like more of a rock than a fireball.
Or maybe a dragonball.
In which case it wouldn’t support Arduboy2Base::initRandomSeed() at any point in Arduboy2’s history, since generateRandomSeed() is actually just the former contents of initRandomSeed() adapted to return the seed instead of feeding it to random().
Most likely the problem is with reading ADC.
Arduboy2 is relying on it producing random noise,
and I’m guessing in ProjectABE it’s currently just producing 0 because it’s an unconnected pin.
Arduboy2Base::generateRandomSeed(), and thus Arduboy2Base::initRandomSeed(), uses a combination of both the random noise on unconnected Pin A4 and the time since the system started. Therefore if you wait for a button press before calling either, you will still get a different seed even if the value read from the pin is always the same.
Mix of old C compilers being what they were and some language features:
sizeof(void) is 1
You can ignore the return value of a function.
And you could compile & call a function with a return value declared but that didn’t have any return statement in it. It would still work. (with whatever garbage was in the CPU’s AL/AX register as the return value if you tried to use it)
My guess is the compiler internally aliased the void type to the char type (or unsigned char) to save on memory since it pretty much worked just the same. They forgot to special-case disable dereferencing on it.
I just saw that both the wolfenstein 3D and Doom books are both available as free PDFs now: http://fabiensanglard.net/gebb/index.html
I have hard copies of both and I would definitely recommend them! Lots of interesting tricks used for the old PC hardware.
I assumed that this was the case. Maybe the emulator can sample random noise when trying to read an unconnected pin?
Maybe! There is still plenty of flash and RAM left available.
Good idea! Alternatively just keep calling the random function each frame until a button press would work too.
They’re interesting, but most are very hardware specific,
and some I wouldn’t advise attempting if you can avoid it.
That would work to a degree, but you’re effectively just shifting the same pseudo-random sequence along a few entries which means that after a while people will start running into the same levels if they take a similar amount of time to skip past the title screen.
Pre-ANSI C is full of weird things.
Apparently GCC will still allow this for C if you pass the right flag.
In modern C (C99, 220.127.116.11.1):
The sizeof operator shall not be applied to an expression that has function type or an incomplete type
The void type comprises an empty set of values; it is an incomplete object type that cannot be completed.
I’m not sure what you mean by ‘ignore’.
That’s worrying, and it makes me really glad that modern compilers have come such a long way.
Well, they had less than 640KB to work with and 64KB data segments.
I probably would have done the same.
I got a table of reciprocals in Starduino that I read out of bound for 0 and 1 on purpose (uint8_t stepping = (reciprocals-2)[height] ) because 0 renders nothing and 1 only renders one scanline so it doesn’t matter if I add a garbage number at the end of the for-loop in those cases.
You save wherever you can. (and not having an MMU to worry about can be fun)