kaijuengine / kaiju Goto Github PK

This project looks very interesting, but honestly this bit of the README makes me nope out of it entirely.

Every PR will be required to have a video of the development process of that request.

I mean, Oh. My. God. What a nightmare, both for contributors and for the PR reviewers. O.O What do you expect the video format to be like? Are you expecting the entire process of implementing the change to be captured, or just a brief overview? Will there be a requirement for audio commentary? Who's going to edit these things, or are we expected to upload 2-hour videos when implementing a large feature or fixing a big bug?

This expects the base of OpenGL to be done

Currently Windows is working, we just need to do the same thing for the X11 surface.

This should include functions for Vec2, Vec3, Vec4, Mat3, Mat4 and any supporting functions

This does not need to be a fully feature complete window, just one that opens, closes and has the events setup and ready to go.

• Move message handling to window_proc
• Select shared memory by hwnd
  • Can use SetWindowLongPtrA and SetWindowLongPtrA
    • SetWindowLongPtrA(hwnd, GWLP_USERDATA, (LONG_PTR)myPtr);
    • LONG_PTR usrData = GetWindowLongPtrA(hwnd, GWLP_USERDATA);
    • Note that the first couple results from GetWindowLongPtrA will be NULL
• Create a struct to hold shared memory and size
• Write fatal error message string to shared memory
• Error on fatal error from window construction

• Create a project folder given a path and name
• Copy the engine source code into the folder
  • .go files should be prefixed with // Code generated by 'kaiju project'. DO NOT EDIT.
  • Ignore the editor folder when copying
• Create a source folder for developer code
  • Create a blank Main function in the root source folder

This should include basic transformations as well as support for parenting transforms to one another

This should render the classic 3 verts with vertex colors. This means the base vertex layout should be established and the shader cache loading/linking system should be setup.

We only want to bind the shader once and then draw all instance groups after it is bound, this way we're not re-binding an already bound pipeline or re-binding it later after another one is bound (out of order). This should basically just be a structure with a shader pointer and slice of draw instance groups. This also means that the shader can be removed from the draw instance groups.

Currently we are generating and deleting a texture every frame for instance data. This change will generate/regenerate the texture as instances are added to the group and delete the texture when all instances are removed or the group is destroyed.

Yaegi is a Go interpreter. When it loads up it should Eval all go code within the source folder of the project. The [project]/source.Main function shall be called with the system host pointer.

Would you be open to adopting the "standard" project layout to organize the repo? I know that there isn't really a standard layout for golang projects, but this is a pattern than you'll see out in the wild quite often. For instance, docker and kubernetes use this to structure their projects.

I see that you already have multiple applications in mind (runtime vs editor, both windows and linux), and having a single main.go in the repo root doesnt really represent your intention. Currently, the main.go in the repo root looks (to me) like an example of using the Kaiju engine. Using this "standard" project layout, it might look something like this:

The refactor effort would be fairly minimal; just moving some things around. Most of what's in the root of the repo would go into either pkg or internal directories depending on whether you intend for them to be used in an external codebase.

I'm interested to hear what you think about this, and would definitely collaborate and create a video if you opened an issue for this.

This expects Vulkan to be working

Something needs to manage all of the drawings that need to happen. This thing should also make it a little easier for adding things to be rendered.

There is currently a window inside of Host. We'll rather want a container of windows inside of the host and let the container manage all the various windows and their polling.

Currently the rendering code is set int the main.go file for testing. I want to move the rendering off to the correct location and call it as I would in production code. This will also require me to refactor how the rending is handled and change it to instanced rendering.

Currently we need to clean the dirty state of every transform after the render. I want to change the code to set the frame that the transform was dirty on so that it could be checked to see if the transform has been dirty this frame. Then whenever the matrix is requested and the transform is dirty, clean it in that moment and set the frame.

This should just initialize OpenGL and clear the screen on both the Win32 and X11 windows.

This should follow the windows code. This should also refactor the windows code structure to separate C code and share go code.

Host and Entity are core concepts to the engine, so they will be created simultaneously here. The host is the mediator to all systems, and the entity is the identifier to an instance of a transform and other data. Entities are housed within the host mediator.

Setup the kaiju project and give a brief description of the project itself

This expects OpenGL to be working

• Create a go mod file for the project
• Create a build batch/shell script for the project
• Create a .vscode folder with launch Windows/X11 script