Mass Effect 1 has problems with BINK video about texmod HOT 18 OPEN

Just saw the issue with Duke Nukem Forever as well and I recognize that green 
screen problem as another BINK video issue.  I went ahead and used the same 
method that he used for loading uMod (copy uMod.exe to MassEffect\Binaries 
directory, copy uMod_d3d9_DI.dll to MassEffect main directory) and started up 
Mass Effect with the "Use global hook" DISABLED.  The game started exactly the 
same way as before with green intro videos.

It occurs on non-Steam version as well. I used the "Start Game Through uMod" 
option in uMOD to load my game, and I also get the green movie bug. So the 
issue seems to be universal.

Some video are displayed through textures. That means, that the content of the 
texture is changed to each frame of the video. There was a former bug in early 
versions of uMod with Resident Evil 5. Maybe I did not fix it correctly. But at 
the moment I don't have time to code at all. I still have a lot of work at home 
:-(

I found a bug in the code which might lead to green BINK videos. Can you please 
use the new version of uMod2 and check if the problem is gone.

Well it appears BINK videos work now, but it doesn't appear my textures are 
actually being replaced either at this point.  Been trying some comparisons 
with and without and things like the film grain still look original.  Going to 
keep testing for a bit longer.

I changed the hashing algorithm, thus by default tpf mods are not supported any 
more. But you can enable the tpf-support, just do a right click in the bottom 
window and set the tick mark and press afterwards update. Keep in mind, that 
only from this point the hash for tpf mods is computed thus (because the 
textures are still loaded) nothing might happen. Just restart the game and the 
tpf-support is enabled from the beginning.

Yeah I saw that it's not enabled by default, but I did go ahead and enable it 
before loading my TPF file.  Are there a set of instructions I can follow for 
converting over to the new format?

No that is not possible until some mathematics genius tells me something else ;)

The tpf hash is a CRC32 and the main problem is, that the pitch of texture is 
not taken into account. The new algorithm is a CRC64 and the pitch is taken 
into account. I could implement a kind of "generating hash conversion"-tool, 
but the "tpf-support" mode does also work and is less effort for me ;)

Of course I could enable the "tpf-support" by default, but than two hashs would 
be calculated by default. Due to the fact, that the new grouping function is 
not supported by texmod and each person who want to use it has to use uMod2 and 
thus also the CRC64 algorithm, it seem to me that disabling the CRC32 algorithm 
by default is the better choice.

BTW: Does your tpf-mods are working now?

I'm going to try some more tonight, but as I was saying before, I was already 
enabling the option you had mentioned and was not getting the texture 
replacements. The first one I was looking for is a very obvious one because 
it's the film grain effect. If it's not replaced, everything looks muddy.

Oh, heh. Gotta love when I use the wrong address to respond to an issue.  #9 
was from me, sorry for any confusion. :)

I reply also sometimes with a wrong mail address ;)

With the previous update I solved a bug in the UpdateTexture function but I 
also introduced one. This bug can lead to wrong replacement of textures or even 
to no replacements of textures.

This bug is solved in the new r52 version. I hope uMpod does now works with 
Mass Effect 1 and is able to load again mods.

Excellent, I'll give this a shot tonight if I have time.  It should be a pretty 
good test, with it being about a 450MB TPF file.

dammed 450MB o.O
uMod has a memory "problem". It hold each texture twice in memory, so that in 
your case 1GB is used (~0.5GB by uMod and another ~0.5GB by the game in 
addition). I like to change the memory handling and introduce shared memory. As 
a consequence uMod would hold each texture only once in memory and the send 
time trough the pipe would decrease extremely (that is an extra plus point). 
But this will take time, because I need a robust garbage collector.

Yeah, it's a rather large texture pack, but memory isn't necessarily a concern. 
 Performance however might be an issue.  I didn't have time last night to test 
this out, but can tonight.

Found the problem and fixed

Sometime it tries to check pDest->m_D3DTex while pDest is NULL

uMod_IDirect3DDevice9.cpp - LINE 679

Change

if (pDest->m_D3DTex!=NULL)

to

if (pDest!=NULL && pDest->m_D3DTex!=NULL)

[deleted comment]

[deleted comment]

Disregard my previous comments.  Downloaded the dev tools and HOPEFULLY I can 
figure out how to get this all recompiled.  Downloading Mass Effect right now 
as I'm typing this and I'll give you a heads up on if this all works.  If so, 
I'll mark the issue closed ([email protected] is my old account :) ).