Mass Effect 1 has problems with BINK video

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Open uMod
2. Add MassEffect.exe to games
3. Enable "Use global hook"
4. Start Mass Effect from Steam

What is the expected output? What do you see instead?
I see uMod detect Mass Effect running, and I can load my texture pack.  That is 
all working just fine, even after enabling Large Address Aware and using a 
rather large texture pack.  The problem though is that all BINK videos are 
green.  The audio still plays, but all the video is unwatchable, including the 
intro videos and the in-game cinematic sequences.

What version of the product are you using? On what operating system?
Using uMod v1.0 r40 on Windows 7 Pro x64

Please provide any additional information below.
I have tried things like swapping out the BINK DLL file from Mass Effect 2, but 
the same symptoms occur.

Original issue reported on code.google.com by detard...@gmail.com on 26 Feb 2012 at 7:01

[GoogleCodeExporter]

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.

Original comment by detard...@gmail.com on 26 Feb 2012 at 7:10

[GoogleCodeExporter]

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.

Original comment by AdamWern...@gmail.com on 26 Feb 2012 at 8:55

[GoogleCodeExporter]

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 
:-(

Original comment by c...@koerner-de.net on 3 Mar 2012 at 8:11

[GoogleCodeExporter]

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.

Original comment by c...@koerner-de.net on 5 Aug 2012 at 11:06

• Changed state: Started

[GoogleCodeExporter]

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.

Original comment by detard...@gmail.com on 5 Aug 2012 at 1:29

[GoogleCodeExporter]

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.

Original comment by c...@koerner-de.net on 5 Aug 2012 at 6:23

[GoogleCodeExporter]

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?

Original comment by detard...@gmail.com on 5 Aug 2012 at 6:25

[GoogleCodeExporter]

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?

Original comment by c...@koerner-de.net on 5 Aug 2012 at 8:24

[GoogleCodeExporter]

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.

Original comment by coffey.n...@gmail.com on 6 Aug 2012 at 1:34

[GoogleCodeExporter]

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

Original comment by detard...@gmail.com on 6 Aug 2012 at 1:40

[GoogleCodeExporter]

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.

Original comment by c...@koerner-de.net on 20 Aug 2012 at 7:13

[GoogleCodeExporter]

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.

Original comment by detard...@gmail.com on 20 Aug 2012 at 8:51

[GoogleCodeExporter]

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.

Original comment by c...@koerner-de.net on 21 Aug 2012 at 6:30

[GoogleCodeExporter]

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.

Original comment by detard...@gmail.com on 21 Aug 2012 at 6:42

[GoogleCodeExporter]

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)

Original comment by francesc...@yahoo.com on 21 Dec 2013 at 8:42

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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 (detard105@gmail.com is my old account :) ).

Original comment by coffey.n...@gmail.com on 11 Jan 2014 at 2:23