Word of advice: Don't use JPGs in your project

#1 @Amanda, nice advice -- however, I don't quite see how it is possible, as the engine should be loading the PNG/JPG using the libpng or libjpeg libraries, then converting it internally into a pixelmap in memory ... technically a jpeg/png in memory should look the same ... I find it odd that that solved your problems -- great to know as well.

#2 I saw this same problem a while back on a few machines and couldn't really explain the logistics of why it happened either. Certain jpgs and compressed pngs would display as just plain white textures on certain machines, while most pngs displayed fine. An uncompressed png would work perfectly fine on these machines, but the second they were compressed as pngs or jpgs they would disappear. Other pngs could be compressed and still work fine, but jpegs never seemed to work. There were two independant culprits that were unfortunately both client based issues.

The first was having hardware acceleration turned off on a machine that fully supported it. There's a slider in your advanced display properties that lets you control your level of hardware acceleration. Slide it up all the way and everything displayed fine and the cursor was moving nice and fast again. I don't know all the reasons why these sliders would be set to "no acceleration", but I think Windows Server 2003 turns it off by default since we saw it there the most.

The second was having another application that was demanding exclusive access to DirectX on an Intel video card (which defaults to the D3D renderer). Specifically, NetMeeting, which seems to have a habit of loading itself and demanding full D3D access on startup on a number of people's work machines. Telling this application not to load itself on startup cleared up the problem.

Both of these issues were only seen on machines with Intel video cards. Forcing OpenGL on Intel video cards also resolved the issue, but was a pretty bad idea because most of the Intel OpenGL drivers on old cards were really bad and caused a bunch more issues so we put it back. Unfortunately we also couldn't get away with using uncompressed pngs for everything, so we just stuck it all in the readme.txt.

#3 Well, I've found another mystery with the video problem. When I'm done, I'll post a readme for developers who want to get their games ready for the casual audience who have less-than-stellar computers.

The mystery... the spec for TGB requires the gamer to have 3D acceleration enabled. However (and ironically), I've found through my beta testers and my publisher's beta testers that 30% of testers (over 1000 of them) were unable to play the game due to video conflicts. For a casual game, this is suicide. So I've been playing around with graphics settings to find out what is going on...

My next finding is that if you want the game to be available for people who do not have 3D acceleration enabled or do not have 3D acceleration, Only use PNGs that have a block of transparency in them. If you try to use a PNG or JPG that has no transparency, you will get the black (or white) screen of death.

So...

1. Don't mix graphic formats. Don't mix JPGs and PNGs. Use PNGs if possible.
2. Don't mix non-transparent graphics (background images) with transparent graphics. Use PNGs with at least one pixel of transparency.
3. Don't user background images larger than 640x480. When older computers try to re-size "down", your background image won't appear.

So... Use PNGs. Make sure one pixel is transparent on each PNG. Don't use graphics larger than 640x480.


I'm not sure if the problems are simply due to mixing formats. For example, maybe if you used all PNGs with no transparency, maybe things will work out well.

:)

#4 On the product requirements for TGB, one of the requirements for games made with TGB is "OpenGL or DirectX compatible accelerated 3D video card."

It would definitely be interesting to see what you have done to get around this requirement.

#5 David, I was also having these problems with ATI video cards that had 3D acceleration turned on. There are a lot of people with ATI video cards and some of them have drivers that no longer have updates. From what I'm learning ATI has really bad openGL support.

So really, the suggestion above provides a fix for people with ATI video cards and everyone else who has 3D acceleration turned off.

My opinion... for casual games, 3D acceleration shouldn't be required. I like TGB, and I think that if it really wants to get involved in the casual game market, it needs to be tuned for people with really crappy computers.

If anything, I'll write up a document for casual game developers to show them how to get their games ready for the casual game portals. :)

#6 I know that Tribes 2 required a T&L capable card because I had to update my card back in the day. I wonder if the ATI cards that they are using are not T&L capable. I'm not sure if TGE/B/A have that requirement, and some pieces of the resource manager may be using it. Just a guess.

I agree on the casual front, though. Even though computers are relatively cheap now-days, many people who do not use them to "do" anything often don't care about upgrading them. And casual games are not something that they "do" so much as something they use to avoid "doing." Casual games need to work on nearly everything humanly possible, which is why it is cool that you have a number of testers out there. Most indies don't have that test-base!

It's almost like you have a game or two under your belt... ;)

#7 Hmm, what type of ATI do they have?
From what I know, 7500 are 3D capable, thought they might not work that good with OpenGL but TGB supports DX as well so this should not be a problem on that end. The only older ATI are Rages and they are XX years old *had one myself in my P2 300 long long ago* but even those had OpenGL support.

The DX path is as well a way to make people play the game that do not have 3D cards at all, at least if they have performant CPU (1 - 2 Ghz).

2D in 3D is something that either needs 3D or powerfull CPU, but thats the price it actually costs to have realtime scale, rotation and alpha on sprites, because thats something that is not possible in 2D without losing a large amount of performance (compared to using 3D acceleration).


