Jump to content
  • Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

354 Neutral

About Mephs

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Mephs

    I'm not dead... I feeel fiiine... croak

    lol! Well you did say that you didn't want all those emails clogging up your inbox ;) Never mind though, I think they're planning a follow-up at some point, but not sure if they are changing to a different game or not... I hope to get some revenge in Q3A though, so I'd like it if we did that again :) Anyhoo yeah, the export stuff is going nicely... just a shame that I'm away for a week in Cornwall now the work is taking off (and now it's looking like terrible weather in Cornwall!)... I've now got bones exporting and an early framework in place for keyframes, IPOs and all the rest of Blender's animation stuff... I'm dying to see a proper animated model all exported in my own format!! Anyhoo... see you in a week! Steve
  2. Mephs

    I'm not dead... I feeel fiiine... croak

    I haven't completely given up on it. The code to load the XML is still in there. My idea is currently to develop the two in parallel and use the XML version for debugging as you have suggested. I am however writing this in the hopes that perhaps one day I might be able to have a marketable game at the end, and I'm figuring that every easy byte saved is a good thing as regards the final download size. :) Cheers, Steve
  3. Err yeah. I'm not dead! The model exporter/loader isn't going to plan as well as I had hoped. I tried to go with an XML based format until I realised that the file sizes I ended up with were horrendous. I've been working instead on a binary chunked format similar to 3DS files, but obviously with an eye to including skeletal animation support. So I've modified my system to work with binary data as well as XML. To put it into context, the model I am working with is a blender model I downloaded of a T-Rex. As an xml-style file it ended up a staggering 16 megs in size :(. It wasn't hugely optimised, but still!! My binary version of the same file is 955k in size, which is smaller than the original blender file, but at present lacks animation data. Of course, with all these distractions I haven't even begun work on animation yet. I'm still trying to get uv's to load in correctly... which incidentally weren't working because of shared vertex issues. I'm currently in the middle of a horrid hack to convert from Blenders vertex/uv scheme into my own. I just wish I had a more elegant solution. All that aside, we went all old school in the office this evening and had a mini Quake III Arena LAN party which was cool :) Admittedly I've lost a fair amount of skill since "back in the day", but I'm quite happy with how I did... I managed to keep a decent score and I think a fun time was had by all. I really need to practise with the railgun though... Anyhoo, sorry to anyone reading that may have been hoping got pictures... there are no piccies yet, I'll keep working on the animation stuff and hopefully get there soon. Cheers, Steve *EDIT* Just managed to get it all up and running properly for the first time... so now I have a picture :) It's not too exciting, but now you can see the model in-game for the first time! *EDIT2* and thanks to my relatively simple rendering system, I've managed to fiddle around and get ambient directional lighting working for the model within only a few minutes :)
  4. Mephs

    New Models :)

    Just a quick post to mark the fact that my model export script for blender is now underway and is at the stage where I can export static meshes and see them in the game :) It's not 100% perfect yet, texture coordinates seem a little off in places, which I think might have something to do with the way D3D uses texture coordinates. Also, objects with no texture in their material do not yet render properly and I also suspect that my exporter might be duplicating some geometry. But all in all I'm happy so far... I just need to tidy up static mesh exporting/importing and then start to look at exporting blender armatures. I'll post new screenshots when I get a completely working static mesh, and see if I can post some kind of flash video or something when I have animation up and running, which will probably take a bit longer! Steve
  5. Mephs

    Let's make it all pretty!

    The XML parser is finished way ahead of schedule :) It works pretty nicely. I think it needs a little more error checking for safety in future, but as I know my system at the moment it suffices. With the basic system being proven to work in the context of a GUI though, I'm now happy to start writing my exporter. I want to get a basic static mesh exported first, then I'll work on animation. Animation however is going to require some code work too, so I'll stick with my original target deadline for the work and see how it goes.
  6. Mephs

    Let's make it all pretty!

    Okay, So with the successful refactoring of my rendering engine (up to a point where it will display 2d elements and static 3d models). I'm now going to work on making things look a little less amateur. First off, I am going to develop and integrate my own XML-like skeletally animated model format. It's one of the things I always wanted to do but never quite got round to. I'm sick and tired of coming across exporter after exporter that either exports models badly or is really awkward to use. I want to just specify a filename, maybe an option or two (but probably not). Hit a button and have a useable model file. Is that too much to ask??! So yeah, I'm currently working on the parser and integrating it with my renderobjects. As I'm nicking bits of code from my GUI for the parser, I'll also have to have a bit of a rehash of the GUI too, but just enough to get me by.. I wont be adding any amazing new features, just getting something functional working again seeing as I have thrown away the guts of the system in rewriting the parser. I'm thinking it will take me until about the end of the week to have my XML system fully working and then perhaps another week or two to write the model exporter (in Python for Blender). If it gets done any quicker then it's a bonus. That all aside, if you didn't spot the comment at the end of my last entry, I managed to raise my frame per second from a horrendous 26 FPS up to a respectable 222 FPS, which is currently rendering around 25 thousand textured polys with alpha blending for the text. That's around about 5.55 million polys per second, give or take a million I guess (these are approximate figures). I don't know if that's good or bad for an ATI X1400, but it's certainly enough to be working with :) Anyway, back to work for me, I'll update on my skeletal animation endevours as soon as I have anything interesting to say! Cheers, Steve
  7. Mephs

    Screenshots :)

    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 :)
  8. Mephs

    Screenshots :)

    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
  9. Mephs

    Screenshots :)

    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 :).
  10. Mephs

    Screenshots :)

    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
  11. Mephs

    Screenshots :)

    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 :)
  12. Mephs

    Screenshots :)

    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
  13. Mephs

    Refactoring almost complete :)

    Yeah, I really liked it too, but I just took it off as I went back to the avatar uploading page to double check. I then spotted that animated gifs aren't allowed, so thought I'd best go back to the not-so-good avatar :(. Maybe I should PM a mod and see if I can get special permission or something as the avatar was cool (and suitable :) )
  14. Woah... back again, who would have thought :) Refactoring is now almost complete. I finally have rendering once more. I did have a screenshot, but it's on my home PC and I'm currently at work on my lunch break, but it was boring as it just showed my main menu screen anyway, so no major loss. But yes, that's right, I now have a UI that is rendering once more. The system worked beautifully when adapted to my bitmap font class and UI classes. I had to make some minor changes to the design once I tried it out in practise, but it all still goes together nice and logically, if not more so since my latest changes. The main thing that I struggled with was the concept of Shader constants. What object should look after them, where should they be set, etc? The problem is that some constants require changing on a per renderobject type basis, some require changing on a per-renderobject instance basis, some require setting on a per-scene basis and some require setting on a global basis. So how in the heck can you code something flexible enough to handle all of that without obfuscating game level code with SetShaderConstant function calls which seem out of place? In the end, I went with some template code madness. The shader constants are now set by default in the render method and the system works by applying overrides. Overrides are only ever set from within a render object, but can be altered through more sensible functions that control them. So now, I can create a scene: RenderScene GameScene; Add some objects to the scene: GameScene.addObject( Model("test.3ds"); GameScene.addObject( guiControl("window.xml"); Then I can modify a scene shader constant by something like: GameScene.SetLightDirection( D3DXVECTOR(1,0,0) ); Within the renderobject/scene is where the template madness comes in. In this case, it would be doing something like as follows: void RenderScene::SetShaderConstantDefault() { // Set Light Direction Shaders::ShaderConstants::LightDirection lightDirection; // convert the stored light direction into a shader constant lightDirection.value( lightDirection_ ); shaderConstants_.push_back( lightDirection.proxy() ); } What happens here is that shaderConstants_ is a vector of shaderConstantProxy pointers. LightDirection is a derived specialized template that operates on D3DXVECTOR4's. The proxy function call returns a proxy object which deconstructs the supplied value into a series of D3DXVECTOR4's (so something like a matrix would automatically be broken down into 4 D3DXVECTOR4's, or a float would be put into a single D3DXVECTOR4). The proxy object allows us to store the templated shader constant type in a vector. So this allows us to easily set any type of constant (vector, float, matrix, whatever). The code will not compile if we try and set the wrong type of data, e.g. setting a float value for the world matrix, because of the templating, so you really can't mess it up and supply incorrect values. Each derived specialized templated Shader constant (phew, what a a mouthful!) has to override a type function, which returns the type of constant. Now this means that because we are able to obtain the type of constant at runtime, any given shader can request a constant of a specified type and set it in Direct3D at will. If the object has overridden the constant, the override will be applied. If it does not exist, the default will be set. This finally means that we can apply any given shader to any given object without messing around with any constants directly. If a given object hasn't overriden a shader constant, the shader just uses a default value (and maybe reports this to a log, so we don't get confused!). It all sounds complex, but from an end coders perspective, they simply change sensible object specific data (such as the light direction of a scene) and the object completely takes care of setting up all the shader constants for you for both vertex and pixel shaders regardless of what shader type you have applied, be it a 2D GUI shader or a 3D bumpmapping shader. Now, I usually miss the blindingly obvious easy ways to do what I try and do, so maybe this could have been done in a much more simplistic manner, but assuming not, I think this system is quite nice :) Cheers, Steve
  15. Mephs

    Refactoring underway :)

    Oh yeah, zombies and explosions :) hehe... well seriously, that brings up a good point about the whole reality vs fantastical designs. I'm usually a fan of heavily stylized games like Psychonauts rather than ultra realistic graphics, but I'm not sure if this type of game would suit stylized graphics. I mean, make all the riders, bikes and environments cutesy looking and I think the game would lose its appeal. Go sci-fi high-tech style and I think the character of the game could also suffer. It kind of feels like this design needs to be based on a modern day setting and needs to have somewhat realistic graphics. If I can think of a way to make it stylistic and yet still work though, you can bet I'll go for it. So uhh... yeah, zombies... just need to think up an excuse for them now :P
  • 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!