IKEMEN Direct X

[assemblaj]

IKEMEN Go Direct X Test Build Here: IKEMEN-Go-DirectX-Test.zip

Disclaimer: This is not an official release

This is a test, the purpose being to work out the kinks in the Kinc library (pun intended) for IKEMEN. If you have any issues, please post them as a response to this thread.

Known Issues

• Window resizing causing misaligning of graphics
• Numpad Enter and Enter both functioning as Return
• TTF fonts currently unsupported and causing crashing on startup
• Screenshots not currently supported
• Inability to map buttons to shift keys
• Problems with pad and stick
  • Up and down inverted
  • Left stick jumps
  • Right stick walks forward
  • Lower diagonals walk backward
    The build instructions below are outdated, will update them soon.

---

@samhocevar was kind enough to implement multiple rendering and input backends via the Kinc library. This is an attempt to learn how to make Direct X IKEMEN builds.

Here are the instructions on how to build a Direct X version via the Kinc library for IKEMEN Go from sources:

• Clone the IKEMEN Go repository if you don't already have it

• If you do not currently have Visual Studio (the native application, not VSCode) installed, downland Install Visual Studio Community Edition 2022

• Clone the Kinc library somewhere on your computer

• Run /path/to/your/Kinc/get_dlc.bat via PowerShell or the command line

• Copy the Kinc folder into your IKEMEN directory

• Go to the IKEMEN-Go/Kinc/Sources/kinc/system.h file and add the KINC_FUNC definition to export the kinc_internal_frame function:
  KINC_FUNC bool kinc_internal_frame(void);

• Replace your render_kinc.go, input_kinc.go, and system_kinc.go with these:
  IKEMEN-Go-updated-kinc-files.zip

