Fallout 2 mod FO2 Engine Tweaks (Sfall)

[Sduibek]

k.... but there's not a download option here. I have no idea how SVN works and don't have interest in installing software just to grab source code files. That sounds backwards and unnecessary. Didn't you used to host a .zip/.rar/whatever package of the source code?

EDIT: Found it, a few links in:

http://sfall.svn.sourceforge.net/viewvc/sfall/?view=tar

Gotta click Code, then Browse Subversion Repository, then the link Download GNU tarball.

 

[Timeslip]

EDIT: Found it, a few links in:

See, I told you you could find it if you look.

Although that did used to be documented on the svn info page. Doesn't seem to be mentioned any more though.

 

[Sduibek]

EDIT: Found it, a few links in:

See, I told you you could find it if you look.

Although that did used to be documented on the svn info page. Doesn't seem to be mentioned any more though.

Dunno. SourceForge is fighting a legendary battle against user friendlyness? "j/k lololol"

Anyway, now I can start working on getting the NumSoundBuffers fix implemented in Fallout 1...

 

[Hexxx]

Can anybody explain where I can get 2XSAIMMX.obj and hq2x_i386.obj required for linking when building sfall source code in Visual Studio 2010?

Or how do I build hq2x_i386.asm and 2XSAIMMX.ASM in /sfall/Filters directory? They seem to contain the keywords of assembler that differs from MASM, so VS2010 can't build them either.

 

[Timeslip]

Using nasm, yasm or another compatible assembler. You can set it up as a custom build rule in VS, but since they never change it's easier to just assemble them once yourself and leave them. (Use the win32 output type.)

You can build it without the filters too. Remove those obj's from the library list, and comment out a few lines of code in ddraw2.cpp. They don't work with the res patch or the gpublt option, so they aren't really relevant any more anyway.

Edit: What're you trying to make a custom build of it for, out of interest?

 

[Hexxx]

I'm trying to add some features. Reversed exe file, have some ideas to check.

p.s. There could be a readme.txt about that nasm trick...

update:
Nasm did the trick for 2XSAIMMX.ASM, but it writes a bunch of errors for hq2x_i386.asm:

error: binary output format does not support external references

Seems like removing the stuff is the only way to build it...

 

[Timeslip]

You haven't specified the output file format correctly. As I said, you need win32, not binary. ('-f win32' on the command line.)

If you do want to build without it, I made a commit this morning to add ifdef's around all the scale filter code, so removing them is a simple case of adding #define NO_FILTERS to the top of ddraw2.cpp, and removing the /filters directory from the project.

 

[Hexxx]

You haven't specified the output file format correctly. As I said, you need win32, not binary. ('-f win32' on the command line.)

Sorry, didn't notice that. It builds fine with -f win32

BTW, where may I post some code review notes? There is too much of assembler. It all can be written it C.
Or it's "we like the way it is" situtation?

 

[Timeslip]

BTW, where may I post some code review notes?

Here's as good as anywhere.

There is too much of assembler. It all can be written it C.
Or it's "we like the way it is" situtation?

What, the filters, or sfall as a whole? The filters aren't written by me, and I don't intend to modify them.

