Same here
2 Likes
I just got like three quotes inside of each other 
1 Like
Itās a bit tricky since I wanted smooth grayscale shading and Arcade only has a 16-color palette, so I went with black&white for the game. I tried a different palette in the Carrier 3D demo, that uses 8 shades of gray and 8 other colors for variety. I donāt currently have plans to modify Space Rocks 3D further though as far as weapons or graphics are concernedā¦
1 Like
After many hours of unsuccessfully trying to debug this, I just posted an issue over at pxt-arcade about this Floating Point Exception specific to the Raspberry Pi for this game:
I hope someone here or there could have a look at this and help squash the bug!
2 Likes
I was about to reply to your bug update in github, but I thought it would be more appropriate here instead of sidetracking the bug investigation in an issue tracker.
And how does āeveryoneā seem to know stuff like that the integer numbers are 30-bit etc.? Apart from the obvious - being better and more experienced coders than I - do you have access to some other special tools to help, like well-commented code, system/code/uml diagrams, serious documentation, custom debuggers, blueprints, whatever?
@mmoskal had given me pointers in this forum thread, i.e. comment 25 and comment 30. He also wrote an article and co-wrote this detailed paper.
If youāre curious, you can also poke around in the gameās compiled output, see the Explorer > Built submenu after selecting a target and downloading - see binary.js for a javascript intermediate representation (which still somewhat resembles the original source), or binary.asm for the ARM assembly (not particularly user friendly).
The core issue for me was to ensure that integer values stayed within the fast 2^30 range including all intermediate values. A nasty side effect is that things still work if that limitation is exceeded (or if the values arenāt integers), it just gets 100x slower on hardware due to falling back to software floating point math. I wrote some benchmarking code to pin down where time was being spent, thatās still accessible from the gameās menu.
2 Likes
Thanks again, @kwx! This was very useful information!
The first article was good and new to me, the second I have read, but apparently have to read again with other spectacles, since my focus when I read it was research on different ways of executing MCA games(simulator, VM/bytecode, MCU executables and other native executables etc.).
Still, as a pretty fresh student of debugging, I am struggling to establish the understanding of MCA game code in the editor vs. the compiled code and runtime, and ultimately the line number in the different pxt libs files for linux where this bug probably might reside.
Even when i compile the rpi .elf with the ?dbg=1 flag, I cannot manage to get gdb to backtrace in any (for me) meaningful way on any of the threads, and a custom compilation of strace with backtrace and strace -f -k is still pretty much Greek to me.
gdb:
āBacktrace stopped: previous frame identical to this frame (corrupt stack?)ā
But I am thankful for your hints about binary.js and binary.asm etc. in the Explorer > Built submenu, which seem relevant and useful to explore further and try to understand.
But if there are no ready tools to debug within the link between the MCA code, the underlying libs and source code and resulting executable file, guess I could try other Raspberrys and maybe the official distro to rule out if thereās actually something wrong with my own runtime environment, chop up your code into smaller modules, if possible, and see which parts trigger the SIGFPE etc.
But since this is not a compile time error, I think you are on to something, about the switch from integer to floating point during runtime, and that the math? libs for RPi somehow experiences a buffer overflow somewhere. There are also hints at different forums, that the SIGFPE might be triggered by some incompatibility in type castings or assignments etc.
However frustrating this bug is on my level of programming expertise, I am in a way thankful, because the main reason for my interest in MCA(apart from the joy of seeing my son learning and creating and doing projects together with him inside MCA), is the underlying pxt source code base, which is interesting enough to keep up motivation, and has enough learning challenges for many years to come in everything from C++(and other languages) programming, debugging, compilation to navigating and understanding bigger code bases etc.
Also a very nice community of people who just want to learn and create awesome stuff, help each other on the way and to make MCA better and better known. I only wish that the advanced community was a lot bigger, with more activity both in this forum and on GitHub, so that maybe the learning curve did not have to be this steep, hehe. But, the harder the nut, the more the learning(and maybe the harder the lesson learned and remembered), thoughā¦ 
2 Likes
Cool game with lots of amazing graphics! Awesome.
2 Likes
@kwx maybe add a way you can change the cock pits from all of the versions that you have like from v1 v2 v3 and all of the other versions.
1 Like
hey, quick question! are you still working on this extended 3d engine or has it been archived?
1 Like
Iām not currently working on it (or any other MakeCode Arcade project). I think the version in Carrier 3D is the latest, but it isnāt really intended to be a general-purpose 3D engine since it has a fair number of idiosyncrasies, for example objects needing to be drawn in a back-to-front order.
2 Likes