• Advertisement

Metus

Member
  • Content count

    655
  • Joined

  • Last visited

Community Reputation

168 Neutral

About Metus

  • Rank
    Advanced Member
  1. Singleton problem

    Personally, I really think people over-uses singletons, but using boost you can create a singleton pretty simple without the need for a "DestroyInstance" function: [source lang = "cpp"] typedef boost::shared_ptr < class MySingleton > MySingletonPtr; class MySingleton { public: static MySingletonPtr GetInstance(); private: // alternatively static MySingletonPtr m_pInstance; } MySingletonPtr MySingleton::m_pInstance; MySingletonPtr MySingleton::GetInstance() { static MySingletonPtr pSingleton( new MySingleton ) return pSingleton; // alternatively if( m_pInstance == 0 ) m_pInstance.reset( new MySingleton ); return m_pInstance; } There should ne no problem to implement this class as a baseclass.
  2. Hehe.. no hard feelings about that :) There's one reason that I'd want the constructor to create the object: I personally prefer that way instead of [source lang = "cpp"] typedef boost::shared_ptr < Texture > TexturePtr; TexturePtr texture( new Texture ) texture->load_from_file( "file.dds" ); // or this way IDirect3DTexture* d3d_texture = { ... }; texure->assign( d3d_texture ); hmm... it seems pretty... weird anyway.. welll I think I have to get back to the design board then :)
  3. I really love to fiddle with engine core design and that includes some very interesting ways of creating flexibility. Yesterday a thing popped up in my head: what if my engine isn't too flexible to work in a large-scale project? 10 minutes lates the answer to that question was something I called "constructor functions". It means that any resource-based constructor only takes one argument and that is a function pointer. Example of my basic texture class: [source lang = "cpp"] Texture::Texture( boost::function < IDirect3DTexture9 () > constructor ) { IDirect3DTexure9* texture = constructor(); // Error checking m_texture = boost::intrusive_ptr < IDirect3DTexure9 >( texture, false ); } With this constructor and the boost::bind I can allow the user to pass in any function that returns an IDirect3DDevice9* to my texture constructor [source lang = "cpp"] IDirect3DTexture9* CreateFromFile( std::string const& source, IDirect3DDevice9 device ) { IDirect3DTexture9* texture = 0; RESULT result = D3DXCreateTextureFromFile( device, source.c_str(), &texture ); // Error checking return texture; } IDirect3DDevice9* device = renderer->get_IDirect3DDevice9(); typedef boost::shared_ptr < Texture > TexturePtr; TexturePtr texture( new Texture( boost::bind( CreateFromFile, "file.dds", device ) ) ); before I start to implement these constructor functions in the rest of my engine, is this a way that you'd like to work or is it just plain stupid? edit: perhaps this should be placed in the game programming section, but since the code contains directx code I though it might fit better here edit2: changed the subject name edit3+ tried to format the code
  4. Vegas007 is finally released.

    Thank you :) We really hope to reach the TOP-10 online poker clients but the release has been a bit slow though.
  5. After almost a year of intense development - Cellar Door Games finally releases the world's first 3D Poker Client - Vegas007. For more information and downloads - visit http://www.vegas007.com Texas Hold'Em screenshot Blackjack screenshot Please note that the screenshots on the site are almost 3 months old. Edit: Tried to fix hotlinking...
  6. Managing fallback shaders

    Ahh.. I'll take a look at the SAS now unsigned int iUserRating = 1732; ++iUserRating;
  7. Yep, that's the question. I have designed and implemented a simple scenegraph for my Neverending::Engine but I have reached a point where I need some fresh eyes on the design. So far I have implemented a Transformation-, a Mesh and a Subset node and the traversal and rendering works flawlessly. This night I had some plans for the Shader node (wrapping the ID3DXEffect interface) but something suddenly hit me: How should the ENGINE manage shaders using non-supported shader models? My first attempt to solve this problem was to automagically fallback to a default shader but I do not know if that is the best way to go. [source lang = cpp] // file: normalmapping.fx technique normalmapping { pass base { // ... } } // as far as i know, normalmapping requires atleast ps1.4 and how should the // shader / engine support this? technique fallback { pass base { // ... } } this could eventually solve this shader, but what if I decided to implement a parallax-mapping shader? [source lang = cpp] // file: parallaxmapping.fx technique parallaxmapping { pass base { // ... } } // the parallax-mapping should probably fallback to the normalmapping shader // FIRST and then - if that is unsupported - fallback to the really simple shader technique fallback { pass base { // ... } } soo should the artist manually add 4 or 5 fallback shaders in his editor for this?
  8. Little 2D RPG

    wow - that's pretty :)
  9. of course - my bad - or is it? Since this is a forum primarily dedicated to game developing - I thought some things were obvious. So to keep this thread alive - Quote:metus I've had a vision... Using all the tips and tricks in the world - how many boxes (8 verts and 12 indexed faces) would I be able to render using Direct3D9 capable hardware? I've had a vision... Using all the tips and tricks in the world - how many boxes (8 verts and 12 indexed faces) would I be able to render using Direct3D9 capable hardware and still get a decent framerate? And with decent frameerate I mean "the-least-amount-of-frames-per-second-that-you-could-play-a-fast-paced-actiongame-in"
  10. I haven't investigated wheter frustum- and occlusion culling will increase the performance when I'm using instances.
  11. I've had a vision... Using all the tips and tricks in the world - how many boxes (8 verts and 12 indexed faces) would I be able to render using Direct3D9 capable hardware? Using the modified "Instancing" demo in the SDK I managed to render around 30k of individually colored and textured boxes. I'm afraid that is NOT sufficient for my vision.. however, using approperiate batching and minimalistic shaders - would I be able to touch the 50k limit? The hardware that I used during this test was: A64 xxxx+ venice-core (overclocked to 2.8Ghz and SSE3), 1Gb of mid-performance DDR and an overlocked nVidia 6600GT (584Mhz on the core and 1113 on the memory)
  12. Culling Discussion

    Quote:Original post by StarikKalachnikov /../ wasn't necessary anymore since todays videocards can handle alot of polygons. /../ That is almost my opinion as well - however, frustum culling is the only thing I suggest since it is very easy to implement and is the culling method that probably will offer the most performance without any extreme computations - like quadtree/octree (not that computational - but anyway) and perhaps even BSP generation. Occlusion culling is probably the most useless culling method ever, since as far as I know, you need to render the scene twice to know what objects occluds other objects. just my 2% of a coin
  13. Serious Sam 2, serious problem!

    That's pretty simple - your display adapter - the GeForce4 MX400 does not support vertex- and pixelshaders that is required by the game. yuo really need to purchase yourself a new videocard if you're planning to play some of the really awesome games of today.
  14. lazy renderer?

    that was exactly the kind of answer i was hoping for Ubik. Considering the API - I have no intention to support both OpenGL and Direct3D so that is no concern. I think the only thing my renderer-class will do is to render primitives, everyting else is done the the external classes: textures will set up themselves, shaders will set constants et cetera.
  15. lazy renderer?

    hehe.. you're obviously not the only one :) as you can see here: [source lang = "cpp"] // totally lazy int kState = 0; pTexture->Bind( kState ); // somewhat lazy int kState = 0; pRenderer->BindTexture( pTexture, kState ); i've displayed two different ways of setting a resource - in this case a texture - one way where the "renderer-sets-the-texture" and the other where "the-texture-uses-the-renderer-to-set-itself" way both these techniques surely have pro's and con's - and i want to know if someone here has chosen the one over the other - and why
  • Advertisement