search

foone / 3DMMForever

A modernized version of the Microsoft 3D Movie Maker release
MIT License
538 stars 24 forks source link

WIP (PLEASE DON'T MERGE): 64-bit version #28

Open beholdnec opened 2 years ago

beholdnec commented 2 years ago

Here is a work-in-progress branch to port 3D Movie Maker to 64-bit Windows!

This will not only bring 3D Movie Maker into the 64-bit future, but another perk is that rewriting the x86-specific parts of the code will make it easier to port 3DMM to other platforms.

Currently, the project builds and runs most of the menu. It crashes when you attempt to create or play a movie. "Internal error 103" messages may appear, but the program will continue.

Since the original code depends on 32-bit libraries, I tried to patch up the missing pieces:

LowLevelMahn commented 2 years ago

i think this pull request is too large - 143 files changes in whole - who should review that? can you splitt this pull request in smaller and more logical seperated pull requests over time?

BRender has been cobbled together from foone's BRender-v1.1.2 repo, which >dates to a few months after 3DMM's version of BRender.

björk also "ported" the 1.1.2 Version, you join forces?

https://github.com/bjrkk/3DMM-BRender (builds with VS2022,clang and mingw gcc, 32 and 64bit) https://github.com/bjrkk/brenSDL - with SDL backend active on discord: https://discord.gg/s5vcHhm2

A nonfunctional stub for the AudioMan library has been created.

is this stub optional? can one switch between the 32bit libs and your stub?

# Local Tooling
add_compile_definitions(
  $<$<PLATFORM_ID:Windows>:WIN>
  $<$<PLATFORM_ID:Windows>:IN_80386> # <====
  $<$<CONFIG:Debug>:DEBUG>
)

the IN_80386 activates most of the x86 inline asm - 3DMM doesn't build even in 32bit full without that wouldn't it be better to cleanup x86 build first and then port over to 64bit?

mdtauk commented 2 years ago

Wouldn't BRender require updating to support 64bit, or is that covered in this PR? Maybe break it out into

bruxisma commented 2 years ago

I would like to add to the recommendation that this PR be split up. I'd also like to advocate that vendoring a BRender implementation is not really a solution here. It precludes the ability for us to easily track upstream BRender implementations, doesn't allow for things like FetchContent, and as others have said, the null stub for audioman also makes it difficult to switch between versions.

My recommendations for getting this PR into a final state to merge are

  1. Convert all tooling that generates x86 ASM to generate C or C++ code instead (PCs are fast enough now, it shouldn't be an issue)
  2. Convert all inline assembly to architecture portable C or C++
  3. Setup a FetchContent option to pull in an upstream project that we later decide on
  4. Get said upstream project working with amd64 architectures
  5. Port rest of code to be amd64 safe

Work regarding a 64-bit replacement/stub for AudioMan can be done separately and alongside all of this, I should note (though given bjrkk's work on getting the SDL renderer to work, I expect SDL audio will be used at some point)

beholdnec commented 2 years ago

Thanks for the feedback. This branch is a work in progress, please don't try to merge it yet. I'll look into splitting this work up.

LowLevelMahn commented 2 years ago
  1. Convert all tooling that generates x86 ASM to generate C or C++ code instead (PCs are fast enough now, it shouldn't be an issue)

Is there a real need for generating c/cpp code?, isnt that some sort of loop unrolling, thats also not needed anymore

beholdnec commented 2 years ago

I fixed some loading issues. You can now enter the editor and place actors.