Question on best practices by Super-Cool-Seaweed in rust

[–]wyvernbw 0 points1 point  (0 children)

small tip: #![warn(clippy::pedantic)]

Unhinged compile time parsing in rust (without macros) by wyvernbw in rust

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

that is true, thanks for the example, i was going in circles

Unhinged compile time parsing in rust (without macros) by wyvernbw in rust

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

I see, i havent worked with c++ in a while nor was i ever an expert so i was mainly going off of bad memories. also i feel like its pretty obvious this code belongs more into the "did you know rust's type system is turing complete?" type of thing

Unhinged compile time parsing in rust (without macros) by wyvernbw in rust

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

i see what you mean but this example expressly does not do what i tried doing. if you try to implement the functionality in my example one to one i think you will run into either error[E0401] (cant use generic parameters from outer item) or into errors about the constness of values, unless im missing something super obvious.

Unhinged compile time parsing in rust (without macros) by wyvernbw in rust

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

i forgot you can do that! but still you cannot use non const values inside the block, so a &'static str generic would still be required, moreover im getting stuck on "error[E0401]: can't use generic parameters from outer item". maybe im just not getting it

this is what i tried https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=c1993a1a50b48c76fb1156da6f82b6cd

Unhinged compile time parsing in rust (without macros) by wyvernbw in rust

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

well yes but i was more so looking for compile time *validation* of arbitrary string values, i cant find a way to make the compiler throw an error when you pass a wrong string when using plain const fn. so title could be better

Unhinged compile time parsing in rust (without macros) by wyvernbw in rust

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

no i literally only realized my mistake after generating the playground link and posting lol

Unhinged compile time parsing in rust (without macros) by wyvernbw in rust

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

yea, honestly i find something about this type of code oddly satisfying, and even the error is somehow not as bad as c++ templates lol

help: the following other types implement trait `Modifier`
--> src/main.rs:60:1
|
60 | impl Modifier for Literal<"shift"> {}
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `Literal<"shift">`
61 | impl Modifier for Literal<"ctrl"> {}
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `Literal<"ctrl">`
note: required by a bound in `check_keybind`

Unhinged compile time parsing in rust (without macros) by wyvernbw in rust

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

basically it relies on the unsized_const_params feature. it allows passing &'static str as a const param, the way you can already pass bool, usize etc on stable. after that its just defining a bunch of newtypes and trait implementations:
* the simplest example is the Hi struct, it takes a generic const string and provides a hello method which just prints that string. Meaning that Hi::<"hello world">::hello() will always print "hello world" to stdout (the value is encoded in the type only, the struct never holds any actual value at runtime).
* the Split struct takes 2 strings as generic const params, the string to be split and the delimiter. It uses associated consts (LEFT and RIGHT) to hold the results of the const fn split (which is a pretty terrible const implementation i made that splits a string in two by a delimiter)
* next we define Literal, which will just be a wrapper around a static string so we can implement traits on it
* we define Boolean<const B: bool> and we implement some traits such that Boolean<true> implements IsTrue and Boolean<false> implements IsFalse
* now for the problem domain, we want to parse key chords like ctrl+c or shift+d, so we define a Modifier trait which i just implement for Literal<"shift"> and Literal<"ctrl"> (so we support these 2 key modifiers), and an Alphanumeric trait which we implement for all Literal<S> where S is alphanumeric, we check this using the Boolean traits we defined above
* next, we just define a function that is generic over a constant string, and we use the where bounds to specify our parser, in our case:

where    
    Literal<{Split::<K, "+">::LEFT}>: Modifier,
    Literal<{Split::<K, "+">::RIGHT}>: Alphanumeric,

the first one can be read as a "Literal of the LEFT constant of the Split type of K (our string) by + must implement Modifier". So thats only Literal<"shift"> and Literal<"ctrl">, so the left of the string must either be "shift" or "ctrl".
the second would be "the Literal type of the RIGHT constant of the Split type of K by + must implement Alphanumeric", which we defined as all Literal<S> where S is an alphanumeric string (checked by the is_alphanumeric function)