• Rename the build folder to something else (Kinc makes its own "build" folder and though I haven't experienced a conflict I want to prevent them from happening)

• Make a Shaders folder and copy the shaders from src/shaders into that folder

• Make a Deployment folder (we will find compiled shaders here later)

• Make a kfile.js file with the following code and place it in the IKEMEN Go directory

nst project = new Project('IKEMEN-Go');

await project.addProject('Kinc');

project.addFile('Sources/**');
project.addFile('Shaders/**');
project.setDebugDir('Deployment');

project.flatten();

resolve(project);

• Run /path/to/Kinc/make.bat windows -g direct3d11 in your IKEMEN directory via PowerShell or the command line
• [ The following steps assumes you have bin, bin/save, bin/font/ and bin/external folders as well as a bin/save/config.json file already. If you don't have those yet view our guide on building and compiling]
• TTF fonts are handled by the glfont library which is not compatible with Direct X, because of this, in order to prevent errors, we have to prevent them from being used:**
  • in your config.json file, set the DebugFont to any font.def (found in the font folder) but debug.def or Open.Sans.def or any other TTF based font
  • in your system.base.def file, find every reference to Open.Sans.def and replace it to any font.def but debug.def or any other TTF based font
  • in your motif.lua file, find every reference to Open_Sans.def and replace it with any font.def that is not TTF based
• Open up Visual Studio
• Click "Open a project or solution"
• Select the IKEMEN-Go.sln file created in the build folder of your IKEMEN-Go repository
• Click the solution configuration menu which by default says Debug, Set it to "Develop"
• Right click IKEMEN-Go in the Solution Explorer window
• Select properties
• Set the Configuration Type to Dynamic Library (.dll)
• Click C/C++ > Preprocessor
• Copy and paste the following and add it to the Preprocessor Definitions section before the existing definitions:
  KINC_NO_MAIN ;KINC_DYNAMIC_COMPILE;
• Click "Apply" > Ok
• Right click IKEMEN-Go in the Solution Explorer window and select Build to build the .dll
• Copy the build/x64/Develop/IKEMEN-Go.dll file into the bin directory
• Copy the files from Deployments (should be .frag and .vert shader files) into the bin directory
• Run the following batch script from your IKEMEN build folder

@echo off
cd ..
set CGO_ENABLED = 1
set GOOS = windows
set CGO_CFLAGS=-I/your/path/to/Ikemen-GO/Kinc/Sources/kinc
set CGO_LDFLAGS=-L/your/path/to/Ikemen-GO/build/x64/Develop -lIKEMEN-Go

if not exist go.mod (
   echo Missing dependencies, please run get.cmd
   echo.
   pause
   exit
)
if not exist bin (
   MKDIR bin
) 

echo Building Ikemen GO...
echo. 

go build -tags=kinc -trimpath -v -ldflags -H=windowsgui -o ./bin/Ikemen_GO.exe ./src

pause

Enjoy your Direct X IKEMEN!

[assemblaj]

IKEMEN Direct X build 1:
IKEMEN-Go-DX-Build-1.zip

[assemblaj]

This is a tentative process, this will change eventually as we learn more about the Kinc library and hopefully receive feedback from @samhocevar about our process. This is for development/testing purposes only at the moment.

Before following these steps, you'll need to have completed all of the steps found here before you can compile any Windows IKEMEN Go build from source. Take note of the "includes" directory of your mingw installation. If installed via chocolatey for example, it could be found here:

• C:\ProgramData\chocolatey\lib\mingw\tools\install\mingw64\include
  But you will have to find it on your own system.

Initializing IKEMEN and Kinc Repos

• Download and extract IKEMEN-Kinc.zip. Right click the ikKincInit.ps1 script and select run in Powershell.

Add Kinc to your system includes:

• Copy the Kinc\Sources\kinc folder from the repo into the include directory of your MinGW installation
• Copy the Kinc\Backends\Graphics4\Direct3D11\Sources\kinc\backend folder into the \kinc folder that you just copied

Build the Ikemen-GO Kinc Project in Visual Studio

• Install Visual Studio Community Edition (or a native Visual Studio compatible with your system) if you don't already have it
• Click IKEMEN-Go.sln in the build folder. This will open IKEMEN-Go.sln in Visual Studio
• Click the solution configuration menu which by default says Debug, Set it to "Release"
  
• Right click IKEMEN-Go in the Solution Explorer window > Select properties
  
• Set the Configuration Type to Dynamic Library (.dll)
  
• Click C/C++ > Preprocessor. Copy and paste the following and add it to the Preprocessor Definitions section before the existing definitions:
  KINC_NO_MAIN ;KINC_DYNAMIC_COMPILE;
  
• Click Apply and then OK
• Right click IKEMEN-Go in the Solution Explorer window and select Build to build the .dll
  
• Copy the IKEMEN-Go.dll from the \build\x64\Develop\ directory and the (shader) files from the Deployment directory into your bin folder
• Run the build.bat. This will take a long time at first
• Copy in your content files into your Ikemen-GO/bin folder. Keep in mind, TTF fonts will crash the program immediately. Open Sans (Open_Sans.def / debug.def in the Elecbyte Screenpack was the primary culprit when I first attempted to build.
  • in your config.json file, set the DebugFont to any font.def (found in the font folder) but debug.def or Open.Sans.def or any other TTF based font
  • in your system.base.def file, find every reference to Open.Sans.def and replace it to any font.def but debug.def or any other TTF based font
  • in your motif.lua file, find every reference to Open_Sans.def and replace it with any font.def that is not TTF based

Notes

• This is an experiment and not an official release.
• TTF fonts are not supported by the Direct X build at the moment, because they are handled by an OpenGL based library. Loading TTF fonts will crash the program. Keep this in mind
• ikKincInit.ps1 initializes a fresh repo for Kinc and Ikemen-GO and does not run if it detects existing Ikemen-GO and Kinc repos in the same directory

[RobDangerous]

First step to make this easier - use Kinc/make --help to see the options. Using --dynlib and --compile will directly create a dll without you even having to open Visual Studio. You can use --to to build in something else but "build". Things like creating directories and manually copying files can be avoided by simply doing it in the kfile - the complete node.js API is available for tasks like that.
And please don't shit-talk my work, makes me sad 😢

[assemblaj]

Hey, I'm sorry about that. I was a little emotional because supporting Direct X means so much to us and I wasn't sure if i could make it happen. Now that I understand it better, I see the true power of the Kinc library and appreciate the way it does things. Again, really sorry. I'll edit any inflammatory comments I made.

[RobDangerous]

No worries 👍

[assemblaj]

Screenshots:

Screenshot support is not implemented yet for the Direct X build. When the captureScreen function is called, on the gl build it goes into this function

func (r *Renderer) ReadPixels(data []uint8, width, height int) {
    r.EndFrame()
    gl.ReadPixels(data, 0, 0, width, height, gl.RGBA, gl.UNSIGNED_BYTE)
    r.BeginFrame(false)
}

for the kinc backend this is just a stub

func (r *Renderer) ReadPixels(data []uint8, width, height int) {
    sys.errLog.Printf("STUB: ReadPixels()")
}

ReadPixels is a native OpenGL function, implimenting similar functionality in Kinc could take some time. Luckily, Kinc seems to support a ReadPixels esque function that it actually uses to generate a screenshot in this sample:

static void update(void *data) {
	kinc_g4_begin(0);

	kinc_g4_render_target_t *render_targets = {&render_target};
	kinc_g4_set_render_targets(&render_targets, 1);

	kinc_g4_clear(KINC_G4_CLEAR_COLOR, 0xFF000000, 0.0f, 0);
	kinc_g4_set_pipeline(&pipeline);
	kinc_g4_set_vertex_buffer(&vertices);
	kinc_g4_set_index_buffer(&indices);
	kinc_g4_draw_indexed_vertices();

	kinc_g4_end(0);
	kinc_g4_swap_buffers();

	uint8_t *pixels = (uint8_t *)malloc(2048 * 2048 * 4);
	kinc_g4_render_target_get_pixels(&render_target, pixels);
	if (kinc_g4_render_targets_inverted_y()) {
		uint8_t *inverted_pixels = (uint8_t *)malloc(2048 * 2048 * 4);
		for (int y = 0; y < 2048; ++y) {
			for (int x = 0; x < 2048; ++x) {
				for (int c = 0; c < 4; ++c) {
					inverted_pixels[y * 2048 * 4 + x * 4 + c] = pixels[(2047 - y) * 2048 * 4 + x * 4 + c];
				}
			}
		}
		pixels = inverted_pixels;
	}
	stbi_write_png("test.png", 2048, 2048, 4, pixels, 2048 * 4);
	exit(0);
}

This involves some setup though, like creating and initializing a render target and rendering into that every frame. So I'm not sure how feasible this method is with our current backend, but it's worth a shot. Will try it today and report my findings.

Edit:
This turned out to be another feature that wasn't as straightforward as it looked. When I attempt this, I either get a black screen or the kinc_g4_render_target_get_pixels call returns nothing, making a black image file. The following is what I did :

type Renderer struct {
        ....
	render_target   *C.kinc_g4_render_target_t 
}

func (r *Renderer) Init() {
        ....
	r.render_target = (*C.kinc_g4_render_target_t)(C.malloc(C.sizeof_kinc_g4_render_target_t))
	C.kinc_g4_render_target_init(r.render_target, C.int(sys.window.width), C.int(sys.window.height), C.KINC_G4_RENDER_TARGET_FORMAT_32BIT, 0, 0)
}

func (r *Renderer) BeginFrame(clear bool) {
	C.kinc_g4_begin(0)

	render_targets := (*C.kinc_g4_render_target_t)(unsafe.Pointer(r.render_target))
	C.kinc_g4_set_render_targets(&render_targets, 1)

	if clear {
		C.kinc_g4_clear(C.KINC_G4_CLEAR_COLOR, 0xff000000, 0.0, 0)
	}
}

func (r *Renderer) ReadPixels(data []uint8, width, height int) {
	// Use render target's get pixels function to read pixels
	C.kinc_g4_render_target_get_pixels(r.render_target, (*C.uint8_t)(unsafe.Pointer(&data[0])))
}

[assemblaj]

Edit 3: After thinking it through, dynamic resizing isn't really necessary for a fighting game anyway. Will probably just lock the resize feature on the Direct X build.

With regards to the UI elements getting misaligned on resizing. Kinc has a way to set a resize callback
kinc_window_set_resize_callback. Going to try to call sys.SetWindowSize with the new width and height upon the callback. I doubt it's that simple but this is the first step.

Edit: Tried this, turns out it's not that simple. The problem seems to be that that there are objects who have fields that are initialized by sys.scrrect, sys.gameWidth, sys.gameHeight, sys.widthScale and sys.heightScale (and possibly the Window width and height fields) at the time of their creation, but when the screen size updates, they don't get the updated values.

One way to handle it is to create a Resizable interface for each such object, store them (perhaps in a map) and then call their resize function with the updated values upon resizing. I'm not sure how well our codebase can accommodate such a system, though, because you'd have to be aware of the object's lifetime so they could be unregistered from the map, and I don't know if IKEMEN's object lifetimes for renderable objects are that clear cut.

Another way to handle it is an "Immediate Mode" approach, recalculating all values that use the window related fields at the time of their use. This seems expensive but performance costs are said to be negligible. I'm not knowledgeable enough about our rendering yet to know whether such calculations could be too expensive or what objects would need to have the Immediate Mode applied. Perhaps @K4thos could provide some insight on this. Either way, it's not exactly as big as a priority compared to fixing features that were lost.

I'd say the next steps would be to take inventory of every object that isinitialized by these fields:

• sys.scrrect
• sys.gameWidth
• sys.gameHeight
• sys.widthScale
• sys.heightScale
• sys.window.width
• sys.window.height

Edit 2: I'm not so sure that my theory is correct anymore because a lot of IKEMEN rendering is already 'immediate mode' in a sense with regards to the window.