what do you intend to do with the collision system? the response, that is?
Either the collision mask or the color values 
Whichever is easier and good enough. I am now doing the multiplayer part and delayed controls. I will think more about the collisions after that.
no, I meant, what is going to happen once you detected a collision ? e.g. increasing ground friction for grass, etc?
Ah, that! Dunno that either. Maybe bouncing. Or slow down the speed.
Yes! There is still room after making a rom image for the HW, with the network code also. The size of the Pokitto binary is 180 KB currently. Those monster tiles (64x64) take 80 KB of that.
1 Like
One option could be storing the track as a signed distance field, particularly if you want cars to bounce (correctly) upon hitting the edge of the road.
Advantages of using SDF:
- Uses very little memory: an entire track can fit within a single 64x64 bitmap, as demonstrated by the Suzuka track example
- Collision detection is simple, as each pixel provides the distance from the road edge
- Easy to obtain the normal vector upon collision detection
However, there are graphical limitations since SDF only gives you the distance from the road edge. You can only apply distinct colors, or textures like grass, sand and asphalt, to specific distance ranges. The utilization of textured SDF can be seen in the Worm-like example).
I can help if you choose to use SDF. I’ve previously made also a line filler for TAS-mode that draws a SDF bitmap on the screen.
1 Like
The online feature enabled.
4 Likes
this is promising!!
SDF seems to really have some very good features, like having longer tracks
I made a small test program to evaluate the rendering speed of Signed Distance Fields on HW at full 220x176 resolution. Unfortunately I was unable to attain frame rates that would be suitable for a racing game: 16 fps with textures and 18 fps with solid colors.
Source code: sdf_racing_test.zip (27.6 KB)
Below is a screenshot of the rendered SDF and the same area in the original low resolution bitmap.
2 Likes
and non-fixed angles/width roads and splits too!
1 Like
Found a way to optimize the SDF rendering. Now it runs at 26 fps textured and 32 fps solid colors. Would that be enough for a racing game?
Source code: sdf_racing_test2.zip (27.0 KB)
Here is what it looks like with solid colors.
2 Likes
That is a good improvement already!
I cannot say if that is enough. The “Fish Life” multiplayer demo used 30 fps. For this demo I planned to try adding audio also, but it is not absolutely necessary (as it can cause “noise” on the HW when networking is used 
).
So we should try how much adding netplay (max 5 players) and audio affects to the framerate. Also the speed does not need to be 30 fps, but lowering that can affect to the online game usability.
There are also some people in the community that could maybe help with optimizing the gfx code, @fmanga, @carbonacat and others
1 Like
I integrated the SDF renderer into Mad Mobiles to test performance in an actual usage scenario. Framerate dropped to 26 fps when rendering the SDF with just solid colors.
1 Like
Somehow works but totally out-of-sync
3 Likes
ok, as soon as I get the movement synchronized I will test the SDF renderer.
1 Like
I managed to optimize the SDF rendering a bit more. Now the game finally runs at 31 FPS on the HW, and my test program runs at 38 FPS.
Source code: sdf_racing_test3.zip (27.0 KB)
1 Like
This is looking really cool already. This is actually one of my favorite style racers so can’t wait to see the end results.
1 Like
SDF generated track by @jpfli . I think it looks really neat! Also the game engine is now deterministic and all clients are in sync.
Next I will make some performance testing using the server in Netherlands.
1 Like
I made testing with 1 hw client and 4 sim clients, connecting to Kamatera server.
The Sdf version was a bit slower on HW, about 24-27 fps in average. The tile based version was about 27-30 fps. The Sdf version Pokitto binary size was about 80 kb smaller!
1 Like