[Game]Pokitto Grand Prix

[jonne]

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.

[Pharap]

(Sorry for the text wall. This one really will be my last post for today.)

@Hanski

rotation vectors

Do you mean a normalised direction vector?

@Hanski

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.

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.

Decision trees.

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.

[Hanski]

Do you mean a normalised direction vector?

That’s right.

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).

A good idea.

[Hanski]

Hi,
here is the latest demo.

Changes:

• Better steering
• Limited acceleration to a sane value
• More gfx by @Pharap
• Change the ship: A + UP
• Change the edge tile: A + RIGHT

Still no collisions!

pzero.bin (39.8 KB)

[Pharap]

I was considering asking how this was going earlier in the week.
I haven’t been working on it because I assumed you were either still on holiday or getting settled back in at work after being away on holiday.

Excellent work. It’s looking very good.
Glad to see that the track has corners now.
(Still a bit of noticable tearing, but it’s bearable.)

If you’re getting back to working on this then I can get back to working on the graphics as well.
I’ll be able to do more next week than I can this week because I’ve got another project that I’m currently working on.

[Hanski]

I haven’t been working on it because I assumed you were either still on holiday or getting settled back in at work after being away on holiday.

Yes, I am now back in business.

(Still a bit of noticable tearing, but it’s bearable.)

I do not know how to get rid of it. Traditionally, tearing happens when the internal screen refresh is not in the sync with the application updating the content to the front buffer. As a result you see the combination of two frames on screen. To fix it the buffer update should be made during the vertical blank time. As far as I know, in the Pokitto LCD, there is no vblank or internal screen refresh, but I might be wrong.

If you’re getting back to working on this then I can get back to working on the graphics as well.
I’ll be able to do more next week than I can this week because I’ve got another project that I’m currently working on.

Great! Maybe the background (off-road) texture update?
I will work on sound effects next, and maybe on some rudimentary collision detection.

[Pharap]

As far as I know, in the Pokitto LCD, there is no vblank or internal screen refresh, but I might be wrong.

Honestly I don’t know either.

I assumed there wasn’t because nobody else had complained about tearing yet,
but maybe nobody else has attempted something where it would be noticable?

I suppose one way to tell would be to uncap the frame limiter and continually render differently coloured frames and see if there’s any noticable tearing.

Great! Maybe the background texture update?

More backgrounds? Sure.

I’ll have to finish what I was doing with the ships first though:

[WIP] F-Zero-esque demo (graphics needed!)

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: [image]

I don’t know if I’ll have chance to work on it today, but hopefully I will.

[Hanski]

Great! Maybe the background texture update?

More backgrounds? Sure

To be more precise, I meant the “off-road” texture, not the scenery texture.
(btw. I do not have your latest scenery texture yet in use)

I was also thinking that should we take into use some fixed “full color” 8-bit palette? It is a tedious work to transfer bmps to C++ headers (with img2pok which is an excellent tool btw), and if the palette indexes change, that should be redone for all textures (!). Using a fixed palette would solve this.

[Pharap]

To be more precise, I meant the “off-road” texture, not the scenery texture.

Ah right. That can be done too.
Grass and dessert would probably look good.
The pink stuff was actually supposed to be for the road border originally.

I was also thinking that should be take into use some fixed “full color” 8-bit palette?

I’ve been intending to build up the palette over time based on which colours I need for the images.
I’m worried that if I pick the colours first that the palette won’t be flexible enough to respond to things like “add more depth to the ship sprites”.

It is a tedious work to transfer bmps to C++ headers (with img2pok which is an excellent tool btw), and if the palette indexes change, that should be redone for all textures (!). Using a fixed palette would solve this.

If I knew what image data format was needed then I could write a new tool that generates a header with both image data and palette data.

I’ve already got a command line tool for Arduboy that I could adapt to Pokitto,
I expect about 75% of the code would be the same.

[Hanski]

If I knew what image data format was needed then I could write a new tool that generates a header with both image data and palette data.

There is already @jonne 's BMP2POK command line tool, but unfortunately it does not support 256 color palette.

edit: https://github.com/pokitto/bmp2pok

edit: looks like it does support 8-bit palette ! I will give it a try.

[Hanski]

I tested a simple audio with the demo. Here are the performance results:

• Without sound: 57 fps
• 8 kHz: 52 fps
• 22 kHz: 47 fps
• 44 kHz: 38 fps

[jonne]

That’s pretty decent

[Pharap]

I’ll try to either finish changing the ship graphics or come up with a new graphic for the roadside some time tonight.

I’m currently close to being able to tick another project off my list so I’ll have time this week to focus on doing some art for this.
(Art should be a nice break from code for a while.)

I’d like to try to trick convince @Vampirics to donate some art for this because he’s a good artist and has done art for some of the other games I’ve been involved in.
(He’s a better artist than I am, but that’s not saying much :P)

---

If anyone’s interested in what my other project is, I’ll post a link after its done.
If anyone’s still interested after that, I’ll contemplate a Pokitto port :P

[Vampirics]

I’d like to try to trick convince @Vampirics to donate some art for this because he’s a good artist and has done art for some of the other games I’ve been involved in.

Nice try, as much i would love to contribute, i can’t commit to this for this week because i won’t have much time. but i will sure try next week if i can.

P.S. : I also have to check what’s needed exactly and what are the limitations. (even though i am used to limitations)

[adekto]

if you do some lowpoly modeling and rotoscoped the art like my sample, it might make things easier.

[Hanski]

As a progress info I have now implemented:

• (very) simple sound effects,
• a simple collision detection,
• the ship shadow, and
• made more turns to the track (even one U-turn ).

I will come up with a new demo version soon once I have finalized the changes.

[Hanski]

The new demo:

• (Very) simple sound effects,
• A simple collision detection. Do not go off-road because it is bumby and you lose speed!
• The ship shadow, and
• Made much more turns to the track!

Binary: PZero.bin (61.0 KB)

[spinal]

(Very) simple sound effects,

Cool, how’d you do it? PROJ_SOUND_BUFFERED ?

[Hanski]

I used Jonne’s SynthTest InPokittoLib as a reference. It is really simple:

In My_Settings.h:

#define PROJ_ENABLE_SOUND 1     // 0 = all sound functions disabled
#define PROJ_ENABLE_SYNTH 1
#define PROJ_AUD_FREQ 8000

In the code:

Pokitto::Sound snd;
snd.ampEnable(1);
snd.playTone(1,tonefreq,amplitude,wavetype,arpmode);

[spinal]

Oh, playtone:-(