Re: [Warzone-dev] vbo and va tests
On 2/18/07, The Watermelon [EMAIL PROTECTED] wrote: 2.Removed the shadowloop function added by one of these patches,and replaced it with opengl displaylist for better performance(at least the geometry data is unchanged during the 1st and 2st passes for us with scrouged gfx cards without stencil_two_side extensions...the shadows code is just too depend on that extension to perform at acceptable speed.Sorry to whoever added 'shadowloop' function.) How much does this improve performance? Might be worth looking into as a temporary solution. But there is no need to undo the shadowloop, there will still be two instances of duplicate code that it cleans up. Things I plan to fix/do: 1.multi-texturing ARB extension supports,the current fill rate is a bottleneck too,increasing resolutions reduces overall performance significantly(w/ or w/o shadows) 2.some other extension to speed up pixel filling. 3.make the effects to take the advantages of opengl point sprite extension to deliver better visual quality and performance. I do not think this throw lots of code at a problem and see if anything sticks-approach works very well. I would strongly prefer that we clean up the code, rather than just throwing in new extensions and combine several different approaches without much plan or design behind it. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] vbo and va tests
On 2/18/07, Per Inge Mathisen [EMAIL PROTECTED] wrote: How much does this improve performance? Might be worth looking into as a temporary solution. But there is no need to undo the shadowloop, there will still be two instances of duplicate code that it cleans up. I dont think the shadowloop makes the code easier to read nor making it run faster(a call to another function is slower than some local loops/blocks),actually the shadows loops are not duplicated anymore with display list: 1.with stencil_two_side,it only needs to draw the shadows shapes once and let the extension handle the increment and decrement of stencil buffer,so we dont need to generate a list for this case. 2.without that extension,it needs to draw the shadow shapes twice(increment and decrement) with identical geometry info,so we better cache the shadow loop into the vram and access it twice later for better performance,so a display list is needed in this case. for the performance,something compiled and executed later in varm twice is definately faster than issuing the commands twice in host memory. I do not think this throw lots of code at a problem and see if anything sticks-approach works very well. I would strongly prefer that we clean up the code, rather than just throwing in new extensions and combine several different approaches without much plan or design behind it. it needs some clean up indeed,but most clean up are done,and I am already finished unifying the vector2/vector3 struct and other fundimental changes.Personally I think clean-up can be done when adding functionalities or fixing exist codes,usually a 'rebundant problem' emerges only when you have pretty good understanding of the code,for instance,I just found out that it adjusts glMaterial and shininess in pie draw function(it should be in display3d renderer main loop) and the shadow/light seems work correctly without GL_NORMALIZE when I was adding other stuff. The problem with the current renderer is the 'working but not working optimally' opengl port,it doesnt even use the most commonly available extensions such as glLockArrayEXT(),which is available on almost all cards including the ancient rage 128. Experimenting with different extensions combinations wont harm either since it only affects one source file or two(piedraw.c and display.c),and most extension can be turned on and off with some simple boolean variables and extension check functions. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] vbo and va tests
On 2/18/07, The Watermelon [EMAIL PROTECTED] wrote: for the performance,something compiled and executed later in varm twice is definately faster than issuing the commands twice in host memory. Well, I did not have to work with OpenGL for long to learn the hard way that statements of the form it makes sense, so it must be faster often mean absolutely nothing in practice. Did you try this isolated from other changes and see noticable difference in FPS speed? The problem with the current renderer is the 'working but not working optimally' opengl port,it doesnt even use the most commonly available extensions such as glLockArrayEXT(),which is available on almost all cards including the ancient rage 128. I am not sure what you would do with glLockArrayEXT(). Using VBOs are, I think, always better, so if we are to rewrite code anyway, there is no need to spend time on yesterday's solutions, like compressed vertex arrays and RAM-side locking. Experimenting with different extensions combinations wont harm either since it only affects one source file or two(piedraw.c and display.c),and most extension can be turned on and off with some simple boolean variables and extension check functions. I believe we need to redesign larger parts of the general 3D workflow to significantly improve the 3D engine, since using VBOs efficiently means storing more data in VRAM rather than in RAM over longer periods of time. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] vbo and va tests
On Sun, 18 Feb 2007 11:53:05 -0500 The Watermelon [EMAIL PROTECTED] wrote: Well, I did not have to work with OpenGL for long to learn the hard way that statements of the form it makes sense, so it must be faster often mean absolutely nothing in practice. Did you try this isolated from other changes and see noticable difference in FPS speed? ofc... ofc? I think it best idea to what you are doing, and seeing if these kind of changes will speed up. That way we know for sure what biggest bottleneck is if someone decides to rewrite the rendering engine. I am not sure what you would do with glLockArrayEXT(). Using VBOs are, I think, always better, so if we are to rewrite code anyway, there is no need to spend time on yesterday's solutions, like compressed vertex arrays and RAM-side locking. games use VBO in conjunction with glLockArray and drawRangeElements...glLockArray is used to tell opengl that the commands inside lockarrayEXT and unlockarrayEXT will not be changed and opengl can do whatever to it such as compile thus making it run faster with or without VBO's... I believe we need to redesign larger parts of the general 3D workflow to significantly improve the 3D engine, since using VBOs efficiently means storing more data in VRAM rather than in RAM over longer periods of time. no the 3D engine is ok,it's just the way the current wz utilizes the functionalities of the engine kills the performance. we dont need to rewrite something in order to use vbo efficiently,we just need to: 1.global number of vbo limits(per pie or per pie type(better)) 2.add a property to imdshape called vbo 3.add a function to convert imdshape to opengl compatible interleaved array 4.upload the data to corresponding vbo and bind to imdshape-vbo 5.delete local copy 6.make draw function passes and accepts vbo id instead of imdshape though I am still lean towards big arrays over VBO... rewriting big parts of code always sounds neat and ambitious,but most will be turned out as reinventing the wheel,whether successfully or not.Afterseeing quite a few failed rewrites in various projects,I dont put much faith in such a thing called 'rewrite remedy',and I seriously doubt we have enough dev and time to rewrite huge parts of code like render engine which was written by a whole team of experienced pumpkin SE cooperatively. Yes, from all reading it seems that the main coders at the time looked at the 3d engine and decided if you rewrite it, might as well rewrite everything else. This why they doing another project. While it sounds better if someone says to rewrite all the engine, I don't think anyone has time for this, so Watermelon approach is best. the most important thing for an open source project,in my opinion,it's the visible development progress and the developers' presence among the community,sure there is no deadline or restriction for an open source project,but the community will stop growing or even worse,begin to degenerate and lose members if we dont show evidence of development progress fastly enough and keep the new features flow. This is true also, but I add that bug fixing to make sure everything works is another reason why people might not like to join. In this stage of game, the things that need fixing most is 3d engine, and network code. -- Click to receive credit card help and get out of debt fast: http://tagline.hushmail.com/fc/CAaCXv1QMqXPOx51VUpKUdq46MGxbdPq/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
