Skip to content

[pull] master from libretro:master#969

Merged
pull[bot] merged 5 commits intoAlexandre1er:masterfrom
libretro:master
Apr 27, 2026
Merged

[pull] master from libretro:master#969
pull[bot] merged 5 commits intoAlexandre1er:masterfrom
libretro:master

Conversation

@pull
Copy link
Copy Markdown

@pull pull Bot commented Apr 27, 2026

See Commits and Changes for more details.


Created by pull[bot] (v2.0.0-alpha.4)

Can you help keep this open source service alive? 💖 Please sponsor : )

have to split them up into separate files
Both drivers' *_initialize_symbols() return false silently when
LoadLibrary("d3d8.dll") / ("d3d9.dll") fails. The caller in turn
returns NULL silently from the video driver's init(), so the only
diagnostic the user gets is the generic

   [ERROR] [Video] Cannot open video driver. Exiting...

from video_driver_init_internal(), with no hint that the legacy
runtime is the problem. Even --verbose does not help, because there
is no log call between the driver being selected and init() returning
NULL.

This is increasingly common on modern Windows installs that ship only
d3d8thk.dll (the kernel thunk layer) and not the user-mode d3d8.dll
runtime; recently made more visible by the qb change that lets D3D8
build without d3d8.lib being available at link time, which means more
people end up running a d3d8-enabled binary on a system where the
runtime DLL is missing.

Falling back to d3d8thk.dll is not an option -- it does not export
Direct3DCreate8, it is only the GDI-side thunk syscalls. So just log
clearly and let the caller fail.

Log dylib_error() (already populated by dylib_load on Win32 via
set_dl_err) and a one-liner pointing the user at the legacy DX runtime
or at picking a different video driver. Also log if the DLL loads but
Direct3DCreate{8,9} cannot be resolved, since that path is silent too.

No behavioural change beyond the new log lines; the error return is
unchanged.
The D3D8 driver previously expanded RGUI's 16bpp menu framebuffer
to 32bpp on the CPU every frame via a per-pixel loop, then uploaded
the result into a D3DFMT_A8R8G8B8 texture.  RGUI already assembles
its framebuffer in 16bpp; D3D8 has supported D3DFMT_A4R4G4B4 as a
baseline texture format since launch, on both PC and Original Xbox.

Add D3D8_ARGB4444_FORMAT to the existing D3D8 format macros (with
D3DFMT_LIN_A4R4G4B4 for the _XBOX build path), and a "d3d8" case
to the RGUI pixel format dispatcher selecting argb32_to_argb4444
(already in use by the rsx/PS3 and d3d9_hlsl/d3d9_cg drivers, which
target the same ARGB4444 bit layout).

In d3d8_set_menu_texture_frame, allocate the menu texture as
D3DFMT_A4R4G4B4 when rgb32 is false (the only case in current
practice; RGUI is the sole caller), and upload row-by-row via
memcpy.  The rgb32 = true API branch is preserved for forward
compatibility and continues to use D3DFMT_A8R8G8B8.

Track the bpp of the currently-allocated menu texture in a new
d3d8_video_t::menu_tex_rgb32 field so the texture is recreated
when the rgb32 flag flips between calls — same approach the D3D9
patch uses for d3d9_video_t.

Endian-safe by construction: argb32_to_argb4444 produces a
host-endian uint16_t with A in bits 15..12 down to B in 3..0;
D3DFMT_A4R4G4B4 is read by D3D as host-endian 16-bit units with
the same bit assignments.  D3D8 only targets LE hosts (Pentium III
on Original Xbox, x86/x64 on legacy Windows), so there is no
byte-swap concern in either direction.

Xbox-specific tex_coords[2]/[3] assignment after texture (re)creation
is preserved.
@pull pull Bot locked and limited conversation to collaborators Apr 27, 2026
@pull pull Bot added the ⤵️ pull label Apr 27, 2026
@pull pull Bot merged commit 5f23e85 into Alexandre1er:master Apr 27, 2026
38 checks passed
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant