Armchair coding Stunt Car Racer

Pagina 4/4
1 | 2 | 3 |

Van TomH

Champion (327)

afbeelding van TomH

18-12-2017, 23:39

Re: the pixels one could put on screen with a base MSX 1, I just stumbled upon Hex-Train for the Memotech 512, which is a 4Mhz Z80 plus a TMS9929a.

Don't be too impressed as its trick is fast mass storage: per its explanation video all possible frames are pre-rendered, deltas between all possible frame transitions are then calculated, precompiled and stored. So the real-time game engine is just a branching video player, sitting on top of probably hundreds of megabytes of data.

It still looks a little too good to be true to me, like maybe I've misunderstood and that's actually the 9938 display (he's produced a fictional super-Memotech that evolves largely along MSX lines), but I thought it was relevant.

Van hit9918

Prophet (2868)

afbeelding van hit9918

19-12-2017, 00:13

THE VIDEO SHOWS WHAT I MEANT Big smile
it is screen 2.

Van TomH

Champion (327)

afbeelding van TomH

19-12-2017, 02:41

hit9918 wrote:

THE VIDEO SHOWS WHAT I MEANT Big smile
it is screen 2.

Yep, you called it. That's what Screen 2 could look like with effectively unlimited processing. I don't think I have the imagination to come up with anything close to that low a level of colour bleeding in real time, no matter how simple the output.

My best idea for real time:

Forget lines. Just aim for alternating coloured track tops plus a single track side and ground colour plus a sky colour.

Render front to back doing the height map thing. So you accumulate a linear list of non-overlapping (colour, height) pairs for each column, filling in the horizon at the end. So it's a linear list of non-overlapping (colour, height) pairs for each column, exactly to fill the display.

Work eight columns at a time with a painful state machine. But I think the primary steps are:

  1. set current position = 0, set next_transition = min(next transition point for any column);
  2. assuming only four buckets so that this step isn't too painful to do 'optimally', bucket each column by colour;
  3. pick the colour with the most votes as background, the colour with the second-most (if any) as foreground;
  4. optimisation: if there's only one colour then, while(y & 7) write_solid_colour; while(next transition > 8) write_solid_tile
  5. otherwise: formulate pattern and colour for columns as best as possible, and output same value for next transition lines (optimisation: repeat the same tile if you've filled one and then have at least one more to fill; this is basically identical to the solid tile optimisation except you have to wait until you've drawn at least one)
  6. you've reached the next transition point, so update the columns that transition here and repeat.

At the transition points you can do a partial update of your bucket collection, and possibly save a full four-way compare.

Plan for spitting out columns is slightly more nuanced than before: find the left-most point in screen space. You've got an ordered clockwise list, so trace along:

  • which each the next point is to the right of the previous, store generated heights to a table;
  • upon finding the first point to the left of the previous, you've hit the rightmost. Change tack. On the way back, if the new height generated is less than the one you stored going in the other direction then output a run from the current height for that column to the newly generated one in the floor colour, then the newly generated one to the stored one in the surface colour. If it is greater then just store a run of the floor colour up to there.

That assumes each top is close enough to convex. Also the bookkeeping is slightly more complicated than just clipping the lines and using them: you should clip naturally to the left and right, but lines that go off the top or bottom of the screen need to generate horizontal segments exactly at the top or bottom to fill the gaps. I'm still trying to figure out exactly how you'd do that to reach all cases. A classic 'real' polygon clipper goes one edge at a time, inserting extra edges in 3d as it goes, but I'm trying to avoid that. I think that as long as each point that is off screen keeps a record of why it's off screen then you can reconstruct the whole thing but full details presently elude me. Needs prototyping.

The big gain of ditching the definition lines is the no-overdraw render pass allows you to optimise for 8x1 colours.

The big loss is that the sensation of speed is probably substantially reduced as most of the time the area of the screen near the car isn't changing. You might need to introduce specs on the floor — just individually projected points that plot in the foreground colour regardless of what it already is in that tile. They'll mostly stay within the main part of tile so they'll mostly stay the same colour. In fact, just don't allow them too near the edges and don't draw them on anything but the segment you're currently on, and probability of colour bleeding is limited.

This all definitely needs prototyping. I worry that it's a case of each individual step sounding easy, but the cost adding up to something well outside of budget.

Pagina 4/4
1 | 2 | 3 |