C&C95 v1.06b radar crash research

[pichorra]

[Nyerguds]

 

Right, I split the discussions Pichorra started about this bug in threads in the cncnet and maps forums and merged them together here. This bug is now resolved (thanks to Pichorra), and the solution is here:

http://forums.gamesector.net/index.php?/topic/363-cc-gold-v106b-revision-2-released/

 

[/Nyerguds]

 

[Pichorra]

fixed my own grammar errors. (4 years can give you much more grammar skills )

[/Pichorra]

OK, I was trying to complete that mission. I freed the orcas and my MCV, Destroyed the enemy CY, builded up a Chinook, put a commando inside and destroyed all Nod factories. And then:

 

1 image is the screen when it was crashed:

2 is the error menssage

[Nyerguds]

Did you save & load the game during your progress? This seems to be the same bug I've been having before... corruption of terrain elements when saving a game. Basically, one of the trees on the map has changed to a desert theater rock, which crashes the minimap when it tries to draw a small version of a file that doesn't exist in that theater.

 

I don't really know how to prevent this... heck, I don't even know if it's an original bug or if it only appears in 1.06.

 

I could fix it the "quick and dirty" way in the next patch... by adding transparent graphics files for all terrain objects in all theaters. Then you'll still have invisible objects, but it won't crash the game when you get a radar.

[pichorra]

I did but I didn't load the game. i think it is a waypoint error.

[Nyerguds]

it isn't. It's related to drawing the radar, as I said. Remember, I can look this stuff up from the error message you post

 

So, it might corrupt it without saving/loading... that's quite disturbing. That means the problem might happen at the point the ini file is read.

 

Then again, that might be a lot easier to fix.

[Lin Kuei Ominae]

I played through this mission already multiple times, also with saving and loading in between, and never had problems.

I always played in DOS TD.

[pichorra]

DOS got some differences in memory threading.

[Nyerguds]

A lot of the problems DO exist in both (like the top-of-map reconnaissance memory leak, the stealth effect problem on the right side of the lowest row of pixels on the screen), but they don't crash DOS C&C because it doesn't care about memory protection in the way Windows applications do.

But I actually suspect that this bug might be my fault somehow...

 

[edit]

 

It looks like it's indeed the bug I'm researching. It only seems to corrupt the tree called T13. A quick comparison of your screenshot and XCC Editor showed that this type of tree is indeed missing:

 

Since all of them seem to have the problem, this might mean the actual data of the basic blueprint of that tree gets corrupted... I'll have to take a closer look at it :|

[pichorra]

I found when the bug occour.

For making it easier...

Download that map and extract it in cnc directory

start the game with v1.06b patch, the mission name is "test". Launch it

there is a LOT of t13 (whose is crashing the map)

press esc and save the game.

and now, say something for me

where is the trees?

 

now, load the same map on v1.06a

load the mission test and do the same things you did on last test (save the game) The trees still here!

Conclusion: That bug only appear on v1.06b.

 

Hey! i cant upload things here anymore! uploaded on my 4shared.

http://www.4shared.com/file/125058755/d6852d59/TEST.html

 

EDIT: V1.06b is corrupting the savegames, i loaded the savegame (created by v1.06b) on v1.06a and v1.05a, it crashes when you build up a radar, but, if you load the savegames created by v1.06a and v1.05a, the game read the trees, but, when you save it agan, it stop showing the trees,

[Nyerguds]

Hm. So the corruption appears during the saving. I'll look into it. Thanks for this information.

 

[Nyerguds]

I found the problem. It's the fault of the compiler optimization in the function that actually creates the terrain blueprint objects (meaning they're corrupted from the moment you start the program). It puts a certain value into register ebx which is used as indication of which theaters can use the tree. For T13, this value happened to be "0C" originally, which is the ID number of T13. Instead of putting that 0C into the register that needed to have the unit ID (ebx), it just moves the value of edx into ebx, meaning it has a wrong ID number in it now.

 

So the original code looked like this:

(mov xxx, yyy = move value of yyy into xxx)

 

mov     ebx, 0C

mov     edx, ebx

 

The new code, with the adaption of the 'theater ownership' (to allow T13 to appear on Snow theater) looks like this:

 

mov     ebx, 1C

mov     edx, ebx

 

while it should be

 

