0 users browsing Hacking. | 2 bots
| Kakashi |
Posted on 19-07-13, 00:12
|
 Post: #147 of 210 Since: 10-29-18 Last post: 1877 days Last view: 1848 days |
(Posted by a guy who desperately wants someone to analyse it for him.) https://gbatemp.net/threads/super-mario-64-has-been-decompiled.542918/ |
| Duck Penis |
Posted on 19-07-13, 11:24
|
|
Stirrer of Shit
Post: #497 of 717 Since: 01-26-19 Last post: 1763 days Last view: 1762 days |
Just keep in mind that we weren't done yet. It's really only like maybe 65% finished, code and documentation wise. This codebase is an absolute treasure for preservation sake. Turns out if you compile your ROM unoptimized its really easy to get the uncompiled code from the assembly. Guess Nintendo should have double checked their CFLAGS before shipping US and JP. Uh, aren't you supposed to compile peformance-critical software with optimizations on? Great work though. Here's the original thread. There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this. |
| Kawaoneechan |
Posted on 19-07-13, 11:28
|
|
YEEEEAAAAH~!
 Post: #296 of 599 Since: 10-29-18 Last post: 196 days Last view: 1 hour |
Me, I'd prefer the original code. But I'll take it. |
| creaothceann |
Posted on 19-07-13, 11:37 (revision 1)
|
 Post: #169 of 456 Since: 10-29-18 Last post: 44 days Last view: 1 day |
Posted by sureanem The optimizer might not have been very effective yet, or might have had too many bugs. You don't have that problem on x86 because it has already been around for so long. My current setup: Super Famicom ("2/1/3" SNS-CPU-1CHIP-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10 |
| CaptainJistuce |
Posted on 19-07-13, 11:38
|
|
Custom title here
 Post: #567 of 1164 Since: 10-30-18 Last post: 63 days Last view: 16 hours |
Everyone knows that if you care about performance, you hand-code the assembly. --- In UTF-16, where available. --- |
| tomman |
Posted on 19-07-14, 16:19 (revision 2)
|
|
Dinosaur
 Post: #440 of 1316 Since: 10-30-18 Last post: 5 hours Last view: 1 min. User is online |
