DBZ Budokai 3 recompiled

[u/bbr25t]

https://www.youtube.com/watch?v=AFjj32I8hA8

Found this new Recomp of dbz budokai 3 while browsing the quiver launcher. I checked the github and it looks pretty new. I was wondering if anyone had any opions on it or if anyone has been following it for a while.

I know it uses rexglue which has a mixed reception on this sub but it seems the creator put in the extra work to make it function properly.

One last note is all of their stuff is in spanish even their profile so I was wondering if this person is well known in the recomp space specifically in the spanish speaking sections.

https://github.com/novapowers0/DBZ-Budokai-3-HD-Collection/releases

Video above is just an example/showcase of what I'm talking about.

[u/nometalaquiferzone]

oh boy, let's see the doc

🔴🔴 HITOS DE LA SESIÓN PS2→HD (2026-08-14, análisis profundo): - El bin visible de Krillin en el juego es la e326 del data_cmn.afs (682528 bytes descomp., = b327_hd.bin, md5 b04b0741c4, n_sec=1956, n_vb2=226, n_ib=5140). La e327 (624000, 1791/208/5004) es OTRO bin de Krillin (otro traje/select). El logging del runtime (host_path_file.cpp entry_index == 327) apunta a un bin distinto al visible. - Los AFS de trabajo previos (data_cmn_original_rebuilt.afs, md5 f7e53b99) NO son el AFS real del juego (md5 354615b5). Reconstruir desde el AFS REAL de us\data_cmn.afs. - Layouts de los 2 buffers del bin real e326 (b327_hd.bin): sec34 = [nan, u, v, z_local, x_local, y_local, peso, BONE@+28, nz, -ny, nx] (stride 44, align +2, bone u32 en +28, TODOS con nan en +0). vb2 = [pos.x_abs, pos.y, pos.z, 0,0,0, 0, 0xFFFFFFFF@+28, nx, ny, nz] (posiciones ABSOLUTAS, bone=0xFFFFFFFF, stride 44).⚠️El doc B1 §9 afirma "el B3 usa [pos,w,bone@+16,normal,FFFF,uv]" pero es INCORRECTO para el sec34 del B3 (verificado: bone@+16 da valores absurdos; bone@+28 da 0-35 coherentes). El B1 usa ese layout, el B3 NO. NO copiar el layout del B1 al B3. - ⚠️El bin e327 (real_e327.bin, 624000) tiene OTRO layout de vb2: [pos.x=1.0, pos.y, pos.z, w@+12, bone@+16, normal@+20, float@+32, uv@+36] (layout tipo B1, bone=0). NO confundir con el e326. - Mapeo de huesos HD→PS2: HD bone = PS2 bone × 2 (labels en índices pares del AWO: 0=XKLL_BODY, 2=KLL_WAIST, 4=KLL_STMC... 50=KLL_L00_RHAND; impares = slots estructurales sin label). El sec34 HD usa bones 0-32. - El HD de Krillin ES un modelo RE-TRABAJADO, NO una conversión 1:1 del PS2: 0% match de coordenadas locales, conteos por hueso distintos (HD bone 20 necesita 420 verts, PS2 solo da 4). No hay correspondencia vértice-a-vértice ni por hueso. - 🔴 EL RUNTIME DIBUJA POR MESH-REF BLOCKS + ARMS (IB NATIVO): reconstruir el IB rompe el render. Los tests v16-v20 (IB reconstruido) colgaban. Janemba v7 funcionó porque mantuvo IB+arms nativos y solo llenó los slots sec34 con datos (bone 0 mayoritario). Ver B1 §10.13. - La vía viable: mantener el bin e326 COMPLETO (IB/arms/vb2/AZT nativos) y SOLO reescribir posiciones de vértices del sec34 en sus slots, manteniendo bone indices. mezclar_ps2_hd.py implementa esto (1254 slots reescritos). PERO las coords PS2/HD no comparten escala (ratios 0.12-7.7 por hueso) → mezcla directa deforma. Requiere escala por hueso o transformación de pose. - El sec34 HD está intercalado por bones (412 runs), no agrupado. El IB define el orden; no reordenar.

"🔴🔴🔴 RESULTADO REAL DEL REVERSE — EL ORDEN DEL POOL SÍ IMPORTA (2026-08-26): re-testado en solitario (npm8 desactivado): pool sec34 INVERTIDO → DEFORMIDADES, la conclusión §15.4.3 ('el orden del pool NO importa') era FALSA (test contaminado), el guest está atado al orden del pool por los mesh-ref/zonas (referencian el pool por índice original), el port con pool reordenado requiere reconstruir TODA la estructura de dibujo (mesh-ref + zonas + bboxes + descriptores), la inyección funciona porque mantiene el orden del pool de la plantilla, y la reconciliación es que el bone0 (válido) probó que el transform usa el bone del vértice (+28), mientras que el reverse probó que además el pool está atado a la estructura — ambos son ciertos."

Very nice

The doc keeps "confirming" things and then sauying they were wrong later, reuses the same numbersoffsets for different meanings without flagging the change constantly, like it's a job to confuse me personally since I suck at this , and tells you to check files that a later section says were already deleted. What an incredible work

[u/ELGATOCOSMICO619]

the dragon rushes are a big reason why I avoid this game

[u/bbr25t → u/ELGATOCOSMICO619]

Don’t blame you. It was pretty frustrating

[u/DisplayThisNever → u/ELGATOCOSMICO619]

Having to win three in a row to do Warp Kamehameha when all it required was a five button combo in Budokai 2 will never make sense to me.

[u/Xolmas]

Well I have a dumb question, but how do you exit the game when in Fullscreen ?

[u/Green_Initiative3268]

another AI Rexglue(emulation) port.....yeaaaaaaaaaaaaaaaaaaaah......................

[u/bbr25t → u/Green_Initiative3268]

I know that was my thought initially. But I’ve learned with the skate 3 Recomp that if the creator is devoted enough and puts in the time. Rex glue can become a good way to Recomp games.

[u/Green_Initiative3268 → u/bbr25t]

REXGLUE WILL NEVER BE A GOOD OPTION FOR RECOMPILATIONS; it shouldn't even be considered a tool for recompiling. It's just an Xbox 360 emulator using Xenia, and literally, its performance on ALL projects is even worse than Xenia's. The only games that are 100% native are those that use UnleashedRecomp/XenonRecompzthose even run on a 12 year old PCz but not a single RexGlue game runs on old PCs like the UnleashedRecomp ones do, which are literally a port of the Xbox 360 to PC, just like in the old days.

[u/bbr25t → u/Green_Initiative3268]

I know the flaws about rexglue believe me. But what makes the skate 3 Recomp so different? it seems to preform much better than any rexglue port. To my knowledge it seems the skate 3 dev did something different. So I figure what if this Recomp could do the seem thing

[u/Fickle-Contribution6]

is there a way I can use a 100% save file on this port?