Permafried-

Members
  • Content count

    190
  • Joined

  • Last visited

Community Reputation

274 Neutral

About Permafried-

  • Rank
    Member
  1. Thread Safety in Accessor Methods

    Quote:Original post by Telastyn The second is pretty much what boost::thread does, so umm... why not use that? I'd considered using Boost for a number of things but I wanted to get some exposure to multi-threading and syncronization myself rather than using a pre-existing library. As it stands there would be nothing stopping an end-user from using the Boost library as opposed to my foundation classes but I'm trying to design them all carefully enough that they're useful and fully-functional. Quote:Original post by Sharlin The second way, utilizing RAII, is certainly the preferred and idiomatic approach. In fact, the first one has a serious problem: it is not exception-safe. If an exception is thrown while m_mutex is locked, it is never released without ugly try/catch/rethrow wrappings. I figured as much and didn't really like the look of the first approach at all. The second is more appealing programatically and is thread safe in and of itself. Thanks to both of you for the feedback...good to know I'm on the right path :).
  2. Since I've been contemplating the best way to handle this for a while now I thought I'd look for some opinions here to help me out. I've been stuck on how to handle thread safety in my foundation classes for a while now particularly in regards to accessor methods. I've been playing with two options on how to handle this so far. The first, I lock the mutex and copy the member variable to a temporary function variable. Then, I unlock the mutex and return the temporary varable. For example: int CClass::GetClassVariable( void ) { m_mutex.Lock(); int iTempVar = m_iMemberVariable; m_mutex.Unlock(); return iTempVar; } m_mutex is of type CMutex which is a wrapper class but the implementation isn't important enough to post that much code. My second option is to add an additional foundation class which acts as an automatic mutex. The constructor accepts a source mutex object and waits to get a lock. The destructor will then release access to the mutex object when it goes out of scope. class CAutoMutex { public: CAutoMutex( CMutex& srcMutex ) { srcMutex.Lock(); // wait indefinitely m_mutex = srcMutex; // copy so i can unlock in destructor } virtual ~CAutoMutex( void ) { m_mutex.Unlock(); } private: CAutoMutex( void ); CMutex m_mutex; }; Now, using the same method as above it would execute as follows: int CClass::GetClassVariable( void ) { CAutoMutex lock( m_classMutexToUseAsSource ); return m_iMemberVariable; // lock will automatically unlock the mutex // when it goes out of scope here } I guess really what I'm looking for is feedback on what people feel the best approach would be of the above two or if there are any other ideas. Thanks,
  3. Quote:Original post by vbms ahh ic, ic. u guys thnk way more complex thn me.. but thnx man thnk that realy helped me ill try that... first ov all... my beer is depleated :p Thought maybe this link would help explain some things as well such as why what you tried to do won't work and in a round-about way why what I did will :) Function Pointers I can't remember 100% the syntax for the second block of code I provided when the class isn't a template class...I think the way I've provided it should work but if not you might have some investigation to do on your own but I know it can be done :). Best of luck EDIT: Yep I knew that syntax was totally wrong. Here's the second block of code re-written to register an internal class method as a pointer to a function :). class particles { public: particles(int type) { // decide here based on your type you don't need pObj // necessarily and execute could just call ( this->*m_pMember )() // but trying to keep syntax consistent pObj = this; m_pMemberFun = particles::fire; }; void execute( void ) { ( pObj->*m_pMember )(); } void fire(); // etc ... private: particles* pObj; void ( particles::*m_pMember )(); }; [Edited by - Permafried- on March 8, 2006 12:16:24 PM]
  4. This might not be the best example (and man I hope I have the syntax right) but you COULD house a pointer to a member function similar to this: template<class T> class particles { public: // particles(int type); particles( int type, T& obj, void ( T::*pMemberFun )() ) { type = type m_obj = obj; m_pMemberFun = pMemberFun; } execute( void ) { ( m_obj.*m_pMemberFun )(); } //void(*pfnc)(); // i tryed this & //void *pfnc; // this type void fire(); inline void ice(); // also tryed inline // etc ... private: T& m_obj; void (T::*m_pMemberFun)(); }; CClassWithFunc* pCls = new CClassWithFunc(); particles<CClassWithFunc> obj = new particles<CClassWithFunc>( type, *pCls, CClassWithFunc::FunctionYouWantToUseAsPointer ); The execute method should correctly call the function assigned through the constructor assuming the object you supplied has not been deleted. If I goofed anything up someone please let me know but that could be one possible solution. EDIT: Removed because the code was incorrect :). [Edited by - Permafried- on March 8, 2006 12:53:26 PM]
  5. headers and sources to dlls

    Quote:Original post by TheFez6255 Actually you don't have to use dllimport depending on when your loading the DLL. If its at load time then you CAN use it (A really dumbed down explination is it just tells the compiler that the implementation is in the DLL and not here. So depending on the compiler, you might be able to get away with not using it). If its at run time, you don't use it at all. Instead you use GetProcAddress and LoadLibrary to get to the individual functions. Note that you still use __declspec(dllexport) though. Thanks that totally clears things up! It would appear the .NET 7.1 compiler doesn't require it then since I've never once had it complain unless of course I forgot to link to the external DLL's LIB file -_-.
  6. headers and sources to dlls

    Quote:Original post by trevaaar When you start to use DLLs, you have to understand 'exports'. An export is a piece of data (generally a function) that can be accessed outside the DLL. For example, the standard Windows DLL user32.dll contains an export called CreateWindowA that is used to create a window. If a function is not exported, code outside the DLL cannot call it directly. There are several ways to export. One is to create a file in your project with a .def extension containing the word EXPORTS followed by a list of all the symbols (complete with compiler name mangling) you want to export, one on each line. An easier way, however, is to mark everything you want to export with __declspec(dllexport) in your project, and mark it all with __declspec(dllimport) in the header that other projects will include. An easy way to do this is to use the preprocessor. In the header that contains all the functions you want to export, put something like this before you define any of your exports (you can change the names of the defines): #ifdef MYDLL_EXPORTS #define MYLIB_API __declspec(dllexport) #else #define MYLIB_API __declspec(dllimport) #endif Then mark all the things you want to export with MYLIP_API (or whatever you want to call it). Ensure that in your DLL project you define MYDLL_EXPORTS before you include any headers containing your exports. Not meaning to hijak the thread but I was hoping maybe someone could explain why you need to define dllimport for modules that consume the DLL? I've gone through the MSDN (which didn't clear much up at all) and tested this out myself and never once have I used it and have no problems whatsoever accessing the exported items in my DLLs (which were of course pre-fixed with __declspec( dllexport ). I know it's good practice to use it but I don't exactly understand the reasoning behind it and whether it still really applies or is more of a legacy item still supported. Thanks!
  7. DirectX Load 3D Model

    Quote:Original post by Tesl Quote:Original post by Anonymous Poster I believe that if you want to open a .X model file all you need to do is load up the D3DXLibrary (which should already be included in your DirectX library) and then call the LoadMesh function. Viola - you're done loading a mesh WITH animations, complex lighting, and material data - and you had to use one line of code to do it. Isn't D3DX great? A single function called LoadMesh that loads up all animations, complex lighting and material data? Could you kindly point me towards this wonderful function? From what iv found, displaying animations from .X files is no fun... EDIT - Sorry, forgot my reply to the OP! The code given by Permafried is pretty much it. Just be sure not to forget to put some lighting in the scene as well =) We actually managed to get mesh animation working using the animation controller but you're not kidding...it's an excessively large pain in the butt especially since the documentation on it is sketchy at best. I think I would have been better off taking a round-about route and using my own linked list of transformations to animate the models but being a 4 month project for school I didn't have any time to spare. Since my example was incredibly basic he should also be optimizing the mesh and storing off the materials should they serve his needs (though the pathing using a .x file doesn't fill the need quite as well as I'd hoped the first time I used it). The mesh interface serves it's purpose if you want to get something up and running quickly (that of course after you've picked through the docs) but in the long run I think you're much better off implementing your own loaders and rendering them using standard vertex and index buffers.
  8. DirectX Load 3D Model

    I definitely understand your frustration since I went through the same thing regarding .X files when I was writing my game over a year ago for my final year's project. Unfortunately if you can't go through the DX SDK examples there's really not much else out there for loading .X file formats but your second best bet is to look at the source code for the .X file viewer included with the SDK to get you going but again you're going to have to search through bloated code. Lookup D3DXLoadMeshFromX in the SDK documentation...this is how you load in geometry, etc. from a .X file and get your mesh loaded. From there you should be able to step through the SDK documentation to find the methods you need to render (DrawSubset( x ) if I remember correctly), etc. EDIT: Here's a link to the online documentation so you know what you're looking for :) http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directx9_c/d3dxloadmeshfromx.asp and a quick example: ID3DXMesh* pMesh = 0; // very basic load method, read doc regarding parameters, would take too // long to explain them all here :) D3DXCreateMeshFromX( L"NameOfFile.x", D3DXMESH_MANAGED, <-- same as D3DPOOL_MANAGED pD3DDevice, <-- IDirect3DDevice9* NULL, NULL, NULL, NULL, &pMesh ); // now to draw it assuming the mesh is not broken into individual // subsets, to simplify things I'm assuming it's not but lookup // ID3DXMesh in the SDK documentation (within BeginScene() ) pMesh->DrawSubset( 0 ); That's a REALLY basic example of loading the rendering a model loaded from a .X file. Hopefully it's enough to get you started :). Best of luck
  9. Wow it's almost scary how close his system behaves to the one I have designed for my system. After toying with a bunch of ideas the listener class seems to be the simplest route for me to pursue especially with the entire event system being multithreaded. The event manager now allows a message to be broadcast throughout the system syncronously or asyncronously (and each listener class can decipher this as well since they handle dispatching to each event handler) but I'm still messing with the idea of components being able to broadcast messages internally to themselves without having to go directly through the queue (since some of my events would only be handled by the module generating them).
  10. Torque vs Roll-Your-Own-Engine

    I'm rolling my own engine simply for the learning experience not only with design but cross-platform development (and have hopes of releasing it before year-end as open source ;)). I feel my coding background is strong but my course didn't cover enough of certain topics including design, threading and Linux development just to name a few. If you're looking to learn about engine design as opposed to game design I'd take the path of rolling your own (though you did say you're lazy and designing a large system takes time :)) but if you're just out to develop a game start with a pre-existing engine such as those you mentioned and start designing around that.
  11. Why not just use a try/catch block and implement classes to handle specific error conditions? As far as I'm aware (correct me if I'm wrong) try/catch is part of the C++ standard (assuming you're using C++ but VB/C# also have their own try/catch blocks) and is not tied directly to any platform: try { // problem encountered throw CSomeExceptionClass(); } catch( CSomeExceptionClass var ) { // do something here with the exception class } catch( ... ) { // apparently something happened you weren't expecting but // catch it anyways and handle it as gracefully as you can } As for your question about XML yes it will handle international languages as long as you properly set the encoding in the xml declaration. Just be careful though as the same rules apply when using international languages as when using standard UTF-8 regarding invalid characters.
  12. Multi-Api Render engine

    Something similar to that yes. When my RenderController is initialized it checks configuration and dynamically loads the correct library at runtime (I have an exported function which accepts a pointer to an IRenderDevice pointer). So I have something similar to the following: class IRenderDevice { IRenderDevice( void ); virtual ~IRenderDevice( void ); virtual void SetShader( params required to set shader ) = 0; ... }; class CDX9RenderDevice : public IRenderDevice { CDX9RenderDevice( void ); virtual ~CDX9RenderDevice( void ); virtual void SetShader( params required to set shader ); ... }; class COGLRenderDevice : public IRenderDevice { COGLRenderDevice( void ); virtual ~COGLRenderDevice( void ); virtual void SetShader( params required to set shader ); ... }; When it comes time to use the device in my engine I do something similar to the following: IRenderDevice* pRenderDevice = 0; // code in here to load the DLL dynamically and create the device (will either return a new CDX9RenderDevice() or new COGLRenderDevice() through extern function)... // i only do it through an extern function because of my architecture there's a number of ways to accomplish this pRenderDevice->SetShader( param ); Hope that helps but it will also totally depend on the architecture of your engine and where you house which objects and interfaces.
  13. Multi-Api Render engine

    Quote:Original post by juglarx Hi guys! if a need to do a 3D-engine with multi api rendering support(OpenGl and DX) what is the best approach?. dll interface with the both api implementation is ok i think (myengineOGL.dll and myengineDX.dll) anyone have a cool implementation ( ideas ,101 steps....) of this to share? thanks in advance This is pretty much identical to the approach I'm taking in my engine design. I have a base interface class which the actual implementation inherits from (OpenGLDrv.dll/DX9Drv.dll) and my RenderController dynamically loads the DLL at run-time based on configuration. This should hopefully allow the system to be easily extensible once DX10 is released unless the API goes through a major overhaul but that's my hope anyways.
  14. Quote:Original post by evolutional I've tried a couple of methods. The first using the command pattern similar to the example by Sharlin. This is ok, but the message handler interface becomes HUGE and would require an entire engine recompile if you add new message types. The second method I've tried is the method used in the Game Coding Complete 2 book, where the message and the data are separate and are based off a standard interface class. Effectively, you have IMessage, IMessageData and IMessageHandler (and some util functions to register handlers) - It's up to the coder to correctly cast them to the required types by identifying them on a unique 'type' key. I found this worked pretty well in the system that I used. The way Mike McShaffry defines his types is to take a hash of the string id for it; this is better than having a single include file with all the numeric IDs for the message types as again, it lets you add messages without a full recompile. I found the system worked well for myself to a certain extent but my engine design is modularised so I'm having a hard time figuring out where to define events that inherit from CEvent so that the entire system (or only sub-systems that require them) have access to them without exposing too much of a sub-system to others. I've taken the basic outline and re-worked it in a number of ways including "callback" functions (not sure how to word this in my engine being developed as a single codebase for linux, mac and windows) to handle events rather than the if-elseif format used in the book. As well adding threading makes it much more robust but at the same time creates additional headaches in syncronization and performance. The example definitely proivdes an excellent starting point though and should work exceptionally well as-is for those looking to quickly implement an event based system in a single-threaded, unmodularised environment. While the entire engine is intended to be released as an open-source project I've considered releasing individual portions of the codebase (mainly my foundation classes) as I go which others may wish to just plug into their games/engines rather than using my solution. EDIT: Moe...while you may not be worried about it right now always keep in mind that you may wish to re-use this code at one point or another so it shouldn't be overly dependent on the design of your current project. In a system the size of mine if changing one interface means re-compiling the entire system I may as well go out for dinner while my build machine chugs away...I'm trying to reduce dependencies as much as possible to make the code truly flexible for almost any project :).
  15. I'm currently in the process of designing my game engine which uses an event system to tigger events throughout the engine. I was thinking of posting what I had currently but the design probably wouldn't do you much good...I could however (if I find time this weekend) code up some dummy classes to give you a general idea of what I'm attempting to do but I can't guarantee it would function 100% as I have no system built up around it. Sharlin's post covers off the general idea regarding events and data contained in them so it's definitely a good starting point :). My approach is slightly different and is a multi-threaded system with some of the following classes: CListener --------- Provides a means for the event manager to dispatch events to classes which have registered with it (it being the event manager) as a listener of a certain event. This class contains references to function pointers registered with it as "event handlers" for individual events. The event manager calls CListener::Dispatch( CEvent ) to return an event to the listener class. It is then up to the listener class to route each event to the correct "handler" method which was registered with it earlier. CEventManager ------------- Maintains control of the event queue as well as a list of listeners and their registered events. Being a threaded environment this class also has a means to allow a subsystem to send a message asyncronously (CThreadedEvent class...not getting into this :)) and forget about it as well as syncronously where it waits for the manager to inform it the event has been added to the queue. From here a sepearte thread is executing that periodically checks the queue, grabs the event and dispatches it to all registered listeners. This has to be quick to avoid deadlock on the message queue otherwise events will begin to lag behind. CEvent ------ Provides a container for an event including it's name/ID and data which receiving handlers will require to correctly handle the event. When a subsystem calls Send(A)SyncEvent() it passes the built up event to the event manager directly. There are a number of other classes involved in the system (I think a total of 8 but I'm at work and can't remember) but most of those you don't need to worry about. Like I said...I'll try my best to find some time this weekend to put my design document down and code up a very basic outline of my system NOT including threading related items...it will just complicate things. If not hopefully this explanation gives you a general overview of how things can be handled especially when mixed with Sharlin's example code. I would highly recommend looking into a book called Game Coding Complete - Second Edition if you're looking into getting into your own engine design. It provides some great insight and interesting approaches to problems to get you on the right track. I borrowed some ideas for the event system from this book but have made a large number of enhancements to it to meet the needs of my system.