Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 25 additions & 0 deletions src/OpenSHC/Audio/mss/SoundSystem/playSound.cpp
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
#include "OpenSHC/Audio/MSS/SoundSystem.func.hpp"

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why the space between includes? I don't really mind, just curious.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just like to make up some structure. My mind currently works roughly like this:

#include "mainForFile.func.hpp"

#include "other.func.hpp"
#include "other2.hpp"

#include "global.hpp"

#include "msAndOther.h"

May vary, certain is usually just main func.hpp first and additional microsoft headers and such last.

Copy link
Copy Markdown
Contributor

@gynt gynt May 23, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good to me. Perhaps you can codify this into our clang-format (different PR)? (not to be 100% foolproof, but rather working most of the time) https://clang.llvm.org/docs/ClangFormatStyleOptions.html#includecategories

Copy link
Copy Markdown
Contributor Author

@TheRedDaemon TheRedDaemon May 23, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, I tested around a bit, and the following things are relevant:

  • Messing with the import of course makes many header files invalid, which will show up when they are changed the next time.
  • I am almost able to recreate the structure I mentioned, but there is one thing: I can not isolate the "main" file for the cpp file, since there is nothing in the filename of the current cpp to match to the hpp file. Two solutions I could think of, both containing changing the include:
    • Adding the class to the filename. Might fail with the globals, e.g. "SoundSystem..cpp"
    • Using another form for them and just handling them as another include category:
      • relative: ..\SoundSystem.func.hpp
      • <>: <OpenSHC/Audio/MSS/SoundSystem.func.hpp>
        • This one is a bit less standard, since it uses the "external/system" syntax convention with <>, but in the end, we so far have used full non-relative paths anyway.

What do you think? Change something? Leave it manually as it is now?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh so you can't really isolate the fact that the cop file's main hpp file is the same name as the parent directory of the cop file? That is too bad! Lets leave like it is, or is there value in what you created so far? I am fine with a 75% solution as long as the manual 25% isn't ugly. Or is it always reporting errors in that case? Then we should leave it I guess.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My current settings have no "manual" anymore, since they would pull everything into the logic I described, for example this form (assuming <> would be used):

#include <OpenSHC/Audio/MSS/SoundSystem.func.hpp>

#include "OpenSHC/Audio/MSS/SoundSystem.hpp"
#include "OpenSHC/Audio/MSS/UnkSoundFlagsAndLoopCount.hpp"
#include "OpenSHC/Audio/MSS/enums/SHC_SoundStream.hpp"

#include "OpenSHC/Globals/BOOL_WasInteracting.hpp"

#include "ucp3.h"
#include <iostream>

The alternative with relative:

#include "../SoundSystem.func.hpp"

#include "OpenSHC/Audio/MSS/SoundSystem.hpp"
#include "OpenSHC/Audio/MSS/UnkSoundFlagsAndLoopCount.hpp"
#include "OpenSHC/Audio/MSS/enums/SHC_SoundStream.hpp"

#include "OpenSHC/Globals/BOOL_WasInteracting.hpp"

#include "ucp3.h"
#include <iostream>

If no special handling for the "main" file is used, it gets sorted into the OpenSHC blob and other func.hpp might end up over them:

#include "OpenSHC/Audio/MSS/SoundSystem.func.hpp"
#include "OpenSHC/Audio/MSS/SoundSystem.hpp"
#include "OpenSHC/Audio/MSS/UnkSoundFlagsAndLoopCount.hpp"
#include "OpenSHC/Audio/MSS/enums/SHC_SoundStream.hpp"

#include "OpenSHC/Globals/BOOL_WasInteracting.hpp"

#include "ucp3.h"
#include <iostream>

I would be happy with either solution, after all, our linting only takes changed files into account, so this would have later effects.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the alternative with relative paths best!

#include "OpenSHC/string-literals.hpp"

namespace OpenSHC {
namespace Audio {
namespace MSS {

// FUNCTION: STRONGHOLDCRUSADER 0x00479DF0
void SoundSystem::playSound(int soundIndex)
{
if (!this->waveOutOpenUnk_0x8 || !this->soundActiveUnk_0x0
|| this->soundFileCurrSampleNum_0x28c[soundIndex] < 0) {
return;
}

AIL_set_named_sample_file(this->sample_0x190[this->soundFileCurrSampleNum_0x28c[soundIndex] + -1],
s__wav_005a6cc4, this->soundFileDataPointerArray_0x122c[soundIndex],
this->soundFileSizes_0x21cc[soundIndex], 0);
AIL_start_sample(this->sample_0x190[this->soundFileCurrSampleNum_0x28c[soundIndex] + -1]);
}

}
}
}
2 changes: 1 addition & 1 deletion status/addresses-SHC-3BB0A8C1.txt
Original file line number Diff line number Diff line change
Expand Up @@ -10889,7 +10889,7 @@ SHC_3BB0A8C1_0x00479C20 | 0.0% | Pending
SHC_3BB0A8C1_0x00479C80 | 0.0% | Pending
SHC_3BB0A8C1_0x00479CF0 | 100.0% | Reimplemented
SHC_3BB0A8C1_0x00479D90 | 100.0% | Reimplemented
SHC_3BB0A8C1_0x00479DF0 | 0.0% | Pending
SHC_3BB0A8C1_0x00479DF0 | 100.0% | Reimplemented
SHC_3BB0A8C1_0x00479E60 | 100.0% | Reimplemented
SHC_3BB0A8C1_0x00479F30 | 0.0% | Pending
SHC_3BB0A8C1_0x00479FC0 | 0.0% | Pending
Expand Down