Wolf is the base framework for many projects, included but not limited to sib , barf and other real time frameworks.
In order to reduce generated assembly codes, memory issues, bugs and achieve better performance, we need to design it heap-less which means mostly use the stack memory.
The following crate will be tested for benchmarking.

Chrono needs the following features:

• sleep , which should be used instead of std::thread::sleep
• timeout for futures
• timer with cancelation
• timer oneshot

Adjust configuration to have better control over the rust build system.

We have been using dxgi duplication which was written by C++/DirectX11 in Wolf.Streamer.
In the new version of Wolf, I would like to suggest winapi-rs

Check the "XSI" extract models and simulate this order in 3dmax 17

Support QUIC protocol via Quiche

Integrate with lzma via #137

We need to move RAFT protocol from barf project to wolf.

update ignore based on gitignore tool.

https://www.toptal.com/developers/gitignore

Need update rename " model , Lods , bounding boxes , Instances " in layers

Will be implemented based on #136

In Wolf2 we've used uWebSockets which is a fast, simple & secure WebSocket library written in C++17.
In Rust community, this is the current state of permessage-deflate in Rust's WebSocket libraries and it seems Rust does not have a stable WebSocket library yet.

So we have two options:

1. Use cxx for binding to uWebSockets
2. Wait for this pull request

We need a Signal/Slot mechanism same as here.
A good solution for this implementation is crossbeam channels

A library for 3D max models achieve

I used w_hash_make_custom function as following,but compiler didn't go to the callback.

w_mem_pool Pool_memory = w_mem_pool_get_default();

unsigned int w_hash_custom(const char* pKey, size_t* pLen)
{
printf("%s","ok");
return 0;

}
w_hash_custom_fn pHashCustomFunc= &w_hash_custom;
w_hash _hash_make_custom = w_hash_make_custom(Pool_memory, pHashCustomFunc);

Please tell me where is the problem.

At GDC 2015, Naughty Dog presented one of their best Game Engine optimization called "Parallelizing the Naughty Dog Engine Using Fibers".

In wolf 2, we used boost.Fiber & boost.Context in order to provide basic framework for this architecture.

In wolf 3 we have two options:

1. use cxx in order to integrate with boost
2. use may. Note that may-minihttp implemented on top of this framework and ranked No 8 in techempower.

In order to improve safety of wolf, version 3 is going to rewrite with Rust.
We still need some old C libraries such as lz4 and etc. , so we need to integrate cmake with build.rs in order to reuse C projects in wolf

Provide RTSP new frame function for rtsp_server_gst

Add some documentation related to project structure.

We need to migrate to AV1, the latest royalty-free video coding format for video transmissions over the Internet.
For streamer we can use rav1e.

Port RTSP C client to here and provide a rust wrapper over it via cxx

Wolf needs a binding for LuaJIT, including way for calling Lua codes from Rust and vice versa.

Apply dev container to the project for a safe coding environment.

We've used WebRTC for RTSP transmissions over Turn/Stun servers. This was implemented by cpp in the last version of Wolf.streamer. In the new version of Wolf, this feature should be smarter and safer and also should be integrate with RedPanda for better management.

w_process.h is a cross platform header which can be implemented via sysinfo and std::process

We need to link live555 libraries via build.rs
The following steps should be implemented

Check whether local source code & libraries are available in ./deps folder or not
If libs are already available then link them
if repo or libs are not available, clone the source and build it via CMAKE, MAKE or Shell script

Hey, I have some questions. Why Wolf.Engine does not using VMA (Vulkan Memory Allocator)? Or you have so good memory allocator?

port w_game_time for handling frame per seconds and tasks based on high resolution time

Add vscode configuration to the workspace to improve control over the development environment.

In regards to #161 , we need AV1 receiver which will be implemented by FFmpeg ( #153 )

Hi Pooya,

Glad you managed to solve the coordinate system issue with the occlusion culling library.

I took a quick peak at your latest commit and just wanted to mention an issue with the project configuration so it doesn't come back and haunt you later. Basically, you want to set the project default instruction set to your lowest target platform (for example SSE2) and then manually change only the MaskedOcclusionCullingAVX2.cpp file to compile with AVX2.

The reason for this is pretty contrived, and has to do with the new VEX instruction encoding for SSE instructions (https://software.intel.com/en-us/articles/avoiding-avx-sse-transition-penalties) which gives best performance when mixing AVX2 and SSE. As you've configured the project now, the SSE fallback in MaskedOcclusionCulling.cpp will also use the VEX encoding, and ironically this will cause it to crash on SSE machines. This wasn't documented in the library, so I've asked to add an extra #error pragma and some comments to ensure that the project is correctly configured.

Happy coding,
/Jon

For those projects which do not support CMake, we need to build C codes directly in the build time.
Right now our best solution is CC

In branch 2.0 , json and xml files are in the form of c++ API.
Please provide c API if it is possible.

For the first part of porting w_net of wolf 2, we need to implement TCP & UDP protocols via mio and rustls
Make sure check the following examples

In the first version of Wolf, I wrote a GUI based on DirectX11 on Windows, later I decided to switch ImGUI and later our main issue was integrating GUIs controls with Designers.
I've been thinking about Integrating Wolf with Adobe Animate CC for a while, we can use WebKit for reading display lists and draw them with GPU, same as what ultralight and CoherentLabs have done.
Then we don't need to write any UI-UX flow controls, all we need is to export webGL draw functions from Adobe Animate CC to the Wolf.
Another agile solution is egui.

We need a Github action to make our project easy to automate.
We have build.rs which runs some CMAKE and Make files for C/C++ dependencies.

Create RTSP with GStreamer bindings for Rust

We need a plugin for 3dmax in order to store data such as model's comments.

We need lz4 compression.
We could use this crate but it is not up to date, so we can use this solution in order to get the latest code from main repository and integrate it to rust automatically.

If the Screen view of "wolfengine" "3dmax" plugin resize by user , the plugin will crash and "3dmax" unexpectly close ,

Wolf needs a binding for Python, including ways for creating native Python modules and running and interacting with Python codes.
PyO3 is a good option.

The first render engine of wolf was implemented based on DirectX 11 & Windows.
In the second major update of wolf, the render engine was implemented with Vulkan and it was cross platform.
For wolf 3, we have to focus on cross platform solutions such as gfx-rs

Integrate engine with Simplygon

We need to link FFMPEG libraries via build.rs
The following steps should be implemented

1. Check whether local source code & libraries are available in wolf/wolf/deps folder or not
2. If libs are already available then link wolf to them
3. if repo or libs are not available, clone the source and build it via CMAKE or MAKE and then finally link wolf to them

We need a connector for ScyllaDB

According to this benchmark, we still need to use base64 implemented by C language for our stream. If this issue will be resolved then we will have a chance to integrate this project to wolf via this feature.
For alternative solution, we can use base64.rs