Messages

@Daniel3D
did you had time for testing?

first demo: https://filetransfer.io/data-package/ejyAdiV6#link

copy the files into a folder with a clean stunts 1.1 installation

the complete game-code (3d engine, sound) is running in 32/64bit (based on this very asm-looking C code that gets generated by masm2c)

only the sound/gfx hardware stuff is emulated by libdosbox (special fork of dosbox for masm2c)

If it can be freed from the memory constraints, then I think there are updates possible that are now unthinkable.

Your question makes not really sense, the current code is 16bit so the code itself constraint it to 640k, this can be only removed by porting the 16bit asm over to C, there are only micro differences between 16bit or 32bit C, but 16bit asm is totaly different to 32bit asm, because you directly doing the memory oprations in asm and C hides that

masm2c just make it able to copy over the semantic of the game code by replicating the original behavior in asm like functions but then the game code runs in 32bit

So its more or less the first step to ease porting or adding code, but only a full C port will get rid of all constraints

Does that mean we can build a version of stunts that is free from the 640k memory constraint?

no - the C code still fakes 16bit assembler behavior - so we are constraint the same way as were running under dos

but its not real 16bit code anymore - its just C code that looks like it

no ancient builds tools need, but a normal C/C++ compiler+debugger can be used, it runs nativly on windows/linux

that eases the porting alot

lets see how good the assembler-source will look

xor2003 ported restunts! that means its nearly (game/sound code 100% but still using hardware emulation for sound/input/drawing) pure asm-looking C code but running pure under Windows

https://github.com/xor2003/libdosbox/tree/masm2c/src/custom/src_restunts

there are two flavors of masm2c

1. run the game in dosbox emulation, trace the code and then creates a "port" on the fly based on this trace
pro: it will more or less work with any game thats not to evil programmed
con: NO symbols like names etc. - the resulting C code looks more or less like assembler with just number offsets

2. parse MASM assembler source code and create the "port"
pro: symbols from the asm code are preserved so variables/labels etc. got the same name as in original asm
con: the source needs to be MASM/UASM compatible - currently that is not 100% the case - im working on that

current port is a in-between of 1 and 2

i hope he releases later a demo of his work so real stunts-pros can give it a try

xor2003 is showing a small game and his Test Driver 3 Port:

https://www.youtube.com/watch?v=MzK9RVgeWGM

mas2c converts assembler or emulated code to assembler looking C code
that means the game still needs to be ported slowly - but that can be done under 64bit Windows/Linux in your prefered IDE/Editor

its runs partially on a special version of dosbox for hardware support etc. but nearly to no emulation

https://github.com/xor2003/masm2c/issues/10#issuecomment-1037026893

For example I already ported Test drive 3...

llm, could you do it for stunts?

Im a fullblown system developer, i can do nearly everything
My biggest problem that i have nearly no free time for anything except writing small forum posts
i hope xor2003 will also test his converter on stunts (he already used the asm source for testing)

https://github.com/xor2003/masm2c/issues/10#issuecomment-1037026893

For example I already ported Test drive 3...

I just hope I can help envision the basic structure.

no problem - but your text was on such a high abstract level thats its compareable to "how to bring a man on the moon"
build a rocket, put a man in it, fly to moon, finished

For the original engine I can't even imagine how to get that done.
I was thinking about the collision part of CAS his engine. (Updated that post for clarity)

I know, but a greefield projects makes it still not easy in detail
Your description of the case will still result in 2000-3000 lines of code with more or less complex math

I know it is more complicated than that.
But simplification can help get a different take on a problem.

Its way more complicated in detail

Like how to port stunts to Windows
1. Disassemble the code
2. Rewrite everything to C
3. Compile for Windows

The grill is just a texture.

but it would be better to have the grill as real polygon object, images are always bad for system transfer or quality

... if no wheels, no spheres and no grilles.

i think you will add that very fast if the pure exporting is running - its not looking that nice without - that will harm your strive in harmony

How curious. The program idea, I was imagining as a simple generator, with no graphics at all. You give it a track, it gives you a 3D file. I can do that more or less quickly if no wheels, no spheres and no grilles.

just do it!

Is it possible to build a tool that runs paralel of Stunts and shows you the track map and your position, for replays and for live racing? Also with a tool like this it would be very interesting to watch live racing

everything is possible but we are currently stuck with closed source or asm-code only - its very hard to do changes in this stage - and limited time is always a problem :/