Screenshots :)

posted in Journal of Mephs
Published April 25, 2008
Advertisement
Wahaay!! Screenshots at last :)





Okay, yeah, I know, the filtering is rubbish, there is no lighting, the model is bad, blah blah!

The point is that I finally got models rendering again :) I had to refactor my shader constant system again. The template madness proved to be too mad... or should I say just too much maintenance work.

I've replaced it with a more simple system which requires less maintenance, but still works in a similar way. Render methods set up a series of default render states and shader constants, and make requests for any shader constants they have no knowledge of themself.

Render objects can then override states and supply shader constants (such as worl*view*projection matrix). The render method concerned alway has final say over what it receives though. If a render method knows that it's shader cannot handle certain values or states, it can set locks to prevent the overrides. So my 2D render method currently locks the z buffer to disabled for example.

All setting of render states is now neatly done in a single function per object type and is very low maintenance. It is very easy to create new types of renderobject and very easy to change how a given object is rendered. Mission accomplished.

Next thing I have to work on is speeding it up. It's currently only doing 26 frames per second :( I have no batching at the moment and this is a priority, as 26 FPS is just terrible. Mind you, I think I'm doing lots of unnecessary geometry building each frame, which is probably another quick and easy optimisation. I need to start flagging geometry builds only when geometry has been updated.

Then I need to get things looking a little less rough around the edges and hopefully at that point I can start loking at beginning my prototype :)

Cheers,

Steve
0 likes 9 comments

Comments

lucius
Sounds good.

I'm sure I missed it somewhere, but what kind of game are you making?
April 25, 2008 06:50 PM
Mephs
Well, what you are seeing here is the refactored remains of my old project (an attempt at a 3D air-hockey game). I kind got stuck in the mud with it's somewhat dull design though, so as mentioned in previous journal posts, my new game is going to be a Urban Motocross Beat 'em Up a la Road Rash with a splash of Tony Hawk games and Burnout thrown in for good measure :)

See my older journal post for more details :)
April 25, 2008 06:58 PM
lucius
Sounds interesting and different - and that's a good thing :)
April 25, 2008 07:01 PM
Jason Z
Mephs is back?! It has been forever since I've seen you around!

Welcome back!
April 25, 2008 08:40 PM
Mephs
Hey Jason,

lol, someone remembers me :) I'm not sure I've really made a big enough impact around the place to be remembered for anything (except maybe with my old terrain texturing thread but that was more thanks to Yann being so helpful) but it's nice that I am. To be honest though, I never really disappeared, I just have a habbit of lurking rather a lot, especially as I've been stuck trying to work out a good design for so long.

I recently started working in the games industry though. So having started doing Game Dev for a living now, I find I'm much more motivated to get on with my own work too as I have learnt a lot in my job (and I think I'm finally happy with this design!). As a side effect of getting stuff done on my own projects again, I thought it would be cool to start up the old journal again.

So yeah, thanks for the welcome back, I'll try not to leave it so long again!

Steve
April 26, 2008 04:06 AM
Mephs
Well, a small update, but not one that I feel warrants a new journal post.

I've now managed to get my framerate up to 130 FPS and I haven't even implemented the batching yet :)

I used the ATI/AMD GPU Perf Studio, AMDs equivalent to nvPerfHud. The analysis tool is just fantastic for picking up on bottlenecks. It basically runs loads of tests such as limiting the application to 2x2 textures or disabling the z buffer, or alpha blending, etc, and works out how big of a framerate increase you get. It then uses the increase/decrease to suggest ways to improve performance. Also it gives you loads of useful statistics such as the number of DIP calls per render state change, etc.

Anyway, so using that, I worked out that my application was using too expensive a pixel shader (I left in an extra, but pointless, texture sampling in one of my shaders which was being used all over the place). It suggested that my texture filters were too expensive as well, and of course enabling mipmapping again helped there. Also, it suggested that my texture bandwidth usage was too high, which I suspect is a combination of textures that may be too large, and too much texture switching as well. So I will still continue with my batching optimisations, but I'm happy to have gotten back to a decent framerate without even having implemented it yet :).
April 26, 2008 08:24 AM
NineYearCycle
Simple, simple is good.

After a day at work I like nothing more than hacking something truly horrible together in the simplest way possible :) it's cathartic!
April 26, 2008 08:52 AM
Mephs
Yeah, my project is miles apart from FS, it all just seems so much more simple now I'm used to dealing with much larger scale projects. I think my code structure though is really improving, much better than the hash of a job it used to be. I never used to cache render states for example, I just blindly set them and hoped for the best. It's amazing how much of a difference it makes by not setting states if there has been no change.

Speaking of which, I'm up to 190 FPS average on my test scene now and I STILL haven't implemented batching. I tried to implement batching and worked out that with renderobjects containing all the geometry in a geometry/material std::map, it was really hard to batch render objects as it was not render objects that needed batching but the geometry/rendermethod and materials.

So I changed to a hierarchical system such that every object has only one geometry member and one material, and each object can contain child objects. Just doing this gained me 50 FPS and now it's gonna be really simple to implement batching too. I might have to come up with a homegrown instancing solution as well, as I suspect rendering multiple instances en-masse is going to cause problems with the current setup. Shouldn't be too hard to do though!

Steve
April 26, 2008 06:32 PM
Mephs
Right, I'm off to bed in a second as I'm very tired :P, but render batching is in and working!! I can now batch by texture and by render method and I have also ensured that duplicate textures are not set, saving many settexture calls.

Final FPS for the evening is 222 :). I'm more than happy with that, especially as the system is so flexible, it should be able to handle just about anything I chuck at it, whilst adapting nicely with the batching system.

Next on the cards is to get things looking nicer (which may involve writing some new shaders and tweaking the render engine), then it's criiiiime fightin' time... err, umm prototyping time :)
April 26, 2008 09:22 PM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Profile
Author
Advertisement
Advertisement