I expect this to be related to the long-since-fixed crash that sometimes happened when they threw Rynn
especially since the procedure in which the crash occurs appears to show signs of earlier modifications
Oh no, it gets far worse than that. VC6 would arguably have been an improvement over this mess...Hope you're not judging setup of such toolchains based on experience with ancient Visual C++ 6.0.
On the contrary - it's elegant, simple and direct. And just as well, I find all the C-variants needlessly convoluted and cryptic.Can't wrap my head around how do you find assembly an easy language. It's all convulted, cryptic
Irrelevant when writing patch code for Win32 binaries. Or anything that targets Win32 exclusively, for that matter.non-portable
Powerful for inducing feelings of rage and/or helplessness in the programmer, that's for sure.Modern high-level languages are pretty powerful
That's what macros and function calls are for...some elegant one-liners in C/C++ take a crapload of instructions in ASM etc.
Nice, software rot. Or rather in this case, source rot?C++ went through a number of revisions, making a newer compiler a hard requirement for some code to compile in the first place.
Haha, lol. Seriously?C# is also significant and a must know for those who want to be hardcore programmers in life.
Besides, I like how there's no artificial notion of a "datatype" in assembly, beyond the different operand sizes.
A number is just a number, and it can mean any number of things. (ok, I'll stop now...)
Besides, personally I find that breaking up complex one-liners into discrete operations greatly helps code readability, and assembly lends itself naturally towards just such an approach.
For example, many of my functions return 2 or 3 values, by using the ECX and/or EDX registers for that purpose, in addition to the usual EAX.
Ha! You should have seen how detecting the CPU type looked like before the CPUID opcode was a thing...Supposedly uses the queries to determine "optimal" way to measure time.
Someone with no understanding of low-level details would be equally unable to put together any working map editor in that particular case, either...Someone with understanding of low-level details doesn't necessarily have sense to make great maps.
Let me bring up an example from another field I used to work in:they happen to be the tools that work for most people these days
In my last post I provided just one example of such arbitrary "specialness": in Pascal at least, any attempt to pass a null PChar results in a valid pointer to an empty string instead, which is very very different from actually passing a NULL pointer - that's impossible with the PChar type, as far as I can tell. And believe me, I have tried.There isn't anything special regarding primitive data types in higher level languages.
Ah, but it also goes the other way.Exactly, you have to know if you'll FILD the variable or FLD it.
You know, there's something about seeing lines like the following one, that makes me cringe:Natural verbosity with today's software would translate to bigger maintenance nightmare
Code: Select all
lpData ^= (-!((PBYTE)(((PDWORD_PTR)0x487A2C) + 0x30) & 2) ^ lpData) & 1;
(in this case, it could be further optimized by moving "mov ebx,[ebx]" to before the first CMP and replacing that with "test ebx,ebx" instead; that would save a few more bytes of code size)mov esi,4835A8h ; location of the settings data in memory
mov ebx,487A2Ch ; location of struct which holds the fullscreen state flag
cmp DWORD [ebx],0
mov eax,[esi + 20h] ; graphical settings flags
or eax,1 ; select windowed mode
bt DWORD [ebx + 30h],1 ; 2nd least significant bit -> 1 = fullscreen mode, 0 = windowed mode
xor eax,1 ; select fullscreen mode
mov [esi + 20h],eax
Not nearly as bad as you would think.Millions lines of assembly code, sounds fun.
Useless overhead everywhere... Why waste time and space on temporary variables when dealing with results that usually won't be relevant more than a dozen lines after the function call is made?That's what passing parameters by reference (pointers in C) is for. Compiler can optimize the call out and inline it. Even with the function call in place, there's no need to follow standard calling conventions for such functions. In object oriented languages, you can return an instance of the object with calculation results.
Someone with no understanding of low-level details would be equally unable to put together any working map editor in that particular case, either...
Sure, they could make a nice GUI and all, but good luck actually having it work with the data.
In fact, how would you even go about making an editor without any understanding of how the underlying data works (and is stored)???
You know, there's something about seeing lines like the following one, that makes me cringe:
(in this case, it could be further optimized by moving "mov ebx,[ebx]" to before the first CMP and replacing that with "test ebx,ebx" instead; that would save a few more bytes of code size)
Not nearly as bad as you would think.
I'd say that those who complain about assembly like that have no idea about how to use it correctly... like trying to use a chainsaw without starting the engine first, you know, that kind of thing.
Assembly "works" in a very different way from the other (high-level) languages, so trying to use it in the same way is beyond foolish.
Useless overhead everywhere... Why waste time and space on temporary variables when dealing with results that usually won't be relevant more than a dozen lines after the function call is made?
Yes. I was thinking of it rather in terms of being more elegant and readable.It would fall in the domain of micro-optimizations.
What for? The WINAPI functions work perfectly fine for this purpose; no point in reinventing the wheel.You could also drop calls to KERNEL32 functions for dealing with INIs and replace it with better implementation.
Yeah.Ever read anything on quirks of CPUs that due to certain factors, a code sequence that should be faster actually executes slower?
But I think we can agree that it makes perfect sense to use a low-level language to create low-level patches?Pretty sure someone seeing your rants on HLLs would make the same argument for them.
The point is thoroughly moot anyway, what with making individual draw calls for every single polygon, and other such nonsense.Drakan devs were also fans of C++, arguing there was no good reason to go with a bit lower level C for speed or anything else, forget anything lower level!
What if I don't want a 64-bit version? Or to target any other platform than Win32?What about if you want x64 version of the program?
Yes. I was thinking of it rather in terms of being more elegant and readable.
What for? The WINAPI functions work perfectly fine for this purpose; no point in reinventing the wheel.
Also for example, the REP MOVS opcode is not always the fastest way to copy blocks of memory (as opposed to a highly optimized tight loop), due to CPU microcode considerations.
But I think we can agree that it makes perfect sense to use a low-level language to create low-level patches?
The point is thoroughly moot anyway, what with making individual draw calls for every single polygon, and other such nonsense.
That's such a performance disaster right there, that the (lack of) other optimization becomes completely irrelevant.
What if I don't want a 64-bit version? Or to target any other platform than Win32?
Yes, things are never so bad that they couldn't get even worse.Things could always be worse.
Audio devices do not appear to be needed anyway (since you can disable audio in the options)
Irrelevant starting with next CP release, since all the settings are now in a per-user INI file (in human-readable format) and not in the registry.One minor quirk here; you can't disable audio through GUI if no audio devices are found.
Then maybe it would have been smartest for the devs not to make it require a 3D-capable display device despite not using any 3D rendering calls whatsoever, except for device enum (verified)...Anyway, it's just that kind of thing that would be done if more thought was put into the server.
Users browsing this forum: No registered users and 2 guests