Outrun style road demo MSX2

Page 20/26
13 | 14 | 15 | 16 | 17 | 18 | 19 | | 21 | 22 | 23 | 24 | 25

Par Metalion

Paragon (1625)

Portrait de Metalion

20-01-2021, 21:11

Ivan wrote:

Btw, which music have you used? The one from the US Gold version on tape or the melodies from the Pony Canyon version on cartridge?

No, I used a midi file which was an adaptation of the arcade music, and rendered it on 9 FM voices.

Manuel wrote:

Perhaps the Arcade sound can be used, as it is made for YM2151 and SegaPCM as VGMrips says. As you know, the YM2151 is in the Yamaha SFG modules. Perhaps a version can be made that supports the original arcade music? Smile I'm sure Grauw can tell us more whether this is feasible, as he did similar things for Ghosts 'n Goblins and VGMplay of course.

Indeed, why not ? Smile

Although I must say that I have struggled to write a light music replayer. My current version (PSG/FM) uses up to 11000 cycles per frame (this is for a peak frame, loading and playing all 9 FM notes). If an YM2151 driver can be added to my replayer and give the same performance, it would be great !

Par Manuel

Ascended (19465)

Portrait de Manuel

20-01-2021, 21:30

Grauw can tell Smile It's only 8 channels by the way. But I don't know how much the SegaPCM is used and important. Emulating that will probably be tricky or at least costly, I guess.

Par Metalion

Paragon (1625)

Portrait de Metalion

24-01-2021, 09:33

Well, a few days later, and I'm stuck ...

I finished a first beta version of the traffic engine, but the result is poor : when incoming traffic is around the main car, their movement is very jerky, leaping several pixels at a time.

And I know the reason :
- road rendering takes about 4 frames
- during those frames, I cannot update traffic position on screen, because I need long OTIR for the road rendering and they cannot be protected by DI/EI, otherwise it could mess up the VBLANK trigger
- Therefore traffic position on screen is only updated once every 4 frames. That's OK for the segments of the road which are near the horizon, but not enough for segments near the bottom of the screen.
- Furthermore, traffic position on z-axis is only by step of 2. When projected on screen in the very first segment (bottom of the screen), this transforms into 3 or 4 pixels. So there also a problem of non-linearity.

It means I have to find another way to implement traffic ...

Par Grauw

Ascended (10768)

Portrait de Grauw

24-01-2021, 14:47

Metalion wrote:

- during those frames, I cannot update traffic position on screen, because I need long OTIR for the road rendering and they cannot be protected by DI/EI, otherwise it could mess up the VBLANK trigger

Is there no way to remove that restriction? What is the problem exactly? If the issues is having VRAM access on the interrupt handler, you could use a VDP command to access VRAM. Alternatively you could perhaps split up the road rendering into smaller blocks.

Par Metalion

Paragon (1625)

Portrait de Metalion

24-01-2021, 17:01

Grauw wrote:

Is there no way to remove that restriction? What is the problem exactly? If the issues is having VRAM access on the interrupt handler, you could use a VDP command to access VRAM. Alternatively you could perhaps split up the road rendering into smaller blocks.

The road rendering engine is a alternating mix of HMMV commands and OTIR sequences.

I could try to go ahead and protect those OTIR sequences with DI/EI and see what the result would be. I'm only thinking that it could mess up the VBLANK trigger, but that might not be the case. I know that in some cases, I have up to 72 bytes sent with OTIR to VRAM. That would mean DI/EI over 1584 cycles... And I have a lot of OTIR sequences for the road rendering engine, up to 360 sequences per rendering.

I could use VDP commands to update the traffic position on screen, it would mean protecting with DI/EI the HMMV commands of my road rendering engine as well. They are fewer (72 times per rendering), but some of them are very long as well. A few of them (mainly the bottom segments) are between 10.000 and 30.000 cycles. It would mean that if ISR happens during those ones, I would have to wait too long for the VDP to be free.

I think my only solution is to re-think the traffic engine. Updating the position every 4 frames is not a problem ONLY IF the positions rendered are smooth and give the illusion of flowing traffic alongside the main car. Maybe I could think not in terms of absolute position (and their geometrical projection), but rather in terms of relative position: every 4 frames this car/truck moves a certain amount of pixels up/down relative to the main car.

