GithubHelp home page GithubHelp logo

trillek-team / tec Goto Github PK

View Code? Open in Web Editor NEW
138.0 26.0 21.0 2.21 MB

The Trillek Engine

Home Page: http://trillek.space

License: GNU Lesser General Public License v3.0

CMake 1.08% C++ 54.32% C 44.61%
trillek engine dcpu16 game-engine linux 0x10c tr3200 trillek-engine

tec's Introduction

Trillek Engine C

Github actions RTD docs Code Coverage
Trillek Engine CI Documentation Status codecov

Support

Head onto our Discord for extended support on building and usage.
Discord Shield

Requirements

TEC requires cmake 3.19, a c++17 compatible compiler, and a few libraries GLFW3, GLM, ASIO, Protobuf, GLAD, Lua, Bullet, Dear ImGui, sol3, Spdlog and OpenAL.

The libraries are automatically installed when using CMake and VCPKG manifest mode.

Quick Start

OS Specific first steps

Windows

Potentially Download and install oalinst.zip OpenAL installer and install it.

MacOS

Prior to 11.0.1, run (NOT TESTED): sudo installer -pkg /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg -target /

If bootstrap-vcpkg fails see here for more help

Linux

Install the following. This is a pretty extensive list and may be more than needed

build-essential pkg-config tar curl zip unzip gdb libgl1-mesa-dev xorg-dev libglu1-mesa-dev libxinerama-dev libxcursor-dev

Build Steps

  1. Install CMake
  2. Install VCPK - git clone https://github.com/Microsoft/vcpkg.git
  3. VCPKG_ROOT must be set a an environment variable, to wherever VCPKG was cloned to
  4. Run $(VCPKG_ROOT)/bootstrap-vcpkg.[bat|sh] to setup vcpkg. Use the correct extension for your OS.
    1. [OPTIONAL] $(VCPKG_ROOT)/./vcpkg integrate install
  5. Open the folder in an editor OR see step 6
    1. Visual Studio
    2. CLion
  6. Run CMake
    1. CLI
      1. cmake --preset=ninja-multi-vcpkg
      2. cmake --build --preset=BUILD_PRESET see presets
    2. GUI - This will only configure the project. CLI steps or Open in an editor are more useful.
      1. Set the source folder
      2. Set the build folder. The presets default to builds/CONFIG_NAME e.g. builds/msvc/
      3. Run Configure
        1. Pick the Ninja Multi-config generator
        2. Select Specify toolchain file for cross compiling
        3. The file input should be filled in, but if not point it to $(VCPKG_ROOT)/scripts/buildsystems/vcpkg.cmake
      4. Run Generate
      5. Open generated solution and build the project(s)

In depth

Build Tool Dependencies:

Linux / WSL Dependencies

  • gcc10 g++10 or clang-13
  • build-essential pkg-config tar curl zip unzip gdb
  • libgl1-mesa-dev xorg-dev libglu1-mesa-dev libxinerama-dev libxcursor-dev p7zip-full

Supported editor(s)

  • Visual Studio
  • Visual Studio (CMake folder mode)
    • Change Tools -> Options -> CMake -> General and enable "Prefer using CMake Presets..."
  • Visual Studio Code
    • On Windows you may need to add the CMake bin to the system path, for CTest to work.
  • CLion
    • Not tested, but CMake folder mode should work as expected

Presets

Config:

  • ninja-multi-vcpkg - Ninja multi-build config preset that references the vcpkg toolchain file relative to the VCPKG_ROOT

Build:

  • ninja-multi-vcpkg-debug - Debug configuration build preset that uses the ninja-multi-vcpkg config
  • ninja-multi-vcpkg-release-dbginfo - Release with debug info configuration build preset that uses the ninja-multi-vcpkg config
  • ninja-multi-vcpkg-release - Release configuration build preset that uses the ninja-multi-vcpkg config
  • ninja-multi-docs - Doc build preset with the documentation custom targets

Test

  • test-base - Base test preset that all other tests derive from DO NOT USE
  • ninja-multi-vcpkg-debug - Debug configuration test preset
  • ninja-multi-vcpkg-release - Release configuration test preset

Documentation

