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).
#2
07/02/2006 (6:10 pm)
Thing is, it doesn't clip if I use the stock demos and terrain_water_demo. (I didn't search on all of these issues though, slap me) :) 
#3
What is the editor draw distance set at for you? If you go to edit -> world editor settings
There's a draw distance/visibility distance field that has been blank in the last few versions of TSE. If you have a really high normal (like on your sky object) draw distance, the default editor view distance value will be much lower than the normal distance. Its kind of funny, since that field was put there originally so the editor would see farther than the normal game.
#1, 2, 3: I don't have these on any version of TSE I have and I don't have yours, so its hard to test. Many things could be the culprit for 1&2, and may be easy to fix - run debug and check the call stack.
#4: A tool that automatically did this sort of thing and managed your /data folder would make this much smoother. As-is, yeah a default material would be nice but its not too big of a deal. The most textures I've ever added at once were for particles, and right now particle textures don't need that, so its all okay :)
07/02/2006 (6:47 pm)
#5:What is the editor draw distance set at for you? If you go to edit -> world editor settings
There's a draw distance/visibility distance field that has been blank in the last few versions of TSE. If you have a really high normal (like on your sky object) draw distance, the default editor view distance value will be much lower than the normal distance. Its kind of funny, since that field was put there originally so the editor would see farther than the normal game.
#1, 2, 3: I don't have these on any version of TSE I have and I don't have yours, so its hard to test. Many things could be the culprit for 1&2, and may be easy to fix - run debug and check the call stack.
#4: A tool that automatically did this sort of thing and managed your /data folder would make this much smoother. As-is, yeah a default material would be nice but its not too big of a deal. The most textures I've ever added at once were for particles, and right now particle textures don't need that, so its all okay :)
#4
2. What is the text of the error? Or a callstack, if you can get it to happen under the debugger.
3. You must have properly defined Material blocks or you will get the invalid material (IIRC). On a low-level perspective, it happens whenever you draw without an active shader specified, in the instanced renderers.
4. Yes, it does. You can write script functions to automate it (ie, defineMaterial('foo', 'bar');). It's a bit of a pain for prototyping but, trust me, very useful on shipping products. :)
5. Mission editor forces view distance to 800m. You can change it by editing line 28 of editTSCtrl.cpp - F32 EditTSCtrl::smVisibleDistance = 800.f;
07/02/2006 (7:09 pm)
1. What is the problem? Must have error text to debug! :)2. What is the text of the error? Or a callstack, if you can get it to happen under the debugger.
3. You must have properly defined Material blocks or you will get the invalid material (IIRC). On a low-level perspective, it happens whenever you draw without an active shader specified, in the instanced renderers.
4. Yes, it does. You can write script functions to automate it (ie, defineMaterial('foo', 'bar');). It's a bit of a pain for prototyping but, trust me, very useful on shipping products. :)
5. Mission editor forces view distance to 800m. You can change it by editing line 28 of editTSCtrl.cpp - F32 EditTSCtrl::smVisibleDistance = 800.f;
#5
07/02/2006 (7:34 pm)
Just to clarify, he's talking about the GUI editor, not the world editor.
#6
When I open the gui editor with PlayGui up, all hell breaks loose :)
Well okay, all that happens is most of the GuiTSCtrl turns green, but it's still wierder than extra clipping.
07/02/2006 (7:42 pm)
Well he said either, and I know there's an issue with the world editor doing that.When I open the gui editor with PlayGui up, all hell breaks loose :)
Well okay, all that happens is most of the GuiTSCtrl turns green, but it's still wierder than extra clipping.
#7
I'll run in debug and see what happens.
07/02/2006 (7:45 pm)
And like I said above, the editor/common/creator files are all the same for both the "terrain_water_demo" and my own "fps" scripts. This is why it is quite odd. No console errors or anything out of the ordinary.I'll run in debug and see what happens.
#8
1. Encounters a problem and needs to close. Console reports nothing unusual. No message box that gives a code file where the error was.
2. States: "Out of range primitive index."
Window is:
07/02/2006 (8:18 pm)
Problem results in debug:1. Encounters a problem and needs to close. Console reports nothing unusual. No message box that gives a code file where the error was.
2. States: "Out of range primitive index."
Window is:
#9
#1, #3-5 are no big deal to me. No one's going swimming in my game, and the others are my fault.
#2, the crash, that's obviously a big problem. Check the above post for the error message when running TSE_DEBUG. And please, please help.
07/03/2006 (3:55 pm)
@Max: Actually yeah, most of the GuiTSCtrl turns a funny color like that, it's not clipping in the GUI editor, but in the World Editor it does that clipping. Also that's clipping a lot less than eight hundred meters. ;)#1, #3-5 are no big deal to me. No one's going swimming in my game, and the others are my fault.
#2, the crash, that's obviously a big problem. Check the above post for the error message when running TSE_DEBUG. And please, please help.
#10
Another thing you want to check if worldeditor is clipping to early no matter what you do is run TSE in debug and place a breakpoint in
bool EditTSCtrl::processCameraQuery(CameraQuery * query)
search it or something
the specific line of interest:
query->farPlane = getMax(smVisibleDistance, 50.f);
what is smVisibleDistance? Notice, it is getting whichever value is bigger - 50, or the distance. So if its clipping very close, its probably clipping at 50 because your smVisibleDistance is something very wrong.
07/03/2006 (9:07 pm)
Well its an out of range primitive index, so it's something in some rendering code somewhere. There's many places that could be occurring - and the problem isnt really in gfxdevice.cpp because then you shouldn't be able to render anything without crashing. Can you post the entire call stack? Or at least the top 10 levels...Another thing you want to check if worldeditor is clipping to early no matter what you do is run TSE in debug and place a breakpoint in
bool EditTSCtrl::processCameraQuery(CameraQuery * query)
search it or something
the specific line of interest:
query->farPlane = getMax(smVisibleDistance, 50.f);
what is smVisibleDistance? Notice, it is getting whichever value is bigger - 50, or the distance. So if its clipping very close, its probably clipping at 50 because your smVisibleDistance is something very wrong.
#11
07/04/2006 (7:30 am)
Where is this "callstack" of which you 1337 programmers speak? All I get in TSE_DEBUG is the error window which has what I posted above on it, and nothing about it in the console.
#12
I don't know what programs/IDE you are using for the C++ part. I think pretty much every Windows user on GG uses some version of Microsoft Visual Studio.
What are you using to work on the engine?
This is what the Visual Studio callstack looks like
07/04/2006 (9:13 am)
Its something that good debuggers show you when you break excecution either by reaching a breakpoint, hitting the break button in the IDE, or crashing the program accidently.I don't know what programs/IDE you are using for the C++ part. I think pretty much every Windows user on GG uses some version of Microsoft Visual Studio.
What are you using to work on the engine?
This is what the Visual Studio callstack looks like
#13
07/04/2006 (10:52 am)
Ah, that. Here's the callstack for the crash when I fire projectiles. (Problem #2, and the only real necessary one)
#14
1. The problem exists on a clean build. Something changed in the engine that is causing a problem that did not exist in earlier Milestones.
2. Firing in any direction while viewing the player in third person or first person will cause the crash nearly all of the time by firing at least one projectile. Sometimes it's the second projectile fired, sometimes it's the twentieth fired.
07/05/2006 (8:19 pm)
Observations: 1. The problem exists on a clean build. Something changed in the engine that is causing a problem that did not exist in earlier Milestones.
2. Firing in any direction while viewing the player in third person or first person will cause the crash nearly all of the time by firing at least one projectile. Sometimes it's the second projectile fired, sometimes it's the twentieth fired.
#15
I've got third person forced on all the time for this project.
When I spawn a projectile (which has no mesh, just particles), the game crashes at the exact same place.
Some differences: I lobotomized the projectile code so they are real simple source-to-target seekers basically and I get the crash on the first projectile every time!
07/09/2006 (4:44 pm)
Do your projectiles have particles? I just started getting this problem! They used to not crash, but I am using a different player mesh than SpaceOrc and now it happens, it might be related...I've got third person forced on all the time for this project.
When I spawn a projectile (which has no mesh, just particles), the game crashes at the exact same place.
Some differences: I lobotomized the projectile code so they are real simple source-to-target seekers basically and I get the crash on the first projectile every time!
#16
07/09/2006 (4:57 pm)
No particles on my projectiles, just meshes. I use my own custom model, not the spaceOrc. My projectile spawning code is pretty stock.. If it works on MS3, why the crash on MS 3.5 (and the slight unpredictability of the crash)?
#17
07/09/2006 (6:02 pm)
I tested using SpaceOrc and a pretty decent number of projectiles and it won't crash. So it seems there is something going wrong with the rendering of players that didn't get fixed because the test player mesh doesn't trigger it...
#18
It's hard to tell what the problem is. I've been able to fire hundreds without problems, then load up TSE again (no modifications) and within 10 projectiles, it will crash.
I posted the callstack when it crashes on the debug version, but I can't make anything of it. Not a very apt coder in C++.
07/09/2006 (6:06 pm)
It crashes using the spaceOrc model, too.It's hard to tell what the problem is. I've been able to fire hundreds without problems, then load up TSE again (no modifications) and within 10 projectiles, it will crash.
I posted the callstack when it crashes on the debug version, but I can't make anything of it. Not a very apt coder in C++.
#19
Based on the callstack, error message, and my situation, I think there is a problem with a buffer overrun or something like that when rendering a lot of translucent shapes. I think thats why my projectile with a particle emitter causes the crash - particle emitters create a lot of translucent polys. Now why it doesn't do that when one player mesh is on the screen compared to another is a good question.
07/10/2006 (11:59 am)
Is there any relationship to how many trees you are looking at and how fast it crashes?Based on the callstack, error message, and my situation, I think there is a problem with a buffer overrun or something like that when rendering a lot of translucent shapes. I think thats why my projectile with a particle emitter causes the crash - particle emitters create a lot of translucent polys. Now why it doesn't do that when one player mesh is on the screen compared to another is a good question.
#20
Are you saying that firing projectiles makes your build crash? I'm tired and couldn't make out what your problem was. If this is the case, I might be able to help you soon.
07/10/2006 (12:16 pm)
@C2:Are you saying that firing projectiles makes your build crash? I'm tired and couldn't make out what your problem was. If this is the case, I might be able to help you soon.
Torque Owner Josh Moore