SC: FA (Moho) engine sources
-
This is the most promising step forward for FAForever, with no intentions to refute other work like the alternative version of the game in written in Rust which is also impressive. @draiget and the others that are or were involved - hats off to all of you. This is such a milestone that it may almost make me come back to see it through. The fact that we can now fix fundamental problems with this engine makes for a promising future for FAForever. The problems that Draiget mention with regards to hardening the application are real. Being able to run the game at x64 instead of x86 is also not to be underestimated, as I assume this would also relieve the RAM limit that we often experience. This truly opens the flood gates:
- We can actually debug and understand the engine now. No more going in circles and guessing.
- We can fix networking problems where they occur. No more wrappers like ICE adapters.
- If I read it correct, the whole thing is even backwards compatible (!!)
These two things on their own are so fundamental. Networking problems have been the Achilles heel of this community. It's literally what's been holding us back. Having more, decent performance is a huge plus. All the other things are not quite as relevant. Having water at different elevations is nice, but (and don't take offense by this, please) it is feature creep. Just like 10k vs 10k ASF battles. These are not the things we need. We need a more stable game, where there's less lag. Matchmaker can just launch, without it being a gamble on 4v4 or higher queues. The game is great (and sure, limited to some extend) on its own. It's why all of you are still here. So whatever happens next, please focus on the problems that actually matter first. The problems that we could never really solve, only apply bandaids for.
-
Welcome back Jip, you know you want to tinker with the engine a bit
-
A question because I'm interested, with the caveat that I'm not sure if this can be actually answered on a public forum:
Do we run into any potential legal issues with this? Is there anything that needs to be considered?
-
@Nombringer my repository is a potential legal issue tbh, less that it was initially because I stripped CRI middleware and replaced it with the open source FFmpeg, but still it does do almost 1:1 reassembly of original binary. Yes that's not "original" sources but it's very close. The way we can make it cleaner, is to remove all mentions of "Address: 0x0..." that I've added in every engine function during restoration process and rename every single class\namespace to a custom one, better a clean-room implementation of moho engine with same replay-parity (which is achievable and I did created specs for this already for future). But since FAF model is to require to buy\have original game before playing - I don't think we someone will even be looking on us with lawyers, but who knows for sure.
-
BUG in d3d12 mode.
Additionally, I have observed that smoke particles from certain explosions behave abnormally; compared to the original version, they drift outward and upward for an excessive amount of time and fail to dissipate. At times, smoke particles remain visible directly in front of the camera for an extended period. I have been unable to consistently reproduce this bug.
-
I know itโs the faf forums but, would this be able to be compatible with LOUD?
-
My understanding is not currently, but Marlo's been working on steam compatibility differences to FAF so it sounds feasible that LOUD compatibility could be reached
-
@Novus-Wojtek LOUD is based entirely on the original EXE, so that points to some differences that aren't currently resolved.
Marlo has indeed made considerable progress in putting together a version of this project which is entirely compatible, which would be a potential boon for both LOUD and users of the Steam version of the game. My personal feeling is this - if this work can reach to all the many players who don't use FAF, or LOUD - then it's only good for both communities.
-
@draiget I have a question about the source code. Have you measured how much simulation time is spent on Lua code and how much on C++? As I understood it, the C++ simulation does not run in parallel with the Lua code. Or is that not the case?
-
@Xiaomi Lua stuff only takes about 6.5% of a tick-time in my measurements:
- 5.3% is Lua threads (unit, weapon, AI brain and score scripts)
- 1.1% is Lua garbage collection.
Calls from the engine into Lua callbacks (OnDamage, OnKilled, weapon and projectile callbacks and so on) aren't separated yet, so they're still counted as C++ time. The rest is C++: bone/animation updates are about 15%, vision/radar about 13%, and building the state sent to the UI about 12%.
On parallelism - basically yes, very bit of sim Lua runs on the single sim thread, interleaved with the C++. Engine calls into Lua, and Lua calls back into the engine, nothing really runs Lua in parallel. What my build adds is helper threads, like: vision refresh, the UI sync data, effects, coordinate updates and the mark/sweep part of the Lua GC. In one case (vision) this C++ work overlaps with the sim thread's Lua, but before that Lua calls any engine function, the helper jobs are finished first, so the results stay identical to the original game and replays still match.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better ๐
Register Login