Game Development Community

GUI Problem

by Rodney (OldRod) Burns · in Torque Game Engine · 08/25/2001 (7:11 am) · 11 replies

I'm experimenting with the GUI and I have run into a problem.

I created a new background for the opening screen (replacing v12-background.jpg).

When I run the modified GUI in windowed mode the new background shows up just fine (except for a few graphics artifacts). In full screen, however, the old original background shows up.

I've searched through the directories and can't see where this original background image is coming from. Anyone know what's going on here?

#1
08/25/2001 (7:19 am)
I have change the original background and it works fine for me.

What have you done exactly ?
#2
08/25/2001 (7:21 am)
Update: I solved the problem - when I renamed the old background image, the GUI script got changed too. Not sure how, but it happened. I changed it to the right name in the GUI editor and it works now.

However, I still have the graphic artifacts that I can't figure out.

Here's a picture:

home.kscable.com/eqbrienna/guiproblem.png
It's kind of hard to see, but in the circled areas (and other places) are patches of lighter color. These are not in the original picture, even when I zoom it up and look in fine detail. They only show up in the GUI in-game.

Anyone know what's causing that?
#3
08/25/2001 (7:28 am)
Cant see whats causing the problems in fullscreen vs windowed.. that image isnt clear enough to tell whats happening.

one thing I did see, was that the background image seems to be chosen from ALL of the images in the ui/theme dir.. so basically it loads a random background. Previously thats been the garagegames one (the only one?)

Try moving the garagegames one to another dir and see if that makes yours load?

Thats just a thought.

phil.
#4
08/25/2001 (7:30 am)
Concerning the script, I have noticed that sometimes a .cs file is not compiled even if it has changed, you must restart a second times the application to compile the file to a .dso one.

If you image is in JPEG format, it may be due to a too important JPEG compression ratio : JPEG compression shows some artifacts at the frontier between objects due to the wavelet compression.

Apart that I do not see a particular reason as I did not have this problem.
#5
08/25/2001 (7:33 am)
Some hint: You may also remove the random choice of the background theme by doing this simple things :

in client/main.cs, comment the call to determineBackgroundTheme(); and add the following line
$backgroundTheme = "~/ui/theme/my-background.jpg";
#6
08/25/2001 (7:35 am)
Ahh, thanks for the info about compression. I changed Paintshop to use the lowest compression and the problem is almost completely gone.

Is there any problem in-game with using lower compression? I would assume they would use more memory, but on the initial screen that shouldn't matter, should it?
#7
08/25/2001 (12:54 pm)
No, it wouldnt matter, the texture cache will turf it out as it loads new textures.. having said that, its a big ass file :)

One thing, try using PNG and dont use compression at all, thats pretty much the best quality your going to get.

Phil.
#8
08/25/2001 (4:03 pm)
Hmmm... I saved the graphic as a PNG and it's twice as big as my uncompressed JPG file. The artifact is still present in the PNG :(

Is there something special I need to do to the graphic in Paintshop to prevent this?
#9
08/25/2001 (4:13 pm)
when you save a image as jpeg, with high compression and reload it and save again in low compression(higher quality) you will see all smuggles done by the first save.

To do it right:

Working on a image, and save it as native format of the paitapp, (.psd in Photoshop)

and then export your stuff you want to include to the game as jpeg with low compression)
WHen you have to change something... change it in your original file(.psd for PS...) and export it again.

So you can avoid that an image gets "lost" just because you work with your source files.
#10
08/25/2001 (5:25 pm)
Lhh,

I remade my image, saving it as a layered .psp as I went along and then exported it to a JPG at the end. It seemed to work much better that way. Thanks for the tip =)
#11
08/25/2001 (5:40 pm)
np :]