Formula 18A / Formula 99 / Formula 99+ development

[TheMole]

I'm a bit too old to be swearing like a sailor in public, but I'm at a loss to express how awestruck I am otherwise. That is so fucking cool!

The pre-recorded sections work really, really well when you're cruising along at speed. I do wonder though how they look when you've crashed or come to a stop and need to accelerate again. I can imagine the number of frames in the animation is optimized for high speed driving?

 

[Asmusr]

9 hours ago, OLD CS1 said:

I interpreted your inquiry to be aimed specifically at the sound of a passing whoosh-like noise.

No problem. Sorry again that I seemed to miss the second part of your message where you do indeed describe the sound would be constructed. I agree that would be the best way to produce a whoosh sound if the noise channel was available. 

[Asmusr]

11 hours ago, wierd_w said:

Perhaps creative abuse of the speech synth?

 

Specifically for engine noise, since that would mostly be similar pitch tones. That would free the noise channel for skidding sounds?

Interesting idea. I guess speech synths are so common that you can almost rely on them being present? However I don't have any clear idea about how I would produce sound effects using the synth.

[Asmusr]

11 hours ago, Vorticon said:

I was wondering if some kind of minimal indication of the wheels turning is possible, possibly the reflection line on the tires moving up and down or something along those lines... I think that would go a long way in enhancing the realism of the car motion. Regardless, awesome work...

That's a good idea. Maybe rotating a few bytes of the sprite pattern would be enough?

[Asmusr]

4 hours ago, TheMole said:

I'm a bit too old to be swearing like a sailor in public, but I'm at a loss to express how awestruck I am otherwise. That is so fucking cool!

The pre-recorded sections work really, really well when you're cruising along at speed. I do wonder though how they look when you've crashed or come to a stop and need to accelerate again. I can imagine the number of frames in the animation is optimized for high speed driving?

The animations actually work quite well at slow speed too. The only real issue with the animations is that in order to save ROM space (keeping it within the limits of the FG) I have not stored them in two versions shifted by 4 pixels, so sideways scrolling during animations is currently 8 pixels, which again is most noticeable at slow speed. 

[Retrospect]

this is fantastic stuff Rasmus, nice job!  I'm not even gonna try doing this in Extended Basic  ha

[wierd_w]

24 minutes ago, Asmusr said:

Interesting idea. I guess speech synths are so common that you can almost rely on them being present? However I don't have any clear idea about how I would produce sound effects using the synth.

Tursi I think Nope, some guy on GitHub has a LPC encoder.  There was recently a TI-Trek mod that replaces the speech package with new LPC samples from the television show, that you could maybe look at?

 

All you would really do, is make one or two LPC allophone samples, and ask the speech synth to play them while fiddling the pitch control.

 

Edited November 6, 2021 by wierd_w

[MueThor]

Dear Asmusr,

 

In my eyes it is still annoying that the opponents cars and the signs at the road sides are only monocolored. Is it possible to realize at least two colored opponents cars and signs at the road sides?

 

 

Regards

Edited November 6, 2021 by MueThor

[artrag]

4 hours ago, Asmusr said:

The animations actually work quite well at slow speed too. The only real issue with the animations is that in order to save ROM space (keeping it within the limits of the FG) I have not stored them in two versions shifted by 4 pixels, so sideways scrolling during animations is currently 8 pixels, which again is most noticeable at slow speed. 

What about storing only differences between frames in order to save rom space?

 

[Asmusr]

1 hour ago, artrag said:

What about storing only differences between frames in order to save rom space?

 

You mean actually subtracting the images pixel by pixel? 

[artrag]

Subtract the color tables of successive frames. You will get a large table of zeros.

Encode each run of non zero bytes as:

Vram_Address, Run_len, Byte, Byte, Byte, etc.

 

The player has only to follow the list of runs

 

Only the first frame has to be coded completely.

The second frame is a set of runs

Vram_Address, Run_len, Byte, Byte, Byte, etc.

