Hmm I never tried loading from the SD, can’t tell if it’s my problem or the loader’s, I gotta check.
Unfortunately some versions of the loader will only show a certain amount of files in the list. Make sure you are running the latest version by adding the ready made game disk to your sd card.
2 Likes
I was initially in 2048 and couldn’t scroll down then changed to 101 asteroids since it was the top of the list and couldn’t scroll then I deleted number 1&2 and could scroll.
Yes but that has the old V4 loader. Go get the new gamedisk and unzip all that stuff on the SD card. Then go to loader and let it update
2 Likes
Idea for another demo:
Port this or something similar to Pokitto. I think there’s a Python implementation somewhere. It’s fun to play around with, here are some pictures I generated:
The good thing is that each picture is completely identified by a short string, so people can easily share them. The demo could be able to save the picture on the SD card, where it could for example be used as a wallpaper for the new loader.
6 Likes
Oh my gosh. Customizable/skinable loader pages??? That would be pretty fun: D
How did I miss this?? Wow!! I’m so blown away by all this.
2 Likes
Will be releasing this soon.
I’m think about taking a break by creating a simple game that would be rendered with ray casting – e.g. a “3D” snake. Or tetris or chess, …
Actually maybe I could port my Arduboy tower defense to Pokitto, and render it with this library – I specifically separated the game logic so that I could do this. Could look interesting.
6 Likes
@drummyfish Would it be possible to do a FP light bike game, using this technique…where the walls are drawn by player movement? Or do they need to be fixed?
Like Tron? I guess it could be done, the walls can change however you like – that’s the advantage of raycasting over the Doom engine. If you wanted to use the rendering functions I currently have, the walls would have to be “thick” though – it would be more of a glorified snake. But if you want “thin” walls (for the light beam), then that’s possible too, you’d just need to write a custom rendering function.
Nice idea BTW, especially once we have multiplayer.
1 Like
incredible! Please don’t fall off your chairs:
https://medium.com/@bananaft/my-journey-into-fractals-d25ebc6c4dc2
Reminds me of Mandelbulber, except this is realtime with a great amount of added awesomeness.
I wanna squeeze Pokitto to render 3D fractals 
EDIT:
Given we have a formula that defines the 3D set which makes up the fractal – basically we have a function:
bool fractalOccupiesPoint(float X, float Y, float Z)
How could we render it?
The traditional way is to raytrace/raycast it (on Pokitto we would definitely only raycast it, which just means one ray per pixel, so no shadows or reflections, just fog). This raycasting would keep going along the ray in fixed steps (typical raymarching, unfortunately things like these for quick intersection finding can’t probably be used) and check at each point if it hit the fractal with the above formula. If it hits, compute the distance and shade the pixel accordingly.
Since the fractal is static, you could accelerated this with cleverness. You might for example voxelize (octree) the space and precompute which voxels only contain empty space – then when tracing the ray you could skip these portions of space. The problem might be zooming in to details on smaller scale. Also the precomputation could take a long time, quite a lot of memory and the rendering would most likely not be 100% realtime either (I imagine it would look like in the Mandelbulber where the image is pixelized at first and keeps sharpening).
Or try other rendering methods? Like voxelize the fractal alone around the viewer? Or something like splat rendering of a point cloud? Don’t know.
Still could be worth a try though, fractal exploration on Pokitto is a dream.
3 Likes
I made a little 2d mandelbrot explorer (on the gamesdisk already) and it quickly gets slow to even just calculate the values (due to the iterative computation). I think the floating point performance of the MCU is simply not up to it. I did a featureful fractal explorer long time ago on the amiga (Fractal Universe) and also there invested quite some time to make things fast, but in the end there is the core computation that can’t be speed up.
2 Likes
I’ll take a look at it. Does the iterating computation be floating point though? Maybe 32 bit fixed point would be enough?
1 Like
Yes it is floating point. Initially you can get away with integer but after zooming in a little you need floating point. I was sometimes thinking that the madelbrot images only exist due to impreciseness of the IEEE number representation 
1 Like
I’ve seen a lot of fractal explorers actually doing a very low resolution (e.g. 2x2, 3x3, 4x4 or more “super” pixels) then refining it if you stayed on place, that could be an intermediate solution ?
Yes, I mentioned this somewhere above, I’d probably have to do it, it’s a nice solution.
This is regarding spatial resolution (my concern was about the iterative formula) – couldn’t this be still solved without FP? I was thinking this:
- Instead of FP use int32 and say it counts let’s say 0.01s (in practice rather a power of two). So if you have a value 50, it means 0.5.
- Then if you zoom a little more, jump to saying that int32 now represents 0.001s. And so on.
However this is actually close to reimplementing FP, right? The additional code that would check which scale you’re at and what fractions to use could in result be just as slow. But it’s not quite the same, there might be some advantages.
You could have a templated code, where the template parameter would be the spatial fraction. Then you’d create let’s say 5 instances of that code for computing with 0.01s, 0.001s, 0.0001s, 0.00001s and 0.000001s. Basically you’d be trading a lot of memory (5 instances of the same code) for bigger performance (no floating point). This way the decimal point would never be floating within given instance, no exponents, no ifs etc.
Then in the main loop you’d have a pointer to the core code, which would be one instance of the 5 code instances. And you’d simply switch this pointer based on zoom level to according code instance.
I’ve used this space-speed trade in my raycastlib in loops that I needed to be fast and it seems to work.
@Pharap I think this would be a very nice use case for templates. Even I wouldn’t date to put such big code into a macro 
Although I’m thinking I’d be able to implement this nicely in C as well like this:
#define FRACTIONS_PER_UNIT 256 // define this for the incoming include
#include "core.h" // <-- core code with no include guard
#define FRACTIONS_PER_UNIT 512
#include "core.h" // <-- same code using different fractions
#define FRACTIONS_PER_UNIT 1024
#include "core.h"
//...
1 Like
The problem with that is that you’d have to know what scale you’d end up going to because it has to be decided at compile time.
If you’re ok with that then it would work fine.
The amount of space used would depend on usage.
People tend to think that templates result in a lot of duplication, but most don’t realise that since every combination of template parameters results in a separate instantiation,
you often end up with lots of different functions that are only used once or twice,
so those functions are much more likely to be inlined,
which then allows them to be optimised further in a lot of cases.
For example, std::array is often just as cheap as using a regular array and manually writing the equivalent of the functions used.
I wouldn’t call that ‘nice’.
@drummyfish : Do you mind if I ask is this fractal thing just a distraction to not have to actually concentrate on making a game? 
3 Likes
Maybe 
I am afraid I have discovered the joy of pushing hardware towards its limits 
I’d really like to make a game, but I have too many ideas now, can’t decide which to choose. If I could make a game that would also achieve something new with the hardware, that would be perfect.