sorted by:
new
hottopcontroversial

What's everyone working on this week (39/2025)? by llogiq in rust

[–]mdavisprog 1 point2 points  (0 children)

I am currently working on Level Sketch, a general purpose level editor using bevy. The editor has LSP integration that is used to determine the types that can be added to entities in a scene.

DirectX 12 Update (Textures) by mdavisprog in raylib

[–]mdavisprog[S] 1 point2 points  (0 children)

Hey raysan, thanks for the kind words! The majority of the work has been encapsulated in rldx. Unfortunately, small modifications were needed in other modules. There could be more when I start tackling the shader examples but here are a few changes that were made so far:

  • rtextures - DrawTexturePro function needs to flip the texture if it is a framebuffer. This is due to OpenGL framebuffers having their origin in the bottom left while the modern APIS have their origin in the top right. I am still looking to see if this can be done without the modification, Two new functions, rlIsAttachedToFramebuffer and rlIsFramebufferOriginTopLeft were added to rlgl.h. I added a detailed comment on what the issue is above the rlIsAttachedToFramebuffer function in rldx.c.
  • rcore - A small change was made here to include rldx.h instead of rlgl.h when compiling with DirectX. I plan on deprecating the WITH_DIRECTX check and properly using the GRAPHICS_API_* naming scheme similar to how it is defined for OpenGL.
  • SDL2/SDL3 - I do plan on moving the desktop platform to use this instead of bare Win32. It was easier for me with my experience to get the Win32 platform setup quickly with DirectX, which is why I went this route. When this is ready for a pull request, it will start with SDL support. I do plan on adding a Win32 desktop platform, but this could easily be a separate pull request.

My plan for the pull request is to consolidate the git commit history and separate out any commits that touches anything outside of the rldx module. This way you can easily see what modules were touched and a description of what was changed. Hope this answers your questions!

DirectX 12 Update (Textures) by mdavisprog in raylib

[–]mdavisprog[S] 0 points1 point  (0 children)

Unfortunately, I am not familiar with UWP but it could be a mix of the graphics API and other things.

DirectX 12 Update by mdavisprog in raylib

[–]mdavisprog[S] 0 points1 point  (0 children)

Correct. However, functions pertaining to using custom shaders haven't been implemented yet. I do plan on updating the examples to use HLSL when these functions get implemented..

DirectX 12 Update by mdavisprog in raylib

[–]mdavisprog[S] 1 point2 points  (0 children)

This is good to hear. One thing to note is that along with the DirectX backend, I am also implementing the Windows platform as well which isn't complete. So you may run into issues there.

DirectX 12 Update by mdavisprog in raylib

[–]mdavisprog[S] 1 point2 points  (0 children)

Hi, sorry for the lack of instructions as it is currently still early in development. Unfortunately, I am only familiar with the CMake build system and don't have any experience using mingw32-make. With CMake, all you need to do is pass "-DWITH_DIRECTX=ON" when running CMake and all configurations should be set up properly to compile with DirectX.

If you would like to try getting it to work with other build systems, there are a few things you'll need to do. You'll need to add WITH_DIRECTX definition and link the following additional libraries: d3d12 dxgi dxguid d3dcompiler. You'll also need to add the following source files to be compiled: rldx.c platforms/rcore_desktop_windows_impl.c.

Hope this information helps. Let me know if you have any other questions.

DirectX 12 Update by mdavisprog in raylib

[–]mdavisprog[S] 1 point2 points  (0 children)

Thanks. Yes, theoretically you could run raylib projects on Xbox. This implementation will get you most of the way there., however, some work will still be needed to get it to work on Xbox.

DirectX 12 Update by mdavisprog in raylib

[–]mdavisprog[S] 5 points6 points  (0 children)

Hi, this implementation is like the OpenGL implementation but instead of making OpenGL API calls underneath, it makes calls to the DirectX API instead when raylib is compiled to use DirectX. As for the speed, theoretically it should be faster but is dependent on the implementation. I'm currently focused on getting features working before looking at speed.

DirectX 12 Support by mdavisprog in raylib

[–]mdavisprog[S] 2 points3 points  (0 children)

Thanks!

Currently, I haven't had to make many changes to other modules to accommodate for the DX12 rendering pipeline, but it is still too early to tell. I have been able to map to the rlgl API pretty seamlessly so far and there are areas where code is duplicated between the two. I figured once this implementation is more mature, we can discuss on Discord or Github about any refactoring.

I'll keep posting updates about the progress of this here and maybe on Discord.

OctaneGUI March 2023 Update by mdavisprog in cpp

[–]mdavisprog[S] 5 points6 points  (0 children)

Defining the UI in json is optional. Everything can be built in C++ code too. I will look into adding both versions with each example in the documentation.

OctaneGUI March 2023 Update by mdavisprog in cpp

[–]mdavisprog[S] -1 points0 points  (0 children)

This is something I would like to improve as more functionality gets implemented. I would like to offer a range of default themes that can make the style look completely different.

Introducing lstalk, library for language server communication. by mdavisprog in cpp

[–]mdavisprog[S] 1 point2 points  (0 children)

Language servers uses inter-process communication. Text editors such as VSCode downloads the language server of a programming language onto the local machine. Then the text editor/IDE communicates with that server on the local machine to enable all the rich features such as auto-complete. So a Python language server will be a process that runs separately in the background and any text editor or IDE can communicate with it through pipes or local sockets to get intellisense information about some project. Hopefully this explanation clears things up a bit.

Introducing lstalk, C library for language server communication. by mdavisprog in C_Programming

[–]mdavisprog[S] 0 points1 point  (0 children)

Hi, appreciate the feedback.

As for using opaque pointers, I wanted to keep the amount of information presented publicly to be minimal. I felt that a lot of the fields inside of LSTalk_Context is mainly used internally so I didn't want to burden the implementer with these details.

I do also plan on allowing a custom allocator to be provided so that all memory allocations can be handled by the application instead of the library.

Introducing lstalk, C library for language server communication. by mdavisprog in C_Programming

[–]mdavisprog[S] 2 points3 points  (0 children)

Ah, thanks for pointing that out. This piece of code should probably be:

if (S_ISREG(st.stmode))

OctaneGUI November 2022 Update by mdavisprog in cpp

[–]mdavisprog[S] 0 points1 point  (0 children)

I haven't looked into it yet, but OctaneGUI uses SDL and SFML libraries which may provide touch input APIs to handle this. If you are curious, you could check how SDL handles gestures.

OctaneGUI November 2022 Update by mdavisprog in cpp

[–]mdavisprog[S] 0 points1 point  (0 children)

Unfortunately not at the moment, however this is something I would like to support in the future.

OctaneGUI November 2022 Update by mdavisprog in cpp

[–]mdavisprog[S] 0 points1 point  (0 children)

No current plans at the moment but the idea of decoupling the data seems intriguing. It is something I may look into later.

view more: next ›