Jump to content
  • Advertisement

LEET_developer

Member
  • Content Count

    28
  • Joined

  • Last visited

Community Reputation

115 Neutral

About LEET_developer

  • Rank
    Member
  1. LEET_developer

    Slow drawing textured quads with direct3D8

    gerbenvv: move the settexture call outside the inner loop, maybe you were already planning on moving it outside but your for loop says "for n vertices that have the same texture" and then on each of these iterations (the code inside the loo) you are setting texture, but you already said in the forloop they all have the same texture... no need to set it... just set it once outside, unless Im confused about what you wrong, then I appologize. and sorry associative arrays are not part of the C++ language, I was just showing you what I meant by hash tables (depends where / when you learn about them they can be called a million different things).. but you'd have to implement it yourself or use STL, which I would recommend against in a game context, better off writing your own to be faster and optimized for your uses. jollyjeffers: thanks, and I'll have to disagree with your statements :P... 1. Sure a quadtree will make rendering that much faster... if a graphics card can push 1 million triangles per second, and you are pushing one 20th of the triangles each frame, you'll get 20 more frames per second (+- with the page flipping and what not being constant across the board, but you get the picture). My point was that too often people ignore constant level optimizations in algorithms saying that "well it was n^2 and now its n, so all is good" when if n is always less than your constant work factor, your n algorithm is actually slower... a good example would be if your terrain never had more than 30 vertices (really really crappy terrain)... you wouldnt bother doing all the math involved in frustum culling, since your card can render more than 600 frames of this terrain as it is without culling. this also applied to your heiarchial culling example... if you are making a fighting game or something, or even one of those oldschool beatem ups that had at most 6 people somewhere in the room and maybe a weapon on the ground... you wouldnt bother heiarchial culling something like this, because it would actually be slower.. these are over simplified examples, usually what you want to do is design an algorithm, do case studies, best / average / worst case, and figure out how often you expect the worst case and how much slower it is than your average case, and how important it is for the best case to be as fast as possible, etc... on an application level its far too important to remember O(n) is not ALWAYS better than O(n^2) in the real world where we do not have infinite data sets. compilers do a great job at optimizing your code. but there are specific things compilers cannot do. Im pretty sure if you have a dynamic loop: for (i < 0; i < variable; i++) where variable is not garaunteed to be any specific value (maybe based on user input) the compiler has a hard time optimizing array entries inside based on that i index... as it should. I think compilers that are in use today will still generate better code if you set a temporary reference to the elements you are looking at, to avoid the dereferencing all the way through, that being said, I havent looked into that for a long time, so I could definitely be wrong :) I should have specified, by assembly I mean writing optimizations in MMX/SSE, being able to divide your data set by 4 on some operations is very useful, and there arent many compilers that take advantage of these features... you just have to make sure you have a legacy code path for people running pentium 133s and lower :P but I doubt they'll have a card that supports direct X 9 anyways. and I definately know that compilers won't turn all your divides into bit shifts or multiplications as necisary, and if you dont care about the small loss in precision, thats almost 8 cycles each you are saving :P heh
  2. LEET_developer

    Slow drawing textured quads with direct3D8

    I wont go picking at your pseudo code :) but you sorted by textures then called a set texture every iteration in the loop... Im not sure if direct X has a check to see if you've already set that texture or if it just goes and does it, in openGl I usually set a texture with a method I make that checks if the texture is the current one, its like a "free" optimization. but sorting is a good idea... another thing you could do, I dont know if you are familiar wtih data structures, but you could have a hash table of buckets. a hash table is basically an associative array. think of it like doing this quadList["texture name"] and that would return you a quad (or list of quads in my bucket example) that all have the same texture... this way you wouldnt have to sort them, you just add them to the appropriate list as they are created... with every implementation there are tradeoffs and it usually comes down to speed vs memory in the end... so you could even just allocate a big array for quads (if you want speed instead of space) and then just have the first 200 be the first text and then the next 200 the next texture, and so on... that also allows you to eliminate the sorting step, I dont know how often you add quads, but it could turn out to be an issue. I dont know what limitations direct X has on vertex buffers, but you could try to make one big enough for your max number of quads... then at least you'll only do one lock and one memcpy... but again, I'm fairly new to direct X so maybe there is a limitation that wont allow you to make them big enough.
  3. LEET_developer

    Slow drawing textured quads with direct3D8

    I just want to clear up a common problem with people using Big-O notation and "proofs". Big-O notation is used to meansure and compare "complexity" in terms of "if you have a very large number of elements, then two algorithm's with the same runtime / space complexity can converge to theoretically the same speed" this works in the classroom and on paper when doing research in computer science. But in the real world those constants that get ignored ( O ( 2198120938 x n ) ~= O ( n ) ) are very very important... for example the original poster is running some code on 150 textured quads... so n = 150 for simplicity sake... and lets say in one algorithm, it runs in O (n) time and uses 150 instructions per quad... that sounds fast, linear time, O(n), etc... but lets say you have an O (nlogn) algorithm ("slower") but only uses 10 instructions per iteration... O(n) < O(n log n)... but 150 * n(= 150) is worse than 10 * 150 * log(150)... sorry about the O(n) rant but in the work place far too often Ill show optimizations for an algorithm that greatly reduce operational constants on a known algorithm that has the "best proven runtime complexity" and people just ignore it, "the constants are insignificant"... which is usually not the case... unless you can prove that your n is going to be much larger than a couple thousand... try optimizing the algorithms for constants as well.. to gerbenvv: if you still care about optimizing code in general, every bit helps... you might want to avoid doign somethings you have there... every time you have a "this->vertices[i + some number].some variable = x;" the compiler is generating alot of instructions for you that you dont need... try setting a temporary variable = to a reference of the vertex in question. Vertex &tempVert = vertices[i + 3]; for example... now not only are you doing i + 3 only once instead of 8 times, you are also not dereferencing the array pointer that many times... sometimes the compiler can optimize this out, but in your case its based on a for loop index, which it will probably expect there is a reason you are dereferencing that many times. if you are only doing it once or twice, an extra 40 instructions per rendering loop means nothing to computers of today... but you are doing it 40 times per loop iteration, that really adds up... especially if you want to have time to do game logic, input, sound... etc.. or port it to GBA where the processor has many less cycles available per second. the second thing is using the D3DCOLOR_XRGB() macro to set all your colours to white... doesnt look like those change, so you could either do a COLORREF whiteColour = D3DCOLOR_XRGB(255, 255, 255); and then just use that variable... this isnt a big deal, but the macro in question does a few bit shifts and will use some scratch registers to do it, Im all about optimizing out as many instructions as you can... bit shifts are usually fast on all machines, but you never know... Sorry that these are all terribly small things, just keep them in mind if you apply to game development studios doing work on non pc hardware... they are often fighting for clock cycles, especially when the AI guys keep thinking they should be writing physics code in their AI code ;) damn AI.... and I agree with jollyjeffers on the locking issue... stalling the graphics pipeline is always bad, you want to hold that lock for as short a time as possible, and dont worry memcpy is fast... and if not, write an MMX / SSE version to be faster :P btw I love your commenting style, I always draw little ascii pictures in methods, its fun :)
  4. LEET_developer

    Salary Quality of life

    The most important point to note is WHERE you want to work. Usually the larger the company is, the more likely they are to hire amateur "new game developers" (not mean't as an insult, but just kind find a way to say lack of experience). Large companies can throw more money at hiring MANY new people and working them all like dogs. for example, say I own a game dev company with 120 developers, I can hire 10 new people for HALF the average salary, work them like dogs and 8 will quit. so now I have two die hard programmers with a small salary willing to do extreme overtime so I can make more money. that's something you don't want. But a lot of smaller development studios cant afford to hire 10 people and have 8 quit, BIG security risk and all that (think about having 10 devs, hiring 10 more and 8 quitting, its almost half your devs, so these new people would have LOTS of important things to work on). So these smaller places will look harder for the best of the best (they tend to disregard people with 0 game dev experience professionally). And if one of these places hire you, you will get a competitive salary, because they KNOW you will help and be valuable, instead of taking you for a cheap trial run to hook you in. but on the other hand, I think on average enterprise developers get 10% more than game developers and don't do over time (not knocking enterprise dev, its a completely different type of developement that relies more on something being designed properly and easily supported as opposed to designed for speed and hopefully doesn't crash). so enterprise developement leads to less overtime because you can follow your design docs and not have to worry as much about "oh we designed it that way, but it turned out to be too slow, so now we are hacking in this change." hope that was of some help...
  5. LEET_developer

    appending to string?

    Call me old fashioned but I would write a String class with overloaded operators for += that take other strings and floats/ints/chars for appending. then internally your string class uses good old char array[MaxStringSize] as its string and c-style string functions (sprintf, strcat, strcpy, etc). This gives you complete control over how your all your operations are done. I've found trying to append numbers and whatnot to the end of std::strings kind of "hacky" using string streams. You can also make your string class use char *, and dynamically allocate and grow your string, this will make it so you aren't limited in size (I have a string class for both types).
  6. LEET_developer

    Need to improve particle systems

    Quote:Original post by RAZORUNREAL LEET_developer, it's not that it's faster to rotate on the cpu, although if you simplify it somehow for this special case it might be pretty quick. It's just that sending all the particles as a single batch is crucial to good performance. If you can rotate them with a shader then that's probably best, but I wouldn't know how. Yeah sending all the particles at once is the tough part, because then you will need not only a vertex buffer for all the particles, but also a colour array for the colours of the particles (if they change colour, as they would in fire) and most likely a texture coordinate array too (if you have a couple variations of particle textures). Having all those arrays with alot of emitters could really end up with a large memory footprint. what if you generate two screen space vectors for up and right, and then copy them 3 or 4 times and rotate them (so there are 4 different orientations which the particles can follow)... so they will rotate in groups, but hopefully be randomly assigned enough that you wouldn't notice? for example, every time a particle is spawned just pick one of the 4 groups and then have it rotate by that group (which could be one full rotation clockwise every 2 seconds) and then the next could go into another group (one rotation ever second)... and then the third could be back in the first group... would this work? that would greatly reduce the number of rotations needed, and then you could just go and draw all the particles at once using a lookup into this array of up and right vectors.
  7. LEET_developer

    Need to improve particle systems

    I was affraid you would suggest rotating yourself, that might even be slower than on the card, because at least the gpu is parallel processing them... I should do some benchmarking on rotating with SSE and rotating on the GPU and using more particles instead of rotation and see which ones are faster if I ever get around to this I'll post the results, although it might be quite a while :)
  8. LEET_developer

    drawing lines over polygons

    Quote:Original post by Kuladus You can use something like glPolygonOffset (I forget the name) to add a small amount to the depth value of each fragment. This will give you the results you are after. glPolygonMode(GL_FILL); //render surface glPolygonMode(GL_EDGE); glPolygonOffset(epsilon); //render surface Can't recall the function names, and don't have my reference handy, sorry. How exactly does polygon offset work... would you be able to see the lines from either side of the polygons? I noticed that it takes a single float parameter, so how does it use the parameter? I want to use this method for decaling, but I'd like to understand how it works. Edit: also, do you have to undo the polygonoffset? or does switching the fill mode change it back to 0? [Edited by - LEET_developer on July 21, 2005 6:03:10 PM]
  9. LEET_developer

    Need to improve particle systems

    Quote:Original post by Delfi why not use fewer particles, but make them rotate to simulate multi-particle-movement and grow with time? How would you do this rotating? You dont want to call one glRotate per particle, do you compute rotated vertices and then draw tri strips using those? I'm just curious what would be faster. cause if you do a glRotate per particle, you would probably start to see slow down quickly while the number of emitters increases. I did a particle engine once using vertex arrays and glDraw elements, problem with this was you couldn't do too many per particle effects without having a bunch of different synched arrays which were taking up too much memory.
  10. LEET_developer

    Pentium M cpu and High performance timer

    It says to use timeBeginPeriod and endPeriod immediately before and after you use it... but then it says that timeBeginPeriod is on a per application / driver instance. So then it would have no adverse effects calling beginPeriod and end period at the beginning and end of your program?
  11. LEET_developer

    Pentium M cpu and High performance timer

    Quote:Original post by Extrarius Quote:Original post by LEET_developer [...]I don't see how anything can be done accurately with a timer that updates every 20th of a second...[...]I agree that such a timer would be difficult to use. It is a great thing, then, that we have access to timeGetTime which, with the help of timeBeginPeriod, has 1ms accuracy. I haven't seen much of this timeBeginPeriod() method... what exactly does that return? that method might be exactly what I am looking for, and if that will give me 1 ms accuracy I will be happy.
  12. LEET_developer

    Pentium M cpu and High performance timer

    Quote:Original post by Omaha I'm forced to agree with people that timeGetTime() offers enough precision for the uses of gaming. I can understand wanting excruciatingly detailed timers for ballistics simulations and nuclear detonation scenarios, but you can model a perfectly fine door getting blown off of its hinges and spaceships blowing up ad nauseum with a clock that's accurate within a 20th of a second, z.b. 50ms+/-, and usually much closer. If it gives you problems later then perhaps you can swap out your timer source for one that fits a little better but don't get stuck up on what timer you're going to use ahead of time, start with what's easily available. Also, if you're designing the whole thing with forethought, it shouldn't be too difficult at all to swap out a timing function in the future if you suddenly realize that the old one is not going to work. I don't see how anything can be done accurately with a timer that updates every 20th of a second... if your game renders at 60 frames per second, you want to have an "update" at least every render frame, or more. that would cause the timer to return a delta T of 0 seconds, and mean all your objects wouldnt move, and then every 7 frames or so, you would get a 50ms tick and the timer would say 50 ms passed and everything would move... unless you suggest some system where you poll the timer 5 times a second and then divide by some average number of frames you had before that to get a "pseudo" higher precision so objects can move a little every frame.
  13. LEET_developer

    need help finding tga font textures

    (Didn't want to use edit because this is technically an answer to my own post) for anyone who wanted to find more TGA font textures, here is a link to a guy who made a tool to create font textures out of truetype fonts http://www.lmnopc.com/bitmapfontbuilder/
  14. LEET_developer

    Trouble Picking a Book

    Quote:Original post by counterrabbit IMO do the c++ code book first. Learn the concepts of programming first as just a simple dx window D3D or Win32 is quite complicated and uses typedefs and pointers that as a beginner are difficult to understand The c# may give you graphical results faster and it always seems like the best idea but i say stick to understanding the object oriented paradigm and its uses. You Will give up if you go for dx, ive been programming for around 3 years now and dx still confuses me, especially classing it all up so that i can reuse it . . which brings us back to understanding OO implementation. So. in short, learn to code, dont worry about the console window cos a robust functioning and playable game such as blackjack or something is as rewarding as building pong, another popular starter program. Pong is i will tell you actually quite difficult to program(if you are brand new at this) despite how simple it looks, so stick with code and hold back the temptation of dealing with graphics and API's. Of course these are my opinions but game creation ISNT easy using c++ and other industry standard languages/API, make plenty of coffee and strap urslef in cos programming is a hairloss and aggravating experience. I agree with the rabbit, learn to code with c++ before you move onto less involved languages, mostly because learning c# first will give you bad habbits that will be hard to break when the time comes also knowing what went into games when they were all made for DOS is invaluable when you start coding for windows.
  15. Quote:Original post by zdlr I may have totally missed the point here but for what it's worth, I find that the texture binding that is required for separate tile files (in OGL especially) can make drawing a significantly complex map extremely slow. That's correct. Binding a texture in opengl is more expensive than pushing 1000+ TNL'd vertices. so basically having all your tiles in one texture would be one texture bind and drawing the entire map (which is likely less than 1000 vertices) would cost roughly the price of two texture binds. so if you have more than 2 tiles in your map, then binding those two textures would already make your map render slower than having one texture (1000 vertices ~= one texture bind is profiled from my graphics card, it could be faster or slower depending on the cards your target audience may be using).
  • Advertisement
×

Important Information

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

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!