Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Little Busters Baseball doesn't work #37

Open
eglaysher opened this issue Feb 16, 2013 · 5 comments
Open

Little Busters Baseball doesn't work #37

eglaysher opened this issue Feb 16, 2013 · 5 comments
Labels

Comments

@eglaysher
Copy link
Owner

The Little Busters Baseball minigame appears to be implemented with a DLL. All the functions it provides need to be documented.

@hi117
Copy link

hi117 commented Feb 17, 2013

Is PT00.dll the dll in question?

@eglaysher
Copy link
Owner Author

Yes. PT00 controls baseball and EF00 renders those little circle/light scenes on the purple backdrop. (Jagarl reverse engineered EF00 back in the day when he was active.)

@hi117
Copy link

hi117 commented Feb 27, 2013

There appears to be a fairly important looking function named reallive_dll_func_call in there which maps its first argument (maybe a bytecode operation) to a function in the DLL. This seems correct from a forum discussion about Clannad. If this is right, then all that is needed is a mapping of input numbers to operations, correct?

@eglaysher
Copy link
Owner Author

Theoretically. It might still be a bit difficult as I'd guess there's a lot of them? Also note that figuring out if and how they modify the interpreter state may be a challenge since I don't know if RealLive still lays out its passed around interpreter state like it claims in the rldev manual.

@hi117
Copy link

hi117 commented Mar 16, 2013

Sorry for being fairly slow at doing this (and possibly responding in the wrong place), I have a couple of the bytecodes that this DLL implements done but they seem useless without many others being done. It appears that this DLL adds 9 structs/classes (its hard to tell at this point what they are, though I think it is safe to assume they are classes).
It implements the following bytecodes (passed as the first argument to reallive_dll_func_call):
10, 11, 12, 30, 31, 50, 60, 61, 70, 71, 72, 100, 102, 103, 190, 900, 901, 910, 911, 920, 921, 930, 931
Each one takes between 0 and 4 arguments and one of the classes/static arguments as follows:
0 arguments: 30, 31, 50, 70, 71, 100, 101, 102, 103, 190, 900, 901, 910, 911, 920, 921, 930, 931
1 argument: 70, 71, 72
2 arguments: 60
3 arguments: 61 (third argument is only checked for truth value)
4 arguments: 10, 11, 12
Now for static references (the names are completely arbitrary):
class_1: 910, 911
class_2: 920, 921
class_3: 930, 931
class_4: 900, 901
class_5: 190
class_6: 101, 102, 103, 70, 71, 72, 100
class_7: 30, 31
class_8: 50
class_9: 10, 11
No references: 12, 60, 61
Although I named them classes (because they're passed strangely), the only one that seems necessary to be a class so far is class_6, which contains function pointers.
Other remarks:
70 and 71 actually chose different functions to call within class_6.
60 actually has the function prototype void b_60(arg_1, arg_2, 0, 0).
All bytecodes have a void return type and subsequently, reallive_dll_func_call always returns 1 even if you give it a nonexistent bytecode.
The DLL also exports the functions reallive_dll_func_load, reallive_dll_func_free, and reallive_dll_func_init.

@eglaysher eglaysher mentioned this issue Apr 15, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants