TGE Patch: Terrain Bump Mapping

#21 ATTN: Using D3D will either crash the engine or make it really screwed up. This probably means that somewhere in the render code for D3D, there is a bad pointer somehow, probably due to an unsupported extension/operation.

That said, I don't know D3D, and I really don't want to learn it just to fix this. However, if someone with the knowhow in D3D would like to help out in fixing it, send me an email, and I'll gladly work with you.

ryan jones: I've seen that before, but only after my team had implemented the daylight cycling, which is tied into the bump mapping. If you could tell me whether or not you are using it, (and especially if you are not) that'll be one thing I'll be able to cross off my list as a possible cause. I can't think of a single problem with the render code, so I assume:
a) I missed a state change that is normally set for me, but is changed back if something happens (in this case, alt+tabbing)
b) Something is going wrong with the texture manager
c) It's a driver problem, or something not working right during the alt+tab process

I've put in functions in my build for debugging this which will turn off one layer at a time, and usually if you strip them both off, then put them back on, it'll fix it, but I have no idea why.

Also, if you're having problems with it, please say which graphics card you are using (driver version might help too), as it might help pin down what's wrong. It was developed on a PNY Verto GeForce 4 Ti4400, with the latest drivers at the time.

And for those of you having trouble with installing the patch:
Make sure you have "patch.exe" on your hard drive. Do a search for it, then check your PATH for the directory that it's in. If it's not, add it to the path. You should be able to find your path in "Environment Variables" somewhere in your system settings. It SHOULD install it fine if you get WinCvs 1.2 (NOT 1.3).

#22 chris: i have not used the day/night patch

#23 Ok, that's one thing that I can cross off my list of suspects. I'll try to look into it today. I have a feeling that when the texture gets unloaded then refreshed, it's being inverted AGAIN, which makes it go back to it's normal, un-inverted state, which is a bad thing.

UPDATE: I found the problem! Yay!

Ok, a few things:
1) It doesn't NOT crash in D3D mode, it just doesn't invert the texture for some silly reason, at least from what I see. I tested D3D in my game, and apparently it crashes on there, NOT torque head.

2) I put the inversion code in loadTexture (silly me!) instead of registerTexture (don't know how I missed that!) so when textures would be "resurrected" after alt+tabbing, they weren't inverting again. I just fixed this.

Grab THIS file, put it in torque/engine/dgl and run:
patch -p0 < bumpTexFix.patch
from that directory.

I diff'ed this from the clean CVS build, not from the origional patch I made, so it MAY not work correctly if you run the two patches sequentially. If you have problems, get the CLEAN gTexManager.cc off of GG CVS, then run the bumpTexFix.patch again, and that should work.

ANOTHER UPDATE:
Grab THIS file for an updated, nice, clean patch file to patch with over a clean HEAD. You'll still need the detail1Bump.png from the origional codefile, however.

YET ANOTHER UPDATE:
Looking through the render code again, I don't see what could possibly be wrong, except something about locking the vertex arrays. If it renders one texture fine, you'd think it would render the other one fine as well. It appears that both are rendering fine, but the second isn't adding to the first. I'm using the GL_COMBINE_EXT extension for combining the textures, which is used elsewhere in the engine, and I'm using GL_ADD to add them. This method is NOT used elsewhere in the engine, so it leads me to believe that it's a problem with the D3D wrapper.

#24 Awesome, works like a charm now.

#25 I'm having a problem applying the patch on a Mac. When I run patch, I get the following:

patching file engine/dgl/gTexManager.cc
Hunk #1 FAILED at 952.
Hunk #2 FAILED at 1025.
Hunk #3 FAILED at 1094.
Hunk #4 FAILED at 1155.
Hunk #5 FAILED at 1169.
Hunk #6 FAILED at 1189.
6 out of 6 hunks FAILED -- saving rejects to file engine/dgl/gTexManager.cc.rej

I get the same failure on all files and hunks. Any idea what's wrong?

Thanks, SteveA

#26 Make sure the files are not read only.

#27 They are not read only. In looking at the patch file, I see nothing wrong (the correct lines of code are in the right place). The only thing that I can think of is that there is a CR-LF problem. I can find no option to change CR-LF behavior (default behavior strips trailing CRs). I tried -l (ignore white space changes) with no success.

#28 It's odd that the TM patch I supplied wouldn't work against a copy of Torque with TM installed. I guess your best bet is to just fix the failed hunks.

#29 Hi I've tryied it but for me it locks the game.
Not slow, stopped.
I've a G450 32MB...maybe it's no good ?

POST-post :
it seems that it puts the bump and tham it render slowly the
texture bumped...first I see a bumped gray texture..then after
5-6 seconds I see the texture well done.

#30 I applied the patch and it worked great in openGL but bad in DirectX. The bumb map, in DirectX, applies in stages as you move around and does not look very good at all. Also drops the FPS quite a bit using DirectX. OpenGL worked and looked great with very little FPS drop. If we can get the DirectX side fixed it would adhance the engine options greatly.

Good job Chris! Great resource.

#31 Actually, this "in DirectX, applies in stages as you move around" is exactly what happens in OpenGL mode as well, except you have to be looking for it to notice it. It only applies to the terrain around you instead of the entire terrain. The problem with the D3D mode is simply render calls, and I have no idea what's screwing that up :\

#32 Well, niether OpenGL nor the DX driver work for me. Probably a bug with the ATI driver, but I'm wondering if it works on any ATI card...

#33 Tim, did you move the locking of the vertex arrays to before the bump render? If you do that, it screws up OpenGL mode, so don't. :)

If you're just using the straight bump2.patch, then you probably have a silly ATi driver bug.

EDIT: Oh, and I'm working on another update for it so that you can change the scale of the bump map. This is especially helpful for games that do not take place very close to the terrain.

#34 Haven't moved anything. It probably is a bug in ATI drivers, which is annoying.

#35 Well, in putting in this scaling, I found that I was using glTexEnvf instead of glTexEnvi for setting up texture environments, which is "impropper" and might have caused your ATi drivers to get confused. This MIGHT fix it, but I wouldn't hold out much hope. I'm creating the patch right now.

EDIT: It is now available HERE.

#36 Ok thanks Chris, I'll give it a try.

#37 correct the link :)

#38 I try it but for a lot of time it gives me only strange things on
terrain...after a while it starts to bump but it locks the fps...please help!

#39 Sorry elettrozero. I don't think you are going to get help since you are not an SDK owner. How can you have Torque if you are not an SDK owner? Hmm I wonder.

#40 Not only are you stupid enough to warez the sdk but stupid enough to come on the GG website and ask for help?

Your lame and thats sad...

Nice catch Michael!