Is game modding supported here?

[pauldacheez]

(01-20-2014, 06:36 AM)isamu Wrote: Yeah but F-ZeroGX is a game which doesn't have built it online netplay. So that's why I mentioned that it would be cool if someone modded it so that it supports online netplay. I don't mean split screen either, I mean true online, where each player has their own full screen, and can play against say, 11 other players.

Modding the game to do actual online play is much more difficult than getting it working with Dolphin's netplay. You can probably tack GameCube BBA (Broadband Adapter) support onto it (like they did with Melee) with enough effort, which would likely work either as well as you dream it will or a little bit less (less max players, issues implementing lag compensation, the project dying halfway through and never being properly completed, etc.), but that still takes quite a bit of effort.

(01-20-2014, 06:36 AM)isamu Wrote: You mention reverse-engineering. Is it really possible to reverse-engineer or hack into a game like this, and actually modify it with a enough talent, skill and time?

Yup. Takes a *lot* of skill/effort/time, though, since you have to figure out not only a bunch of file formats, but also the engine's limitations and how to properly embed and load the tracks (especially without replacing built-in ones).

(01-20-2014, 08:06 AM)Chuck Finely Wrote: I have an idea for it. This idea would only work EACH INDIVIDUAL GAME!!!

If someone found the scripts in a HEX editor that initiated the music and merely removed, or re-routed the script so that it would never be used, then the music could be disabled in-game entirely. In addition, have a plugin that looks for certain hex map codes and allows the playing of a music file within the emulator. This method would have six major benefits: the song would play at its normal rate regardless of the FPS in the game since it is running separately from the emulation, it would negate the need for an in-game track editor entirely because the programs already exist and it would be able to play normal audio files, higher quality audio, possibly a much easier code to write instead of direct editing, possibly higher FPS because the emulator does not have music to run, and possibly higher stability for the same reason.

As stated before, that method would only work for whatever HEX-based game it was built for. The audio plugin itself could be universal, but the settings would have to be adjusted per game.

In addition, that concept could be applied to run the music in other code languages as well, but would still have the same restrictions as the hex language.

Your critical thoughts?

That actually sounds like a terrible idea. Not only are game-specific hacks to remove audio from every game (there are a LOT of games) a waste of developers' time, they'd cause more bugs and stability issues than they'd fix. DSP emulation is surprisingly finicky – you'd expect the thing to just play audio, but games rely on it for the weirdest shit. Wind Waker, for example, will hang if certain sounds don't finish playing at the exact moment it expects them to, and numerous other games do worse things. If you want to fix every possible issue, it's better to just emulate the DSP properly (do what the games expect) than trying to remove audio and then fixing every part of the game that relies on audio for stupid things (changing the games' expectations).

delroth's better than I am at explaining why DSP emulation isn't something you can really fuck with: http://blog.lse.epita.fr/articles/38-emulating-the-gamecube-audio-processing-in-dolphin.html

Emulation can be made faster in numerous other ways – it's not really possible to make DSP emulation that much faster, especially with DSP HLE (which is pretty much as fast as it possibly can be, it just needs bugfixes), but there's a few things that can be done to the CPU and GPU emulation that'd speed things up *much* more, e.g. a JIT that actually links blocks and optimizes them (and possibly passes blocks through LLVM in a separate thread – three-core support!) and a proper state tracker and/or second-level FIFO for the GPU thread.