[HN Gopher] Leaked Wipeout source code leads to near-total rewri...
___________________________________________________________________
Leaked Wipeout source code leads to near-total rewrite and remaster
Author : isaacfrond
Score : 188 points
Date : 2023-08-25 14:42 UTC (8 hours ago)
(HTM) web link (arstechnica.com)
(TXT) w3m dump (arstechnica.com)
| holoduke wrote:
| Always impressed how some people possess the skill to plough
| through these kind of codebases. I wouldnt even know where to
| start. Yet alone find the time to execute these kind of projects.
| Although maybe I should remember my life before kids. Coding till
| 4 pm every day. Huge respect for this guy.
| wredue wrote:
| Look at it as a whole bunch of little problems instead of one
| big problem.
| nlunbeck wrote:
| I know, right? I've spent the last 15 or so minutes just
| marveling at how nicely cleaned up it all is, I can only
| imagine how overwhelming it must've been to see the mess it
| was. Really shows what some extra time/budget could do for
| major studios releasing remasters.
| ars wrote:
| It goes like this: You read a function and understand what it
| does. You scream at the original programmer (who was probably
| yourself) for being an utter idiot and doing it badly. Then you
| rewrite it better.
|
| Then you go to the next function, and realize it doesn't even
| need the previous function at all, so you get mad at yourself
| and delete all that wonderful code you just wrote.
|
| Then you try a new way: instead of inside out (start at the
| internal functions) you start at the top - you find where the
| code handles some particular task, and you drill down deep into
| it, throwing away useless code left and right and rewrite the
| thing better. (Your advantage being you know exactly what it
| needs to do, unlike your previous self who did not know that
| since he was still developing it.)
|
| You also use a tool that finds dead code - in particular
| functions that are never called by anything.
| bityard wrote:
| Breaking big problems down into small ones is part of the
| process, yes, but only once you are well-versed in the
| problem space. The guy who rewrote this:
|
| 1. Is proficient in C.
|
| 2. Understands Playstation architecture and development
| better than the original programmers of the game. (Although
| Psygnosis had far less time and hindsight on their side.)
|
| 3. Is apparently quite familiar with 3D game programming and
| techniques in general, and how/when to use them.
|
| 4. Already had experience reverse-engineering parts of the
| game previously.
|
| 5. Had the free time to undertake a project of this scale.
|
| So it's not something any random dev can just snap their
| fingers and decide to do. It's a case study on the
| intersection of experience, preparation, and luck.
| morelisp wrote:
| On the other hand I think ars's point is good advice: The
| way you do the work is, by doing the work.
|
| So many people I work with these days are constantly
| looking for tricks, or secrets, magic tools, or whatever
| they seem to think I'm doing to consistently outpace them,
| just to avoid writing code (/ reading code / thinking
| through code). They take 2-10x longer and their result is
| invariably worse. When you ask why they do it, they answer
| "you'd have to do so much refactoring", "the algorithm
| would be hard to implement", "I'd have to replace
| dependency X", and so on as a list of things that actually
| aren't so hard or time-consuming if you sit down and just
| do the work. But my only "trick" is that I write the code.
|
| Just sit down and do it! I'm reminded of Harlan Ellison,
| commenting on why he wrote in public,
|
| _I do it because I think particularly in this country
| people are so distanced from literature, the way it's
| taught in schools, that they think that people who write
| are magicians on a mountaintop somewhere. And I think
| that's one of the reasons why there's so much illiteracy in
| this country. So by doing it in public, I show people it's
| a job._
|
| Wipeout was asses in chairs writing code. This cleanup is
| an ass in a chair writing code. Yes soft skills are
| important blah blah. But if you want to be good, to learn
| to do this stuff, there's no way around putting your ass in
| the chair and writing code.
| Sohcahtoa82 wrote:
| > So many people I work with these days are constantly
| looking for tricks, or secrets, magic tools [...]
|
| I mean, that basically explains the utter cesspool that
| is the npm ecosystem.
|
| JS/Node programmers don't write code, they just glue
| together a bunch of libraries and hope it works.
|
| I used to think that the "is-odd" package [0] was a joke,
| but then I see it has nearly half a million weekly
| downloads. People are actually using it!
|
| [0] https://www.npmjs.com/package/is-odd
| morelisp wrote:
| Shipping bad code fast and with little understanding
| isn't really what I'm talking about. I would say the kind
| of frontend developers you're describing lack hubris; the
| ones I'm talking about (which are all over the stack but
| I would say somewhat concentrated in the middleware-to-
| commodity-backend, Spring Boot, etc. area) lack laziness.
| hinkley wrote:
| If we could get this kind of energy invested into shared
| libraries...
| ChrisArchitect wrote:
| Previous discussion from a few weeks ago:
| https://news.ycombinator.com/item?id=37082304
| bityard wrote:
| This is the third time it has made the front page in as many
| weeks. :)
| suby wrote:
| The refactored source code is really clean and readable.
|
| https://github.com/phoboslab/wipeout-rewrite
| TehShrike wrote:
| Readers may prefer the original post by the programmer behind the
| rewrite: https://phoboslab.org/log/2023/08/rewriting-wipeout
| _a_a_a_ wrote:
| I'm sorry, 6,000 FPS? How is that possible?
| [deleted]
| lunchdetail wrote:
| They're talking about the speed of the internal engine, not
| the display. So the display could still only be showing 60
| frames to the user each second (or 120, or anything) but the
| internal engine is running at 6000fps.
|
| Plenty (maybe nearly all?) of games do this because modern
| engines decouple the engine speed from the display speed. In
| older systems where you knew the engine was only going to run
| for a specific game on specific hardware (e.g. a SNES or
| GameCube or PlayStation), and you knew you were always going
| to be targeting 30fps, no more no less, you could pretty
| safely assume the game would _always_ run at 30fps and could
| use a "frame" as a unit of time. So if you want some in-game
| action like a melee attack to take 1 second, you could just
| count 30 frames and you would know it was 1 second long. But
| if somehow this game was later run at 60fps, that same attack
| would now only take .5 seconds, since there were twice as
| many frames in a second now.
|
| So if you took a game like this meant for 30fps and ran it at
| 60, everything would just run twice as fast. You wouldn't
| actually be able to play the original game at anything higher
| than the original frame rate.
|
| What they're saying here is that they decoupled the two,
| where originally they were coupled. So now the game can run
| at high fps and feel smoother than the original lower fps
| rate, but the gameplay is still at the original intended
| speed.
| bityard wrote:
| Interesting twist: Wipeout XL/2097 for PC was a
| terrifically bad port, and the game speed was proportional
| to how fast your video card could draw the 3D scene, just
| as you describe.
|
| There was a patch at some point to fix this, but honestly
| just easier to load the game up in a PSX emulator these
| days.
| mmastrac wrote:
| The code was probably hyper-optimized for decade+ old
| hardware.
| db48x wrote:
| No, it wasn't hyper-optimized, it just doesn't draw many
| triangles or use many light sources. There is simply a lot
| less for the renderer to do than in a modern game.
| squeaky-clean wrote:
| It means it's calculating 6000 frames per second, but all of
| them don't need to make it to the screen. On a 60hz screen,
| every 100th frame calculated would actually be displayed. (If
| we assume a perfect 6000fps, the video shows fluctuations
| between 4000fps-7000fps.
|
| If you just mean how can it be so high in general? Old, well
| optimized, games run really well on faster modern hardware. I
| remember getting over 1,000 fps in Guild Wars 1 on a GTX 1060
| when looking at an area with no monsters/NPCs.
|
| edit( this paragraph doesn't apply here) ~~The PS1 also
| doesn't have floating point math, mostly everything is done
| in fixed point with integer math which is obscenely fast
| compared to floating point (it could also simulate an FPU if
| the precision is absolutely necessary but that's not suitable
| for realtime)~~
|
| Just read further down the article that they converted it to
| float. I guess the game is just super optimized. I would have
| thought fixed point savings factored in here.
| _a_a_a_ wrote:
| > all of them don't need to make it to the screen
|
| ah gotcha, thanks. The bandwidth would have to be
| terabytes/sec. Come to think of it, pretty dumb of me to
| think they did.
| squeaky-clean wrote:
| Nah, most people would probably not think of unseen
| frames being generated unless you're into studying your
| graphics performance.
|
| It also technically does make a difference in some games.
| Even if the frames don't make it to the screen, if your
| mouse polls at 1000hz then you can get more precise input
| tracking by rendering up to 1000fps. It's something only
| really noticeable to professional gamers. But pro CSGO
| players are positive they can feel an improvement when
| running at fps more than double their monitor rate.
| kmeisthax wrote:
| Also keep in mind that games don't run at a constant FPS.
| The "FPS" stat that we talk about is an _average_ of the
| time each frame took to process and render, 1 /x. But we
| can also talk about deviation from that average, which is
| where you get "1% low" and "0.1% low" stats. If your 1%s
| or 0.1%s dip below your monitor refresh rate, that
| becomes microstutter, which is way more noticeable than a
| reduction in the average frame time.
|
| Wanting to have FPS at 2x your monitor's refresh rate
| will[0] provide a significant safety margin against
| frames that take too long to render. I will also point
| out that this 2x rule came into the community before we
| had adaptive sync, so the alternative would be turning
| off vsync in the vain hope that microstutter would get
| lost in the tearing.
|
| For the record, "microstutter" wasn't really a common
| thing people talked about until fairly recently, so I'm
| kind of applying today's more scientific analysis of game
| performance to things that back then were largely
| superstitions that happened to work.
|
| [0] Assuming a fast CPU and GPU drivers worth using
| ufjfjjfjfj wrote:
| Isn't it a waste of computing power to produce 6000 fps and
| only use a fraction of them
| throwaway14356 wrote:
| you need about the same impossible accuracy to play this.
| im only half joking, if you want to improve you will need
| to somehow respond more accurately. Seeing someone play
| it well is mind blowing if you know how hard it gets.
| ComputerGuru wrote:
| Yes, but in practice, no. These games are usually coded
| as a loop that runs with full CPU as fast as it can
| (unless capped, which the old one wasn't), using as much
| cpu as is available. In that case, the fps is a side
| effect of how long the loop takes to run each pass (which
| is what happened here) - i.e. you don't determine the
| fps, the fps is a result of how complicated or
| (in)efficient your code is. So going from running at 30
| fps because it was so poorly coded and made such
| inefficient use of the cpu to running at 6000 fps because
| it now completes each loop pass that much faster, the cpu
| usage is actually the same.
|
| Now if your code is so optimized that it can run at 6000
| fps, _at that point_ you can say "gee, I don't need this
| many updates a second, let me cap it to x frames per
| second." But how do you do that? The GPU is grabbing
| finished frames out of the buffer at its own pace,
| whether you are generating them at 6k /sec or just 5/sec.
| To cap your cpu consumption you would usually say "we
| need a new frame every 0.015s to always have a new frame
| ready for the GPU so that the screen updates sixty times
| a second, so if we finish a frame in 0.001s instead,
| sleep (effectively yielding cpu consumption to other
| processes) for 0.01 seconds after we run through the
| loop" - but while that may work for some things, there
| are other stuff that need to happen "in real-time" such
| as reloading the audio buffer (to avoid pauses or
| corrupted/garbled audio), etc and you also can't rely on
| the system to _actually_ wake you before 0.015s even
| though you asked it to wake you after just 0.01s to be
| extra safe.
|
| Tl;dr, yes, _once_ your code is running at 6k fps, _then_
| capping it to reduce consumption is an option, but
| running at 6k fps doesn't actually increase cpu vs
| inefficiently running at 30fps.
| johncoatesdev wrote:
| You can get a callback when a frame is going to get drawn
| and only render then. That way you don't render needless
| frames.
|
| Your logic loop that controls the game state can be set
| to an optimal tick rate so it's not just maxing out a
| core.
|
| The audio buffers I've worked with have also supported
| callbacks so they can remain optimally filled.
| leptons wrote:
| It's possible that going far above "6000fps" might be
| necessary someday for holographic/3D displays that need
| to render the scene from hundreds or thousands of
| different viewpoints for one single frame.
|
| Say you need to render a scene from 1000 different angles
| for a 3D display, just to get to a 60hz refresh rate you
| would need to render the scene 60,000 times.
| tomcam wrote:
| Everything about that article is delightful. Author is way too
| modest to point out that it's a stunning achievement.
| standardly wrote:
| A next-gen wipeout in VR would be incredible. And vomit inducing.
| jonhohle wrote:
| Nexter-gen than the wipEout Omega Collection on PSVR? While
| enjoying wipeOut, I could only handle a few races and went back
| to playing on a screen.
| Sohcahtoa82 wrote:
| You might enjoy Redout:
|
| https://store.steampowered.com/app/517710/Redout_Enhanced_Ed...
|
| Note that it's VR _supported_ not VR _required_. You can play
| this without VR just fine.
| pengaru wrote:
| The numbers are somewhat artificially exaggerated since it sounds
| like the source leak contains what are effectively multiple
| platform-specific copies of the same game.
|
| That's a pretty common pattern when you're porting to a
| substantially different system, from a bespoke base like a small
| launch title, that was never intended to run on anything else.
| Especially in an era before everyone used vcs tools like git with
| cheap branches. We used to work on diverging whole copy forks
| _constantly_.
|
| Going through this mess and cleaning it all up must have felt
| incredibly satisfying because of all the low-hanging fruit. It's
| like a long overdue spring cleaning.
| mbStavola wrote:
| Wipeout was great, but I always preferred playing Extreme-G on
| the N64. I know the source for the third game in the series was
| leaked, but I'm still waiting for the original!
| mjevans wrote:
| "Either let it be, or shut this thing down and get a real
| remaster going."
|
| Solidly agree, copyright / IP shouldn't be about holding the
| public hostage. It should be about maximizing the mutual benefit
| for both the creator and, very importantly, the public.
|
| Culture deserves love and respect and must be 'accessible' (able
| to buy); or it should be set free (public domain).
| esaym wrote:
| What is the backstory for this leak? Where was it found, etc.
| [deleted]
| 93po wrote:
| https://twitter.com/forestillusion/status/150804826817699020...
| psychphysic wrote:
| Excellent..more of this please.
|
| Super Mario 64 has also had stupendous rewrites from decompiled
| code I believe.
|
| https://youtu.be/t_rzYnXEQlE
|
| His videos on the Sine function in sm64 is a fun watch as the
| limitations make nearly all optimizations justifiable.
| efields wrote:
| > The 5000 lines of if else that handles the menu state is a
| striking witness to this insanity.
|
| > He takes the code from 40,699 lines to 7,731 and notably loved
| an excuse to work in C. "I had an absolute blast cleaning up this
| mess!"
|
| I't just marvelous to learn what kind of crap coding makes it to
| production. It's a huge boost to my self-esteem.
| rgoulter wrote:
| The risk of 'bad' code is that it might be hard to make the
| change you want. I would believe that spaghetti code is more
| likely to have bugs than 'well designed' code.
|
| When code is fresh in your mind, there's more tolerance for how
| disorganised the code can be and still be easy to change.
|
| If your shipping method is "one shot".. time spent cleaning it
| has a chance to provide value; but time spent adding features
| is very likely adds value. -- Probably if the code is very
| clean, then at least some time would have been better spent
| adding features.
| taeric wrote:
| You aren't wrong, but a lot of the risk of "good code"
| nowadays is that there is more of it. An added risk is a lot
| of "good code" is leaning heavily on practices that are not
| good for performance.
|
| I don't want to push for lax testing standards. And I
| generally prefer modern build practices for programming. It
| is hard to take a lot of criticism of gaming code seriously,
| though, as games were shipped at what feels like a higher
| success throughput than most business software.
| gopher_space wrote:
| The IRS isn't going to get involved if your physics don't
| match reality. Defining and creating your own data means
| you get to skip most of the headaches in business software
| development.
| taeric wrote:
| Not a small point, but I think it is more than IRS
| concerns that have caused web bloat. Gmail taking seconds
| to respond to keyboard is definitely not explained away
| with business logic being hard. Is it?
| Pannoniae wrote:
| "Bad" code also has way less abstractions. It's
| ridiculously easy to change something (unless it's really
| spaghetti/everything is intertwined)
|
| "Good" and modern code often has many abstractions. In some
| cases, that gives ultimate flexibility, but in some cases,
| if you are fighting the abstraction or the framework, it
| will make it almost impossible to change.
| ldjkfkdsjnv wrote:
| I was going to post this, abstractions almost never work
| out well as the code base changes
| fidotron wrote:
| In games it happens quite a bit.
|
| The great debate is always "will I want to change this tiny
| thing here without impacting everything else?" vs DRY. Studio
| cultures differ, but I would say at least half resort to hard
| coding things like positions of every item manually given the
| excuse they might want to shift something by a bit later (in a
| hurry, crunching etc.) without side effects.
|
| Thankfully the emergence of more standard tooling and engines
| has pushed this to being more of an art resource concern, but
| it does lead to things like being told that taking a game that
| assumes a 16:9 1080P display and making it more flexible will
| take multiple years of person time.
|
| Personally I cannot stand this tendency, but do get why they do
| it.
| maccard wrote:
| I think the days of that happening are mostly gone. In the
| days where games were one-and-done, gameplay code was like
| this, but in the age of sequels & live service games, game
| code is as good (or bad) as any other code.
| hinkley wrote:
| You can get pretty close to the end of a project before you
| really understand what it was you were trying to do.
| Especially if management is allowed to keep moving things on
| you. I think this is substantially the instinct that leads to
| Waterfall. I just want to know what I'm supposed to be
| building for a while before you 'ruin' it.
| ClimaxGravely wrote:
| Definitely. I've worked on my fair share of projects where
| the game is essentially completely changed midway or late
| in development.
|
| Stuff like "this single player game we've been working on
| for 2 years now has to be a multiplayer game". That was a
| fun one.
|
| In other industries I've been able to reasonably strategize
| for various changes but in games the change can be so
| profound and out of left field it's pretty much impossible
| to anticipate the change and plan for it.
| hinkley wrote:
| "We are never going to internationalize this software."
|
| "We just discovered a thing called a globe."
| tomcam wrote:
| > You can get pretty close to the end of a project before
| you really understand what it was you were trying to do.
|
| Truer words were never spoken.
| fidotron wrote:
| In my case the insight happens about 3 weeks after the
| project was delivered.
| hinkley wrote:
| "You were _serious_ about that? "
| tomcam wrote:
| Holy shit that knocked the wind right out of me!
| blueboo wrote:
| Is the gameplay of Wipeout actually any good? Always admired the
| aesthetics, and I love F-Zero GX, but...
|
| The bonking against sides, the short view distance induced by
| excessively-curved tracks makes it feel like the NES game RC Pro-
| Am, but instead of an tightly-cropped overhead view of the track,
| you see the next fifty feet of track ahead (at 1,000
| scifimeters/sec).
|
| The game felt brute-forceable through its brittle, unforgiving
| driving but it was so frustrating I never gelled with it. Was I
| missing anything?
| Jare wrote:
| It's very good for its time, but also very harsh. It was
| polished to perfection in Wipeout 2/XL.
___________________________________________________________________
(page generated 2023-08-25 23:01 UTC)