Vram_Address, Run_len, Byte, Byte, Byte, etc.

[...]

Once you have completed the second frame, the 3rd will be a set of runs as well, and so on

 

You get a sort of video player based on differential encoding of frames (color tables)

Edited November 6, 2021 by artrag

[Asmusr]

31 minutes ago, artrag said:

Subtract the color tables of successive frames. You will get a large table of zeros.

Encode each run of non zero bytes as:

Vram_Address, Run_len, Byte, Byte, Byte, etc.

 

The player has only to follow the list of runs

 

Only the first frame has to be coded completely.

The second frame is a set of runs

Vram_Address, Run_len, Byte, Byte, Byte, etc.

Vram_Address, Run_len, Byte, Byte, Byte, etc.

[...]

Once you have completed the second frame, the 3rd will be a set of runs as well, and so on

 

You get a sort of video player based on differential encoding of frames (color tables)

Sounds good in theory, but there are some issues with that approach:

1. It makes it difficult to scroll sideways. You might have to start drawing in a middle of a run.

2. Not all frames are necessarily drawn. It depends on the speed.

3. It would make it difficult to add the car background to the image while it's drawn to the VDP, as I do now.

 

   

[artrag]

46 minutes ago, Asmusr said:

Sounds good in theory, but there are some issues with that approach:

1. It makes it difficult to scroll sideways. You might have to start drawing in a middle of a run.

2. Not all frames are necessarily drawn. It depends on the speed.

3. It would make it difficult to add the car background to the image while it's drawn to the VDP, as I do now.

 

   

1. You are right. Scrolling makes things more convoluted. You could encode the runs on the sides in multiple versions according to the screen offset, while runs that do no cross the side borders needs only a VRAM offset.

2. This technique should be also much faster than rendering full frames, as I expect to plot about the 20% 30% of the frame. It should be possible to render multiple frames in the same amount of time you use today to render one frame

3. You are right. With this encoding restore only a region of screen is a nightmare. For software sprites I would save the background in advance by reading it from the VRAM before plotting the sprite.

 

BTW, I would examine the differential data. If my idea that only the 20% 30% of the bytes changes is disconfirmed probably it is not worth to investigate any further the other options

Now you plot about 4KB per frame. Because of the overheads, things get interesting only if you can reduce that figure to about 1KB.

Edited November 6, 2021 by artrag

[Tursi]

I don't know what the current size is, but ROM space probably isn't a huge issue? We can do 2MB with standard boards, and if you really need it, I can donate my 128MB boards 

 

[+Ksarul]

18 hours ago, Tursi said:

I don't know what the current size is, but ROM space probably isn't a huge issue? We can do 2MB with standard boards, and if you really need it, I can donate my 128MB boards 

 

I have plenty of 512K and 2M boards in stock at the moment too, so current supply isn't a problem either.

[artrag]

Hi Rasmus 

How is going on this project? If you use precomputed data for all road segments using paged rom you could spend he saved CPU on cars and partial occlusions.  And use two pages for double buffering the plotting.

Happy new year!

Edited December 31, 2021 by artrag

[Asmusr]

On 12/31/2021 at 8:44 PM, artrag said:

Hi Rasmus 

How is going on this project? If you use precomputed data for all road segments using paged rom you could spend he saved CPU on cars and partial occlusions.  And use two pages for double buffering the plotting.

Happy new year!

Happy new year. I'm afraid I got sidetracked by another project (that didn't turn out to be very successful), so I have only worked very little on this one.

[Willsy]

Just been catching up on a few threads - my gob is well and truly smacked :-) 

 

Happy new year 'yall!

[GDMike]

29 minutes ago, Willsy said:

Just been catching up on a few threads - my gob is well and truly smacked 🙂

 

Happy new year 'yall!

He's breathing words... happy new year! Hahaha... always a good day when you peek in.

[+TheBF]

1 hour ago, GDMike said:

He's breathing words... happy new year! Hahaha... always a good day when you peek in.

Indeed it is.

Happy New Year Mark.