Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: A PSX/DOS style 3D game written in Rust with a custom software renderer

totenarctanz.itch.io

Post reply on HN
Print view View original

21–30 of 37 posts

Re: Show HN: A PSX/DOS style 3D game written in Rust with a custom software renderer

#21

Post by nextaccountic »

mvx64 wrote: post #4
armitage__ wrote: post #3

I love custom game engines. Looks fantastic! Will you be sharing the source?

Thanks! For several reasons, most probably and regrettably no, for now at least. More than happy to talk about any specific part however (e.g. how scenes are handled, the code itself, or how particular features are implemented or optimized).

You talked about using Rust as a better C so I just wanted to ask, do you define any enums with payloads? (also called "sum types" or "tagged unions" in other languages) (edit: also called "algebraic tyeps" and there's an article about it in the front page, though this is a slight misnomer)

Things like

    enum Something {
        One(String),
        Two(i32),
    }
Also, how is your usage of Option? (one such enum)

I think this plus pattern matching is the foundation of Rust's superpowers. It's also very old tech and absolutely not Rust's invention, present in languages like OCaml and SML. Hence the early Rust slogan, "technology from the past, come to save the future from itself"

Re: Show HN: A PSX/DOS style 3D game written in Rust with a custom software renderer

#22

Post by nextaccountic »

mvx64 wrote: post #13
galangalalgol wrote: post #12

Earlier quoted context omitted.

Could you talk more about the subset of rust you settled on? You said you didn't explicitly use simd, but did you do anything to help the optimizer autovectorize like float chunking

It's a very procedural style. I have not used: iterators, lifetimes, Arcs/Boxes/RefCells and whatnot, any kind of generics, data structures other than vecs/arrays, async, and many more. Also avoided functional style, builder patterns... I only used traits to more easily implement the scenes; a Scene needs to implement a new(), a start() and an update(), so that I can put them in an array and call them like scenes[cur…

> I have not used: iterators,

Here's a counterpoint: every time you write a for loop in Rust, you are using iterators.

Re: Show HN: A PSX/DOS style 3D game written in Rust with a custom software renderer

#23

Post by mvx64 »

nextaccountic wrote: post #22
mvx64 wrote: post #13

Earlier quoted context omitted.

It's a very procedural style. I have not used: iterators, lifetimes, Arcs/Boxes/RefCells and whatnot, any kind of generics, data structures other than vecs/arrays, async, and many more. Also avoided functional style, builder patterns... I only used traits to more easily implement the scenes; a Scene needs to implement a new(), a start() and an update(), so that I can put them in an array and call them like scenes[cur…

> I have not used: iterators, Here's a counterpoint: every time you write a for loop in Rust, you are using iterators.

You mean implicitly? I am aware that idiomatic Rust strongly prefers iterators over indices for performance, but in my case, the only place where it really matters is when counting pixels to draw, and there is no kind of collection there, just x,y numbers.

Re: Show HN: A PSX/DOS style 3D game written in Rust with a custom software renderer

#24

Post by mvx64 »

nextaccountic wrote: post #21
mvx64 wrote: post #4

Earlier quoted context omitted.

Thanks! For several reasons, most probably and regrettably no, for now at least. More than happy to talk about any specific part however (e.g. how scenes are handled, the code itself, or how particular features are implemented or optimized).

You talked about using Rust as a better C so I just wanted to ask, do you define any enums with payloads? (also called "sum types" or "tagged unions" in other languages) (edit: also called "algebraic tyeps" and there's an article about it in the front page, though this is a slight misnomer) Things like enum Something { One(String), Two(i32), } Also, how is your usage of Option? (one such enum) I think this plus patte…

Actually yes! I use it when passing a texture into a draw function. I have a TexOrColor enum, and when calling the function you either provide an &Image or a &Color. Before that, if I wanted a colored textureless model, I passed a dummy 1x1 texture to sample from.

And of course, Options and pattern matching are easily the best part of the language and very powerful. I am obsessed with things like "let x = if {...}".

Re: Show HN: A PSX/DOS style 3D game written in Rust with a custom software renderer

#25

Post by nextaccountic »

mvx64 wrote: post #23
nextaccountic wrote: post #22

Earlier quoted context omitted.

> I have not used: iterators, Here's a counterpoint: every time you write a for loop in Rust, you are using iterators.

You mean implicitly? I am aware that idiomatic Rust strongly prefers iterators over indices for performance, but in my case, the only place where it really matters is when counting pixels to draw, and there is no kind of collection there, just x,y numbers.

Yep implicitly, for receives an IntoIterator, so it iterates either on an iterator like 0..10 or something that can be converted into an iterator like &myvec

(Note that it was a severe design flaw to make ranges like 0..10 iterators directly rather than just IntoIterator, because this means ranges can't be Copy and as such it's inconvenient to pass them around.. but fortunately they are going to fix that in a new edition)

But actually..

Do you mean you prefer writing for i in 0..myvec.len() and then accessing myvec[i], rather than using for x in &myvec or for x in &mut myvec, and using the x directly? But why?

Re: Show HN: A PSX/DOS style 3D game written in Rust with a custom software renderer

#26

Post by bmn__ »

> I do my own physics, quaternion/matrix/vector math, TGA and OBJ loading.

> FPS ranges from […] [70-80] on a 2005 Pentium laptop

> I am using [Rust] more as a "C

Great minds think alike! Please, I invite you to submit your work for approval here:

https://xcancel.com/tsoding/status/1960511663788188095

https://xcancel.com/tsoding/status/1964636951358894337

Re: Show HN: A PSX/DOS style 3D game written in Rust with a custom software renderer

#27

Post by galangalalgol »

mvx64 wrote: post #18
galangalalgol wrote: post #17

Earlier quoted context omitted.

Thanks! That seems like a nice subset for a lot of use cases. You say it isn't functional, which in rust it is hard to be pure, but if you consider it a spectrum, the style you describe is closer than most game code I've seen.

Right, it's a spectrum, you can't avoid some things (and rightly so). Another soft rule: no member functions (except for the Scenes); structs are only data, all functions are free functions. Also no operator overloading, so yes, lots of Vec3::add(&v1, &v2). I was hesitant at first but this makes for more transparent ops (* is dot or cross?) and does not hide the complexity. The whole thing is around 6-7kloc and I thi…

I don't find the idea of rewriting the subset of a blas library I want to use for each project very fun, but I bet with so few dependencies a stripped binary gets pretty small.

Re: Show HN: A PSX/DOS style 3D game written in Rust with a custom software renderer

#28

Post by em-bee »

nice, but i find it very hard to play. acceleration is either not enough and you are pulled in by the planet, or it is to much and you are getting away so fast that you can't counter steer. shouldn't gravity take care of that? if i am in orbit, then speeding up along my trajectory should slowly increase the orbit, and slowing down should decrease it. but speeding up takes me immediately out of the orbit as if the planet had no gravity.

Re: Show HN: A PSX/DOS style 3D game written in Rust with a custom software renderer

#29

Post by Klonoar »

mvx64 wrote: post #10
p0w3n3d wrote: post #6

Earlier quoted context omitted.

I believe you can build to mac targets on github though

Didn't know this, but I'd rather not use github to be honest. Isn't there also some kind of signing required to publish a Mac build?

You don’t need to sign it, the user just has to do some leg work to run it without it.

Re: Show HN: A PSX/DOS style 3D game written in Rust with a custom software renderer

#30

Post by mvx64 »

em-bee wrote: post #28

nice, but i find it very hard to play. acceleration is either not enough and you are pulled in by the planet, or it is to much and you are getting away so fast that you can't counter steer. shouldn't gravity take care of that? if i am in orbit, then speeding up along my trajectory should slowly increase the orbit, and slowing down should decrease it. but speeding up takes me immediately out of the orbit as if the pla…

Thanks for trying it out. It's a regular inverse square law, no tricks. The numbers (masses, distance) determine the final acceleration but not the actual trend of the curve.

I've become too familiar with it over testing to notice unintuitive behaviour, but I think I understand what feels off: in real world units, the gradual region you describe is very wide, and feels linear. This would make for very boring gameplay (imagine spending minutes to reach the planet). You need to keep the playable area [radiusForce0, radiusForceMax] small. So you will either map that small [r0, rmax] into real world [F0, Fmax], which means the force will be almost constant across, or "compress" the [F0, Fmax] curve so that you can fit both [zero outer space gravity, strong surface gravity] into that [r0, rmax].

That's what happens here, I probably tweaked the values for the second case. It's kind of an accelerated version of reality and the margins feel very tight, and you have to "buy into" that reality.

For example, Master difficulty in Mission 1 may seem impossible, but if you try to be gentle and find a balanced orbit, you can complete it with miniscule fluctuations in distance and minimal input.

Just rambling though, I never really actually designed or balanced the game.

Post reply on HN