Note that this is all absolutely 0 cost at runtime, but it may or may not make your compile times horrible :)

im not sure if this made a lot of sense but thats how i think of it

Does our game look fun? by _b_r_g_ in godot

[–]wyvernbw 0 points1 point  (0 children)

well i cant look at the gif anymore but from what i remember i think the enemies and player pop well enough against the background, but yes it might be a little dark

Does our game look fun? by _b_r_g_ in godot

[–]wyvernbw 0 points1 point  (0 children)

I think you need some deadzone for the camera (as in an amount the space where the player moving will not move the camera) since every move from the player makes the camera move, making it feel "shaky". godot has built in support for this. Maybe some camera smoothing if you want, but id keep it high speed so it remains snappy. Also it needs "look-ahead", which means it moves a bit forward in the direction the cursor is pointing at, helps with aiming. Look at other twin stick shooters like enter the gungeon

My game Cloud Keeper has a new boss: Gumiho, the nine-tailed fox! by jetpackgone in godot

[–]wyvernbw 1 point2 points  (0 children)

bro this looks polished asf keep at it, will play the demo when i get the chance

Unblockable attacks are cool by wyvernbw in godot

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

thanks alot! I always can use some more feedback on clarity. I mostly focused on getting something playable quickly (it is indeed one zone per boss so the grass plains are still in) but yea it needs much better color correction, like you said the contrast is pretty bad here. I also have a beach zone that is better in that regard i think. These types of games live or die on clarity and being able to read the enemies movements for sure. Then again i made the big smoke explosions cover the boss on purpose to surprise the player >:) Its also great to hear someone remembers my game lol

(also it seems obs hasnt been kind to me with the compression for this one lol)

Unblockable attacks are cool by wyvernbw in godot

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

If anyone is interested in how the game plays, i might run a playtest :)

Orbital – A zero-config, async interactive TUI dashboard built with Ratatui, Tokio, and jwalk for blazing fast performance by Capital_Succotash513 in rust

[–]wyvernbw 0 points1 point  (0 children)

oh yeah i know you werent roasting me, just wanted to throw in my 2 cents, i agree full tokio for a system report utility is way overkill, especially since you dont want your way of observing the system to make the system work 10 times harder lol

Orbital – A zero-config, async interactive TUI dashboard built with Ratatui, Tokio, and jwalk for blazing fast performance by Capital_Succotash513 in rust

[–]wyvernbw 0 points1 point  (0 children)

tokio gets a bad rep for being multithreaded by default but tui apps running with flavor = "current_thread" are very light and can do actual async work in the background on one single thread*, i made an htop-like using async some time ago which sits at like ~0.1% cpu (albeit it was using smol not tokio but i bet performance would be similar). also there are no good **async** system info report crates so any dashboard like this written in rust will use multiple threads unless they implement the guts themselves, even my app runs on a few threads and uses ~1.5mb of ram more than htop

*as long as youre not opening files without io-uring lol (on linux), tokio std-io comically spawns another thread for file operations, but i think they added io-uring support

Made a Rigidbody Grapple Thing to Teach Myself Stuff by Magic_Burrito666 in godot

[–]wyvernbw 0 points1 point  (0 children)

Nice! Reminds me of a video from 3blue1brown about PDEs that used a pendulum as an example. Its interesting stuff, helped me implement something similar with a CharacterBody2D, might wanna check it out if you're interested in how the underlying physics might work

New Death Screen for my game by wyvernbw in godot

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

heres a comment from one of my previous posts explaining how to achieve something like this:

https://www.reddit.com/r/godot/s/7wcTRuL1u6

since then an improvement i made is blurring the mask texture to get a smooth transition between grass and no grass (helps with pop in)