Backyard Soccer-- Will it ever get higher than 20%?

[curlycarlos]

Hi, I recently got ScummVM and really want to play Backyard Soccer. However, the completion is at 20% and so it is unplayable. I was wondering if these games are ever revisited, or if it'll just sit this way. Thanks!

[clone2727]

The reason Backyard Soccer is not playable is because of its high use of the u32 library. That means, that each u32 function has to be reverse engineered as well. Unfortunately, each u32 library is specific to each HE game that uses one.

[curlycarlos]

...does that mean that it'll take a lot of work to get every aspect of the game to run well?

[Kirben]

Yes, the u32 library is math related functions, which requires reverse engineering of large amounts of FPU assembler code.

[sev]

If anyone is aware of open source postfix -> infix expressions converter, I'd be grateful and will add those U32 opcodes much faster.

I had to use paper and pencil to unwind stacks for all currently implemented U32s, and it takes considerable amount of time.

For the curious ones, postfix expressions which FPU uses are in this form:

2 3 + 5 *

which translates to

(2 + 3) * 5

I.e. it is stack-based.

I know number of infix -> postfix converters, particularly implemented in Forth language which uses the latter, but I am not aware about the reverse. Though, to be honest, I did not google for too long.


Eugene

[ssdsa]

If anyone is aware of open source postfix -> infix expressions converter, I'd be grateful

How complicated are those expressions that are to be converted? I could write a simple Python script to do the conversion for you, if that helps.

[sev]

Well, the FPU itself puts a limitation. Its stack is 8 numbers in depth.

You may find some manually converted expressions in engines/scumm/he/logic_he.cpp file.

For set of FPU commands see Section 1.2.3 here.

I remember this tough example which used whole stack:

Code: Select all

	var18 = (argf[5] + argf[1] + var20) * argf[4] * var10 * 2 +
		argf[6] * argf[6] * var28 + argf[4] * argf[4] -
		argf[0] * argf[0] * var10 * var10 -
		argf[5] * argf[0] * var10 * 2 -
		argf[5] * argf[1] * 2 -
		argf[1] * argf[1] - argf[5] * argf[5];

Eugene

[ssdsa]

I remember this tough example which used whole stack:

Code: Select all

	var18 = (argf[5] + argf[1] + var20) * argf[4] * var10 * 2 +
		argf[6] * argf[6] * var28 + argf[4] * argf[4] -
		argf[0] * argf[0] * var10 * var10 -
		argf[5] * argf[0] * var10 * 2 -
		argf[5] * argf[1] * 2 -
		argf[1] * argf[1] - argf[5] * argf[5];

I see, that's from LogicHEfootball::op_1023.
Could you post the corresponding FPU postfix commands that led to this infix C source?
Or, to put it this way: What is the syntax of the input you would feed into my conversion script?

It would be easy to write a script that converts something like "2 3 + 5 *" into "(2 + 3) * 5" (for any stack depth), but I've got the strong feeling that this isn't exactly what you need.

[sev]

Here goes LogicHEfootball::op_1010() code

Code: Select all

                mov     [esp+4+args1], eax
                mov     esi, [esp+4+userData]
                fild    [esp+4+args1]   ; Load Integer
                add     ecx, -46        ; Add
                mov     [esp+4+userData], ecx
                fsubr   ds:flt_10019350 ; Subtract Real Reversed
                fmul    ds:flt_10019390 ; Multiply Real
                fstp    [esp+4+args1]   ; Store Real and Pop
                fild    [esp+4+userData] ; Load Integer
                fld     [esp+4+args1]   ; Load Real
                fmul    ds:flt_1001935C ; Multiply Real
                fsubp   st(1), st       ; Subtract Real and Pop
                fld     [esp+4+args1]   ; Load Real
                fmul    ds:flt_10019368 ; Multiply Real
                fmul    ds:flt_10019364 ; Multiply Real
                fsubr   ds:flt_10019348 ; Subtract Real Reversed
                fmul    ds:flt_10019360 ; Multiply Real
                fdivp   st(1), st       ; Divide Real and Pop
                call    __ftol          ; Call Procedure
                push    eax
                push    108
                call    [esi+userData.writeVar] ; Indirect Call Near Procedure
                fld     [esp+0Ch+args1] ; Load Real
                call    __ftol          ; Call Procedure
                push    eax
                push    109
                call    [esi+userData.writeVar] ; Indirect Call Near Procedure

But make it work, I'll port it to C and extend desquirr IDA plugin with your algos, so it will be possible to automate this. IDA has all info about constants, addresses, function parameters, etc. I need just the core logic.


Eugene

[john_doe]

Could this be of any help?
http://multimedia.cx/eggs/barretts-basi ... -are-back/
I don't know much about the x87 FPU so bear with me

[ssdsa]

Could this be of any help?
http://multimedia.cx/eggs/barretts-basi ... -are-back/

Yes, I think so! I had a look at that bb86 program referenced in http://multimedia.cx/eggs/barretts-basi ... -are-back/ and it looks promising.
You can find the download link in this post http://multimedia.cx/eggs/what-re-looks ... ment-86937 by Sean Barrett. (Direct download link is: http://nothings.org/remote/bb86.zip)
bb86 parses the FPU commands quite similar to the way I intended to do (but haven't done yet). It comes as C-source. For me, if I'm going to write such a tool from scratch, the hard part of the work would be to figure out what each FPU command does exactly (does it pop or push the stack, etc.). That part is already taken care of in bb86.
sev, please have a look at bb86. Maybe it gives you enough inspiration for the core logic.

[sev]

sev, please have a look at bb86. Maybe it gives you enough inspiration for the core logic.

I'm already doing it. It's exactly the thing I need.

I've extended it a bit, as it does not process many FPU commands, but it's already looks promising.

Eventually I plan to put it inside of desquirr so it could automate the process even more.


Eugene

[curlycarlos]

I don't know if this helps, but I someone deleted one of the files that was installed from Backyard Soccer, and the game ran exactly as it did on ScummVM. Does that mean that if ScummVM accepted more than just the .he0, 2, 4, and 9 files, it would run better? Probably not, but I just wanted to say so, if it helps...