Messages

neuviemeporte's strategy is to reverse the disassembly function by function into C code that produces the same binary code as in the original executable

using the old MSC 5.1 compiler that was originaly used to compile the game (which is the exact same compiler that was used for Stunts)

this strategy is very time consuming and will take easily years to finish - what is typical for reverse projects - for example BladeRunner in ScummVM took more then a decade to finish

the reconstructed C source will be more or less exact the same as the original (except symbol-names, comments, etc.)

based on this C source everything will be possible - porting as is over to other platforms (keeping the software renderer etc.) or replacing the 3d engine with OpenGL, Vulkan, Raytracing... stuff, Resolution changes etc. just everything someone can think of

there is an discord for technical discussion: https://discord.com/channels/819897993624682516/1155564470828007434

http://anders-e.com/code/browser/restunts/trunk/restunts

i've got a recent svn backup
but i think that xor2003 and Duplodes fork are recent - there wasn't changes in the last years

I know nothing about clvn. So impossible to tell for me if he maintains a copy..

last change to the "official" svn server (seems to be down) from clvn is from ~2015

I know @dstien put stunpack online, not sure if restunts also exists somewhere.

dstien isn't the initial creator/svn maintainer of restunts - clvn is - so he never controlled the source

Brøderbund Stunts 1.0 support

nice!

anything planned for Stressed - also a move to the new github repo, ..., extensions?

I'm using Stressed 0.2.1 now, which is very cool. Though I'm not sure I'm losing a lot of functionality or not.

0.2.1 seems latest so you're not losing anything

I found the source in the Github. But then I'd have to compile it myself. I'll give that a try.

done that for you: ~6MB, stressed20230602.7z, fresh VS2019 x64 build of the stressed source code, using Qt 5.15.2

https://easyupload.io/pmo3nr

Wow, great Stuff

Do you think it could be possible to export all that information to created a Blender movie from replays?

There are a lot of them (if i read correctly)
Is it possible to redo it while maintaining the labels and comments that are made?

sadly that feature can't be reverted

but i check if there is some other option to revert it

im currently a little bit confused about the current state of some functions in the asmorig - some of the functions you've showed me are full of unused labels, messing the asm code a little
these labels do not exists if i freshly analyze the current game exe with IDA - need to find out what these labels are for

found the reason for that: IDA got a "Display assembly lines/basic block boundaries" feature for the disassembling - these strange lables get generated if that option is activated - sadly that feature can't be reverted

Cas is correct, i've forgot that detail

so your logic is correct Daniel but the CPU still needs different code

im currently a little bit confused about the current state of some functions in the asmorig - some of the functions you've showed me are full of unused labels, messing the asm code a little
these labels do not exists if i freshly analyze the current game exe with IDA - need to find out what these labels are for

The code has things that even i find strange, like in seg000:

Code Select Expand

loc_143BB:
    cmp     ax, 4D00h
    [u]jnz     short loc_143C3[/u]
    jmp     loc_144A4
loc_143C3:
    jmp     loc_14188
loc_143C6:
    cmp     [bp+var_selectedmenu], 0
    jnz     sh
I guess this could be written as:

Code Select Expand

loc_143BB:
    cmp     ax, 4D00h
    jnz     short loc_14188            ;loc_143C3
    jmp     loc_144A4
                                       ;loc_143C3:
                                       ;jmp     loc_14188
loc_143C6:
    cmp     [bp+var_selectedmenu], 0
    jnz     sh

you're right - could be written as you said

sometimes assembler is that much of code that minor details like these gets lost while
developing because it still works - seems to be assembler-code in the first place or
some strage C code with gotos in original - the C code of that 2000 lines monster would be somewhere around <200-300 lines i think

or in Kevin Pickell words:

It was my first 3d game and I made many mistakes

sorry

Code Select Expand

... For this reason the number of arguments is not appended to the name of the function by the compiler, and the assembler and the linker are therefore unable to determine if an incorrect number of arguments is used...
is that text from me? because that talks about name-mangling, that means the signature types of the function are also attached in a special way to the function name - but that does not happen for cdecl C functions - so its not relevant here

and this "problem" only happen with variadic parameters - that means functions like printf with an open parameter count - these variadic parameters
are nearly never used in normal code - so also not relevant here

Is this kind of optimization the reason that it is difficult to reverse assembly back to C? (after it is assembled, compiled, decompiled, disassembled and converted to C) I probably have the steps wrong or mixed but (again >) you know what I mean. 

thats the primary reason with todays compilers, they optimize it the code so damn hard that you even can't find the functions anymore (inlineing etc.) - old 1990 compilers lucky weren't that advanced
so at least for Stunts - every C function (that implise cdecl calling convention) is more or less directly "seeable" also the parameters etc. because there is nearly no optimization

the pure assembler based functions (written in assembler in original) like the 3d engine doesn't need to follow any calling convention and can transport function-parameters in any technical possible way - using registers, evil stack filling, etc. - this are harder to detect - because stack pushes are very easy to see, some registers sets somewhere before the call not that much - you need to read the function code to understand if a register is a parameter, for a cdecl function you just need to look for add sp,VALUE after a call and some pushes before and its absolutley clear (in the case of stunts) that it is a cdecl C function
so i thing every call ..., add sp,VALUE is a cdecl C function call in the code

Is it possible to "fix" these functions with your disassembled code. (I still have to process the rest of the code, maybe i can do that Wednesday or Friday). If both versions create a bit perfect assembly then they should be interchangeable right?

sadly not direct - the IDA Database (IDB) is not really good merge-able - doesn't cleany follow source-only principe (much more then every tool i know, but still not enough) - but i think i will be ok in the end