It needs an implementation for `free_texture` in 4ed_metal_render.mm (like `get_texture_of_dim`, and `fill_texture`).
We also need to make sure that the texture (`handle` parameter in get_texture_of_dim and fill_texture) is not zero as the original fix expect 0 to signify "invalid texture". More specifically in `4ed_font_provider_freetyp.cpp` there is `if (texture) { fill the texture }`
and in `4ed_font_set.cpp` there is `if ( slot->face->texture != 0 ) { graphics_free_texture(...);}`
Added "code/" in the string that point to the generator so it's easier to find the correct files.
Regenerated the 4 affected files (just to update the comment string).
The crash is caused by dereferencing a invalid pointer to a texture. The D3D11 renderer as a arbitrary limit of 32 textures (there is normally no reason to have more than 2 or 3 textures in 4coder) because it needs to keep track of a few pointer in its state, while OpenGL doesn't (it just uses the id returned by `glGenTexture`). The code that recreate the texture atlas when changing the font size, never frees the previous texture, so both DirectX and OpenGL are leaking texture.
So this fix just frees the previous texture after 4coder successfully creates a new one. If for some reason the new texture can't be created, we continue using the last one. This is better than crashing as we can still use 4coder, but since we can't change font size anymore the editor might be stuck with a uncomfortable font size.
Unfortunately 4coder doesn't expose a way to delete texture outside the platform layer, and the font size code is not in the platform layer. So I had to expose a `free texture` function, which lead me to understand how 4coder generates API in the `generated` folder.
I updated the README to keep that information somewhere since it's not clear from the get go. The basic idea is that there are a few files that you can compile as a small standalone program and run to generate the files. For the graphics api, you need to compile `4ed_graphics_api.cpp`.
I took some time to also modify a little the generator so that the generated file contains the name of the file that generated them, and added a bit of indentation to make the file a bit more readable (even if we're not supposed to modify them).
win32_keycode_init only initialize 30 KeyCode_Ex values (0 to 29) as the code generating the enum only generates that amount (explicitly loops from 0 to < 30).
Fixed duplicated entries in 4coder internal clipboard (Fix from VDK on the 4coder discord).
Removed the unnecessary loop that was there to try to fix the clipboard missing entries (which was fixed previously by removing the `next_clipboard_is_self` variable).
Up until now, several keys were assigned the same key value because the `keycode_lookup_table` array wasn't properly initialized. The values at the end of the array were all set to `KeyCode_Ex0 + 1` which is 112. This would cause several key to be treated as the same key.
In my case the key next to the left shift key ( `<` and `>` on AZERTY) was getting the same value as the `Right Windows key`. But I suppose that the left and right windows key would get the same value too (I can't check this as I have only 1 windows key on my keyboard).
This fix just properly initialize the array. I also fixed a typo in a function name: `keycode_physical_translaion_is_wrong` => `keycode_physical_translation_is_wrong`.
Changed how DXGI factory is handled. I retrieve the one associated with the current DXGI device and adapter instead of creating a new one.
Fixed missing new line in the log at 1 location.
While debugging an issue with the dx11 backend, I noticed that 4coder only clipped rectangles that are outside the screen vertically. Another potential issue (it might be the intended behavior) causes some things to not work with line wrapping, which means that we could have very long horizontal lines, causing a lot of vertices being sent through the render pipeline that will just be clipped after the vertex shader. This causes higher than necessary GPU memory usage, and low performance for things that aren't rendered in the end.
An example of problematic is:
```c
u8 data[ ] = {0,0,0,0,...,0}; // With a lot of zero, and no space between them.
```
This fix just checks that at least one vertex of each rectangle we try to draw is in the screen. It would be better to use the current clip rect, but it's not available at that point in the pipeline. If we want we can modify the API a little to pass it down, as a parameter to those functions.
Using RenderDoc, I saw the vertex count going from over 500K to 13K with this change, and the performance were from 57ms to 25ms. So perfs are not great (but still an improvement), but testing the bounds of 500K vertices is not free. Fixing the line wrapping issue would probably help getting back to reasonable frame rate.
code/platform_win32/win32_4ed.cpp:
- Modification to be able to choose between OpenGL and DirectX. You choose between the two by defining WIN32_DIRECTX macro. If you don't define it it uses OpenGL.
- Note that win32_gl_create_window and other part of the file that depend on OpenGL or DirectX have been moved to win32_opengl.cpp and win32_directx.cpp.
- Fixed os_popup_error using the title as the message and the message as the title.
code/platform_win32/win32_opengl.cpp: Contains previous code that was in win32_4ed.cpp.
code/platform_win32/win32_directx.cpp: Code for creating a DirectX window and context.
code/platform_win32/4ed_directx_render.cpp: Imlementation of the 4coder renderer using DirectX.
To see the issues, you can set the font atlas size to 128 * 128 by changing line 325 "ft__bad_rect_pack_init(&pack, V2i32(1024, 1024));" to "ft__bad_rect_pack_init(&pack, V2i32(128, 128));".
The first issue was that the max_dim.y parameter was not respected. The dimension produced would always grow on Y to accommodate for more characters. And so the whole texture array thing was never use.
A second issue was that when a character didn't fit on the x axis, we created a new line, but never check that the new line fitted in the current texture slice.
A third issue was that when we ended a line because a character didn't fit vertically, we grew the line with a line height equal to the height of the character that didn't fit.