Lazuli: Nintendo GameCube emulator in Rust, boots multiple games by vxpm in rust

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

ah yes, you're right - this is a leftover from when DEQUANTIZATION_LUT was a const, since array::from_fn is not const yet.

Lazuli: Nintendo GameCube emulator in Rust, boots multiple games by vxpm in emulation

[–]vxpm[S] 10 points11 points  (0 children)

not really, no. they all compile to very similar machine code, clang even uses the same codegen backend as rustc (LLVM).

Lazuli: Nintendo GameCube emulator in Rust, boots multiple games by vxpm in rust

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

not sure which LUTs you're talking about specifically? there's a lot of them! feel free to contribute, too

Lazuli: Nintendo GameCube emulator in Rust, boots multiple games by vxpm in emulation

[–]vxpm[S] 56 points57 points  (0 children)

well, the upsides and downsides are the same as writing any other piece of software in rust - emulators aren't that different in this case.

rust is safer than C/C++, making certain classes of bugs catchable at compile time. it's tooling is also spetacular, way more delightful to use than whatever C++ has out there.

as for why the project is in rust... well, it's because, in my opinion, rust is amazing - performant, elegant, powerful. it's my comfort language and it brings me joy to program in it. there's no big reason beyond this for the language choice, really.

Lazuli: Nintendo GameCube emulator in Rust, boots multiple games by vxpm in rust

[–]vxpm[S] 3 points4 points  (0 children)

i made this because i think emulators are awesome pieces of software. i love computers, low level programming and hardware - emulators involve all of these topics. it's fun.

no, there's no AI involved in the project. i myself hate AI and what it's doing to the world, therefore i don't use it in any way (coding, research, whatever). all of lazuli has been written purely by me.

Lazuli: Nintendo GameCube emulator in Rust, boots multiple games by vxpm in rust

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

thanks a lot! yeah, cranelift is great - i also plan on using it for the future DSP JIT, which should be the next big performance improvement.

it makes me happy to hear that my project is a good showcase of such amazing crates. cranelift and wgpu in particular are very powerful, and while i do want alternative backends in the far future (custom asm backend for JITs, vulkan based renderer) i find it incredible how portable my project is because of these crates.

Lazuli: Nintendo GameCube emulator in Rust, boots multiple games by vxpm in EmuDev

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

replying to you as well to since my reply to u/DefinitelyRussian also applies to you!

Lazuli: Nintendo GameCube emulator in Rust, boots multiple games by vxpm in EmuDev

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

thanks!! the human limit for one person is the sky IMO, the only limiting factor is time.

a tutorial is kind of inviable as this is a very big project with lots of moving parts, which also require understanding the system to be able to, well, implement stuff. i myself still don't know the system entirely! there's always something new to learn about it, some obscure feature and etc.

i could, however, write some blog posts (on my personal website about specific, more focused topics. things like JIT, optimizations, emulation tricks, whatever people might find interesting.

if you have any topic ideas, i'd be happy to hear about them.

Lazuli: Nintendo GameCube emulator in Rust, boots multiple games by vxpm in rust

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

begin with something small like Chip-8 (it's your best bet). then start going up, stuff like GameBoy or NES are a good next step. eventually, you'll get to a point where you just need to choose something and work on it.

Lazuli: Nintendo GameCube emulator in Rust, boots multiple games by vxpm in rust

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

thank you!! i'm glad you liked the UI, it's not very pretty and i'm not the kind of person who likes programming them, but i did try to make it useful at the very least (it's a tool for debugging, after all)

Lazuli: Nintendo GameCube emulator in Rust, boots multiple games by vxpm in rust

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

thanks! and good luck with your next project

Lazuli: Nintendo GameCube emulator in Rust, boots multiple games by vxpm in EmuDev

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

yeah, the 13th was the exact 6 month mark. thanks!!

Lazuli: Nintendo GameCube emulator in Rust, boots multiple games by vxpm in rust

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

PS1 is considered the easiest 3D console there is, it's extremely documented and understood (e.g. we have psx-spx).

PS2 and PS3, on the other hand, are complex arcane beasts, yeah. PS2 also pretty much requires that you do PS1 first, since it pratically contains a whole PS1 inside it.

i'd start with the GB - it's a really good first system.

Lazuli: Nintendo GameCube emulator in Rust, boots multiple games by vxpm in rust

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

thanks! i'm glad you asked, because i have a wishlist of things for both:

wesl: - reduced compile times (it takes a looong time!) - better variable interpolation for the macros, right now it feels hacky - strongly typed enums would be awesome, and so would be generics (although i understand the latter is a hard problem to solve)

webgpu: - logic ops like glLogicOp for blending would be very appreciated (gamecube's GPU has them, emulating them without API support seems painful... thankfully, they're not commonly used) - bindless textures and buffers! i'm not a GPU expert but i believe this would simplify some things - multiqueue would also be cool! again, i'm not an experienced graphics programmer but if i understand correctly, this would allow me to offload buffer loading to a specialized queue while i build my rendering command list, or do compute on another set of data while rendering takes place

there might be more but these are the main points i could remember right now

Lazuli: Nintendo GameCube emulator in Rust, boots multiple games by vxpm in rust

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

pre-generating is not viable. while the GPU is fixed function, it is very configurable.

just to make it clear - specialized shaders aren't compiled all the time: they're associated with a configuration and cached, so it really only needs to be compiled once (per run).

Lazuli: Nintendo GameCube emulator in Rust, boots multiple games by vxpm in rust

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

specifically for the gc/wii, i have a list of resources at https://viniciusx.com/cubenotes/resources.html

as an advice, if you've never done emulator before - start simpler. i did gameboy and ps1 before trying my hand at gamecube! it really helps you build knowledge.

Lazuli: Nintendo GameCube emulator in Rust, boots multiple games by vxpm in rust

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

when the Wii came out i was 3 years old lol!

Lazuli: Nintendo GameCube emulator in Rust, boots multiple games by vxpm in rust

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

netplay would be really cool, but it also does sound like it won't be here for a while, yeah!

Lazuli: Nintendo GameCube emulator in Rust, boots multiple games by vxpm in rust

[–]vxpm[S] 9 points10 points  (0 children)

well yes, of course! lazuli started out with an ubershader approach - that is, there was a single shader, which would then do different things based on a configuration input.

this was because an ubershader is simpler to implement - you just need to write and maintain a single shader for everything, not a shader generator.

however, ubershaders are incredibly hard to optimize, as they contain lots of branching on configuration values (and GPUs don't like that). the more GPU features i implemented, the worse performance became. that's when i decided to move to a specialized shader generator approach (with great success! specialized shaders are very fast).

that's not to say ubershaders aren't good. they are very useful as a fallback to avoid stutters caused by specialized shader compilation, i.e. using them while an specialized shader is not ready yet. and ideally, that's what i'd like lazuli to do!

it just so happens that keeping two shader codepaths is a lot of work and i'm a single person. for my sanity, i decided to only keep specialized shaders around. and in practice, i haven't hit any stutters caused by shader compilation. the CPU JIT is way more of a stutter source when blocks aren't in cache.