Main » Hacking » Leaked Super Mario 64 Decompiled Source » New reply
    Alert
    You are about to bump an old thread. This is usually a very bad idea. Please think about what you are about to do before you press the Post button.
    New reply
    Post help

    Presentation

    [b]…[/b] — bold type
    [i]…[/i] — italic
    [u]…[/u] — underlined
    [s]…[/s] — strikethrough
    [code]…[/code] — code block
    [spoiler]…[/spoiler] — spoiler block
    [spoiler=…]…[/spoiler]
    [source]…[/source] — colorcoded block, assuming C#
    [source=…]…[/source] — colorcoded block, specific language[which?]
    [abbr=…]…[/abbr] — abbreviation
    [color=…]…[/color] — set text color
    [jest]…[/jest] — you're kidding
    [sarcasm]…[/sarcasm] — you're not kidding

    Links

    [img]http://…[/img] — insert image
    [url]http://…[/url]
    [url=http://…]…[/url]
    >>… — link to post by ID
    [user=##] — link to user's profile by ID

    Quotations

    [quote]…[/quote] — untitled quote
    [quote=…]…[/quote] — "Posted by …"
    [quote="…" id="…"]…[/quote] — ""Post by …" with link by post ID

    Embeds

    [youtube]…[/youtube] — video ID only please
    Thread review
    tomman It's now official, go clone your gits:

    https://github.com/n64decomp/sm64

    You need to bring your own retail SM64 ROM for asset extraction, and the Linux distro of your choice.

    I sincerely HOPE that with this, we can actually get ROM hackers to leave the "PJ64 unconsole" well behind, and easily produce hardware-compatible ROM hacks (or even original games!). But then, I guess this also implies getting tool developers to actually care and come up with better tools. Either way, now Mario has the keys to the realm :D
    Wowfunhappy
    Posted by tomman
    ...now after reading some comments here and there, it seems the biggest roadblock for a possible PC port would be dealing with the rather primitive SGI RSP graphics architecture, it doesn't sound like a walk in the park to essentially rewrite half of the game for OpenGL (I'll pretend DirectX does not exist for this example, but the end result will be the same)


    Couldn't they just use software rendering? Not exactly like Mario 64 is pushing technical boundaries today...
    ‮strfry("emanresu") Done.
    Kakashi What is input prediction? Please make another thread if you want to talk about it since it's been pointed out that it wouldn't benefit and has nothing to do with a PC port of an N64 game.
    Sintendo I don't think I could've come up with a more confusing name even if I tried.
    Nicholas Steel I... thought that one used a Glide Wrapper like it's predecessor. Neat that it doesn't.
    wareya The current best HLE graphics plugin is actually GL-native, GLideN64. Not to be confused with Glide64.
    Nicholas Steel
    Posted by sureanem
    Oh, and as for N64's graphics APIs: supposedly, they map very well to the archaic Glide API, which in turn has shims for OpenGL and friends. So that could very well be a way to go at it. On the other hand, then you get 2+ layers of stacked shims, so that could have all sorts of problems.
    The best graphics plugins for N64 emulators use Glide wrappers for OpenGL.
    ‮strfry("emanresu") So what exactly _is_ input prediction, if it's not game state prediction and it's not rollback? Is it the same thing as client-side prediction?
    I'm serious, not trying to ask rhetorical questions or anything. The Wikipedia article gives the impression that client-side prediction presupposes rollback and game state prediction. Is this correct?
    wareya Game state prediction and input prediction are different things and the former is not called the latter. Nobody calls what fighting games with rollback do "input prediction", because it's not.
    ‮strfry("emanresu") Oh, and as for N64's graphics APIs: supposedly, they map very well to the archaic Glide API, which in turn has shims for OpenGL and friends. So that could very well be a way to go at it. On the other hand, then you get 2+ layers of stacked shims, so that could have all sorts of problems.

    Depending on how the game is written, it might not be too much work to tear out the rendering code at a higher level than the straight API calls, depending on how much abstraction the original codebase used.
    ‮strfry("emanresu") YMMV. Smartphone keyboards are okay and I can type almost as fast on them as on a computer, if with a bit more typos. With T9 I type about as fast as in the picture.

    Taking much resources? Not really, no. It's a function of the latency and the prediction algorithm. Just assuming the player sends the same input as last frame is probably good enough, and that can't take more than a handful of cycles.

    For "real" algorithms, they tend to be rather expensive to train but decently fast to run. A SVM is basically just linear regression, but it can apply kernels to the result to pretend it isn't, just like how Excel doesn't actually do exponential regression but instead does linear regression on log(y) and then transforms the result. So I would think they're also fast enough for all practical purposes.

    The real pain is the simulation. The higher ping you have, the more frames you need to roll back each time you get an update. So with 100 ms (50 ms one-way), you need to roll back 1-2 frames, which means you need to do about 2-3x more emulation. Of course, you can skimp out on the graphics for the intermediate frames and do various other dodgy tricks, but it's still more work.

    The only way around this is to only simulate your part whenever you have the opposing player's inputs too, like Kademlia does. Then you get input lag of half your ping on top of whatever lag you already have, which isn't very pleasant. And arguably, that has worse failure modes under extreme conditions (100ms input lag is unplayable or at least gives you nausea) than rollback+prediction (CPU use is linear to latency, players might "jump" into position if we mispredicted them by too much). Under good conditions, literally anything is fine, of course.
    wertigon
    Posted by tomman

    As for input prediction, doesn't that involve obscene amounts of resource usage just for a niche feature with little gain? Dude, for your own good, stop overthinking stuff! Let it be, there are still good reasons of why native ports of SM64 (or any console game, for that matter) make sense over emulation.


    Input Prediction in terms of network play means the game has a simple algorithm that guesses what the player will do next. This is why sometimes you can see a player avatar run forward only to get snapped back a meter or two the next frame. It is a way to deal with latency issues and reduce the number of times that particular instance happens.

    It would be possible to put an AI and train it, then make a network using a very simple matrix calculation for the input prediction at the end. Even an 8x6 matrix would be decent at predicting inputs at these levels, and is hardly resource intensive for a modern GPU.

    Posted by tomman

    ...now after reading some comments here and there, it seems the biggest roadblock for a possible PC port would be dealing with the rather primitive SGI RSP graphics architecture, it doesn't sound like a walk in the park to essentially rewrite half of the game for OpenGL (I'll pretend DirectX does not exist for this example, but the end result will be the same)


    With Vulkan, probably not as much of a pain as you think. It would be possible to create wrapper functions with Vulkan as a base that does the same thing. Still a big hassle, but it would save a lot on the rewrite boilerplate.

    Or just rewrite it all to Vulkan because why not... :)
    tomman
    Posted by Screwtape
    Maybe he wants to type text messages on an old Nokia?


    T9/iTAP beats touchscreen keyboards any day of the week, one of the many, MANY reasons I still hate smartdevices.

    As for input prediction, doesn't that involve obscene amounts of resource usage just for a niche feature with little gain? Dude, for your own good, stop overthinking stuff! Let it be, there are still good reasons of why native ports of SM64 (or any console game, for that matter) make sense over emulation.

    ...now after reading some comments here and there, it seems the biggest roadblock for a possible PC port would be dealing with the rather primitive SGI RSP graphics architecture, it doesn't sound like a walk in the park to essentially rewrite half of the game for OpenGL (I'll pretend DirectX does not exist for this example, but the end result will be the same)
    ‮strfry("emanresu")
    Posted by wareya
    That's not input prediction, that's rollback. Input prediction is a term of art with a specific meaning. It only applies to the local player's own motions.

    Surely, input prediction consists of predicting inputs?
    My reading of the Wikipedia page is that you apply the local player's inputs to the game, and then make some shit up for the other players.

    >The process of client-side prediction refers to having the client locally react to user input before the server has acknowledged the input and updated the game state.[1] So, instead of the client only sending control input to the server and waiting for an updated game state in return, the client also, in parallel with this, predicts the game state locally, and gives the user feedback without awaiting an updated game state from the server.

    Are you saying the prediction has to assume everyone else stays still?
    Screwtape Maybe he wants to type text messages on an old Nokia?

    wareya That's not input prediction, that's rollback. Input prediction is a term of art with a specific meaning. It only applies to the local player's own motions.
    CaptainJistuce Nintendo 64 emulation is fast enough, so let's bolt on some neural network simulations to slow it down! Someone's gotta sell those RTX cards for nVidia...
    ‮strfry("emanresu") Sure it is, why wouldn't it be?

    The simplest possible algorithm would be to just assume that the other player keeps holding down whatever buttons he used to and play out the game as if he did, and then update whenever you get told otherwise. This would probably work decently. The next simplest would be to use some kind of generic prediction algorithm or such. Somewhat better still, game-specific neural network. And even more advanced would be to take the game state into account.

    You can't do interpolation (except for graphical such), but it shouldn't make too much of a difference in most scenarios. If you have 50 ms ping, that's 25 ms one-way, or 0.75 frames (at 30 fps). Surely, not too much can happen within that time span?
    wareya >and have room over for input prediction and other book-keeping

    Dude, input-based emulator netplay isn't capable of input prediction. What are you talking about?
      Main » Hacking » Leaked Super Mario 64 Decompiled Source » New reply
      [Your ad here? Why not!]