Eliminate the use for (C)Pixel!

Find bytes 8C4D0 in the exe. It will apear with (C)Pixel. Delete that to ........ etc.(00000000 etc in codes), to delete the need for (C)Pixel! Now, no matter what is in place for the last few bytes of the images, it will always work.

 

Find bytes 8C4D0 in the exe. It will apear with (C)Pixel. Delete that to ........ etc.(00000000 etc in codes), to delete the need for (C)Pixel! Now, no matter what is in place for the last few bytes of the images, it will always work.

Not quite true, but not entirely false either. If you put 0x00 instead of (C)Pixel, the game will test the file for a series of 0x00s. If your image doesn't end like that, the test should fail.

Generally-speaking, most image files end in 00 00 00 00.. so it should work. But a permanent solution would be to NOP out the code which tests against this and to always make it return 1 in eax at the end of the function.

 

Not quite true, but not entirely false either. If you put 0x00 instead of (C)Pixel, the game will test the file for a series of 0x00s. If your image doesn't end like that, the test should fail.

Strange. It seems to work with anything.


This is a shot of the MyChar data, with random figures placed as the last few. It still works.

 

Actually on second thought, it'd make sense that it would work. You're giving it a null-terminated string as a comparaison, and the string has 0 lenght (since the first character is a null.) My bad - I originally thought it was a byte-by-byte comparaison, not a string operation, but some digging through the code showed otherwise.

 

Even if it were a byte-by-byte comparison, it's concievable that it would work regardless, because most higher-level file-read methods routines will return 0 on out of bounds read operations.

 

Depends. A lot of modern languages will set an error that can be retreived via GetLastError(). Which Pixel uses (though I'm not sure which contexts call it and which don't at the moment. See below though - it's a moot point in this situation.)

Modern APIs have deprecated mixing error codes with usable return values exactly for this reason: there's no telling apart an error from a bona-fide correct value. This is especially common with modern graphic APIs, like OpenGL for instance.

IIRC, CS uses fread to work with files (a relic from the C era I'm also guilty of using ) which takes a pointer to some reserved memory to fill up with read info and returns solely an error code. A simple tst eax,eax / je (exit) is all it would take to cancel the read operation and fail the method. Wether Pixel tests this or not, I can't say right now, though, so you could be right anyhow.