Add chusanhook for Chunithm New - [opened]

[icex2]

In GitLab by @rakisaionji on Nov 8, 2021, 22:05

Merges chusan -> master

New Feature

Summary

Just like the title, this feature is to add support for Chunithm on ALLS platform such as Super Star and New.

Description

Originally named chunewhook from my private fork of segatools.

To maintain compatibility with custom DLLs for old Chunithm, I will keep the same chuniio and chuni-dll.

That means we can use older segatools.ini from chunihook for chusanhook with some proper modifications.

Related Issue

There were 3 failed attempts (!46 !47 !48), pathetically.

How Has This Been Tested?

Originally built with VS2019 using MSVC backend, works well on my ALLS UX workbench.

Tested with Chunithm Super Star and Super Star Plus. They should be literally the same with New.

Checklist

• Tested with the following games:
  • Chunithm New
  • Chunithm Super Star (Plus)
• Followed the developer (style) guidelines
• Updated existing doc of or add new doc to README file(s)
• Updated development documentation

[icex2]

In GitLab by @rakisaionji on Nov 8, 2021, 22:06

marked the checklist item Chunithm New as completed

[icex2]

In GitLab by @rakisaionji on Nov 8, 2021, 22:06

marked the checklist item Chunithm New as incomplete

[icex2]

In GitLab by @rakisaionji on Nov 8, 2021, 22:07

marked the checklist item Chunithm New as completed

[icex2]

In GitLab by @rakisaionji on Nov 8, 2021, 22:08

marked the checklist item Chunithm New as incomplete

[icex2]

In GitLab by @rakisaionji on Nov 8, 2021, 22:09

Some folks said @felix has Chunithm New so maybe he could test it?

[icex2]

In GitLab by @Mai on Nov 15, 2021, 09:07

I haven't been able to get your branch to work on either versions of Superstar or NEW when building from Linux with mingw-64, but the same compiled code works on nu1.1 versions of the game fine.

The process will dump out

--- Begin chusan_pre_startup ---
Pinned shader compiler, hMod=56C00000
Pinned debug helper library, hMod=6DA30000

Game processes have terminated

Event Viewers says it's an access violation, but without any knowledge of attaching a debugger to this, I'm afraid I'm out of my usefulness.
Crashes on both the amdaemon and the game executable itself. But I can say it is indeed attempting to hook into d3d9.dll.

[icex2]

In GitLab by @rakisaionji on Nov 16, 2021, 20:22

approved this merge request

[icex2]

In GitLab by @rakisaionji on Nov 16, 2021, 20:30

Well, since Chunithm Crystal (SDBT 1.41), SEGA has already started using CrackProof to protect the executables. To get them working with segatools, you have to unpack your executables. @felix is an expert in this field, he has Chunithm New unpacked and working already.

I believe this MR would not be merged in near future unless some certain "hackers" in a "virus factory" decided to "release" their unpacked stuff. However, I have a strong feeling that @felix has tested this thoroughly and trying to improve with more stuff.

Btw some people said there is something wrong with Package.mk. Well, I don't bother to fix it. I'm Windows race, I know nothing about Linux.

[icex2]

In GitLab by @Mai on Nov 17, 2021, 04:18

Commented on Package.mk line 23

When building this solution, architecture suffixes are not present on build. These would return file not found errors
(this comment has been pending for days lmao)

[icex2]

In GitLab by @Mai on Nov 17, 2021, 04:30

There's honestly no real rush, if the MR is not up to a level of standard that is appropriate to what DJH expects in their repo they are free to close or improve off of it. I can't tell you not to spit at them in the thread here but it won't earn you any respect from anyone

[icex2]

In GitLab by @rakisaionji on Nov 17, 2021, 06:07

Tbh I have no problem having DJH improving this MR. I welcome every positive commits to improve this MR. Otherwise, I don't care about useless comments and such.

If it's working for me then it should work for you, that's enough for me. If you can fix Package.mk, I am really appreciated.

[icex2]

In GitLab by @rakisaionji on Nov 17, 2021, 06:10

Commented on Package.mk line 23

I have realized it already when a patron reported the bug to me couple days ago. Any suggestion?

[icex2]

In GitLab by @rakisaionji on Nov 17, 2021, 06:13

I have no problem having DJH improving this MR and also their segatools. Just their gatekeeping scheme is getting more sketchy by giving n-0 to useless leakers rather than people who can actually do shit.

[icex2]

In GitLab by @Mai on Nov 17, 2021, 09:02

Commented on Package.mk line 23

this is a blatant hack because I looked at the meson documentation for five-ten minutes instead of, ironically, wanting to go out to the arcade.

I keep iterating over this implementation, granted how reducing work for existing methods are with a focus on x86 builds.
Like the a very simple solution would just be to add additional copy commands that rename the file to the destination.
If you want something that names the file in the build process, from my short read you have two values we can add to the shared_library() function in meson.build.

to my dismay, it's either at the start of the filename, or as the extension (forcing a period).
my first test ran this value of replacing the name_prefix with our target machine cpu family

name_prefix : target_machine.cpu_family() + '_',

and this does generate some good files, note that the x86_64 is consistant with their reference tables

but we can further extend this by using ternary operators. This allows you to keep the consistency of not having a output with an architecture label on 32 bit versions, but specifying them for the 64

name_prefix : target_machine.cpu_family() == 'x86_64' ? 'x64_' : '',

I guess I learned a lot today, but It's probably just easier with cp commands

[icex2]

In GitLab by @rakisaionji on Feb 5, 2022, 17:07

marked the checklist item Chunithm New as completed