Documentation is done via Doxygen for C++ code and supplementary docs must be maintained for the Lua API in docs/.

Engine documentation is generated with the with the ninja-multi-docs build config doxygen target, and is then converted to markdown via doxybook2 with the ninja-multi-docs build config doxybook target.

All documentation is converted to mkdocs format with the ninja-multi-docs build config mkdocs target, and then readthedocs hosts the mkdocs files.

Doxygen and mkdocs files are not committed, but can be generated locally for consumption/validation. Doxybook generated engine docs and all other docs in docs/ are committed.

Documentation Dependencies

  • doxygen 1.9.4
  • doxybook2 1.4.0
  • python 3.10.4 (Earlier version may work, but untested)
  • pip 22.0.4 (Earlier version may work, but untested)
  • pip-tools 6.8.0 (Earlier version may work, but untested)
  • mkdocs 1.3.0 (see docs/requirements)

Readthedocs setup

To generate the python requirements for mkdocs to be used by readthedoc run pip-compile docs/requirements.in in the project root.

Documentation Targets

The following targets can be built when the CMake build preset is set to ninja-multi-docs

  • doxygen - Generates full doxygen docs in doxygen/
  • doxybook - Generates markdown versions of doxygen docs and places them in docs/engine/
  • mkdocs - Generates mkdocs from docs/ in places them mkdocs/

Local Preview

To preview the mkdocs docs locally visit run mkdocs serve, in the project root.

Clang Format

The follow docker script will setup a docker container that will run clang format. docker build -t clang-format-lint github.com/DoozyX/clang-format-lint-action

Windows

Run the following on windows to format all source files in the src dir docker run -it --rm --workdir /src -v ${pwd}:/src clang-format-lint --clang-format-executable /clang-format/clang-format11 -r -i true .

Linux

Run the following on windows to format all source files in the src dir docker run -it --rm --workdir /src -v $(pwd):/src clang-format-lint --clang-format-executable /clang-format/clang-format11 -r -i true .

tec's People

Contributors

adam4813 avatar devaukz avatar dimaguy avatar elantzb avatar eldahl avatar fahlmant avatar jmf avatar joshuamasci avatar meisaka avatar milesrout avatar nicholasnelson avatar ralian avatar shiroy avatar simon987 avatar sonoftheright avatar taneb avatar zardoz89 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

tec's Issues

Console and logging

A quake like console would be nice. Not only would show a log of what the engine is doing (very useful!), But would have a simple command interpreter to execute a few commands or execute LUA scripts; and list/view/edit engine config variables (like full-screen mode, key-bindings, etc..) exactly like what does Quake or Doom consoles.

GLM not checked in cmake

GLM is utilized but never referenced in cmake. Consequently, I'm not sure what version you're using (and it seems some things tec is using are deprecated in the latest version.)

Linux compilation error

I have some errors on linking stage:

../lib/libTEC_LIB.a(physics-system.cpp.o): In function `tec::PhysicsSystem::Update(double)':
physics-system.cpp:(.text+0xd31): undefined reference to `btRigidBody::setMassProps(double, btVector3 const&)'
../lib/libTEC_LIB.a(physics-system.cpp.o): In function `void __gnu_cxx::new_allocator<btCapsuleShape>::construct<btCapsuleShape, float&, float&>(btCapsuleShape*, float&, float&)':
physics-system.cpp:(.text._ZN9__gnu_cxx13new_allocatorI14btCapsuleShapeE9constructIS1_JRfS4_EEEvPT_DpOT0_[_ZN9__gnu_cxx13new_allocatorI14btCapsuleShapeE9constructIS1_JRfS4_EEEvPT_DpOT0_]+0x76): undefined reference to `btCapsuleShape::btCapsuleShape(double, double)'
../lib/libTEC_LIB.a(collisionbody.cpp.o):(.rodata._ZTV23btGImpactShapeInterface[_ZTV23btGImpactShapeInterface]+0x28): undefined reference to `btCollisionShape::getBoundingSphere(btVector3&, double&) const'
../lib/libTEC_LIB.a(collisionbody.cpp.o):(.rodata._ZTV23btGImpactShapeInterface[_ZTV23btGImpactShapeInterface]+0x38): undefined reference to `btCollisionShape::getContactBreakingThreshold(double) const'
collect2: error: ld returned 1 exit status
CMakeFiles/TEC.dir/build.make:137: recipe for target 'bin/TEC' failed
make[2]: *** [bin/TEC] Error 1
CMakeFiles/Makefile2:70: recipe for target 'CMakeFiles/TEC.dir/all' failed
make[1]: *** [CMakeFiles/TEC.dir/all] Error 2
Makefile:149: recipe for target 'all' failed
make: *** [all] Error 2

