Jump to content
  • Advertisement

BearishSun

Member
  • Content count

    87
  • Joined

  • Last visited

Community Reputation

555 Good

1 Follower

About BearishSun

  • Rank
    Member

Personal Information

  • Role
    Game Designer
    Programmer
  • Interests
    Design
    Programming

Social

  • Github
    BearishSun

Recent Profile Visitors

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

  1. BearishSun

    bs::framework

    bs::framework is a C++ library that aims to provide a unified foundation for the development of real-time graphical applications, whether games, engines or tools. Highlights Built from the ground up in modern C++14 with a clean user-facing API Lightweight implementations without the crud often found in older, larger solutions Clean, highly modular architecture that can be easily understood, modified and built upon Cross-platform, highly optimized, multi-threaded core capable of running very demanding projects Focus on modern technologies and high-fidelity graphics Fully documented codebase with an extensive API reference Current feature-set includes a wide range of high level systems, ranging from math and utility libraries, to a physically based renderer backed by Vulkan, DirectX or OpenGL, all the way to input, GUI, physics, audio, animation and scripting systems, with asset support for most popular resource formats. Visit www.bsframework.io for more information.
  2. BearishSun

    New C++14 GameDev Framework Released

    bs::framework is a newly released, free and open-source C++ game development framework. It aims to provide a modern C++14 API & codebase, focus on high-end technologies comparable to commercial engine offerings and a highly optimized core capable of running demanding projects. Additionally it aims to offer a clean, simple architecture with lightweight implementations that allow the framework to be easily enhanced with new features and therefore be ready for future growth. Some of the currently available features include a physically based renderer based on Vulkan, DirectX and OpenGL, unified shading language, systems for animation, audio, GUI, physics, scripting, heavily multi-threaded core, full API documentation + user manuals, support for Windows, Linux and macOS and more. The next few updates are focusing on adding support for scripting languages like C#, Python and Lua, further enhancing the rendering fidelity and adding sub-systems for particle and terrain rendering. A complete editor based on the framework is also in development, currently available in pre-alpha stage. You can find out more information on www.bsframework.io. View full story
  3. BearishSun

    New C++14 GameDev Framework Released

    bs::framework is a newly released, free and open-source C++ game development framework. It aims to provide a modern C++14 API & codebase, focus on high-end technologies comparable to commercial engine offerings and a highly optimized core capable of running demanding projects. Additionally it aims to offer a clean, simple architecture with lightweight implementations that allow the framework to be easily enhanced with new features and therefore be ready for future growth. Some of the currently available features include a physically based renderer based on Vulkan, DirectX and OpenGL, unified shading language, systems for animation, audio, GUI, physics, scripting, heavily multi-threaded core, full API documentation + user manuals, support for Windows, Linux and macOS and more. The next few updates are focusing on adding support for scripting languages like C#, Python and Lua, further enhancing the rendering fidelity and adding sub-systems for particle and terrain rendering. A complete editor based on the framework is also in development, currently available in pre-alpha stage. You can find out more information on www.bsframework.io.
  4. BearishSun

    What engines do you use, and why

    I'm working on my own: GitHub I've built a cross platform rendering library that (currently) supports OpenGL, DirectX and Vulkan. Recently it was modernized so it supports features like command lists, pipeline states, GPU queues (async compute, upload) and even explicit multi-GPU. I worked with the guy at the XShaderCompiler project to bring a unified shading language into the engine. Now all the code is HLSL (even for OpenGL/Vulkan) and I wrote some extensions to the language so full material definitions can be specified, as well as some helpful constructs for combining and mixing and matching shaders. All the rendering in the engine is multi-threaded (which seems to be rare or non-existent in other open source solutions). I think I have a pretty clean, mostly automated design when it comes to it, making sure its easy and safe to work with. I've put a lot of focus on making the codebase clean and modular so it is easy to understand and modify. Codebases like UE4 (if you dig deep down into the engine core, where the interesting stuff lives) look like hell to modify, and I wanted something tinkerers & low-level developers like me can easily dig into and modify/experiment with. It's also written from scratch (aside from third party libs) in modern C++14 (I'll also be moving to C++17 modules as soon as compiler/IDE support is better). I used to work with Unity a lot (~5 years) but it ended up being a nightmare for anything that's a slightly bigger project or when we tried to do something out of the box. Primarily because of its closed source nature, as we had to hack around various restrictions and bottlenecks (instead of just changing them at the source). Frustrations with Unity were actually the primary reason why I went with my own engine. I really enjoyed its editor (ease of use, iteration time and extensibility were top notch) and C# scripting but wanted something that is more powerful under the hood, and can be easily modified. I'm currently working on a physically based renderer (80% done), and will be adding Mac & Linux ports (hopefully) by the end of the year. Engine still isn't ready for production use but I strongly believe it offers a better foundation than anything else out there (that I've seen), and hopefully I can grow the feature-set to compete as well.
  5. Indeed, this gets rid of the error and is exactly what I was looking for. Thanks!
  6. I'm getting this error when trying to dispatch a compute shader that does some writes to a 3D texture:   The (shortened) compute shader (full one here): RWTexture3D<float4> gOutputTex; [numthreads(8, 8, 1)] void csmain(uint3 dispatchThreadId : SV_DispatchThreadID) { float3 gammaColor = ...; gOutputTex[dispatchThreadId] = float4(gammaColor, 1.0f); } UAV format is set to DXGI_FORMAT_R8G8B8A8_UNORM. To me this feels like it should work, write as float and the hardware converts it to an 8-bit integer (it certainly works with render targets). And if I ignore the reported error, it does in fact render fine on my machine. Also I'm pretty sure this code ran fine without errors until some recent OS/driver update (but I might be wrong). I can't find anything about this on MSDN or elsewhere on the web. Am I forced to use "uint" in the shader and manually convert from float? Anyone has any insight?
  7. BearishSun

    Banshee Engine (Updated May 2017)

    PROGRESS UPDATE MAY 2017 Engine is nearing first stable release, aimed towards early 2018! New stuff since the last time I posted: Vulkan backend - Vulkan is now fully supported along with DirectX 11 and OpenGL 4.5. A full refactor of the low-level rendering API has been done in order to provide a modern interface that ensures best features of Vulkan can be utilized efficiently, yet still be as simple to use as DirectX 11/OpenGL 4.5. Audio system - Audio system with support for both OpenAL or FMOD, 3D/2D audio, on-the-fly streaming and decompression, and a built-in support for variety of formats like .ogg, .mp3 or .wav. Animation system - Support for skeletal animation with skinning, 1D/2D blending and additive animations. Support for morph shape animation. Support for animation events and IK post-processing. Added built-in animation editor able to animate any script property.  Renderer enhancements - Added support for hybrid tiled deferred / forward clustered rendering. Added support for physically based shading, area light sources, reflection probes with geometry proxies, irradiance maps and more. More renderer enhancements coming over the next few months. C++ documentation - Over a HUNDRED new manuals for the C++ (non-scripting) part of the engine. Includes documentation oriented towards normal users, as well as those interested with tinkering/extending engine internals. Unified shading language - New unified shading language allows you to develop shaders that work on DirectX, OpenGL and Vulkan, while also supporting high level concepts not available in HLSL/GLSL. HLSL syntax (with extensions) ensures it is easy to learn for new developers. Automatic script binding generation - Automatic code generation support for script bindings ensures scripting API can now nearly transparently match the C++ API, as well as opening the door for easy addition of new scripting languages. As always, more information here: https://github.com/bearishsun/bansheeengine
  8. BearishSun

    Banshee Engine (Updated May 2017)

    VERSION 0.3 RELEASED!   New stuff: PhysX integration, with support for colliders, rigidbodies, triggers, joints and scene queries. Full access to the physics interface is provided by the scripting API, as well as integrated into the editor. The physics sub-system was also designed to be extensible, so you can easily add plugins for other middleware like Havok or Bullet without having to modify the user-facing interfaces. Improvements to the renderer, including HDR rendering, filmic tone mapping and gamma correct rendering. HTML documentation for both native and managed parts of the engine. Clang compilation and CMake build in preparation for Mac/Linux ports.   Visit www.banshee3d.com for all the information.
  9. BearishSun

    Banshee Engine (Updated May 2017)

    Yeah I'll be using Doxygen. I just need to group the classes together, and get rid of the chaff - it's very unreadable with a big class list and a bunch of enums and structs that probably shouldn't be there, making it hard for people to focus on what is actually important. I'm in the process of refactoring that a bit, plus I need a better doxygen template because I don't like the default HTML it generates - need to look into that more.
  10. BearishSun

    Banshee Engine (Updated May 2017)

    VERSION 0.2 RELEASED!   New stuff:  - C# scripting  - Extensible editor  - BSL shader language  - Hundreds of bugfixes and improvements to Core   Still a lot more work to do but I'm hopeful most major systems and mac/linux ports will be done by early 2017.   I think I'll be doing more frequent updates from now on, first of which will be PhysX integration in a couple of months, and I'm also hoping to publish the API reference and some manuals as I'm aware that it's pretty hard to get into the source code as it has grown substantially (all methods are documented, I just don't have a neatly organized HTML yet).   Check out the updated feature list, with new media materials (screenshot/video): https://github.com/bearishsun/bansheeengine
  11. BearishSun

    Banshee Engine Architecture - RTTI & Serialization

    It's the same versioning system that Google protobuf uses and from experience it is very simple and easy to work with compared to more traditional methods. Main advantage of it is that it doesn't require code that specially handles older versions - I wanted a very general purpose system that requires only the base definitions from the user and handles the rest, sacrificing a byte per field definition was an acceptable price to pay. Those that do not wish to pay it can use the plain type specializations.   Thanks for the heads up on the string allocation. 
  12. BearishSun

    Banshee Engine Architecture - RTTI & Serialization

    The system does versioning on a per-field basis, not with a single version number, so serialization ends up being a bit more complex than just iterating over the fields. Additionally the system saves/restores references and handles arrays which are all an additional layer of complexity.   These are all the features your "callable" would need to support - and with data transformations it appears I would need many different versions of "callable", each calling the high level code that handles these features, which is messy even if I encapsulate that code as much as possible since I'm relying on the child implementation to do something that should be transparent.   And if I index the fields at application start up then I end up with pretty much the same field layout I have now   You should take a look at "Plain type specializations" chapter. Since you were unaware of the high level features of the RTTI system like versioning in your original post, that is pretty much the system you are describing using templates. It doesn't support the high level features but it's light weight and more customizable. (You can add versioning by adding an extra byte as you say, although I am not a fan of that approach)
  13. BearishSun

    Banshee Engine Architecture - RTTI & Serialization

    Primary uses for this system are versioning, reference restoring and serialization, not just iterating over fields :)   I could have implemented it the way you describe and while it would probably change the structure of the system quite a bit, 95% of it would remain essentially unchanged, just referenced in different places. All that it would really change is that I would no longer hold my field data in a container and instead they would be available implicitly, which feels like a trivial difference to me.   Couple of minor downsides to your approach I can think of are:  - More code generated due to templates since I no longer need one class generated per type, but I'd need NxM classes where N is number of types and M is number of operations I need to operate on the data.  - I can no longer perform quick lookup if a field exists, which is used in versioning a lot. Instead I'd need to iterate all over them to find out.  - Data transformations become hard to do as I'd additionally need to specialize "callable" per parameter name, since some require special operations. This means I need to define the parameter name in multiple places without a way to enforce that.
  14.   I think you are confusing data driven design and data oriented design Data oriented is all about performance (cache misses being a part of it), it's one of the first things it says on one of the pages of the link you posted (quoted below) . Although I think there are semantics to be discussed (My definition of data-driven is what the bitsquid engine guys use. They also mention data oriented, but only when talking about performance and optimizations). Semantics aside, what I was referring to in my original post was purely the "data oriented" design for high performance sake.  
  • Advertisement
×

Important Information

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

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!