Jump to content
  • Advertisement

fleissi

Member
  • Content Count

    4
  • Joined

  • Last visited

Community Reputation

3 Neutral

About fleissi

  • Rank
    Newbie

Personal Information

  • Role
    Programmer
  • Interests
    Art
    Programming

Recent Profile Visitors

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

  1. fleissi

    Custom Game Engine Code Review

    One more thing to note regarding heap allocations: It's not only important to avoid them when rendering, but also ACCESSING heap-allocated memory can be a huge problem. In my engine I have a high-level component called StaticMeshRenderable, and the renderer creates a low-level component wrapper from it that holds pointers to shader and material. For hierarchial view frustum culling, the low-level component accesses the (heap allocated) hight-level component to return the bounding box used for visibility tests. Whereas in the current implementation, the low-level component copies the necessary data in the constructor, so it doesn't have to access the high-level one again during visibility tests and rendering. With this simple change, frustum culling went from ~8 ms to ~5 ms, culling ~4 000 000 meshes, where ~20 000 remain after culling. So memory fragmentation is something to look out for when designing a game engine / renderer, even on a PC.
  2. fleissi

    Custom Game Engine Code Review

    First of all, thanks for your feedback! @R-type: I do NOT use GL types in my common interfaces. I use GLM at certain locations in the code which is a common math library that is not limited to just OpenGL, I use it for DirectX as well. I also wrote my own little math library and defined operators that allow to convert between GLM and my own Vector and Matrix types. @Shaarigan@turanszkij: The dependency stuff is done this way on purpose, because I do not want my repository being convoluted with third party libraries. The best solution is probably to include them via git submodules. Regarding documentation: I also like to put comments above methods that give a short description about how to use them. Then use tools like doxygen to generate the documentation automatically.
  3. fleissi

    Custom Game Engine Code Review

    Thanks, I will definitely follow your advice, and your'e absolutely right when you say that one should measure frame times instead of fps. I did checkout your engine as well some time ago, it's awesome. Can you recommend any resources about global illumination techniques for real time rendering?
  4. Hey guys! I'm new here and I recently started developing my own rendering engine. It's open source, based on OpenGL/DirectX and C++. The full source code is hosted on github: https://github.com/fleissna/flyEngine I would appreciate if people with experience in game development / engine desgin could take a look at my source code. I'm looking for honest, constructive criticism on how to improve the engine. I'm currently writing my master's thesis in computer science and in the recent year I've gone through all the basics about graphics programming, learned DirectX and OpenGL, read some articles on Nvidia GPU Gems, read books and integrated some of this stuff step by step into the engine. I know about the basics, but I feel like there is some missing link that I didn't get yet to merge all those little pieces together. Features I have so far: - Dynamic shader generation based on material properties - Dynamic sorting of meshes to be renderd based on shader and material - Rendering large amounts of static meshes - Hierarchical culling (detail + view frustum) - Limited support for dynamic (i.e. moving) meshes - Normal, Parallax and Relief Mapping implementations - Wind animations based on vertex displacement - A very basic integration of the Bullet physics engine - Procedural Grass generation - Some post processing effects (Depth of Field, Light Volumes, Screen Space Reflections, God Rays) - Caching mechanisms for textures, shaders, materials and meshes Features I would like to have: - Global illumination methods - Scalable physics - Occlusion culling - A nice procedural terrain generator - Scripting - Level Editing - Sound system - Optimization techniques Books I have so far: - Real-Time Rendering Third Edition - 3D Game Programming with DirectX 11 - Vulkan Cookbook (not started yet) I hope you guys can take a look at my source code and if you're really motivated, feel free to contribute :-) There are some videos on youtube that demonstrate some of the features: Procedural grass on the GPU Procedural Terrain Engine Quadtree detail and view frustum culling The long term goal is to turn this into a commercial game engine. I'm aware that this is a very ambitious goal, but I'm sure it's possible if you work hard for it. Bye, Phil
  • 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!