Messages

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

I kinda get what you mean, but this is a few steps too advanced for me. I don't really know how memory stacking works. I have a vague impression, but that is part literal and part logical and most likely a big part wrong.. 

that stack space is located by segment: ss and register sp for offset
the stack grows down - normaly the stack is at the end of the exe, so i grows down in direction of the code the stack should never reach the code space - but could if there a bugs (aka stack-overflow)

push means put this word value on stack
pop means get it back from stack - so called LIFO principe - last-in-first-out

Code Select Expand

push 1
push 2
push 3
pop ax => 3
pop bx => 2
pop cx => 1
thats it, no further magic