Mode 13 is 110x88x8bit
Thanks!
Those all sound fine to me.
I am actually using 8x8 pixel tiles in the engine. Road border circles are made of 2x2 tiles. My engine currently uses 3-level abstraction:
There is not much difference but I actually like the original “Pokitto” best, because there is a bigger contrast and clear line between light and shade areas. That gives it more depth in my opinion.
Ok, I must have got mixed up for some reason.
Possibly got mixed up with Mode 15.
I’m not quite sure what the difference is between the three.
Ok, I’ll see what I can do.
I’m trying to make sure there’s a pattern to the colours being used so it’s easy to make them lighter/darker.
The block map is an array of tile maps. So that you don’t need a huge array to store a huge level map.
Oh right, that sort of thing. Normally I’d call that chunking (since that’s what Minecraft calls it).
(We used chunking when making Dark & Under.)
For colouring I’ve got a system of ‘shades’ where 1 ‘shade’ is 0b0001000 (or 0x08) in RGB888 terms (which is the ‘epsilon’ of R and B in RGB565).
This allows me to lighten or darken images by adjusting the ‘shade’ of every colour used and to increase contrast by changing the step between ‘shades’.
The two ships I had before were 2 ‘shades’ apart for each colour.
This new one here is 4 ‘shades’ apart for each colour:
Anybody knows any neat algorithms for NPC ships that the user is racing against? Like:
I have a book on Game AI. I’ll pop upstairs and see if it has anything on the subject.
Is the road perpetually straight or will there twists and turns.
And will the road be randomly generated or will there be a map?
(Has an impact on what options are available.)
I found this:
https://www.gamasutra.com/view/feature/3920/the_pure_advantage_advanced_.php?print=1
You can skip most of it and head straight to the ‘Implementation’ section.
Upon reading it I feel kind of cheated because I suspect racing games that I’ve played are doing something similar, but it’s an interesting approach.
Nothing really on this subject in the book (Programming Game AI by Example / Mat Buckland)
Of the top of my memory car games use a combination of waypoints & “look-ahead” envelope and collision avoidance.
This means:
There will be turns and there is a map also.
Yeah, looks like we can win only if the computer kindly lets us, poor humans, to do so 
I think for MarioKart, the track are split into rectangle regions, each having a destination point within the next region. So an npc is always driving towards the ‘next’ region. Something like this…
[edit] Like Jonne said 
I’ve got to dash off for the day, but here’s a half-scribbled mess of ideas that I’ll attempt to explain tomorrow:
(Probably the scruffiest thing I’ve drawn in a while.)
Basically it should be possible to calculate:
Most of which use velocity vectors.
The ‘path correction’ requires a node map (a list of points would suffice, perhaps with weights or vectors for creating curves/interpolating).
I haven’t actually figured out and of the maths involved, these are just ideas off the top of my head, but I’m reasonably convinced that they’re possible.
And obviously the AI is going to need to be a sort of state machine, perhaps built with a sort of ‘strategy pattern’ to make it easier to change the behaviour.
A lot of good ideas! A picture always makes it clearer to me.
I think that the first step would be just placing waypoints/control points/destination points throughout the course. Each waypoint contains the position (obviously), speed, and rotation vectors. Then I just interpolate each vector between the current state and the waypoint. The problem would be that the ships are going one after another throught the same route, but that can be helped by having some randomness on how fast they interpolate.
After that more AI can be added.
Also I was thinking to try to add some (simple) audio early in the development, to see how much it affects to the performance.
Btw. I have now done a very fast scaling and blitting implementation of an arbitrary bitmap, which can be used to scale npc ships and other objects in the horisont. Maybe also mipmapping is of better use there.
Let me add a few sound features to make it a bit easier. Been meaning to do it now that the tracker is mostly functional
What are you planning to do?
Basically you can do SFX already with setOSC but its not exactly super easy. I will add an easier way to load and control a sound effect.
(Sorry for the text wall. This one really will be my last post for today.)
Do you mean a normalised direction vector?
See in my top right diagram I’ve got the AI factoring in both the current target node and the next target node and it’s encorporating the positions of both into its vector calculations.
The idea is that you want the cars to naturally try to avoid each other by looking at each other’s velocities (i.e. direction) and calculating how to move away from each other (let’s call that the ‘avoid’ state).
That in itself should make them deviate slightly from the path.
Once they’re sufficiently far away from any other cars, they switch back to gradually manoeuvring themselves back towards the path (let’s call that the ‘target’ or ‘path’ state).
But rather than just looking at the next node and travelling straight towards that, they look at both the next node and the one after that and mix the two (e.g. lerp/slerp the vectors).
The mixing should make the movement slower and slightly more angled/curved.
(Should being the key word - this is all just theory.)
But anyway, you get the idea - the collision avoidance system should cause them to deviate from the path because the decision to avoid each other necessitates being less strict about following the path.
If that’s not good enough though, you could give each car a slightly different path, either hand made or by interpolating nodes between the edges of the road somehow…
One last thing.
All this talking about how they should be behaving reminded me of a technique for building flexible but complex AIs.
You may or may not have heard of them before.
If you can’t be bothered to read the text, skimming the images should give you an idea of how they work:
Might be a bit overkill, depends how well the state machine approach goes and how complex the driving behaviour needs to be.
That’s right.
A good idea.