1) Assuming this ever gets finished, how feasible would be something like, say, a native PC port? 2) Oh, scene drama! Also, Nintendo DMCA'ing some asses is in the order for today. Hackernews coverage: https://news.ycombinator.com/item?id=20418577 Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| Duck Penis |
Posted on 19-07-14, 17:57
|
|
Stirrer of Shit
Post: #503 of 717 Since: 01-26-19 Last post: 1763 days Last view: 1762 days |
They used an entirely unmodified GCC, although some developers might have used other stuff. They also had some other software to do some stuff, since they couldn't modify GCC nor interact with it too tightly. Not sure what the point of a port would be - for performance UltraHLE is already pretty much transparent, and if you want fancy input then that could be done without a port like in 1964. But from my understanding, it'd be nearly trivial since you have x86 shims for the N64 API already. There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this. |
| tomman |
Posted on 19-07-14, 20:42
|
|
Dinosaur
Post: #441 of 1316 Since: 10-30-18 Last post: 5 hours Last view: 1 min. User is online |
> Not sure what the point of a port would be Given the overall quality of N64 emulators, a native port of ANY N64 game can be able to provide a much better experience. Not having to emulate a foreign CPU architecture can free CPU resources for more impressive special effects, for example. > for performance UltraHLE is already pretty much transparent I'll pretend I didn't read that. > and if you want fancy input then that could be done without a port like in 1964. Trying to emulate a controller with another can be troublesome in some cases (ask the Dolphin guys - it may not be a problem for N64 but you can always do things The Proper Way with a native port). With a native port, you can improve keyboard-only experience, for starters. > But from my understanding, it'd be nearly trivial since you have x86 shims for the N64 API already. Was it on the original N64 SDKs? Early devkits were SGI/Irix-based, dunno about later ones. But then, Nintendo is no stranger to multiplatform development... Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| Kakashi |
Posted on 19-07-15, 02:51
|
|
Post: #150 of 210 Since: 10-29-18 Last post: 1877 days Last view: 1848 days |
They are already able to compile it on PC, with some work. Where is this DMCA, specifically? |
| Duck Penis |
Posted on 19-07-15, 18:03
|
|
Stirrer of Shit
Post: #504 of 717 Since: 01-26-19 Last post: 1763 days Last view: 1762 days |
> for performance UltraHLE is already pretty much [not] transparent Well, how isn't it? N64 >CPU 64-bit NEC VR4300 @ 93.75 MHz >Memory 4 MB Rambus RDRAM (8 MB with Expansion Pak) UltraHLE supposedly needed a ~300 MHz CPU and 32MB ram. So at the back of the envelope, ~30% efficiency. Which is worse than I thought, but still not too bad. And application of modern techniques could probably get the number down further. (in case anyone says performance at those levels is unimportant nowadays: for netplay it sure isn't, since then you might need to emulate several frames per frame, and have room over for input prediction and other book-keeping) >Trying to emulate a controller with another can be troublesome in some cases (ask the Dolphin guys - it may not be a problem for N64 but you can always do things The Proper Way with a native port). With a native port, you can improve keyboard-only experience, for starters. You can do this for emulation too though. Look at the PD/GE mouse injector, for instance. It just writes/reads RAM directly. If you wanted to get things reproducible, you could compute the desired value of, say, "looking.x" and "looking.y" one frame from now, and then work backwards to the needed inputs. It'd be trivial to test automatedly and perhaps even decide functions for. Of course, sometimes you can't move more than one position in a menu per frame, for instance. But I wouldn't reckon that's such a big problem, since the standard mode of using menus is not to consistently fling your mouse across the room several times a second. Considering the work needed to port one game, it seems like a better investment of time to map out the RAM locations you want to hit and functions you can safely replace with native APIs, and keep the non-performance-critical code emulated. And then you could still do all the fun stuff like keyboard entry for character names, mouse entry in menus, and so on and so forth. Kind of how like machine learning and whatnot uses Python et al, but calls into C/C++ for the heavy lifting. Performance would be as good, development velocity much better, legal issues non-existent, and you'd probably end up with a higher quality end result. I mean, 90% of the code (reading memory values, image map stuff, mouse/keyboard input stuff, console input stuff) would be re-usable. All you'd need to do is map out the RAM (no programming skills needed), draw image maps (completely non-technical), and write function replacements (a bit of work but only needed for performance, most modern computers can run Mupen64Plus/Project64 no problems). Also, the function replacements' validity can be tested in an automated fashion. The others can be tested trivially, if still requiring some human effort. And since your emulator-port hybrid relies on human work for each game anyway, you might as well pull a ZSNES with a games database. >[Were the x86 N64 API shims included] on the original N64 SDKs? Early devkits were SGI/Irix-based, dunno about later ones. But then, Nintendo is no stranger to multiplatform development... I mean the shims they use in UltraHLE, for instance. The devkits needed you to have a physical console that you connected via serial port. If I recall correctly, they shipped documentation of it but not implementations. The SN64 devkit which I think was the most common one ran on both SGI and Windows. There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this. |
| wareya |
Posted on 19-07-16, 00:05
|
 Post: #71 of 100 Since: 10-30-18 Last post: 1782 days Last view: 1347 days |
>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? |
| Duck Penis |
Posted on 19-07-16, 11:29
|
|
Stirrer of Shit
Post: #507 of 717 Since: 01-26-19 Last post: 1763 days Last view: 1762 days |
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? There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this. |
| CaptainJistuce |
Posted on 19-07-16, 13:33
|
|
Custom title here
Post: #572 of 1164 Since: 10-30-18 Last post: 63 days Last view: 16 hours |
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... --- In UTF-16, where available. --- |
| wareya |
Posted on 19-07-17, 03:09 (revision 1)
|
|
Post: #73 of 100 Since: 10-30-18 Last post: 1782 days Last view: 1347 days |
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. |
| Screwtape |
Posted on 19-07-17, 03:21
|
|
Full mod
 Post: #303 of 443 Since: 10-30-18 Last post: 1101 days Last view: 172 days |
Maybe he wants to type text messages on an old Nokia? The ending of the words is ALMSIVI. |
| Duck Penis |
Posted on 19-07-17, 11:33
|
|
Stirrer of Shit
Post: #512 of 717 Since: 01-26-19 Last post: 1763 days Last view: 1762 days |
Posted by wareya 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? There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this. |
| tomman |
Posted on 19-07-17, 16:16
|
|
Dinosaur
Post: #443 of 1316 Since: 10-30-18 Last post: 5 hours Last view: 1 min. User is online |
Posted by Screwtape 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) Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| wertigon |
Posted on 19-07-17, 20:35
|
|
Post: #87 of 205
Since: 11-24-18 Last post: 156 days Last view: 27 days |
Posted by tomman 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 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... :) |
| Duck Penis |
Posted on 19-07-17, 20:52
|
|
Stirrer of Shit
Post: #517 of 717 Since: 01-26-19 Last post: 1763 days Last view: 1762 days |
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. There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this. |
| Duck Penis |
Posted on 19-07-17, 20:57
|
|
Stirrer of Shit
Post: #518 of 717 Since: 01-26-19 Last post: 1763 days Last view: 1762 days |
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. There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this. |
