mindty-kollektiv / tdme2 Goto Github PK

I have never used any 3D engine before, and I'm a bit lost, i think providing examples of programs using the engine would help people like me to understand how the engine works.

No skinned mesh objects are displayed using GPU skinning on AMD hardware using Windows 10.

This is strange. While GPU skinning works with Vulkan on Windows 10 it does not using GL4.3+
Need to investigate.

To be able to port the engine quickly from JAVA to C++, we decided for several reasons to pass std::array and std::vector with pointers instead of references when calling methods.

In a C++ manner you would rather pass with references.

So if interessted look in src/**/* for std::arrays, std::vectors beeing passed as pointers instead of references in methods and change it to references. If also appliable you could apply some constness.

JAVA does not support operators. C++ does.

Implement operators for tdme/math/*, e.g. Vector3
All the math is in place by inline methods and should even just be called when implementing operators.

The build system could use some improvements like:

• like building tools in a tool lib archive as a game does not need to include tools
• ext objects are created in top level "obj" path, whereas "src" is not and retains its sub folders
• maybe its feasible to also support creating dynamic libraries, not sure yet

The Makefile can be much shorter and more readable.

This is my test node issue.

There seem to be some getters that return pointers of STL containers like vector and map.
As long as the container is always backed and the method never returns nullptr I like
to have it changed to returning references as this seems to be the most common practice.

You can see those methods by using the following grep queries

• grep -Enr 'vector<[A-Za-z0-9*&]+>* get[[:upper:]]' src/tdme/*
• grep -Enr 'map<[A-Za-z0-9 ,&]+>* get[[:upper:]]' src/tdme/

Please be careful though as assignments then means copying if not using reference operator like:

In most cases you do not want:
auto vertices = group->getVertices();
But:
auto& vertices = group->getVertices();

Thanx @mahula

To get rid of the following messages it would be nice to remove dynamic exception specifications while making sure exceptions are mentioned as doxygen tags.

Example:
src/tdme/os/filesystem/FileSystemInterface.h:144:59: warning: dynamic exception specifications are deprecated in C++11 [-Wdeprecated]

Mouse events will be consumed twice if clicking on floating node on top of a normal node.
So if there is a dropdown(which is implemented using floating nodes) and you click on a element and there is a button below 2 action events are delegated.

i follow the step (Building how to.md 1.6)
but i couldn't find exe file... only 2 exe file found at tools folder...

VorbisDecoder uses standard C functions to load data from disk. This should be changed the way that it uses os:filesystem::FileSystem.

The portable code for atomic adds looks like the following

	#if defined(_WIN32) && defined(_MSC_VER)
		uint32_t clientId = InterlockedIncrement(&clientCount);
	#else
		uint32_t clientId = __sync_add_and_fetch(&clientCount, 1);
	#endif

This kind of code is somehow spread a little into TDME2 and should be replaced by a static inline method of a new class in os/threading.

J2C moved constructors and destructors to the bottom of class declarations in header files.
They should be moved back to the top.

If you have questions please ask.

@mahula will be working on this.

Lighting seem to be broken in rendering when using older OpenGL implementations.
E.g. Haiku and NetBSD use MESA 10.x.y and Lighting is broken.

I checked if uniforms are set properly and could not find any error. Still something seem to go wrong in shader whereas compiling and linking do not fail.

If interessted check this video to see how the tests should look like:

• https://www.youtube.com/watch?v=2_24_NEdc0w&feature=youtu.be

Your project is building fine on MSYS2 MINGW64 on Windows 8.1 64 bit. Don't be a MSVC-only project!

Hi,

Performance can be improved by changing the following in network module:

./udpclient/UDPClient.h:157:    typedef map<uint32_t, Message> MessageMapAck; --> typedef map<uint32_t, Message*> MessageMapAck;
./udpclient/UDPClient.h:166:    typedef map<uint32_t, SafeMessage> MessageMapSafe; ---> typedef map<uint32_t, SafeMessage*> MessageMapSafe;
./udpserver/UDPServerClient.h:166:      typedef map<uint32_t, Message> MessageMapSafe; ---> typedef map<uint32_t, Message*> MessageMapSafe;
./udpserver/UDPServerIOThread.h:55:     typedef map<uint32_t, Message> MessageMapAck; ---> typedef map<uint32_t, Message*> MessageMapAck;

Please keep in mind, if you add stuff to those maps then you have to release memory eventually also.
Also favoring unordered_map instead of map could help.

You could also benchmark at the end both versions.