There is 2 problems to that approach :
1) As I would be completely outside the geometrical projection, I would have somehow to reproduce the effect of the traffic moving quicker as they are closer, slower as they are farther. But that could be solved by a good old table.
2) There would not be a "global traffic" anymore. At present, the traffic engine handle every car/truck/pickup along the global road (from start to finish), updates their absolute position, and then checks if it is within the rendered "window". Which allows, for example, if the main car stops, to see the traffic behind overcome and speed along. That probably would not be the case anymore with the relative position approach.

Par theNestruo

Champion (421)

Portrait de theNestruo

24-01-2021, 17:13

Metalion wrote:

2) There would not be a "global traffic" anymore. At present, the traffic engine handle every car/truck/pickup along the global road (from start to finish), updates their absolute position, and then checks if it is within the rendered "window". Which allows, for example, if the main car stops, to see the traffic behind overcome and speed along. That probably would not be the case anymore with the relative position approach.

Use a circular buffer. When a vehicle goes too far, replace it with a new one just behind the player. When a vehicle is overtaken, replace it with a new one as far as possible (or, to keep the number of vehicles in the buffer small, it may be interesting to just spawn it at the maximum visible distance).
The "circular" buffer is for allowing you to traverse it further-to-closer (or closer-to-further, depending on your needs) just by updating the start pointer after replacing a vehicle.

Par Metalion

Paragon (1625)

Portrait de Metalion

24-01-2021, 18:56

theNestruo wrote:

Use a circular buffer. When a vehicle goes too far, replace it with a new one just behind the player. When a vehicle is overtaken, replace it with a new one as far as possible (or, to keep the number of vehicles in the buffer small, it may be interesting to just spawn it at the maximum visible distance).
The "circular" buffer is for allowing you to traverse it further-to-closer (or closer-to-further, depending on your needs) just by updating the start pointer after replacing a vehicle.

I already use a circular buffer, but its size is the whole road from start to finish. The absolute z-position is on 16 bits, so when the car/truck reaches 65536, it automatically goes back to the start of the game. But that buffer size it too big, because it implies that I have to update on ISR between 150 and 250 traffic objects (and check if they are on screen). I already thought about spawing traffic items in a reduced circular buffer, and it might be the solution.

Par theNestruo

Champion (421)

Portrait de theNestruo

24-01-2021, 19:29

Metalion wrote:

(...) But that buffer size it too big, because it implies that I have to update on ISR between 150 and 250 traffic objects (and check if they are on screen). I already thought about spawing traffic items in a reduced circular buffer, and it might be the solution.

Keeping 150/250 elements seems unpractical, indeed! I would keep about 2x the visible objects (so if you can see 4 cars at the same time, the buffer would be of 8 cars). That will drastically reduce both size and processing time.
If you absolutely want to keep the same cars at the same positions, just store that ("the 37th car is a truck") for spawning the "correct" sprite, but I think that is no necessary; nobody will notice if the fourth car that overtakes him after a crash was a beetle instead of a truck Big smile

Par hit9918

Prophet (2932)

Portrait de hit9918

24-01-2021, 21:50

Metalion wrote:

I'm only thinking that it could mess up the VBLANK trigger, but that might not be the case.

What is a vblank trigger, some TIMI variable or some status bit hardware?

Metalion wrote:

I know that in some cases, I have up to 72 bytes sent with OTIR to VRAM. That would mean DI/EI over 1584 cycles...

That's 7 rasterlines. Such delay is no problem for vblank interrupts, but it is much for line interrupts.

Par Grauw

Ascended (10768)

Portrait de Grauw

25-01-2021, 00:16

The vblank interrupt signal stays active until acknowledged. Like all other interrupts do btw, VDP or otherwise. So only if it stays unacknowledged for an entire frame or longer, you will “miss” it. As hit9918 said, a 1584 cycle delay means the interrupt routine will at most be called 7 lines later, but still well in the vertical blanking period (if that is a concern to you at all).

Page 20/26
13 | 14 | 15 | 16 | 17 | 18 | 19 | | 21 | 22 | 23 | 24 | 25