[Blixibon]

The MP and SP branches of Source 2013 under one unified codebase based on the TF2 SDK. If merged, then this will enable mapbase-mp-2025 to be merged into Mapbase's master branch without requiring direct singleplayer support in the TF2 SDK, relieving most of the logistical burden of maintaining two branches at once.

The way this works is that libraries from the SP branch have been added as 32-bit counterparts to the MP branch’s 64-bit libraries, and preprocessors have been added to applicable interfaces and library code to switch between MP and SP-compatible code on project generation. All other code from the MP branch that is functionally compatible with the SP branch is unchanged. The desired branch is selected automatically based on whether the VPC project was generated for 32-bit or 64-bit.

To those who understand the technical implications of this, let it be known that this was not my ideal option.

What this will mean for SP mods

Even though SP wouldn't have 64-bit or the MP engine changes, it will still have the new file structure, the new build tools, and all of the other code changes from the TF2 SDK. This means SP mods would basically be moving to the MP branch without actually moving to the MP engine.

This has many of the same tradeoffs that moving to the MP branch already had:

• Any additional files a mod tracks in Git will need to be moved from sp/src to src.
• Some of the changes in the TF2 SDK could collide with changes made by mods, although mainly just if they touch areas in the base code.
• Visual Studio 2013 will no longer be supported, and Visual Studio 2022 will be required for development on Windows.

This does mean SP mods on the MP branch will be able to use some of the new features from the TF2 SDK, including point_worldtext, although many features (e.g. lightmapped props, bicubic lightmaps) still require engine changes.

This also means SP mods will be able to easily switch to the MP engine within the same codebase by simply generating a 64-bit project file instead.

Shaders

The MP and SP branches share shader sources. However, since the MP branch supports direct shader overrides while the SP branch does not, each branch will need to have different names for every shader. Rather than change them directly, the shader macros have been modified to prefix “SDK_” automatically when using the SP branch. For shaders which shouldn't have it regardless, the prefix can be toggled via a new include (see sdk_screenspace_general.cpp for an example). These shaders will look for .vcs files prefixed with "sdk_", but the shader compiler will still export them with their default names; a simple batch file has been added to help add the prefix to generated shaders when needed.

Other notes

• Linux is functional on both branches. A few hacks were needed to get the SP SDK working with Ninja and modern versions of GCC, although past work on Linux support (mainly from z33ky) did most of the heavy lifting already.
• The compile tools' VMPI code has been commented out in the VPCs instead of being made compatible due to its effective obsolescence in the SDK.

Preliminary FAQ

What if 64-bit SP support is added to the MP SDK, or an equivalent 64-bit SP SDK is released?

If proper singleplayer support is added to the MP SDK after this PR is merged, and there is no reason to continue using the original SP branch, then support for it will stop being maintained.

If a separate singleplayer 64-bit SDK is released, then plans will depend on its implementation. If it’s just an update to the singleplayer branch on the base SDK, then perhaps those changes will just be pulled and the previously mentioned solution will be used, although other changes may be needed if it has engine differences from the MP SDK.

If any of the above occurs before this PR is merged, then our plans to integrate it may change depending on the update’s stability, and what would be best for SP mods to transition to the new branch.

Can this be used to readd support for 32-bit in multiplayer?

By default, not really. You would need to basically take the same steps as this PR, but with the previous version of Source 2013 MP from 2015, which differs from the SP interfaces in this SDK. Having it coexist with the SP branch would also be difficult, since SP currently occupies the spaces for 32-bit libraries.

Would the old file structure still be maintained in a separate branch?

The last version under the old file structure would probably be split off into a separate branch, but it wouldn't receive changes outside of hotfixes.

---

Despite having a comprehensive outline for this PR, I have not committed to merging it and I am very much inviting input on this subject. I did most of this work in under a week and was unsure if it would be feasible up until that point, and there are still a number of pitfalls for this route. If you have any concerns about this, or if you feel that it will negatively impact your work, then please let me know.

This PR will remain in draft status until I'm reasonably confident that no more fundamental changes will be needed.

[GrubPL]

Didn't MP have some engine issues whenever it comes to the save/restore system?
and the other SP issue that caused insta crashes valve did fix, but they have yet to update the SDK with those changes

[Blixibon]

Didn't MP have some engine issues whenever it comes to the save/restore system? and the other SP issue that caused insta crashes valve did fix, but they have yet to update the SDK with those changes

That is correct. This PR is intended to sidestep them by just using the SP engine instead until those issues are fixed. There are a couple other issues with singleplayer in the TF2 SDK's game code as well, but I've sorted out most of the ones I know of

[Blixibon]

I did an interactive rebase to clean up the commit history, mainly to remove changes that were reverted later. This includes the removal of protobuf 2.3.0 from the SP SDK, since a 32-bit version of 2.6.1 was compiled and appears to be fully functional in SP.

[Blixibon]

I've tested the Linux version of this on every game for both the SP and MP branches, and it appears to be fully functional. The compile tools also appear to work correctly across both branches. However, it still feels a bit too soon to open this up for review, as I still want to allow time for discussion and potentially explore ways of removing the extra Steam headers.