mov     ebx, 1C

mov     edx, 0C

 

so edx has the right value.

 

It should have had "mov     edx, 0C" there in the first place, but the compiler optimizes it to take as few bytes as possible, and moving a register into it was shorter than moving the value into it -_-

[Irony]

That's strange, because I think register to register is technically slower than value to register.

 

Where

mov eax, ff

is

read instruction

move ff into eax

 

 

then

mov eax,ebx

is

read instruction

read value of ebx

move value of ebx into eax

 

 

Surely you want the compiler to optimise for speed as opposed to size?

[pichorra]

so, a v1.06b r2 will be avalable? or this fix will be only avaliable on v1.06c?

 

[Nyerguds]

That's strange, because I think register to register is technically slower than value to register.

Surely you want the compiler to optimise for speed as opposed to size?

I don't know about that. I just know what it DOES. And what it DOES is optimize for size.

Though personally I doubt that copying one register to another would be slower than reading a new 4-byte value from the code. Your example is flawed, because it doesn't have to 'read' ebx, it simply already has it. what would it "read" to, besides straight to eax?

 

Anyway, I just fixed it. When 1.06c is released, this bug is history

 

so, a v1.06b r2 will be avalable? or this fix will be only avaliable on v1.06c?

Well, if you want I can release a hotfix too...

 

[edit]

http://nyerguds.arsaneus-design.com/cnc95upd/cc95p106/cc95v106b_radarcrash_hotfix.rar

Here ya go. I don't have time to actually release a new version now, or even to announce it on the site, but you can always spread the word.

 

[edit again]

I just noticed... why the heck are we discussing this in a cncnet-related thread? This bug is single player only XD

 

[pichorra]

Tanx! the fix works!

and... Tore, move it to an apropiate local 

[Nyerguds]

I added another small fix to the hotfix, after noticing the exact same error occured in the bare terrain section (with shore type SH15). As far as I know this second error had no impact on the game, since it reads those IDs straight from the map file instead of translating a string from the INI file to an ID, but still, better to have it fixed

 

I have made a sticky topic about this in the Command & Patch forum for my patch:

http://www.commandandpatch.com/index.php?name=Forums&file=viewtopic&t=44

[Nyerguds]

Right, I split this topic because it seemed to turn up in very unrelated threads... right now, it has its own thread right here

[CCHyper]

That's strange, because I think register to register is technically slower than value to register.

 

Where

mov eax, ff

is

read instruction

move ff into eax

 

 

then

mov eax,ebx

is

read instruction

read value of ebx

move value of ebx into eax

 

 

Surely you want the compiler to optimise for speed as opposed to size?

 

But you wont even notice the difference, well, unless its graphical. Systems now days, especially with these old C&C games, just stream though the code.

[Irony]

Whether you notice the difference or not I always make sure I write the most efficient code I can (especially assembler - Or I'd just use C)

 

I can see your point about C&C not being too taxing on the CPU though

[Nyerguds]

Seriously, what's a couple of clock tick on multiple-GigaHz CPUs? Especially on assembler level that doesn't matter, since writing asm manually usually means taking the most straightforward approach where some predefined structures in higher programming languages would give more complex bytecode.

[Irony]

haha, I guess we use assembler for different things.

 

I generally use it in conjunction with C programs for bits of code that are going to get looped several million times.

 

Those extra ticks don't make much odds on their own, but when looped they can make a big difference

[Nyerguds]

well I just use it for writing new subroutines in C&C95. Usually stuff that's only executed once in a while, like in mission loading, menu load or game init

[pichorra]

well I just use it for writing new subroutines in C&C95. Usually stuff that's only executed once in a while, like in mission loading, menu load or game init

 

Why? C&C Load so fast!, no need it anymore, maybe, a 10 years before need, but, today...

[Nyerguds]

whaat? I'm talking about loading NEW stuff, like the new music and new mission options. you know, my patch 1.06.

 

The bytes in a compiled program are ALREADY asm code you know. Pure machine language.

[pichorra]

ops, i was thinking a load bar, sory 

[CCHyper]

Whether you notice the difference or not I always make sure I write the most efficient code I can (especially assembler - Or I'd just use C)

 

I can see your point about C&C not being too taxing on the CPU though

 

I tell ya, these games are as optimised much as a turtle, simple games...