Anyone else have these odd issues?
by Chris Byars · in Torque Game Engine Advanced · 07/02/2006 (10:29 am) · 41 replies
I'm having some REALLY weird behavior here in the latest TSE MS 3.5.
For reference throughout, I have a main folder here where everything is happening. If main.cs is modified so "terrain_water_demo" is the game, every problem below that I describe is nonexistant. If main.cs is modified so "fps" is the game, well, problems ensue. I did in fact copy all of the items from the "data" folder in "terrain_water_demo" over into the "data" folder in "fps" just to make sure I didn't miss anything. I brought up both folders in Codeweaver, ran multiple searches, made sure all filepaths are functional.
1. I cannot go underwater. My camera cannot get wet. Just before the camera goes underwater, just as its edges touch the depths below, TSE encounters a problem and needs to close.
2. If I fire about 5-10 projectiles so that they survive for a few seconds (ex: shoot them in the air), TSE encounters a problem and needs to close. I thought it solved itself after fixing a weapon hud issue in the source. (Fired over 120 projectiles all over the place, no problem). But then I went in again and the problem arose. Fire a few projectiles so they last for a while, crash. Solution by Brian Ramage pending.
3. I get the "NO MATERIAL" texture on the default test objects if I load the "fps" directory, or basically some of them don't even show up. Keep in mind I copied the "data" folder from the one that worked file for file over into the "fps" directory, and made sure all paths were valid. MS 3.5 Feature
4. It appears that every material now requires a materials.cs definition that says "baseTex = this" and "mapTo = this"? This is more of an inquiry than a problem. I find it annoying, though. MS 3.5 Feature
5. If I enter either the GUI editor or the World Editor, the screen is clipped peculiarly. Solution: Change visibility in world editor settings.
All of these issues are apparently script-side, as there are none of these problems in the "terrain_water_demo" game. I have absolutely no idea what I'm missing. The common, creator, editor, show, all of those directories are used by both of the games, so the problem must lie in their own directory (fps and terrain_water_demo).
For reference throughout, I have a main folder here where everything is happening. If main.cs is modified so "terrain_water_demo" is the game, every problem below that I describe is nonexistant. If main.cs is modified so "fps" is the game, well, problems ensue. I did in fact copy all of the items from the "data" folder in "terrain_water_demo" over into the "data" folder in "fps" just to make sure I didn't miss anything. I brought up both folders in Codeweaver, ran multiple searches, made sure all filepaths are functional.
1. I cannot go underwater. My camera cannot get wet. Just before the camera goes underwater, just as its edges touch the depths below, TSE encounters a problem and needs to close.
2. If I fire about 5-10 projectiles so that they survive for a few seconds (ex: shoot them in the air), TSE encounters a problem and needs to close. I thought it solved itself after fixing a weapon hud issue in the source. (Fired over 120 projectiles all over the place, no problem). But then I went in again and the problem arose. Fire a few projectiles so they last for a while, crash. Solution by Brian Ramage pending.
3. I get the "NO MATERIAL" texture on the default test objects if I load the "fps" directory, or basically some of them don't even show up. Keep in mind I copied the "data" folder from the one that worked file for file over into the "fps" directory, and made sure all paths were valid. MS 3.5 Feature
4. It appears that every material now requires a materials.cs definition that says "baseTex = this" and "mapTo = this"? This is more of an inquiry than a problem. I find it annoying, though. MS 3.5 Feature
5. If I enter either the GUI editor or the World Editor, the screen is clipped peculiarly. Solution: Change visibility in world editor settings.
All of these issues are apparently script-side, as there are none of these problems in the "terrain_water_demo" game. I have absolutely no idea what I'm missing. The common, creator, editor, show, all of those directories are used by both of the games, so the problem must lie in their own directory (fps and terrain_water_demo).
#22
Do you guys have custom muzzle flashes? Try turning them off and see if that helps.
07/10/2006 (3:36 pm)
From the stack, it's looking like some kind of problem rendering something translucent. I can't repro this issue, I've got a test mission with 5 orcs, firing projectiles from script every 2 seconds with particles, a random particle emitter, explosions with debris and smoke trails, and water reflecting it all. Not seeing it.Do you guys have custom muzzle flashes? Try turning them off and see if that helps.
#23
07/10/2006 (3:53 pm)
Muzzle flashes (meshes on the weapon) that use visibility animation, and are translucent. Like I say, it's hard to reproduce... some times it happens within 1-10 projectiles, sometimes it never happens with hundreds of projectiles. That's why I've edited my posts so much, I thought it was fixed, then next time, it causes a crash.
#24
Although, the crash remains. It's pretty random, but it happens when I fire projectiles, that's for sure. (There's also the "the view cannot go underwater without crashing" bug too, that does not exist in the demo scripts, so that's my fault somewhere)
07/10/2006 (4:21 pm)
Well Brian, it appears your translucency fix that was checked into CVS did the job. Everything translucent renders to perfection. Thanks again.Although, the crash remains. It's pretty random, but it happens when I fire projectiles, that's for sure. (There's also the "the view cannot go underwater without crashing" bug too, that does not exist in the demo scripts, so that's my fault somewhere)
#25
I mucked around looking at the state its in when it crashes, specifically in ::render and ::drawPrimitive (last 2 on the stack that are really interesting).
To recreate (warning: on my project. I havn't tested with fresh TSE3.5, I need to sleep!)
:::
add translucent = true; to the SpaceOrc material. Then add a ton of particle emitters or players, and cross your fingers (sometimes it happens instantly, sometimes not).
Some data for you to crunch on:
the primCount on all the PB's in ::render is going to be = to the number of translucent prims using that material you are rendering. However, the primCount on the mCurrentPrimBuff in ::drawPrimitive is 0 when it crashes for me. So somehow the setPrimBuffer or whatever the function is, is not quite working, or maybe the buffer is getting set right but something else is messing up the primCount or values or something.
It is really hard to observe the function because throwing a breakpoint in there is obnoxious :(
That, and I'm tired...
07/10/2006 (10:45 pm)
(I'm writing this late and I closed my debugger window, so it might be hard to follow.... but I've narrowed it down a lot)I mucked around looking at the state its in when it crashes, specifically in ::render and ::drawPrimitive (last 2 on the stack that are really interesting).
To recreate (warning: on my project. I havn't tested with fresh TSE3.5, I need to sleep!)
:::
add translucent = true; to the SpaceOrc material. Then add a ton of particle emitters or players, and cross your fingers (sometimes it happens instantly, sometimes not).
Some data for you to crunch on:
the primCount on all the PB's in ::render is going to be = to the number of translucent prims using that material you are rendering. However, the primCount on the mCurrentPrimBuff in ::drawPrimitive is 0 when it crashes for me. So somehow the setPrimBuffer or whatever the function is, is not quite working, or maybe the buffer is getting set right but something else is messing up the primCount or values or something.
It is really hard to observe the function because throwing a breakpoint in there is obnoxious :(
That, and I'm tired...
#26
And if it's NOT deterministic you've learned something about the nature of the bug.
07/10/2006 (11:38 pm)
Have you tried making a journal? If you can get it to reproduce under a journal it's much much easier to debug - as you can replay as much as you want, set breakpoints to go off the 49549th time, whatever it takes.And if it's NOT deterministic you've learned something about the nature of the bug.
#27
07/11/2006 (3:57 pm)
Ya, journals can really help you stay sane when checking a problem like this that is hard to reproduce.
#28
It's definitely not a particle issue, either, as the other weapons I used fire projectiles with extremely large amounts of projectiles, and I had quite a few on screen, as well as the muzzle emitter, water, sun flare, and all of my translucent GUI objects.
The "crash when you go underwater" issue though, baffles me. Works on "terrain_water_demo", crashes on my "fps". Something in "terrain_water_demo" does not exist in "fps" that causes a crash when going underwater.
07/11/2006 (6:08 pm)
I've found that the only time this crashes during firing one of my weapons. All the others fire fine. Not sure what in its scripts would cause a crash, though. Searching.It's definitely not a particle issue, either, as the other weapons I used fire projectiles with extremely large amounts of projectiles, and I had quite a few on screen, as well as the muzzle emitter, water, sun flare, and all of my translucent GUI objects.
The "crash when you go underwater" issue though, baffles me. Works on "terrain_water_demo", crashes on my "fps". Something in "terrain_water_demo" does not exist in "fps" that causes a crash when going underwater.
#29
07/12/2006 (12:36 pm)
Ya, journals can really help you stay sane when checking a problem like this that is hard to reproduce.
#30
Whether our issues are related or not, I will try to resolve mine using this journal feature. I never really noticed it... but it looks useful.
07/13/2006 (8:17 pm)
C2, I hijack your thread and then proceed to not read it, muwahahah. Er, sorry :)Whether our issues are related or not, I will try to resolve mine using this journal feature. I never really noticed it... but it looks useful.
#31
I still have to take a deeper look into the scripts for my one weapon. I cannot think of a thing that would crash the game. (For certain with in five or so consecutive rounds fired)
07/13/2006 (8:48 pm)
I'm not sure how to use it. :) Never heard of it. I still have to take a deeper look into the scripts for my one weapon. I cannot think of a thing that would crash the game. (For certain with in five or so consecutive rounds fired)
#32
@Max: Use -jSave to save a journal to a file, and -jDebug to play it back. Both take filenames as arguments. Extension doesn't matter. If you grep for journal you should find some comment blocks that explain in some detail.
07/13/2006 (9:16 pm)
@C2 - Strongly recommend running debug build under visual studio. You should either hit an assert or find out where it's dying pretty fast.@Max: Use -jSave to save a journal to a file, and -jDebug to play it back. Both take filenames as arguments. Extension doesn't matter. If you grep for journal you should find some comment blocks that explain in some detail.
#33
Essentially, my test setup:
- terrain_water_demo in TSE3.5
- I replaced the map with one that is just the big demo tower, 2 spaceOrcs, and 7 "busy" particle emitters
- I added translucent = true; to the spaceOrc material
It'll crash reliably.
I've fixed it though!
The fix I made is not what I'd like. I'll explain what it's doing wrong and what I did and you guys tell me what you think.
The problem is entirely in ' void RenderTranslucentMgr::render() and what essentially causes the crash involves this bit here:
The problem is that ocasionally lastPB will not actually be pointing to the correct adress at the time the comparison is made, and the buffer is never corrected because for some reason, lastPB is pointing to passRI->primBuff etc (but the GFX device mCurrentPrimitiveBuffer is not pointing to that). Right after this block, it goes ahead and does drawPrimitive. But the GFX device is using the wrong primitive buffer, one which is empty, and this causes it to throw the assert. if you keep going, it will then access a bad place in memory.
I changed that comparison to be this instead:
Of course you also need to make mCurrentPrimitiveBuffer public instead of protected to compile.
It seems rather crash proof with this in place. But this doesn't really fix the problem, it just avoids it.
Somehow, lastPB is going out of synch with what the real buffer is. Something is changing the buffer somewhere along the way and its not being taken into account.
07/14/2006 (9:59 am)
Actually reproducing the bug wasn't the hard part, I can see where journals could be useful, but in this case it wasn't necessary. It usually crashes within 1 second, though sometimes it does take a while and requires you jiggle the camera a lot.Essentially, my test setup:
- terrain_water_demo in TSE3.5
- I replaced the map with one that is just the big demo tower, 2 spaceOrcs, and 7 "busy" particle emitters
- I added translucent = true; to the spaceOrc material
It'll crash reliably.
I've fixed it though!
The fix I made is not what I'd like. I'll explain what it's doing wrong and what I did and you guys tell me what you think.
The problem is entirely in ' void RenderTranslucentMgr::render() and what essentially causes the crash involves this bit here:
if( lastPB != passRI->primBuff->getPointer() )
{
GFX->setPrimitiveBuffer( *passRI->primBuff );
lastPB = passRI->primBuff->getPointer();
}The problem is that ocasionally lastPB will not actually be pointing to the correct adress at the time the comparison is made, and the buffer is never corrected because for some reason, lastPB is pointing to passRI->primBuff etc (but the GFX device mCurrentPrimitiveBuffer is not pointing to that). Right after this block, it goes ahead and does drawPrimitive. But the GFX device is using the wrong primitive buffer, one which is empty, and this causes it to throw the assert. if you keep going, it will then access a bad place in memory.
I changed that comparison to be this instead:
GFXPrimitiveBuffer * bleh = GFX->mCurrentPrimitiveBuffer;
if( bleh != passRI->primBuff->getPointer() )
{
GFX->setPrimitiveBuffer( *passRI->primBuff );
lastPB = passRI->primBuff->getPointer();
}Of course you also need to make mCurrentPrimitiveBuffer public instead of protected to compile.
It seems rather crash proof with this in place. But this doesn't really fix the problem, it just avoids it.
Somehow, lastPB is going out of synch with what the real buffer is. Something is changing the buffer somewhere along the way and its not being taken into account.
#34
Thanks for the info Max and C2!
07/14/2006 (11:59 am)
Oh, jeez, OK, after taking a look at renderTranslucentMgr, I can see how that could easily happen. If it renders something that is just a normal translucent mesh poly, and then renders a particle, and then renders another mesh poly, the lastPB could still be pointing to the particle emitter's PB. I will fix this. Don't know if I can get to it today, but I can get to it on Monday. Thanks for the info Max and C2!
#35
07/14/2006 (2:07 pm)
That does make some sense. The muzzle emitter has both translucent muzzle images, particle emission, then spawns the projectile which is a translucent mesh, then makes an explosion of a translucent mesh and particles. Glad to hear it's on deck.
#36
07/18/2006 (6:29 am)
Just wanted to say, Matt's "fix" works for me. *joy*
#37
07/18/2006 (12:24 pm)
OK, I uploaded a new renderTranslucentMgr.cpp. Worked for my test case, let me know how it goes for you guys.
#38
07/18/2006 (3:36 pm)
Works perfectly. :)
#39
07/19/2006 (2:51 pm)
Works great Brian. Another bug bites the dust!
#40
07/20/2006 (5:57 pm)
Cool guys, thanks very much for tracking this down and testing! 
Torque Owner Chris Byars
Ion Productions
I do notice that it will crash without firing a thing (just looking so that the particles would be in view) when I'm on one of my old missions with a hefty amount of particles for a waterfall effect.
@Stefan: Yes, it seems that firing my weapon makes my build crash. (It may be linked to my translucency problem, as my muzzle animation uses translucency)