Wow almost a month since I last posted!!!!

posted in Good Enough?.... Never!

Published September 25, 2006

Time flys is all I can say.

Well I have come to the admit defeat and just drop the view I have had in my game and just go with the standard top down look but slightly skewed. The user can move up and down to zoom in a bit and rotate 360 degrees, but no more looking out over the vast landscape. I have determined that shadowmapping unless its PSSM just isn't up to par with the quality I want to see in large outdoor areas. PSSM is nice but comes at a performance hit. I can't afford anymore FPS hits as my FPS are borderline where I think they are acceptable so far. My skydome looks ok, but from a realism stand point ugh, just a texture of a sky, not good enough anymore and this would take more of my time that I don't have to find/fix the sky to make it look up to par with what I want. All of these and other points start to push my game back more and more. I just want to finish it and then look at whats out at the time for power and code accordingly.

I have been looking at PBO's lately but not sure what good they would be for a RTS. Anyone have any ideas glad to hear them.

How is everyone rendering 100's of models on the screen these days? Lets say you have 50 different model types but you have two players that can have 250 units each. So 500 units on the screen from 50 different units. Can't I just have one model object for all the instances of that unit and just render it where I want to, by just using a lets call it mesh manager that hold each instance's position and ID number and then loop throught that mesh manager and render that units mesh at the locations... Still seems wasteful, what about instancing how is that different from what can be done now? Instancing draws once and you can place that mesh all over the scene with one call? This I can see saving cycles...

Previous Entry About time

Next Entry Fog and more fog

0 likes 5 comments

Comments

extralongpants

PBOs might help you out, depending on how dynamic your meshes are (constantly locking/unlocking and updating geometry data might be slow, although I'm not entirely up-to-date on this kind of thing). All in all, I doubt they'd make your game run slower, but you should determine first if they are worth the effort. Are your meshes animated (I would assume they are)? A mesh manager will save you memory, but depending on your implementation, it may actually increase processing requirements, especially if your meshes are animated.

I haven't read much of your journal yet, so if you've already done this, I appologize: You should really profile your code before you start trying to optimize things such as geometry submission. Adding prettier graphics might push the frame-rate over the edge, but that does not necissarily mean that graphics are your bottle-neck. I would make an attempt to find out what is really causing your game to run slowly. You may find a few easy fixes and surprise yourself; maybe you'll be able to put nicer shadows in after all.

September 25, 2006 01:43 PM

Ravuya

You really should post more screenshots. Hint, hint. [wink]

I don't think there's much of a problem with making a top-down game; I've made quite a few.

September 25, 2006 03:14 PM

LachlanL

How I do it is have an array of models (contains vertex/index buffers, pointers to textures, radius of object's bounding sphere, etc) and an array of instances. All the instance has to hold is either a pointer to the model, or array index, as well as physical position. Then when you call draw() on the instance, it draws using the model's data.

Of course, you'll want to have the instances in some sort of spacial hierarchy, maybe a quad-tree from the sounds of your application? That way you don't have to search the entire array of instances to determine which ones are on-screen.

As far as instancing is concerned, isn't that a DX10 feature? Feel free to correct me if I'm wrong, of course. But if it is, you'll be limiting your customers to ones with DX10-compliant gfx cards.

Ohh yes, and I second that call for screenies! [grin]

September 25, 2006 06:39 PM

_the_phantom_

Instancing exists in D3D9 but no direct support for OGL exists.

However, in this instance its unlikely to gain you anything unless your models are very low polys so that glDrawRangeElement call overhead > drawing time.

Instancing was introduced to get around the (brain dead) issue of having to switch to kernal mode in D3D for every drawprimative() function, which on small batch sizes murdered performance.

OGL doesn't perform this switch so doesn't suffer the penalty (yay!), however D3D's (brain dead) choice has been fixed in D3D10.

So, unless you are constantly binding gl*Pointers() before every draw call, which you shouldn't be doing if your mesh management system is sane, you'll simply be issuing draw calls from the same data constantly, only a gltranslate/glrotate different, thus you won't even pay for rebinding buffer pointers.

September 25, 2006 11:16 PM

MARS_999

As for screenshots the first Journal post shows some screenshots... :)

I now have bumpmapped units and shadows from other units cast shadows onto other units.

Phantom I will keep that in mind for now, but Nvidia seems to think GL needs it since they have a extension in the works...

Still not 100% sure on PBO. Some definitive examples would be nice other than animations for models... Thanks

And here are some SS's from various points in my development. A few are from the Mac days so be nice...

terrain