sfall as a whole can never be written entirely in C; (nitpick, but it's c++ rather than c.) how would you mesh it together with fallout? Fallout uses the old watcom fastcall-like calling convention, which can't be represented with VS or any other compiler, not to mention all the places where sfall hooks straight into the middle of functions. You could certainly restructure it to only ever use asm for glue code handing sfall<->fallout transitions, but in many cases the glue would be larger than just writing the feature in asm to begin with. (That's more or less how I decided what to do in asm and what to do in C. If the glue would take more lines of code than just using asm in the first place, I use asm.)

There is one exception of note; the non-gpublt version of the screen copying code in ddraw2.cpp. Yes, that can be written quite easily in c. Try it, and watch what happens to your framerate.

 

[Hexxx]

Make the assembler trampolines and wrappers to make it compatible with Watcom. Not a big deal actually. Everything else make C/C++ or whatever you call it

I prefer no to have code like this:

		mov args[0], esi; //attacker
		mov edi, [eax+0];
		mov args[4], edi;
		mov edi, [eax+4];
		mov args[8], edi;
		mov edi, [eax+8];
		mov args[12], edi;
		mov edi, [eax+12];
		mov args[16], edi;
		pushad;
		push 7
		call RunHookScript;

 

[Timeslip]

Whu? But that bit of code you quoted is just a piece of glue code.

It moves a few variables out of the registers that fallout keeps them in (well, it's a memory structure in that case, but most of the hook scripts aren't,) into a nice ordered array, and then calls into a perfectly normal stdcall c function. If you can invent a better way of writing that, I'd like to see it. (ok, so it could probably do with a few comments to say what each variable actually is, but in that particular case you can get it from hookscripts.txt.)

 

[Hexxx]

Whu? But that bit of code you quoted is just a piece of glue code.

It moves a few variables out of the registers that fallout keeps them in (well, it's a memory structure in that case, but most of the hook scripts aren't,) into a nice ordered array, and then calls into a perfectly normal stdcall c function. If you can invent a better way of writing that, I'd like to see it. (ok, so it could probably do with a few comments to say what each variable actually is, but in that particular case you can get it from hookscripts.txt.)

For FindTargetHook() It could be something like this:

static void __declspec(naked) __qsort(void *base, void * num, void * width, void *compare )
{
__asm mov eax, base
__asm mov edx, num
__asm mov ebx, width
__asm mov ecx, compare
__asm call _qsort
__asm ret
}

static void CopyArguments(void * rEsi, void * rEax)
{
args[0]=(DWORD)rEsi;
memcpy(&args[1], rEax, 0x10);
}

static void __declspec(naked) FindTargetHook()
{
void * rEax;
void * rEsi;
void * rEbx;
void * rEdx;
void * rEcx;

__asm hookbegin(5)
__asm mov rEax, eax
__asm mov rEbx, eax
__asm mov rEcx, eax
__asm mov rEdx, eax
__asm mov rEsi, esi

CopyArguments(rEsi, rEax);
RunHookScript(7);
if (cRet>= 4)
{
memcpy(rEax, rets, 0x10);
}
else
{
__qsort(rEax, rEdx, rEbx, rEcx);
}

__asm hookend
__asm ret

}

I know, it looks longer. But the main part is written in C. And there's no pain in the ass about stack, registers, the offsets, and the argument order while calling. Just save the necessary registers into stack on the function start, like the compiler does.

Code generation can be used to generate call stubs like this:

static void __declspec(naked) callWatcomFunc4args(void * func, void * arg1, void * arg2, void * arg3, void * arg4)
{
	__asm mov eax, arg1
	__asm mov edx, arg2
	__asm mov ebx, arg3
	__asm mov ecx, arg4
	__asm call func
    __asm ret
}

So that you don't have to write the function wrapper as I did for __qsort

And I'm sure that it's possible to refactor the code so that argument global arrays:

static DWORD args[8];
static DWORD oldargs[8*MAXDEPTH];
static DWORD* argPtr;
static DWORD rets[8];

won't be needed anymore.

 

[Timeslip]

For FindTargetHook() It could be something like this:

You've turned one 34 line function into 3 functions that total 40 lines, which isn't a great start for a simplification, but on top of that your version wont actually work. You're trashing fallouts registers, but you mention that, and I'll assume that the mov rxxx, eax gunk was supposed to be saving the registers and you just got bored of typing half way through. Even with all that in place, your '__asm mov rEax, eax' line will generate the assembly 'mov [ebp-8], eax', but you're in a naked function, and you never manually loaded ebp. (And that's only true for a debug build. With optimization on, it'll generate something different. If there's one rule I stick to, it's not using c code in naked functions. It's never worth trying to second guess what the compiler's going to do.) Fallout doesn't use bp based frames, so if you're lucky ebp wont contain a valid address and you'll crash. If you're not lucky, you just overwrote some random part of fallouts memory, which can be a great source of obscure hard to track bugs. By the time you fix all that up, you're going to have another dozen lines of code. That's a big overcomplication of what was originally a simple easy to read function. (ok, maybe I've been overexposed to asm a bit by now, but imo it really was a lot easier to see at first glance what the original was doing than what you've written.)

Code generation can be used to generate call stubs like this:

And if I didn't think you'd overcomplicated things already, adding a layer of automatic code generation on top would really take the biscuit.

And I'm sure that it's possible to refactor the code so that argument global arrays:
won't be needed anymore.

Sure you could. You could have a separate version of RunHookScript for each possible script, or have it take a big pile of mostly 0 extra arguments, or make it cdecl and varargs and add the extra support gunk for that. There's any number of ways of writing anything. In the absence of fallout suddenly going multithreaded, using a bit of static storage seemed like a reasonable way of handling it, but I'm sure there's others.

 

[Hexxx]

So you want me to spent my time to make both it compilable, and compatible? I won't.
My intention was to show you that it's possible to write it in C, not to rewrite it all in a second without any bug.
It may look complicated, but it will be C not asm, with a possibility to edit the code and make it understandable for more, than the person who reverses the code.

Ok. You like it your way. Let it be.

 

[Timeslip]

2.16 is up.

>Added new script functions: force_aimed_shots, disable_aimed_shots, mark_movie_played
>Added a config file to change the SPECIAL/derived stat relationships
>Added an option to limit inventory by space as well as weight
>Improved the compatibility mode check

I can't remember who wanted the limit inventory by space option, but it's been a request in the wiki since forever, so I thought I'd better take a stab at it.

You can either set a single global value in ddraw.ini or set individual values in each proto. (The 10th stat, or 'STAT_unused', in define.h. It's just the extra value that's used, rather than base+extra.) You can limit the effect to just the player, party members or everyone. You need a few extra message strings: #35 in inventory.msg to mirror #20, and #542 and 543 in proto.msg to mirror 540 and 541. You also need to shrink #20, or the line wont fit properly as soon as your inventory starts filling up. (Ideally, both 20 and 35 should be 2 letters long, which is a little cramped...)

Current issues with it are that you can't see how 'full' the inventories of party members are getting, and that there's a few ways of getting items into your own inventory that check for weight but still don't check for size.

 

[.Pixote.]

I can't remember who wanted the limit inventory by space option, but it's been a request in the wiki since forever, so I thought I'd better take a stab at it.

Does this allow the players inventory to be restricted to holding just a small "realistic" number of weapons, instead of the current warehouse approach.

 

[Timeslip]

Does this allow the players inventory to be restricted to holding just a small "realistic" number of weapons, instead of the current warehouse approach.

Yup, that was the justification given in the wiki. It means the sum of all of your item sizes have to be kept under some total, as well as the sum of their weights. I've no idea if the default item sizes in the protos are particularly realistic though, given that their main use previously was in the stealing formula. They might need looking at.

Also, something that just occured to me is that bags probably offer a simple way around the limit. The sum of the sizes of everything in a bag should be kept under the size of the bag itself, but given the bugginess of bags and that (iirc?) killap removed them all in his patch, it shouldn't be an issue.

 

[x'il]

I can't remember who wanted the limit inventory by space option, but it's been a request in the wiki since forever, so I thought I'd better take a stab at it.

I suspect it may have been Josan12, i think i remember him talking about it for a 'hardcore' mod he wanted to make... heh.

 

[.Pixote.]

I can't remember who wanted the limit inventory by space option, but it's been a request in the wiki since forever, so I thought I'd better take a stab at it.

I suspect it may have been Josan12, i think i remember him talking about it for a 'hardcore' mod he wanted to make... heh.

I think Mutants Rising will be using this new feature, restricting the amount of weapons you can carry, EG: 2 rifles only, or one big gun only, or 2 pistols and one rifle, etc. Gone are the days when you could drag 20 weapons around the desert.

@Timeslip - Is it possible to create a feature where the more you carry the less AP you have. For instance for every 50-Ibs you carry you have one less AP to use in combat, 100-Ibs 2 AP, etc.

 

[Timeslip]

@Timeslip - Is it possible to create a feature where the more you carry the less AP you have. For instance for every 50-Ibs you carry you have one less AP to use in combat, 100-Ibs 2 AP, etc.

That would be better off being scripted than being handled by sfall.

Although off the top of my head I'm not sure if there's already a script function for checking how much weight a critter is carrying? If not, I'll add one.