Jump to content
  • Advertisement

Pascal Bormann

  • Content Count

  • Joined

  • Last visited

Community Reputation

350 Neutral

About Pascal Bormann

  • Rank
  1. Interesting line of thought Apoch, but is the file structure on the disc really the problem? What if we could afford to write our own IDE to handle all file-related stuff for us?   With a custom IDE, the IDE itself could decide how to map the code written into different files on the disc, ideally without intervention from the developer. Then, the IDE could display a custom "view" on the code in whichever way you prefer. To solve the issue of navigating around and tracing paths through code, maybe it would be possible to generate some sort of "code-flow-graph" that maps the connections between methods or code-fragments in the code base. This could be partially automated (like a recursive call to "Go to definition"), but there still has to be a lot of intervention for more obscure connections, starting with virtual methods (MethodX takes an ISomething and calls a virtual method on it, where does this go to?) and harder-to-trace things like event queues in multithreaded applications or network serialization (Cast fireball? Well we are playing an MMORPG and first have to ask the server if we can do this and then a frame later or something the control-path of "casting a fireball" resumes). This would require some sort of meta-information about the code, i guess similar to the tags that Álvaro mentioned. This is potentially error-prone, just like writing comments, because the meta-information has to be kept in sync with the actual code. But if you were to provide that information during creation of a code-segment, maybe this could be simplified a little. Just as regular code is grouped into modules, upon creation of a new code-element (could be a class or a global function or whatever) this particular code-element could be assigned one or more "domains", like "memory allocation", "unit movement" or "casting fireball". A domain would be similar to a namespace or package, but it maps more directly to "use-cases" in the application and is independent of the underlying grouping of code-fragments.  Then it would be possible to map a code-path for domain "casting fireball" starting from a given point. This could then also be displayed in a single document or in multiple connected documents or whatever is convenient. The domains would also have the positive side-effect of making dependencies between code-pieces easier to track (though I'm sure this is somehow already possible with some tools).  Thinking about it, if you get a new code-base from someone who has worked with this IDE and followed its rules, you would open the project and could display a high-level "domain overview" showing all the different elements of the whole code-base.  The downside would be that version control has to be somehow integrated into the IDE and has to work with the meta-information too.    Could be fun to try out if that would even work or if it is a stupid idea All in all I personally would prefer an approach that lets me work with code without having to deal with how it is stored on the disk instead of creating a new storage scheme
  2. Pascal Bormann

    Thread-safe weak pointers

    Ok maybe a little more info on what I'm acutally doing with the renderer: My company is making CAD software, not games (and I apologize for not pointing that our earlier). I figured there are a lot of similarities at least from the graphics point of view to a game engine, however the one big difference is that the client application (the one using my renderer) is not running in realtime. The principle is more like "Render a frame when something changes or the mouse moves". This makes it so hard for me to assume anything about the lifetime of my resources. There is no fixed point at which the application thread is guaranteed not to do anything, so I'm basically assuming that they can access my resources at any time. So @Andy Gainey, even though what you say sounds very reasonable to me, I'm afraid I can't make any assumptions for the calling application... However, it seems as if the std::weak_ptrs are handling the situation quite nicely. We are currently in the process of implementing my renderer into our existing software, so I was always profiling the client application and my renderer together. Turns out the performance hit of excessive copying came from the client application not passing my resource pointers around as const references. Once I changed this at some places, the cost of copying seemed like less of an issue since there simply aren't that much copies anymore.    To wrap things up: I think Andys way of thinking would solve all of my problems, but std::weak_ptr works well enough that the little performance overhead is neglectable compared to other things like OpenGL driver overhead.
  3. Pascal Bormann

    Thread-safe weak pointers

    So I tried implementing it with std::weak_ptr which makes accessing of the underlying pointer significantly faster, but now copying of the pointers is much slower than before (where I only copied the weak reference index). I'll have to do some more profiling, but it might be that this additional cost is amortized by the gain in access speed. All in all I think your answers have helped me a lot and I also have some more interesting areas where I will look into to see if and how I can optimize further.         In a general game engine that may often be the case, but I'm developing only a renderer, nothing more  Basically only an elaborate abstraction of graphics APIs. Also I'm already at a point where fundamental design changes are not feasible because of too much code that has to change.
  4. Pascal Bormann

    Thread-safe weak pointers

    Thanks for the answers guys std::weak_ptr might just work, I will try this instead of my own crude weak pointer implementation (I guess that's what you get for thinking "who needs STL, I'll just do it all by myself"). The main problem is indeed the cost of the lock, I will also look into the compare-and-swap style approach, thanks for pointing it out Dave!         Thanks for the honest words, and you're propably right with it too. I just remember reading something like "Write your code so that it is hard to use it incorrectly", which I liked as an approach. But no one would propably do something like delete somePtr.Get() without malicious intent, and then he would only harm himself
  5. Hello everybody,   this is my first post here after lurking around for the better part of the last two years, so greetings to all the nice people here   Onto my actual question: I'm currently developing a small rendering engine for the company I work at (so unfortunately I can't post any code, sorry guys...) which is coming along rather nicely, but one topic that I'm unhappy with is handling of the resources for renderer (models, textures, shaders etc.). I rather dislike throwing around raw pointers, especially to clients of my renderer, so I initially thought it would be a good idea to use some sort of weak pointers. For this, I'm keeping all pointers to the raw resources in an internal array and give clients objects that act like pointers by holding and index into the internal array. Now, my renderer is working multithreaded and both clients as well as the renderer itself may create or destroy resources at any time, which means I have to lock access to the internal array. This turned out to be a noticable performance hit, since I basically lock a mutex every time someone calls operator->() on any of those pointers.  So I thought about what my resource pointers should be able to handle: They should abstract the underlying pointer object and disallow clients to mess with them (no "delete somePtr.Get()" or something like that) They have to handle destroyed resources gracefully: The clients are able to free specific resources at any time they want, which should invalidate all pointers to that resource (which is easy with weak pointers, I can simply check if the object at the index exists or not) They have to be thread-safe or better yet don't care about threads at all Access of the underlying objects has to be fast  I thought about smart pointers, but they're not very well suited for explicit destruction of an underlying object. Also, I don't need reference counting. I also thought about just using an object that encapsulates the raw pointer inside itself, but then I would have no way to find out if the pointer points to something valid or something that has already been destructed.   So if anyone has an idea on how to handle this situation gracefully, I would be happy to know  I also appologise if something similar has been asked already, I did only find information on the usual smart pointers online.   Greetings,   Mortano
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!