Specs:

  • Arch Linux x86_64
  • cmake 3.3.2
  • bullet 2.83.6
  • openal 1.16.0
  • glew 1.12.0

Massive use of shared_ptr

Not sure if this project is still active, but going to give my 2 cents anyway.

I know how a programmer feels about C++11, great amazing stuff introduced, better ways of developing software and stuff, but often you don't need those features. Let's say we have a Multiton (not that I like this patter in this context) as a global variable, using a shared_ptr inside it's bad. That's because the map (I don't see any reason to not use unordered_map, tbh) will always own it and even if all other pointers to it are freed the resource won't get freed. This makes the reference count a useless overhead.

The best solution, I think, is to just use a owning ptr, i.e. unique_ptr, and pass around non owning ptr, i.e. raw pointers (or references if you really don't like them).

Or if you feel so you can use weak_ptrs and a custom deallocator (you have to remove weak_ptrs from the map when they aren't needed anymore), but still think about who'll own the memory.

Component packages

This is a method to bundle up several components into an easy to use package. When a package is added to the world all components will be added to the active entity or, If needed, a new entity will be created.

Replace/Fix spdlog or implement a simple logger

Looks that spdlog clash badly with ASIO. ASIO have a higher priority over spdlog, so would be necessary try to fix spdlog or replace it.

List of requisites that should have a logger for us :

  • Multi-thread safe (a lock-free queue ? https://github.com/gabime/spdlog/blob/1bd10957cb47824c0e24859db2bd637e472ab97d/include/spdlog/details/mpmc_bounded_q.h )
  • Lightweight, we not need something with same level of bells and whistles that log4j
  • A way to write simple messages for different levels : errors, warnings, normal output and debug/trace messages.
  • A way to setup the log level output (ie, disable/enable debug and trace messages)
  • Log output to :
    • Errors and warnings should go to cerr (standard error output)
    • Normal and debug/trace to cout
    • All messages go to GUI Console
    • On a future, a way to write logs to a file. Because, when we have a server working, would be nice to read logs to track any issue or problem.
  • Optionally, a simple way to indicate from what class was the log write (errors, warnings and debug/trace), so could be filtered.

GLSL 3.30 is not supported

I have a problem to run TEC (black screen):

Initializing voxel system...
[Shader] Error compiling shader : debug.vert : 0:1(10): error: GLSL 3.30 is not supported. Supported versions are: 1.10, 1.20, 1.30, 1.00 ES, and 3.00 ES

[Shader] Error compiling shader : debug.frag : 0:1(10): error: GLSL 3.30 is not supported. Supported versions are: 1.10, 1.20, 1.30, 1.00 ES, and 3.00 ES

[Shader] Error linking : error: linking with uncompiled shadererror: linking with uncompiled shader
[Shader] Error compiling shader : deferred_geometry.vert : 0:1(10): error: GLSL 3.30 is not supported. Supported versions are: 1.10, 1.20, 1.30, 1.00 ES, and 3.00 ES

[Shader] Error compiling shader : deferred_geometry.frag : 0:1(10): error: GLSL 3.30 is not supported. Supported versions are: 1.10, 1.20, 1.30, 1.00 ES, and 3.00 ES

[Shader] Error linking : error: linking with uncompiled shadererror: linking with uncompiled shader
[Shader] Error compiling shader : deferred_light.vert : 0:1(10): error: GLSL 3.30 is not supported. Supported versions are: 1.10, 1.20, 1.30, 1.00 ES, and 3.00 ES

[Shader] Error compiling shader : deferred_pointlight.frag : 0:1(10): error: GLSL 3.30 is not supported. Supported versions are: 1.10, 1.20, 1.30, 1.00 ES, and 3.00 ES

[Shader] Error linking : error: linking with uncompiled shadererror: linking with uncompiled shader
[Shader] Error compiling shader : deferred_light.vert : 0:1(10): error: GLSL 3.30 is not supported. Supported versions are: 1.10, 1.20, 1.30, 1.00 ES, and 3.00 ES

[Shader] Error compiling shader : deferred_dirlight.frag : 0:1(10): error: GLSL 3.30 is not supported. Supported versions are: 1.10, 1.20, 1.30, 1.00 ES, and 3.00 ES

[Shader] Error linking : error: linking with uncompiled shadererror: linking with uncompiled shader
[Shader] Error compiling shader : deferred_light.vert : 0:1(10): error: GLSL 3.30 is not supported. Supported versions are: 1.10, 1.20, 1.30, 1.00 ES, and 3.00 ES

[Shader] Error compiling shader : deferred_pointlight.frag : 0:1(10): error: GLSL 3.30 is not supported. Supported versions are: 1.10, 1.20, 1.30, 1.00 ES, and 3.00 ES

[Shader] Error linking : error: linking with uncompiled shadererror: linking with uncompiled shader
[Shader] Error compiling shader : deferred_shadow.vert : 0:1(10): error: GLSL 3.30 is not supported. Supported versions are: 1.10, 1.20, 1.30, 1.00 ES, and 3.00 ES

[Shader] Error compiling shader : deferred_shadow.frag : 0:1(10): error: GLSL 3.30 is not supported. Supported versions are: 1.10, 1.20, 1.30, 1.00 ES, and 3.00 ES

[Shader] Error linking : error: linking with uncompiled shadererror: linking with uncompiled shader
[Vorbis-Stream] Can't load file /home/ziggi/build/tec/assets/theme.ogg code 6 : Can't open file

This branch: https://github.com/Zardoz89/tec/tree/bullet_external
OpenGL version 3.0 Mesa 11.0.2 is supported
glew 1.13.0

Lua API needed

The following items need to be exposed to the scripting system in the form of an API, once a scripting system is integrated.

  • Play, Pause, Stop audio
  • Entity interface
  • Edit Velocity
  • Edit Transforms (position, orientation, scale)
  • Event listeners

Attachment points

These are points, in model space, that entities and such (wires) can be attached to, on an entity.

The attachment will consist of the attachment point list and an entity id or similar to track what it is attached to any given point.

These points will be stored in some form of list or vector that can be iterated over in order to find the closest match for example a mouse click.

Wire/connection system

Drawing and updating power and data wires between components that have appropriate ports for said wires.

Depends on #37 attachment.

Clicking on an attachment point that is compatible begins a connection action. Clicking on another compatible attachment point ends the connection action and creates a connection. Canceling the connection action should end the connection action.

This "link" will need to be saved as a component for both entities and have an identifier that describes the target attachment point.

OS X Instructions + CI

We should have a continuous integration build on travis.ci for the OS X build and instructions in the README.

Bullet debug draw

As per a talk with paultech bullet debug draw will be extraordinarily helpful and is quite easy to implement.

"virtual void drawLine( const btVector3 &from, const btVector3 &to, const btVector3 &color );
just interheit from btIDebugDraw"

Global systems container

Actually we are creating all system object on the main and we not are storing it on any place. So if for example another system need to access another system (for example, the whole gui that now are on the main.cpp, could be his own system, and be a editor-gui-system, but need to access to imgui-system), could access this container.

For example on main, we could have a pre-game loop code like :

SystemContainer.init();
SystemContainer.addSystem("os", tec::OS os);
SystemContainer.addSystem("gui",  tec::IMGUISystem gui( ((tec::OS)SystemContainer["os"]).GetWindow());
...

Perhaps we could implement it using multitone and with a ASystem abstract base class for all systems.

GLEW should be replaced

GLEW has several annoying bugs and issues with binary builds. We should replace it with a different extension loader, for example gl3w or glad.

Unit test framework - gtest

Add an unit test framework and the necessary stuff to handle it on cmake.

Cmake should search and use it, but only if is enabled the appropriate option.

I suggest keep using Google gtest, as we have it working on windows/Linux on the virtual computer module and on previous version of the engine.

Default PixelBuffer/Texture

Add a default embed PixelBuffer and Texture, so the engine not crash if there is a missing texture. The default texture could be a checker texture like : https://svn.ict.usc.edu/svn_vh_public/trunk/lib/OgreSDK/media/materials/textures/checker.png or something like this : DooMBuilder missing texture

Could be (Pseudocode) :

On RenderSystem subsystem init :

...
{
  std::uint8_t tmp_buff = {
    #include "default_texture.hpp" // Carmack's trick . Contains a 128x128x1 bytes of monocrome texture data
  };
  PixelBuffer default_pbuffer(128, 128, 8, ImageColorMode::MONOCHROME );
  std::copy_n(tmp_buff, sizeof(tmp_buff), default_pbuffer.LockWrite());
  default_pbuffer.UnlockWrite()
  PixelBufferMap.Default(default_pbuffer);

  TextureObject default_texture(PixelBufferMap.Default());
  TextureMap.Default(default_texture);
}
...

Create proper CMake subprojects

Right now the src directory still contains things specific to the client only, and the build system is very monolithic with one central CMakeLists.txt file in the root directory. We should move the remaining client-specific code to client/, and create client/CMakeLists.txt and server/CMakeLists.txt files that take care of building only the client or the server, respectively.

Building dependancies should be optional in cmake.

Having cmake create projects to build the dependancies should be optional (off by default or at least via some form of check), so those that might already have it built in their system itself won't have to build local copies.

Delta component updates

Instead of just assigning the component to the new value, only data that was changed should be updated. This will prevent loss of state and reduce object creation.

Entity::Update() could take a bitset saying what data was updated and passing that to the component in some useful way. This might require components to provide an update function in the form of a lambda.

Compiler warnings and errors

Whe compiling TEC with gcc 5.x, two compiler warnings related to imgui are shown. In gcc 6.x, those are treated as errors, so this should be fixed soon.

/home/john/Documents/git/tec/client/main.cpp: In lambda function:
/home/john/Documents/git/tec/client/main.cpp:132:125: warning: converting 'false' to pointer type for argument 2 of 'bool ImGui::Begin(const char*, bool*, ImGuiWindowFlags)' [-Wconversion-null]
   ImGui::Begin("Connect to Server", false, ImGuiWindowFlags_NoResize | ImGuiWindowFlags_NoMove | ImGuiWindowFlags_NoCollapse);
                                                                                                                             ^
/home/john/Documents/git/tec/client/main.cpp: In lambda function:
/home/john/Documents/git/tec/client/main.cpp:258:176: warning: converting 'false' to pointer type for argument 2 of 'bool ImGui::Begin(const char*, bool*, ImGuiWindowFlags)' [-Wconversion-null]
   ImGui::Begin("ping_times", false, ImGuiWindowFlags_NoResize | ImGuiWindowFlags_NoMove | ImGuiWindowFlags_NoCollapse | ImGuiWindowFlags_NoTitleBar | ImGuiWindowFlags_NoInputs);

Entity world placing

This involves the ability for a player to add, move, and remove entities to the world.

For this, engine systems will need to handle mouse click events and take appropriate action. Also editing widgets such as a rotation arc ball and translation cross-hair will need to be added as well.

  • Determine mouse click location within world
  • Create new entity at given location with selected properties
  • Add collision check for valid placement
  • Add shader to indicate valid placement

Material picker

The ability to create, modify, and choose from different materials and then apply them on a per-vertex-group basis.

This will be used for players to "paint" entities they place. The material would presumably be in an inventory that players would pick from, click on the target entity, and the server would store the material used by the entity.

Component streaming

For this is work entity class will need a static map for out stream lambdas for each added component. The lambda should take a stream and will allow type erasure so all lambdas can be stored in the same map.

std::map<eid, [] (stream) {}> component_out_streams; // Potential signature

Vitals component

A component that contains vital data for a character including, but not limited to:

  • Health
  • Oxygen level
  • Temperature
  • Heart rate

This component would be used by the scripting system to determine if, for example, the character is alive or dead.

tec::EventQueue needs virtual destructor

In specific dynamic implementations, tec::EventQueue might be stored and freed by anonymous superclass references, resulting in a memory leak unless tec::EventQueue::~EventQueue is made virtual.

View Frustum Culling and other basic graphics optimizations

Actually we not are pruning anything to the render pipeline, and eventually we would need to not throw everything to the GPU rendering pipeline.

A first and easy optimization, is doing a view frustum culling. I have reading about doing it on GPU side with geometry shaders. Other way, is doing a collision test with the physic engine, against a box or a frustum that represents the view frustum, and only send to the GPU, the objects that are inside (I did this with BEPU with C#. But BEPU, have this implemented, so I only need to call the method and get a list of object that I need to render).

Other possible optimization is LOD. Here I have a lecture about using (again) shaders to do it on GPU, but on this case is done on OpenGL 4.0. I don't know if could be adapted to 3.3 : http://rastergrid.com/blog/2010/10/gpu-based-dynamic-geometry-lod/

Also, the voxel rendering need to fuse/prune no visible quads as it would give a abysmal rendering speed boost. I would try to put a lecture that I read a lot of time ago of a guy creating a voxel engine and doing this with a lot of explain of how does it.

Exponential movement slowdown

After moving a certain amount of distance (and/or possibly time), player starts slowing down and almost stops, but then jumps back again after triple stutter.

Edit. Velocity seems to stay the same = 7, so maybe it's server problem ?
Also found another bug if you press D to move right, then pressing A before releasing D will result in a pause right after releasing D; same with W and S.

compiling aborts in vcomputer-system

l updated cmake to 3.2.2 (from there https://launchpad.net/~george-edison55/+archive/ubuntu/cmake-3.x), a cmake version higher than 3.1 should also work, shouldn't it?

Here's the error message:

[ 10%] Built target VCOMPUTER_STATIC
[ 59%] Built target libprotobuf
[ 68%] Built target glfw
[ 73%] Built target Bullet
[ 75%] Building CXX object CMakeFiles/TEC_LIB.dir/src/vcomputer-system.cpp.o
tec/src/vcomputer-system.cpp: In member function 'void tec::Computer::In(const tec::proto::Component&)':
tec/src/vcomputer-system.cpp:39:37: error: 'make_unique' is not a member of 'std'
     std::unique_ptr<TR3200> trcpu = std::make_unique<TR3200>();
                                     ^
tec/src/vcomputer-system.cpp:39:60: error: expected primary-expression before '>' token
     std::unique_ptr<TR3200> trcpu = std::make_unique<TR3200>();
                                                            ^
tec/src/vcomputer-system.cpp:39:62: error: expected primary-expression before ')' token
     std::unique_ptr<TR3200> trcpu = std::make_unique<TR3200>();
                                                              ^
make[3]: *** [CMakeFiles/TEC_LIB.dir/src/vcomputer-system.cpp.o] Error 1
make[2]: *** [CMakeFiles/TEC_LIB.dir/all] Error 2
make[1]: *** [CMakeFiles/TEC.dir/rule] Error 2
make: *** [TEC] Error 2

Add Physics commands

These include commands lime set velocity/gravity, set position/orientation, and disable/enable.

Atmosphere system

A system (could be done in scripting) that dictates the level of oxygen, temperature, etc of a given region. The system would iterate over all entities within its region and modify that entity's vital component to adjust its corresponding stat. E.g if the O2 goes down in the room the entity's vital component O2 stat would decrease.

Packet header and contents sent separately

Technically this is probably fine, but we'll want to use UDP instead of TCP for connecting to the game server as soon as possible and this will obviously break horrifically with UDP.

Client performance is very low

Currently the client uses a lot of CPU power without doing much.
On my system, it uses 100% of one CPU thread.
This is inconvenient especially for mobile systems with batteries, where economical CPU usage matters.

Seg fault on tec::RenderSystem::PointLightPass

From @ziggi on October 3, 2015 20:40 -> issue #58

I got segfault.

GDB result:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000981bbd in tec::RenderSystem::PointLightPass (this=0x7ffffffe4140)
    at /home/ziggi/build/tec/src/render-system.cpp:258
258         size_t index_count = this->sphere_vbo.GetVertexGroup(0)->index_count;

Copied from original issue: #58

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.