9643e021987a43e072254f85174d702fff302980
8
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  CydandClaude Opus 5
|
b7b2c3b148 |
The GPU transforms the vertices
The cockpit displays were updating every two to three seconds while the 3D view held a perfectly smooth 55 fps. This is why, and it is one line. Every device was created D3DCREATE_SOFTWARE_VERTEXPROCESSING - every vertex on the track transformed and lit on the CPU, on the one core this game uses for everything. That was not a choice when the engine was written; there was no hardware to hand it to. The error message beneath the call still says "Couldn't create HARDWARE_VERTEXPROCESSING device", so the flag was changed at some point and the message left behind. Measured on the biggest track, 1920x1080: software foreground 17.2 ms background 1.2 ms 2.4 gauge passes/s hardware foreground 0.2 ms background 17.9 ms 50.0 gauge passes/s The frame loop runs the foreground and then spends whatever is LEFT on the background gauge work. A foreground costing 17.2 ms of an 18 ms frame leaves nothing, so the gauge loop got the single pass it is guaranteed and no more. A pass needs about twenty steps - eighteen gauges and three display copies - so the cockpit ran at two passes a second, and since the renderer walks a sixteen-step rate wheel, a gauge on one step redrew once per SIXTEEN of those. Three seconds. The map, the clock, the boost gauge and the sim still running after the fade to black were all that one number. Hardware T&L is now the default and sw is the way back. Fixed-function lighting and fog are not bit-identical between the old software path and a driver, so the escape hatch stays - but the picture was checked against both and the difference is not the one worth defending. A cockpit whose instruments update twice a second is. It falls back to software by itself if the adapter has no hardware T&L. The instruments that found it stay in, because nothing about this was visible from outside: - FrameSplit, under RP412GAUGEDIAG, reports foreground against background against whole frame. APPMGR has computed those four timestamps every frame since forever and never reported one of them; it would have pointed here on the first day. - FrameDiag reports frames per second on the same window, so the gauge sweep rate can be read against the frame rate rather than guessed at. - ProfileReport, which already existed and was only reachable through F11 on the RIO controls mapper - not the mapper a desktop player runs, so in practice unreachable - now runs on a timer under RP412GAUGEPROFILE. Its per-gauge line gains the rate mask and tier, which is what names a display as one-in-sixteen rather than merely slow. - The winners' circle logs what its exterior and name-plate rebuilds cost, since nothing else runs while they do. RP412VSYNC is here too, and it is honest about itself: presenting IMMEDIATE was measured and made no difference to the frame budget, because the frame was full of work rather than waiting. It stays as a latency-against-tearing preference, not a fix. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
a1f9c0e3c0 |
Winners Circle framed off the stand, not off who is on it
The camera was built from the spots that actually got filled: the first filled one for the front, the average of the filled ones for the centre. So it moved with the finishing order and the head count, and would move between machines if a remote player's vehicle was not there to place. Measured on Wiseguy's Wake, where win1 sits at (1199.84, 3, 2.92) and the eight spots run back to z~38 on the high tier: one finisher eye 1199.84,15,-33.08 aim z 2.92 eight finishers eye 1199.82,18.44,-9.03 aim z 26.97 Twenty-four units closer to the stand and looking at the middle of the tiers instead of at the winner - a different photograph of the same podium depending on how many people showed up. The stand is fixed furniture on every map, so the shot comes off the geometry now. The eight dropzones are read once, up front, before anybody is placed; win1 anchors the framing and the axis from the back rows out through win1 gives the facing, so a map that mounts its stand at another angle is still photographed from the front rather than relying on the old (0,0,-1) fallback. Placement then runs as its own pass and is the only thing that cares who finished - the log reports "N placed on M spots" precisely so a changing N beside unchanged camera numbers is visible. The framing constants are untouched and so is the shot they produce: the new numbers for a single finisher are eye 1199.77,15,-33.08 aim 1199.84,5,2.92, which is the old single-finisher shot to within 0.07 in x. That is the case the standoff/height/aim defaults were dialled in against, so the approved photograph is what everybody gets now instead of what one person got. Verified by running a race to the podium: the eight spot positions log as expected, the camera numbers match the calculation, and the frame is the same one as before - rank 1 centred with its callsign, 2 and 3 flanking on the low tier, 4-8 across the high tier behind. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
e1a3ef7cf1 |
Put the pilot's own vehicle on the Winners Circle
Your own vehicle is built insideEntity - a cockpit and no hull, because you are sitting in it and never see it. That is fine for a race and wrong for a podium: from the presentation camera your spot on the stand was the one that was empty, and on a single-pod race that is the whole picture. The renderer now gives the viewpoint entity an exterior before the shot. Disconnected_Eye is the engine's own switch for this case, documented as being there "so higher level renderers can fix the eye in one spot and watch the viewpoint entity drive around", and it is what makes NotifyOfNewInterestingEntity choose outsideEntity. The exterior is added alongside what is already there rather than by tearing the entity down and rebuilding it. Teardown-and-rebuild is the path the interest manager uses constantly for scenery dropping out of range, so it looked safe, but it is not safe for the viewpoint entity: that one is never uninteresting, the eye renderable goes down with it, and doing it mid-mission stops the scene rendering at all - the screen went black from the moment the podium came up and never came back. Adding the renderables directly does the same job with nothing removed. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
858fb7fb42 |
Fade into the Winners Circle instead of cutting to it
The podium arrived as a hard cut: the race was still on screen one frame and the stand was there the next. The race has its own fade-to-black already, and it was being suppressed to keep the fade from blacking out the podium behind it - which threw away the transition along with the problem. Now the two are sequenced. StopMission lets the race fade out as it always did and posts the podium to itself for when that fade has landed on black; the handler stands the finishers up behind the black and ramps back in. The fade-in is the end-of-mission fade run backwards - the same multiply on the fog colour and both fog distances, from nothing up to what the Winners Circle asked for. Timings: 0.7s of fade-out and black, then a 0.45s fade in. Both come out of the 11 second hold, leaving about ten seconds of podium. RP412PODIUMFADEIN sets the ramp. Verified by measuring frame brightness across the transition. The race falls away and the screen reaches black, then the stand comes up - and with the ramp stretched to 3s to make it resolvable at a half-second sampling interval, it climbs 71.8, 77, 78.7, 79.7, 80.5 rather than stepping, so it is a real fade and not a cut arriving late. The camera also comes down and tilts up across the tiers, which is how a podium wants to be shot. It is a balance in both directions: drop it further or tilt harder and the sky takes the top half while the winner's spot slides off the bottom of the frame; tilt down instead and the shot turns into a floor plan. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
28df53aa31 |
Frame the Winners Circle for the shape it was built for
The stand was composed to be looked at from a 4:3 pod monitor. On a 16:9 canvas its platform runs out at the sides and the shot fills up with sky and void, so the podium is now pillarboxed: the scene renders into a centred 4:3 viewport with the surround left black. The projection has to use the cropped shape too, or the scene comes out squashed into the narrower viewport instead of cropped by it. RP412PODIUMASPECT overrides the ratio, 0 turns it off. The camera also came in closer, from 33 units rather than 45, and now aims slightly below the group rather than above it. That tilt is what buys back the sky above the grandstand - aiming above the group tips the camera up instead and walks the winner's spot off the bottom of the frame, which is the one position that has to be in shot. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
461dcfb6b9 |
Clear the cockpit glass for the Winners Circle
The six secondary displays sit over the viewscreen like the pod's bezels and have nothing to say once the race is over. Worse, the radar sits dead centre along the bottom edge - directly on top of the winner's spot, so the one position that matters was the one you could not see. They are hidden when the podium comes up, which uncovers the canvas the 3D is already being drawn on. No matching show: the mission is over by then, and the next race builds a fresh cockpit. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
9389ec2003 |
Winners Circle: the award platform at the end of a race
The pod hall stood the finishers on a numbered platform when the race ended. All of it shipped in this repo and none of it ever ran here: the stand geometry, the eight ranked dropzones win1-win8 in every one of the 11 maps, and the sequence that places the racers on them. The sequence lived on RPL4PlaybackApplication - the mission-review build - behind a spool file, so the app the pods actually race has never called it. RPL4Application now has its own StopMission handler that ranks the finishers, drops each onto their spot, freezes them, re-sorts the name plates into finishing order and frames a camera on the stand. It fires once: StopMission arrives twice, from the console at the buzzer and again from the player when the ending fade expires, and only the first is the end of the race. Ranking works in football as well as a race. CalcFootballRanking ranks only the RunnerPlayers group, which would have placed the runners and stopped - but nothing calls it. What runs is Player::CalcRanking, every frame, over every scoring player by score. Three pieces of the original had been stubbed out in the D3D9 port and are restored: SetViewAngle was an empty function, so the 45 degrees the sequence asks for did nothing. It now rebuilds the projection the way DPLReadINIPage does and pushes it, and sets viewRatio, which nothing had written since the DPL body was commented out. winnersCircleFogStyle was an empty case. The stand sits far off the track in open ground where the track's own fog leaves it dark; this is the blue-violet the original used, with the fog pushed back to 100/1050 and the clip plane pulled to 1100. The end-of-mission fade had to be told to stand down. It multiplies the fog colour and both fog distances toward zero every frame - correct when a race just ends, fatal to anything shown afterwards. That fade is what made the podium a black screen, and it took a while to find because every frame was being built and presented correctly the whole time. The presentation camera overrides D3DTS_VIEW between the eye renderable writing it and ExecuteImplementation reading it back for the draw calls, so no CameraShip is needed. It builds with LookAt LH, not RH: the projection is LH, and RH aims the camera the opposite way - ask to look down at the stand and you get the sky behind you. The engine's own eye renderable is right to use RH, because its forward and up come out of the entity matrix already in that convention. The mission is held open 11 seconds rather than 3. That fade timer is the only thing keeping the simulation and the renderer alive once the race is over, and it has no upper bound on the ending path. Switches, all off-by-default behaviour aside: RP412PODIUM=0 skips it, RP412PODIUMCAM=0 keeps the cockpit view, RP412PODIUMSTANDOFF/HEIGHT/AIM frame the shot, RP412MISSIONSECONDS overrides the menu game length (the shortest it offers is 3:00, a long wait when what you are testing is the buzzer), and RP412RENDERDIAG=1 reports what a frame is made of. Verified end to end on Wiseguy's Wake: the stand, its tiers, the blue 2 and 3, the red 4 through 8 and all eight name bays, held steady for the full 11 seconds and then handing off to the results screen. Known gaps: the name plates are blank, because the player1-8 textures are runtime name bitmaps that do not resolve as files in this port, and your own vehicle has no exterior model - you see the others, not yourself. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Opus 4.8
|
4abbf8879f |
Initial import of Red Planet v4.10 Win32 source
Imports the current Win32 source for the pod-racing game 'Red Planet', built on the MUNGA engine and its L4 (Win32/DirectX) platform layer: - MUNGA / MUNGA_L4: cross-platform engine core and Win32 backend - RP / RP_L4: Red Planet game logic and Win32 application - DivLoader, Setup1: asset loader and installer project - lib, MUNGA_L4/openal, MUNGA_L4/sos: third-party audio dependencies Removed stale Subversion metadata and added .gitignore/.gitattributes. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |