GithubHelp home page GithubHelp logo

rbfx / rbfx Goto Github PK

View Code? Open in Web Editor NEW
737.0 50.0 128.0 336.38 MB

Lightweight Game Engine/Framework in C++17 with WYSIWYG Editor. Experimental C# bindings.

Home Page: https://rebelfork.io

License: MIT License

Batchfile 0.13% Java 0.03% CMake 2.58% C++ 86.31% Objective-C 0.05% GLSL 1.69% Shell 0.28% Makefile 0.01% C# 3.14% Python 0.27% HTML 0.26% SWIG 5.25% Dockerfile 0.01%
game-engine 3d-engine urho3d csharp imgui hot-reload 3d-graphics cpp17 desktop directx-11

rbfx's Introduction

Build Status Discord Chat Support on Patreon

The Rebel Fork aka rbfx is an indie game engine/framework. It is an experimental fork of Urho3D game engine distributed under MIT license.

The Rebel Fork is:

  • Free and Open Source Software, and it will stay this way;
  • Suitable for 3D games and applications;
  • Moderately lightweight and modular;
  • Supported for Windows, Linux, MacOS, Android, iOS, Web and XBox (via UWP);
  • Just a C++ library with a couple of tools;
  • There are optional experimental C# bindings.

Note: The Framework is not yet released and is undergoing active development. Backward compatibility is (mostly) preserved on resource level, but C++ API is prone to changes.

Using the Framework

There are two template projects that you can use as example.

Empty Project is the absolute minimum of code that is required to get things running on Desktop platforms. Check it out if you don't care about recommended high-level workflow and want to do things your way.

Sample Project demonstrates recommended workflow which enables certain high-level features like writing your code once and then running it both from Editor and standalone. Sample Project is also Mobile and Web friendly and is deployed to itch.io.

Building the project is usually straighforward on Desktop platforms: standard CMake configure and build. On Mobile and Web platforms extra steps may be needed. If you cannot figure it out, check how our GitHub Actions are configured. Chech documentation for more information.

Supported Platforms

Graphics API/Platform Windows UWP Linux MacOS iOS Android Web
Direct3D 11.1
Direct3D 12
Vulkan 1.0 ✔* ✔*
OpenGL 4.1
OpenGL ES 3.0
WebGL 2.0

(*) Vulkan is supported on MacOS and iOS via MoltenVK. Additional setup is required.

Links

Reasons to use

There are multiple game engines out there, both proprietary and free. Here are some reasons why you may want to try this one:

  • It's "code first" framework with full control over code execution, unlike Unity-like game engines with "IDE first" approach and script sandboxes.

  • It's portable and relatively lightweight framework that can be used like any other third-party dependency, unlike huge mainstream game engines.

  • It's a fork of the mature and stable Urho3D engine (which was released in 2011), so it's more feature-rich and well tested than many of the new non-mainstream game engines.

  • If you already use Urho3D, you may want to try this framework if you like Urho3D but you are not fully satisfied with current Urho3D feature set.

Reasons NOT to use

Don't use the Framework if:

  • You are not ready to do your own research. Due to small community size, we don't have as much documentation, tutorials and other onboarding materials. Consider using mainstream engines with bigger communities.

  • You are not ready to write code when you need some feature. Due to small community and maintainers team size, we don't have as much "ready to use" codebase. Consider using mainstream engines with user store and ready-to-use assets.

  • You want to have cutting-edge graphics or technology for AAA game. We try to provide decent level of technology, but we don't aim to be on the level of AAA graphics fidelity. Consider using commercial mainstream engines backed by paid full-time developers.

  • You are happy with Urho3D. This framework is not intended to be a replacement of Urho3D. Consider using U3D or Urho3D.

  • You want C#-oriented Urho3D. While this framework does have C# bindings, C# is not a first-class citizen here and its support is lacking. Consider using Urho.Net.

Screenshots

rbfx's People

Contributors

1vank avatar alexparlett avatar arnislielturks avatar aster2013 avatar cadaver avatar cosmy1 avatar darwikey avatar enhex avatar eugeneko avatar friesencr avatar gleblebedev avatar hjmediastudios avatar iainmerrick avatar juj avatar konstantintomashevich avatar lumak avatar mike3d avatar monkeyfirst avatar ninjastone avatar orefkov avatar plasmadev5 avatar predatormf avatar rokups avatar superwangkai avatar svifylabs avatar szamq avatar thecomet avatar trevorcash avatar urho3d-travis-ci avatar weitjong avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

rbfx's Issues

Editor fails to build

Using the Following Cmake Configuration with Visual Studio 2017 (Commit: 5017f64):
-- Runtime SHARED
-- Library STATIC
-- SSE ON
-- 2D ON
-- IK ON
-- Threading ON
-- Navigation ON
-- Network ON
-- Physics ON
-- Samples ON
-- WebP ON
-- CSharp OFF
-- MiniDumps ON
-- Developer options:
-- Packaging ON
-- SystemUI ON
-- Logging ON
-- Profiling OFF
-- Extras ON
-- Tools ON

image

How to compile this editor?

I love this editor very much,
I used win7 + vs2015 compile this project ,but can not find engine editor? can you help me how to compile this engine editor? is this project need NET 4.7 ?

Project Management landing window

When opening the engine you are shown a blank window with no information on what to do. For many people this may look like the engine is broken, especially if they don't spot the file tab.

I feel it would be good to provide a window to create and manage existing projects. To help demonstrate what i have in mind and to maybe provide a starting point for further discussion i have created a quick mockup (im no artist)

landingpageMockup

Terrain does not render in web builds

Error: WebGL warning: linkProgram: Programs with more than 16 samplers are disallowed on Mesa drivers to avoid crashing. 19_VehicleDemo.js:1:305249
Error: WebGL warning: drawElements: The current program is not linked.
19_VehicleDemo.js:1:299032
[2019-05-03 16:13:25.350] [main] [error] Failed to link vertex shader TerrainBlend(DIRLIGHT PERPIXEL SHADOW) and pixel shader TerrainBlend(AMBIENT DIRLIGHT PCF_SHADOW PERPIXEL SHADOW SPECULAR):

Getting re-create directory failure.

From @TrevorCash on April 4, 2018 23:43

GetSubsystem<FileSystem>()->RemoveDir(dir, true);
GetSubsystem<FileSystem>()->CreateDir(dir);

This code will fail for me on my windows machine if the directory already exists.

The directory is removed. But the directory is not created again, I get a failed to create directory message from Urho.

The directory is in the users documents directory. I am on windows 10 64bit.

Copied from original issue: urho3d/urho3d#2296

Crash-proof play mode

The problem

At the moment editor plays scene in same process. This has several undesired side-effects.

  • Scene inevitably uses user code. A mistake means editor crash.
  • Input handling is designed around the concept that game owns input while in editor we want to switch between scene (optionally) having input lock and and editor processing input.

Goal

Goal is obviously a solution to both problems above. While input problem could be solved with a larger refactor, crash problem is hard to contain. Especially since user will be using C++. The only sensible solution in this case is to allow crashes by putting game simulation into a separate process. For best user experience we also want to maintain display of game simulation in a tab in the editor.

Multi-process architecture problems

As with everything - putting game simulation in a separate process presents bulk of issues on it's own.

Loading time

New process has to load game assets from the disk. It will be slow in larger processes. This can be alleviated by having ResourceCache use allocator which uses shared memory. Memory would be shared with game process thus speeding up loading process.

Input and log forwarding

Input from editor has to be forwarded to subprocess. We also would like to see any logs from subprocess forwarded to the editor for display. This could be done relatively easily using shared memory approach.

Display of simulation

This is probably most complex problem. We have to embed rendered result of subprocess into editor tab. There are few options.

  • Use os-native APIs to embed actual window in editor window. This has a downside that tab resizes will inevitably be slow and look bad. This is also not trivial because subprocess window has to become a child of imgui window and that requires implementing first.
  • Use shared memory to copy [subprocess(GPU)]->[shared memory]->[editor(GPU)] on every frame. This will definitely result in reduced framerates. By how much - this is an unanswered question.
  • Spawn game simulation in a separate window and call it a day. By far the simplest solution.
  • Render game simulation into a texture and use OpenGL/DirectX resource sharing to share this texture with the editor for display. It is unclear if this is possible, but if it is - it would be most efficient approach that allows us to keep the illusion execution within editor.

Restoring NuGet packages from VS fails.

Fails with following error:

Error occurred while restoring NuGet packages: '$(NETStandardImplicitPackageVersion)' is not a valid version string.

Workaround: restore packages from command line by running msbuild Urho3D.sln /r or using Makefile.cmd to generate CMake build directory.

Makefile.cmd

In Makefile.cmd msbuild Urho3D.sln /t:restore
Urho3D.sln renamed to Urho3D.part.sln

And next error on build:

Studio/2019/Community/VC/Tools/MSVC/14.20.27508/bin/Hostx64/x64/cl.exe -- works 
-- Detecting CXX compiler ABI info 
-- Detecting CXX compiler ABI info - done 
-- Detecting CXX compile features 
-- Detecting CXX compile features - done 
CMake Error at CMake/Modules/UrhoCommon.cmake:350 (message): 
  sn coild not be found. 
Call Stack (most recent call first): 
  CMakeLists.txt:36 (include)

Fixed Update Rate Option For Engine

Sometimes its nice to have a fixed update rate instead of specifying min and max fps. This is especially true if you want accurate physics. physics engines require update rates that are constants. I have been running on modified Engine code that uses fixed timing for a long time now.

cr.h on OSX?

Has anyone had any success using cr.h on OSX? From the repo, it sounds like it is doable, and there actually is an osx branch, but I have not been able to get it working.

Editor Suggestion: Add the ability to reference an existing node as a "prefab"

Adding the ability to load in a seperately saved node file in "Prefab" mode. whereas multiple prefabs from the same file can be loaded - and a change to one will issue the same respective change to the other prefabs. Nodes that are in "Prefab" mode could be marked somehow in the hierarchy so that it is obvious to the user that a change to one will effect the others.

This may not really be possible with the current architecture I don't know. The editor would have to be smart about it.

Is this runnable on the hololens?

The urhosharp implementation provides a binding for hololens, and a StereoApplication class that extends Urho.Application.

Just wondering if anyone has this running on a hololens, and if so, what is the pathway to do it?

RemotingException when loading plugin or closing editor

Object '/dc463179_9123_4101_befd_c33c8c591123/eto5muvjapabdbjee9yxcirh_3.rem' has been disconnected or does not exist at the server.
   at EditorHost.DomainManager.LoadPlugin(String path)
   at EditorHost.Program.CommandHandler(ScriptRuntimeCommand command, IntPtr args)
   at Urho3DNet.Urho3DPINVOKE.Application_Run(HandleRef jarg1)
   at Urho3DNet.Application.Run()
   at EditorHost.Program.Run(String[] args)
   at EditorHost.Program.Main(String[] args)

BGFX - Metal backend

Due to depreciation of OpenGL/OpenGLES by Apple in the coming release.
I would like to use your bgfx branch as a reference to create a viable solution for a Metal support on iOS/MacOS .
If succeeded I will share it with all the Urho3D users .

Are you OK with that ?

Editor Suggestion: Separate Actions: "Revert Scene", "Pause Scene", and "Take Current Scene State"

Sometimes it may be nice to play the scene forward in time and then take the current state as the new "master" state. consider playing a physics simulation where you want to simulate alot of objects falling into their natural place and then saving the scene right at that moment.

The "Pause" button does not just pause but also reverts the scene.

One solution would be to have separate buttons visible when the editor is playing.

  • "Pause Scene" (only pauses)
  • "Revert Scene" (reverts the scene to state right before the play button was hit, also exits play mode)
  • "Take Scene" (saves the current scene state and exits play mode)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.