View Full Version : XBCT I've got a Quake3 viewer question for ya
07-13-2000, 12:59 PM
Hi XBCT, or anyone else interested
The reason I specifically put XBCT in the title is cause I saw he's working on a Q3 viewer.
My question is how do you get all the proper textures? I've got alot of the texture reading in but I am not getting them all. Here is the process I use.
Get the shader name from the bsp file. Try to see if that is a .jpg file if it is then I got it. Other wise I go to the scripts directory and then get the approprite .shader file. After that I parse the proper shader from the file looking for .tga files. I thought that would get me all the textures I need. But it doesn't.
One example of a texture that doesn't load anything are the ramps that you can bounce off of in q3dm17.bsp.
I don't really care about getting shaders working yet, I just want the basic textures to work for now. Do you had a better/differnet way or see what I'm missing?
One last thing, though this one isn't very important right now. Some of my textures aren't mapping properly. THey get really streched out in one direction. Is there a some trick to this, i'm just mapping the textures to the tex coordinates in the .bsp file. Don't think too hard on this one though cause it's likely related to me not reading in all the textures or a stupid mistake (since I havn't looked for this problem yet.)
07-13-2000, 01:35 PM
I've also made a Q3 viewer and have had to deal with the texture naming scheme. Here is the approach I use, which appears to be the same as Quake3. First remove any extension that may be on the texture name. Then check to see if the name is the name of a shader, if so get the texture names from the shader.
If it is not a shader name (not a shader file name mind you), then look for a tga with that name, if the tga is not found, then look for a jpg with that name.
Concerning the stretched textures, that is very well possible due to a shader not being fully implemented as it may scale a shader arbitrarily. If it is happening to lots of different textures, then something appears to be corrupting your texture coordinates.
[This message has been edited by DFrey (edited 07-13-2000).]
07-13-2000, 04:16 PM
Dfrey is correct about the order of trying to load textures/shaders in Q3. Also, as Dfrey mentions, it is also possible that the shader could be specifying some sort of texturing scaling...so when you apply the texture directly without regard to what the shader specifies, you will get incorrect results ( assuming the shader even specifies a scale ). Not saying that's what's happening in your case, but it's possible.
07-14-2000, 05:42 AM
Thanks guys I'm now loading in the order you specified, but I am still not getting all the textures for some reason. Does anyone know the name of the texture of the ramp that you can bounce off of in q3dm17?
Even after running though all those posibilities some of my faces still don't get a texture (ones other than the "noshader" ones.) My problem might be something with the .shader files??? After collecting all those .tga files from the proper shader some of those .tga files don't exist?!? Why is that? Also if there is more than one .tga file in a shader is there a specific one I should get to start with? Right now I grab them all and then bind them all, but only the last .tga in a shader gets drawn to a polygon.
I'm kinda stuck here and any advice would be apricated. I just don't get why some polygons that have textures in the game don't get textures in my viewer.
ribblem:Hmm....I 100% agree with DFrey´s answer to your probs....
Dfrey:How far are you with your viewer?And do you know how Q3 exactly overbrights the lightmaps(´cause mine look a little too yellow and I need to change the gamma ramp to get the output of my viewer bright enuogh)?
I have some questions on speed:
I coded a really fast front-end which uses all forms of culling possible(View-frustum + back-face + PVS).The front end runs at about 180FPS(p2-450) in q3dm1 if I disable the back-end,which means that I don´t draw anything.I know no gfx-card can handle 180FPS but I still wonder if this is fast enough ´cause I´ll need the cpu for other purposes too(physics,AI,....).So does anybody here now how fast the rendering front-end(mainly culling) should perform in a q3-like engine?
[This message has been edited by XBCT (edited 07-14-2000).]
07-14-2000, 07:00 AM
Hello, XBCT. I've emailed you about the details of my viewer.
As to how Quake3 handles overbrighting, I'm not sure but it appears to be done by losing a bit of precision in each color channel, and jacking up the gamma ramps (See SetDeviceGammaRamp info) I don't know what Q3 does if the videocard does not support downloadble gamma ramps. The particular gamma functions (one for each primary color) that Quake 3 uses is still unknown to me, but I have figured out a way to see. I plan to crash Quake 3 and then use GetDeviceGammaRamp to see how Q3 set the gamma ramps. http://www.opengl.org/discussion_boards/ubb/biggrin.gif
Concerning your front-end speed, that looks mighty good to me. Although ultimately the videocard will play a major role in determining how much cpu time is left for your game code (on the typical PC anyway).
[This message has been edited by DFrey (edited 07-14-2000).]
07-14-2000, 08:14 AM
DFrey, I got it sort of working now, definently have to start scaling those textures though. What I had to do is take the .tga specified in a .shader file and change it to a .jpg. Why in tar-nations would someone name a file with a .tga file when it is really a .jpg in the shader???
Thanks for all you're help.
07-14-2000, 08:51 AM
Because originally Quake3 (in the form of Q3Test) did not support jpg files, only tga. So some shaders made at that time included the tga extension in the texture names. Later when jpg support was added, they replaced some tga files with jpg files, and to minimize the amount of work in doing so, Quake3 was programmed to ignore the file extension of a texture when it was given explicitly. See, even though the shader may have sometex.tga, Quake3 first looks for sometex.tga and then sometex.jpg if sometex.tga does not exist. This way, they didn't have to go back through the shader files and change the extensions of all the tga textures that were replaced with jpg textures.
It would be cool if you could crash Q3 and look if your desktop is overbrighted then which would indicate the use of setDeviceGammaRamp.I tried to do it too but if I type "/crash" into the console Q3 doesn´t crash back to desktop anymore(once I managed to do it but that was long time ago and I didn´t worry about the brightness of my desktop ´cause I didn´t already code a Q3-viewer....),it freezes my pc immideately.
07-14-2000, 11:41 AM
Yes I too get that behavior with the /crash command. But I'm thinking about making the game dll crash to the desktop, I've done it before by accident http://www.opengl.org/discussion_boards/ubb/tongue.gif . Also might it be possible to get the gamma ramps in a background process while quake 3 is running in the foreground?
Yesterday I managed to crash Q3 back to desktop again(don´t know why it worked,I tried 5 times or so and suddently it crashed back to desktop).However I noticed it does not only make the output brighter but also changes the output to be more white as usual.I cannot manage to create a similar gamma ramp by guessing so your idea to make a second thread which gets the gamma settings while Q3 is running sounds good.The only problem is that you cannot use the task-menu while Q3 is running so you cannot start your app while Q3 is running.I guess one needs to code some app which after it is started waits 1 minute or so and then takes the acual gamma ramp.You would start that app and then go for some deathmatch action.
Where did you find info on the file format for .bsp
Sorry I forgot all those urls,but if you look at the source of aftershock or titan,you´ll get lots of informations by looking at "bsp.h".Search for these two q3-viewers with altavista or something and you´ll find them....
Thanks XBCT, got the code and I am now loading up BSP's cool...
Powered by vBulletin® Version 4.2.0 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.