Performance advice: Only use images which have sizes of power of 2 and are square. Even if the card support something different, this makes a performance difference of 50-100% even on Radeon 9000 cards!
PS: This advice as well could make the game show up at all on older cards. But you will have to make sure that the images and image frames you load meet the requirmenents for those cards.
Because we are talking of cards with 4 / 8 / 16MB VRAM here. This means that a 1024x1024 would already fill the 4MB card (together with the frame buffer which needs at least 2 * height * width * 2 byte if in 16bit) and thus lead to blank screens / application crashes if you try to load more than that. Especially in OpenGL this is an issue as OpenGL does not have any texture management that can hold currently unrendered textures in System RAM. Either it fits into VRAM or you have a problem.
Another important thing that needs to be done on no-end graphic cards is that they need to be forced to play in fullscreen.
Those cards had massive problems back then with 3D in window and trying to use that ends with black windows, white windows and crashes as well. (DX would fire a nice "3D device could not be created" error but OpenGL won't)

#8 The TGB supports DX9 through the opengl2d3d library which is inefficient and have a lot of bugs(at least have a handle leak)
In TGB no 3D lighting is use, so you don't need fully TnL support, but alpha blending is needed as well.
ATI cards have a porblems with OpenGL, but in more complex issues.
I've use ATI card in development and don't have any problem with 2D.

#9 You are right that DX is slower.
But the only other alternative for 2d only systems (ATI pre Radeon 7000 series, NVIDIA pre TNT series, S3 virge, SiS in general, intel pre Extreme *GMA 900* series) is to install mesa3d to get a better software opengl emulation that windows offers out of the box.
At least if there is still a Windows version of it. Used it back in Rage Pro days before ATI offered a beta driver with OpenGL support (that was about 8 years ago), which was needed for Quake 3 Arena :)

#10 Yeah, that cards have problems for sure. But, DX isn't only slower. Actually, there is no real DX in TGB. It's just a workaround. This is not good for a commercial games.

#11 Thats sadly right.
But beside Mesa3D OpenGL software emulation drivers its the only solution to support systems that are far below TGBs minimum requirements (3D accelerated card -> T&L capable cards -> Radeon 7500, NV TNT2, new S3 and Intel Extreme higher with a not-OpenGL broken driver. IGP and other onboards will most likely not work. They are cut down to the point where they actually are office and DVD only chips, no true 3D acceleration and thus normally no to nearly no support for OpenGL)

#12 Sorry to bring up an old topic, but we ended up fixing this JPG issue

It seems that D3D (at least Torque's implementation of it) really really hates images that don't have a transparency designated.

You can solve this in 2 ways, one involves having a transparency image for each non-transparent image, i.e. nonTransparentImage.jpg and nonTransparentImage.alpha.jpg

Short of doing that, you can actually go into the engine code (which we did) and force every image coming in to have an alpha channel, even if it doesn't normally have one.

Both solutions will require more memory on the computer that is running it, but it will allow you to use JPGs, BMPs, or other images that don't have alpha's on older computers in D3D mode.

#13 Can anyone explain to me why our graphics are displayed crappilly on OpenGL mode but properly on Direct3D?!

http://www.testudios.com/files/temp/D3DOGL.png

Is this seriously a GAME engine? I regret the moment I spent my $250 on TGB. I wish I had spent $3,000 on an engine that actually did what it promised. The time (= money) we have spent so far trying to fix things that shouldn't need fixing surpass the $3,000 by far. This is truly a non-professional solution.

If anyone can answer the above question, be my guest!

#14 I looked at the screen but didn't see any noticable difference between a not enabled filtering on the OpenGL side most likely.

#15 Marc, open it in Photoshop or a similar editor at 300% and you'll see what I mean.

#16 Is it a game screen or a 2D high quality art.

I don't check at 300% for something that is not visible at a higher resolution than what you posted, makes very little sense as the user will not see it as well and in motion its even less visible ...

So if there is anything visible that makes it inacceptable for a GAME visual (which is the only thing you are allowed to dev with Torque Technology and regular license) I would be happy if you would point that one out so I can avoid potential problems in the future.

Oh what I forgot: you did not mention on what card you tested that.
If it was an intel or SiS onboard, its no wonder that D3D ends better than OpenGL as their OpenGL supports at best is "running" but nothing more.

#17 It's from a game screen taken at 800x600, which is the game's native resolution and it's not acceptable to me, when my original graphic (and by that I mean the one in the images folder) is high quality, like the one diplayed in the D3D panel but the OpenGL rendering destroys it.

I'm using an ATI card, by the way.

#18 Are you on WindowsXP or Vista?

If you are on the later, I'm sorry to tell you but AMD so far has not found time to fix their crappy drivers to include OpenGL support.
for that reason you would be running on Microsoft OpenGL drivers which are there for "showing something at all" not for doing anything usefull

#19 I am surprised that OpenGL is mangling your image, as Torque handles D3D much worse. Only thing I can think is possibly Vista with poor OpenGL support.

#20 Windows XP, guys.