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 Figured out how to remap keys: the menu is there in the new Options menu (which is compiled by default; press virtual R on pause)

    Default keys are all screwy: START is Space, analog stick is WASD, one of the shift heys are A (or B?), L seems to be R or whatever... but once remapped, all is good again. Except that if you opt-in for the "better camera", you'll have a tougher time playing the game. Ah well, consider it a new experience then. It works better with dual analog sticks. A Xbox 360 gamepad gets a sane mapping, basically the same as Mupen64Plus (right stick = C-keys).

    Oh, and it seems to implement the Shindou Edition improvements: vibration works on my X360 pad - feels weird to feel the breeze in your hands when Mario is fired from a canyon, for example.

    Can't wait once ROM hackers start making magic with this, if they don't want to get bound by the original hardware limitations...
    CaptainJistuce I never had reason to use T9 text entry much. Only phone I ever did, the buttons were so stiff and nasty that the actual keyboard was my obstacle more than text-processing.
    And I still hate full QWERTY on a pocket display.



    Non-paid promotional content: I have actually used MessagEase on my Android devices for a few years. I find it very pleasant, with a remarkably mild learning curve, and an excellent use of limited space on a compact touchscreen.
    This is also how I generate utterly alien typos like "e instead of space" sometimes.
    kode54 Chiming in to point out that this port is also on the AUR as a package there, if you use Arch, btw.

    Oh, and retorting to your comment on fricking T9. I never managed to get the hang of T9 during the years I owned a feature phone, while my little brother handled it just fine. The best I could do was bang out a single sentence in a whole two minutes. Give me a touchscreen full qwerty keyboard any day. Oh, and I don't use my thumbs for this shit, I hold the phone with one hand and tap with my right fore finger. Or if I'm on a tablet, I can do more fingers on both hands.
    tomman And now fate was met: someone managed to make a native SM64 PC port:
    https://github.com/sm64-port/sm64-port
    Or even better: https://github.com/sm64pc/sm64ex (you can actually configure stuff, etc.)

    Now you can run good ol' Super Mario Sixty-Four just like SGI intended: not on a crippled $300 STB, but on an actual 64-bit Unix workstation!
    Forget about borked PJ64_v1.x N64 emulators - the princess is now in another castle. And she still looks the same, but native :P

    (Technical details: the engine is more or less unmodified, apparently they reimplemented the F3DEX ucode on D3D/OGL, and created libultra shims - everything else is compiled as-is, natively)

    In the case of sm64ex, they somehow managed to break the camera even harder: try the Koopa the Quick race at BOB and enjoy frustration because camera completely loses its mind. Oh, and remapping keys isn't straightforward - a Xbox 360 gamepad helps.
    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?

      Main » Hacking » Leaked Super Mario 64 Decompiled Source » New reply
      Yes, it's an ad.