Some elements not visible on some machines
by Cary Howe · in Torque Game Builder · 01/23/2007 (10:09 am) · 16 replies
This one may be a deal killer for me, I'm being quite litteral. We've been sending a demo level to several distributors but they are having trouble running the game. It's a problem I keep having and it may force me to drop Game Builder. The game is being built for a toy company and there's distribution in place if we can deliver a working game.
Basically on a lot of machines background layers and elements aren't visible. Everytime I think I've figured out what's causing it and how to avoid it the problem happens again. There's unfortunately no tech support and a previous post the best I got is I'm making elements too big. Unfortunately with scrolling background elements there are limits to how small you can make them. I've had the problem with elements 256X256 and 512X512 so it's not just the size. At one point I thought it was only PNGs, they have it the worst, but I've had it happen with JPGs as well.
I'm really at witts end with this one and it may be about to kill our video game endevors before they even start. Kind of stunned that we'd be having this much trouble. If all elements need to be under 256X256 that's pretty much a deal killer for me because it means the game we are building can't be made to work. I can get it to work on all our machines but as soon as we have others trying it out the problems come back. The problems vary so much between machines it's tough to nail down what the specs would be for a machine to work or what is really causing the trouble.
I really love Torque but after months of fighting with it I'm wondering if we're building an unsellable boat in the basement. If there are severe restrictions on background elements I need to know what they are. If 90% of the machines out there can't run it no distributor will touch it. I know there are lots of commercial games using it that isn't the point. The point is we are having severe trouble with background elements not being visible in the built game, ironically that's another issue, they almost always show in the test mode it's just in the built games that the problems come up. Is there a rule of thumb for background scrolling elements for sizing? I also have a lot of trouble with smaller elements that just move across the screen. If they need to be 128X128 images tiled it kind of severely limits what type of game you can do. If I can't nail down this problem really soon I'm going to have to slam on the brakes. I can understand FPS issues with display but not seeing the elements at all has me stumped. I've tried both keeping the elements square, 256X256 styled, and using the 64 convention, say 128X512 as an example but still had problems with both. The joke being a lot of the existing elements in Torque don't use either convention. Like I said it's tough to nail down what's even causing the problem because it seems to be random and on an image by image basis. I've had two nearly identical elements in the same level with one visible and the other not. The non visible one I tried reducing it several times and it was still not visible so it's not just size causing the problem. No matter how small I made the element it still wasn't visible in the built game.
On some level this has to be a bug since the games work in test mode and only develop the problems in built games. As near as I can tell it is related in some way to the video cards in part because the games generally don't work on notebooks at all and they have the worst video cards. I can get the games to run semi reliably on a 3200 with a decent video card but for a 2D scroller game that's a hefty spec and even then I've had the problems and it varies from machine to machine.
Basically on a lot of machines background layers and elements aren't visible. Everytime I think I've figured out what's causing it and how to avoid it the problem happens again. There's unfortunately no tech support and a previous post the best I got is I'm making elements too big. Unfortunately with scrolling background elements there are limits to how small you can make them. I've had the problem with elements 256X256 and 512X512 so it's not just the size. At one point I thought it was only PNGs, they have it the worst, but I've had it happen with JPGs as well.
I'm really at witts end with this one and it may be about to kill our video game endevors before they even start. Kind of stunned that we'd be having this much trouble. If all elements need to be under 256X256 that's pretty much a deal killer for me because it means the game we are building can't be made to work. I can get it to work on all our machines but as soon as we have others trying it out the problems come back. The problems vary so much between machines it's tough to nail down what the specs would be for a machine to work or what is really causing the trouble.
I really love Torque but after months of fighting with it I'm wondering if we're building an unsellable boat in the basement. If there are severe restrictions on background elements I need to know what they are. If 90% of the machines out there can't run it no distributor will touch it. I know there are lots of commercial games using it that isn't the point. The point is we are having severe trouble with background elements not being visible in the built game, ironically that's another issue, they almost always show in the test mode it's just in the built games that the problems come up. Is there a rule of thumb for background scrolling elements for sizing? I also have a lot of trouble with smaller elements that just move across the screen. If they need to be 128X128 images tiled it kind of severely limits what type of game you can do. If I can't nail down this problem really soon I'm going to have to slam on the brakes. I can understand FPS issues with display but not seeing the elements at all has me stumped. I've tried both keeping the elements square, 256X256 styled, and using the 64 convention, say 128X512 as an example but still had problems with both. The joke being a lot of the existing elements in Torque don't use either convention. Like I said it's tough to nail down what's even causing the problem because it seems to be random and on an image by image basis. I've had two nearly identical elements in the same level with one visible and the other not. The non visible one I tried reducing it several times and it was still not visible so it's not just size causing the problem. No matter how small I made the element it still wasn't visible in the built game.
On some level this has to be a bug since the games work in test mode and only develop the problems in built games. As near as I can tell it is related in some way to the video cards in part because the games generally don't work on notebooks at all and they have the worst video cards. I can get the games to run semi reliably on a 3200 with a decent video card but for a 2D scroller game that's a hefty spec and even then I've had the problems and it varies from machine to machine.
#2
My programmer working in another state has had exactly the same trouble so it's not just me.
I mentioned the notebooks because I'm assuming it's a video card issue but that doesn't explain the problem on good machines. Personally I don't care if I'm the only human on the planet having this problem because I'm having it consistently. It's very distressing that it rarely shows in test mode and generally only shows in built games.
I'm not automatically assuming it's a Torque problem, if it's happening only in built games and not in test mode it IS a Torque problem. Something is happening when the game is built to cause the issue. We've also had problems getting built games to run that ran great in test mode.
This is hardly a problem that just happened I've been fighting with it for months and I'm no closer to solving it.
01/23/2007 (10:51 am)
Well to be equally blunt I have to say I've had the problem show up on a 4800 dual core running a good video card. Don't always assume the worse.My programmer working in another state has had exactly the same trouble so it's not just me.
I mentioned the notebooks because I'm assuming it's a video card issue but that doesn't explain the problem on good machines. Personally I don't care if I'm the only human on the planet having this problem because I'm having it consistently. It's very distressing that it rarely shows in test mode and generally only shows in built games.
I'm not automatically assuming it's a Torque problem, if it's happening only in built games and not in test mode it IS a Torque problem. Something is happening when the game is built to cause the issue. We've also had problems getting built games to run that ran great in test mode.
This is hardly a problem that just happened I've been fighting with it for months and I'm no closer to solving it.
#3
01/23/2007 (11:12 am)
How do you have them layered? Do you have any other layers set to interact with the background elements (even on accident)? How big are the uncompressed images to see if it is a buffering issue?
#4
The one thing I can think of that is "works in level builder, doesn't work without level builder" type bugs is when you incorrectly base your game logic on a callback to t2dSceneWindow:: callbacks, instead of naming your game scene and handling callbacks in the namespace.
The reason for that is that the level builder creates additional scene windows, and therefore the rate at which the callback handler is called is much greater when the level builder is active than when it isn't.
This should be a relatively easy check: do you have the following function in your code with game logic in it:
01/23/2007 (11:31 am)
I honestly don't grasp the problem at all myself. Do you have the ability/flexibility to release a small demo with a reproduction case?The one thing I can think of that is "works in level builder, doesn't work without level builder" type bugs is when you incorrectly base your game logic on a callback to t2dSceneWindow:: callbacks, instead of naming your game scene and handling callbacks in the namespace.
The reason for that is that the level builder creates additional scene windows, and therefore the rate at which the callback handler is called is much greater when the level builder is active than when it isn't.
This should be a relatively easy check: do you have the following function in your code with game logic in it:
function t2dSceneWindow::onUpdateScene()
{
// game logic should NOT be here
}function myGameSceneWindow::onUpdateScene()
{
// my game logic should be in a callback handler named appropriately
}
#5
01/23/2007 (11:33 am)
I also think David's on to something, but I honestly don't know what.
#6
Plus, I've had bus issues in the past where a nice piece of hardware (like a PCI Express slot) had a very slow bus. So the card could do great work. The processor could make great use of what it did. But communication was slow between the two.
Of course, if Cary's been at it for months now, I doubt it is something as jaw-droppingly simple as that. I happened to notice my problems when scanning through my cs's looking for something else and realized I was still doing some very unnecessary things. It took me about 45 minutes to scan and clean it up. But I had to know what I was looking for in the first place.
I do a lot of stupid things, and I only wish that some of them, sometime would be helpful to other people. Instead, they're somewhat helpful to me as I realize that I should never have done in the first place and get to kick myself.
01/23/2007 (11:48 am)
A while back while playing with large backgrounds and a lot of animations, I had bus issues with the amount of data I was pushing through the pipe because I had linked a lot of things that I hadn't meant to link, which had me keeping things active longer than I intended, crudding up the pipeline. It worked fine on my dual G5 with a R9800, but went wonky with my mini because I was keeping track of things that I did not need to. Same thing happened on my Vaio UX180P and Acer Tablet PC, though the things that popped strangely depended on what I happened to be doing and loading and tracking at the time. It took me a long time to clean the pipes, and a lot of it came down to how I was tracking collisions on backgrounds when I was starting and how I ended up doing it later. My legacy bit me in the face. So I was wondering if something like that was happening here.Plus, I've had bus issues in the past where a nice piece of hardware (like a PCI Express slot) had a very slow bus. So the card could do great work. The processor could make great use of what it did. But communication was slow between the two.
Of course, if Cary's been at it for months now, I doubt it is something as jaw-droppingly simple as that. I happened to notice my problems when scanning through my cs's looking for something else and realized I was still doing some very unnecessary things. It took me about 45 minutes to scan and clean it up. But I had to know what I was looking for in the first place.
I do a lot of stupid things, and I only wish that some of them, sometime would be helpful to other people. Instead, they're somewhat helpful to me as I realize that I should never have done in the first place and get to kick myself.
#7
As to layering not sure what you mean? I usually will keep scrolling background elements between layers 25 to 30 and forground elements between 0 and 5 mostly for organizing with any other elements between the two. I generally try to keep five layers between element types just so it's easier to add in elements without conflicts.
Can't be a scripting issue since most of the elements have no scripts attached so it has nothing to do with Callbacks.
The sizes on the images vary so much it's hard to specify sizes. What are reasonable limits? Say how big would be a max for sprites and how big for static elements like backgrounds? I've definately had trouble with 256X256 and 512X512 but as I remember I've even had 128X128 images have the problem and that's pretty small for a static element. I've even had sprites that work on one level not work on another, the exact same sprite.
Like I say the problem seems to be really random when it comes up and two nearly identical images can behave very differently, one visible and one not.
01/23/2007 (11:56 am)
The elements in question in no way interact with other elements. In truth they generally don't even have collision set and aren't linked in anyway. They usually just move across the screen or are scrolling.As to layering not sure what you mean? I usually will keep scrolling background elements between layers 25 to 30 and forground elements between 0 and 5 mostly for organizing with any other elements between the two. I generally try to keep five layers between element types just so it's easier to add in elements without conflicts.
Can't be a scripting issue since most of the elements have no scripts attached so it has nothing to do with Callbacks.
The sizes on the images vary so much it's hard to specify sizes. What are reasonable limits? Say how big would be a max for sprites and how big for static elements like backgrounds? I've definately had trouble with 256X256 and 512X512 but as I remember I've even had 128X128 images have the problem and that's pretty small for a static element. I've even had sprites that work on one level not work on another, the exact same sprite.
Like I say the problem seems to be really random when it comes up and two nearly identical images can behave very differently, one visible and one not.
#8
Well, texture size in height and width can definitely be an issue, but depending on your compression level and scheme (JPG and PNG use different algorithms), the data will be packed differently. What I was looking for was the raw, uncompressed size of the images. Larger, uncompressed images will take up more of your pipe and cache, but streaming a large amount of smaller ones can also cause a problem.
I'm not sure why it wouldn't happen with both versions, though.
01/23/2007 (12:06 pm)
Sounds like you have a smarter layering scheme than I've had in the past. Mostly because of shortsightedness on my part. That's pretty close to what I use now, so that I have room to work between. One of the problems that I have with prototyping is that I do a lot of quick and dirty things that just end up being dirty later when I want to use them.Well, texture size in height and width can definitely be an issue, but depending on your compression level and scheme (JPG and PNG use different algorithms), the data will be packed differently. What I was looking for was the raw, uncompressed size of the images. Larger, uncompressed images will take up more of your pipe and cache, but streaming a large amount of smaller ones can also cause a problem.
I'm not sure why it wouldn't happen with both versions, though.
#9
You posted while I was writing.
The odd thing is I've had the trouble show up when there's a very simple level with no interaction. I did a test level that had a spinning background. I'm talking one background image and a simple fairly small sprite for the player. It worked on my system but didn't show up on the clients.
I'd be inclined to blame the systems but like I said my main machine is pretty decent. If the games will only play on very fast machines with the best bus speeds then I'm pretty much dead. I can check the specs but my main machine is a top of the line Shuttle Box. I went to them because they were easy to build and very reliable. It has an SLI set up, I just use a single card, so the bus speed should be good since it's meant to be a graphics and gaming machine.
I'd say I have too many elements but I also do have the trouble on levels with very few elements. The joke is some of my most element heavy levels work the best.
Really stumped.
01/23/2007 (12:09 pm)
(Responding to David Blake)You posted while I was writing.
The odd thing is I've had the trouble show up when there's a very simple level with no interaction. I did a test level that had a spinning background. I'm talking one background image and a simple fairly small sprite for the player. It worked on my system but didn't show up on the clients.
I'd be inclined to blame the systems but like I said my main machine is pretty decent. If the games will only play on very fast machines with the best bus speeds then I'm pretty much dead. I can check the specs but my main machine is a top of the line Shuttle Box. I went to them because they were easy to build and very reliable. It has an SLI set up, I just use a single card, so the bus speed should be good since it's meant to be a graphics and gaming machine.
I'd say I have too many elements but I also do have the trouble on levels with very few elements. The joke is some of my most element heavy levels work the best.
Really stumped.
#10
If it's a pipeline issue I'm stumped why it's so image specific? A number of times I've had an image that would be almost exactly the same as another that wouldn't render. I kept downsizing it and it would never show no matter how small. It's just bizzare. Also if it's the pipeline why would I have trouble with levels that have just two or three elements?
All I can think is there are more than one thing causing the trouble so it's tough to lock down where the issues are. I do try to change things one at a time to eliminate the varibles. I can often times by varying the size and sometimes outright rerendering the source image solve the problem but other times I can't seem to get rid of it. I've restarted the game four times now but I can't seem to get even one level working reliably on more than a couple of machines.
Just an FYI. The game is a variation on the scroller demo. We used part of the code but the majority is original. It's more just so you know how it's structured. Like I say it can't be a scripting issue since I can set up a simple level with no custom scripting, just the default scripts that are there when you start a game, and have the problems.
01/23/2007 (12:24 pm)
I was sure it was a PNG issue until I started having the trouble with JPGs. The PNGs definately are twitchier. I try to keep the elements as small as I can because it does help but it's not a 100% solution to the problem.If it's a pipeline issue I'm stumped why it's so image specific? A number of times I've had an image that would be almost exactly the same as another that wouldn't render. I kept downsizing it and it would never show no matter how small. It's just bizzare. Also if it's the pipeline why would I have trouble with levels that have just two or three elements?
All I can think is there are more than one thing causing the trouble so it's tough to lock down where the issues are. I do try to change things one at a time to eliminate the varibles. I can often times by varying the size and sometimes outright rerendering the source image solve the problem but other times I can't seem to get rid of it. I've restarted the game four times now but I can't seem to get even one level working reliably on more than a couple of machines.
Just an FYI. The game is a variation on the scroller demo. We used part of the code but the majority is original. It's more just so you know how it's structured. Like I say it can't be a scripting issue since I can set up a simple level with no custom scripting, just the default scripts that are there when you start a game, and have the problems.
#11
A different topic that I read recently just popped into my head. It was one on creating/destroying a large number of instances on each frame update. So this was causing a massive slow-down because the pipe was quite crudded up. But if there aren't enough things on the screen, and the assets are pre-cached in the level builder and testing functionality but NOT in the packaged version because the level builder scripts are not pre-caching, rather than slowing it down, it may just be causing sketchy problems.
Now I'm off in esoteric land. I should shut up and get some work done since I'm not helping.
01/23/2007 (12:34 pm)
How are you creating your PNG's and JPG's? Have you run them through an optimizer to strip out unnecessary header information that could be crudding them up?A different topic that I read recently just popped into my head. It was one on creating/destroying a large number of instances on each frame update. So this was causing a massive slow-down because the pipe was quite crudded up. But if there aren't enough things on the screen, and the assets are pre-cached in the level builder and testing functionality but NOT in the packaged version because the level builder scripts are not pre-caching, rather than slowing it down, it may just be causing sketchy problems.
Now I'm off in esoteric land. I should shut up and get some work done since I'm not helping.
#12
The suggestions have been helpful in that I do know a lot of things to look out for in the future. I guess I'll take one more stab at redoing the level and do my best to optimize the images and maybe reduce some of the gameplay. None of it is really addressing the overall problem but unless I can get a working level to the ditributors soon it's a moot point.
01/23/2007 (1:19 pm)
All the elements are prepped in Photoshop. You got my attention with "optimizer". Not to sound ignorant but I've never run across a utility for optimizing images. Sounds like an amazingly handy piece of software. With JPGs I put a lot of effort into tweaking the compression but there really isn't much you can do with PNG files. I desperately love PNGs as a format and generally I find them really stable. Game Builder was the first time I ran into trouble with them. Odd that I'm having so much trouble with them since most of the media included with Game Builder are PNGs.The suggestions have been helpful in that I do know a lot of things to look out for in the future. I guess I'll take one more stab at redoing the level and do my best to optimize the images and maybe reduce some of the gameplay. None of it is really addressing the overall problem but unless I can get a working level to the ditributors soon it's a moot point.
#13
01/23/2007 (3:58 pm)
If you have Photoshop 5.5 or more recent, may I suggest you to check your original CD media. You'll find an application with the name ImageReady, which only purpose is to optimize images (for the web) created with Photoshop... If you have Photoshop 5.0 or earlier, you'll have to check for the stand-alone version of this product. Or you could try Macromedia (now Adobe) Fireworks, which allows image optimization as well. You may even define regions of your image which may need different/selective compressions. There might be other products out there, but I use these two.
#14
Thanks
01/23/2007 (4:14 pm)
Still running off 6.0. I'll dig out the disk. I use the web prep utility all the time but that's mainly for JPGs and I think GIF, never use them myself. I'll check out Fireworks. I'd love to be able to tweak PNGs since they tend to be much larger than JPGs. I'm hooked on the transparency of PNGs.Thanks
#15
On the topic of image optimizers, I often run my png's through one of pngquant, pnggauntlet and pngcrush which do various things to compress or color-reduce pngs properly. Photoshop's built-in png capabilities have been traditionally poor (see http://user.fundy.net/morris/?photoshop27.shtml for details).
01/23/2007 (4:39 pm)
Out of curiosity Cary, do any of the stock demos (Fish demo, space shooter demo) exhibit the bad behavior? A looong time ago (1.0.2-ish back in beta) there was a problem with tile layers shrinking on certain combinations of video chipsets and video drivers. The problem was visible in one of the stock demos too. I doubt it is your problem though considering you've mentioned that it happens on more modern hardware, but I thought I'd mention it anyway.On the topic of image optimizers, I often run my png's through one of pngquant, pnggauntlet and pngcrush which do various things to compress or color-reduce pngs properly. Photoshop's built-in png capabilities have been traditionally poor (see http://user.fundy.net/morris/?photoshop27.shtml for details).
#16
I'm trying to get specs on the machines that are having problems. Maybe between optimizing the PNGs and reducing them yet again I can solve some of the problems.
Thanks for the suggestion of several PNG optimizers. I've got a good exporter for DDS and the built in JPG compressor is good but as you mentioned the PNG support is minimal in Photoshop. I was curious if CS was better? I got tired of every upgrade meant relearning the software and to be quite honest 6.0 has served me well. Probably the oldest piece of software I use daily that has yet to be upgraded. Still my favorite software Photoshop. I just wish everyone would stop moving controls and defaults. I dred upgrades because I know it'll be weeks to months until I get comfortable with the new version. Several of my animation softwares think it's cool to change the keyboard shortcuts with every version. Lightwave even reversed how a tool functioned. Drove me nuts and I never got used to it after ten years of the tool working the other way. I switched to Modo around that time and rarely touch the modeller. I use a mix of Maya and Lightwave for 3D elements. In truth for the current game my environmental elements are mostly VUE 5. Absolutely one of the most fun to use. The interface is a bit bizzare but it's fast to use and the environments are stunning.
01/23/2007 (4:55 pm)
All the stock demos seem to work but problems do arise when I start adding custom artwork.I'm trying to get specs on the machines that are having problems. Maybe between optimizing the PNGs and reducing them yet again I can solve some of the problems.
Thanks for the suggestion of several PNG optimizers. I've got a good exporter for DDS and the built in JPG compressor is good but as you mentioned the PNG support is minimal in Photoshop. I was curious if CS was better? I got tired of every upgrade meant relearning the software and to be quite honest 6.0 has served me well. Probably the oldest piece of software I use daily that has yet to be upgraded. Still my favorite software Photoshop. I just wish everyone would stop moving controls and defaults. I dred upgrades because I know it'll be weeks to months until I get comfortable with the new version. Several of my animation softwares think it's cool to change the keyboard shortcuts with every version. Lightwave even reversed how a tool functioned. Drove me nuts and I never got used to it after ten years of the tool working the other way. I switched to Modo around that time and rarely touch the modeller. I use a mix of Maya and Lightwave for 3D elements. In truth for the current game my environmental elements are mostly VUE 5. Absolutely one of the most fun to use. The interface is a bit bizzare but it's fast to use and the environments are stunning.
Torque 3D Owner Stephen Zepp
You are almost certainly trying to use an engine that required 3D hardware acceleration (listed in the required specs right up front) on cards that don't support 3D hardware acceleration.
And, if that is in fact your target market, then you are probably right--TGB isn't a tool appropriate for that market specification.