Jump to content
Sign in to follow this  
  • entries
  • comments
  • views


Sign in to follow this  
Evil Steve


A mini update, since I'm bored and my friend has wandered off briefly...

My BSP loading code was taking 30 seconds plus in a debug build, but loaded almost instantly in a release build. Turns out that BSP loading requires over 6000 allocations, because of my use of STL vectors without a custom allocator (Something I'll deal with later). In debug builds, it uses my memory manager, which performs a stack walk to find where the allocation came from. Unfortunately, when the allocation happened, I did a full stack walk; which involved going through each stack frame, walking up one function, getting the function name, checking if it starts with "PMemory::", "operator new" or "std::", if it doesn't then it's probably the caller. That's pretty slow, mainly because of looking up the function name.
So, the new code just walks the stack for up to 16 frames, and records the program counter (the EIP register in x86, RIP in x64). Then it does the symbol lookup, and finds the caller when it dumps any memory leaks. So that takes about 2 or 3 seconds, which is much better, and acceptable for a debug build.
Without the stack tracing code (But still using my memory manager), it loads in about half a second. The stack trace code can be turned on or off with a preprocessor define in the memory manager header, which isn't included by a lot of files, so it's easy to do.

Also, I found that non-power of 2 textures are A Bad Thing. The graphics card in my server (ATI X300) objects to them. It doesn't crash or spit out any warnings, even with the debug D3D runtimes, it just uses the top left texel over the entire texture. The reason being, it supports np2 textures, but conditionally. The D3D docs say that "conditionally" supporting np2 textures means that the textures can't repeat, so the wrap mode needs to be "clamp". In Quake BSP files, the texture coordinates pretty much equal the vertex coordinates, so you might have a square with texture coords of (15365, 47365), (15366, 47365), (15365, 47366), (15366, 47366). And that would be bad for non-wrapping textures.

I've now added a couple of functions to my engine to check for np2 and non-square texture texture support (Might as well go all the way...). I now need to stretch the original texture to a power-of-2 size if needed, and then use that. Which is a bit of a pain, but it really needs done for older cards like this. I don't want to support non-vertex shader cards, but non-non-power-of-2 textures is reasonable.

Anyway, my friend is back now...
Sign in to follow this  

1 Comment

Recommended Comments

Even cards as recent as the X1950 inexplicably don't support npow2 textures, so investing the time here is worthwhile.

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!