A Rust-Powered Starfield in the Browser with Macroquad + WASM

Unknown — Wed, 01 Apr 2026 00:00:00 +0000

AI can get you to a working result quickly. What it doesn’t replace is the value of understanding why something looks right, breaks, or feels good to tune.

I wanted a small Rust project where the mechanics stayed visible, and a browser-based starfield was a good fit: simple enough to build quickly, but visual enough to make the underlying math worth paying attention to.

The nice part is that this effect is mostly a handful of small ideas wired together correctly. We are not building a full engine here. We are just using Rust, a rendering loop, and some basic projection math to create a convincing sense of forward motion.

This walkthrough assumes you're comfortable reading basic Rust, but not necessarily familiar with Macroquad, WASM, or graphics code.

Setting Up the Machine</h2>
Before we get to the pixels, we need the right tools in the garage. For this project, we're using Macroquad's own web loader path, which keeps the setup simple: compile to `wasm32-unknown-unknown</code>, drop the output into a small web/</code> folder, and serve it like static files.`

1. Create the Project</h3> If you do not already have Rust installed, start with rustup</code> from rustup.rs</a>. Once that is in place, create a new Rust binary project and move into the directory: cargo new starfield --bin cd starfield # Install the WASM target rustup target add wasm32-unknown-unknown # Optional: install a simple static server for local testing cargo install basic-http-server </code></pre> 2. The Blueprint (Cargo.toml)</h3> We only need a few parts to get this engine running. Macroquad handles the graphics, and we’ll use the rand</code> crate for our star distribution. I landed on this exact rand</code> config after a failed browser build. The small_rng</code> feature is enough for this project, and disabling rand</code>'s default features avoids pulling in browser glue that does not match Macroquad's plain HTML5 loader path. [dependencies] macroquad = "0.4" rand = { version = "0.8", default-features = false, features = ["small_rng"] } </code></pre> 3. The Glue (web/index.html</code>)</h3> Macroquad's browser path expects a canvas and a JavaScript loader. Create a web/</code> directory, and inside it add an index.html</code>: <!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <title>Rust Starfield</title> <style> html, body { margin: 0; padding: 0; overflow: hidden; background: black; height: 100%; width: 100%; } canvas { display: block; width: 100vw; height: 100vh; } </style> </head> <body> <canvas id="glcanvas" tabindex="1"></canvas> <script src="mq_js_bundle.js"></script> <script>load("starfield.wasm");</script> </body> </html> </code></pre> Note on mq_js_bundle.js</code>: You need to place a copy of this loader in your web/</code> directory. You can usually find it in your local Cargo registry: cp ~/.cargo/registry/src/index.crates.io-*/macroquad-*/js/mq_js_bundle.js web/ </code></pre> Troubleshooting: If you cannot find it locally, you can download it directly from the Macroquad GitHub repository</a>. The Stack: Macroquad & WASM</h2> There are powerful graphics options in Rust like Bevy, but for this, I wanted something direct. I chose Macroquad. It’s a minimalist engine with a low-friction API. It doesn't hide the execution loop behind much abstraction; you write a loop</code> and tell it exactly what to draw every frame. It feels less like building a factory and more like working directly on the engine block. When you compile to WASM, you ship a self-contained binary. You still need that small JS shim (mq_js_bundle.js</code>) to bridge to WebGL, but the setup stays lean. The Anatomy of a Star</h2> The "star" is our basic unit: struct Star { x: f32, y: f32, z: f32, speed: f32, brightness: f32, } </code></pre> x, y: Coordinates in space.</li> z: Depth. As z</code> decreases, the star moves closer.</li> speed: Allows for different layers of motion.</li> brightness: Adds visual depth.</li> </ul> To get moving, we populate a Vec</code> with randomized starting positions: fn init_stars(count: usize) -> Vec<Star> { let mut rng = SmallRng::seed_from_u64(0); (0..count) .map(|_| Star { x: rng.gen_range(-1.0..1.0), y: rng.gen_range(-1.0..1.0), z: rng.gen_range(1.0..32.0), speed: rng.gen_range(0.008..0.025), brightness: rng.gen_range(0.6..1.0), }) .collect() } </code></pre> Two Rust details worth calling out here: SmallRng::seed_from_u64(0)</code> creates a deterministic field, which is great for debugging.</li> (0..count).map(|_| ...)</code> is the idiomatic way to say "repeat this count</code> times." The |_|</code> means we don't need the loop index.</li> </ul> One small visual tweak: If you keep x</code> and y</code> in too tight a range, stars bunch around the center. Widening the spawn volume (which we'll do in the "Polish" section) makes the field feel more believable. The Infinite Loop (The Projection)</h2> The "warp" effect relies on a simple 3D-to-2D projection: as z</code> decreases, we scale coordinates to push stars further from the center. for star in stars.iter_mut() { star.z -= star.speed; // Move forward if star.z < 0.2 { // Recycle star star.z = 32.0; star.x = rng.gen_range(-1.0..1.0); star.y = rng.gen_range(-1.0..1.0); } // Projection: dividing by 'z' is the key. let sx = (star.x / star.z) * screen_width() * 0.5 + center_x; let sy = (star.y / star.z) * screen_height() * 0.5 + center_y; draw_circle(sx, sy, size, color); } </code></pre> The Full Engine (Core Version)</h2> Replace your src/main.rs</code> with this. It sets up the window, initializes the field, and runs the loop. use macroquad::prelude::*; use ::rand::rngs::SmallRng; use ::rand::{Rng, SeedableRng}; struct Star { x: f32, y: f32, z: f32, speed: f32, brightness: f32, } const STAR_DEPTH: f32 = 32.0; const TITLE_TEXT: &str = "RUST // WASM"; fn init_stars(count: usize) -> Vec<Star> { let mut rng = SmallRng::seed_from_u64(0); (0..count).map(|_| Star { x: rng.gen_range(-1.0..1.0), y: rng.gen_range(-1.0..1.0), z: rng.gen_range(1.0..STAR_DEPTH), speed: rng.gen_range(0.008..0.025), brightness: rng.gen_range(0.6..1.0), }).collect() } #[macroquad::main("Starfield")] async fn main() { let mut stars = init_stars(400); let mut rng = SmallRng::seed_from_u64(macroquad::miniquad::date::now() as u64); loop { let screen_w = screen_width(); let screen_h = screen_height(); let center_x = screen_w * 0.5; let center_y = screen_h * 0.5; let time = get_time() as f32; clear_background(Color::from_rgba(3, 4, 10, 255)); for star in stars.iter_mut() { star.z -= star.speed; if star.z < 0.2 { star.z = STAR_DEPTH; star.x = rng.gen_range(-1.0..1.0); star.y = rng.gen_range(-1.0..1.0); } let sx = (star.x / star.z) * screen_w * 0.5 + center_x; let sy = (star.y / star.z) * screen_h * 0.5 + center_y; let depth_factor = 1.0 - (star.z / STAR_DEPTH); let size = 1.0 + 2.0 * depth_factor; let brightness = star.brightness * depth_factor; draw_circle(sx, sy, size, Color::new(brightness, brightness, brightness, 1.0)); } let pulse = 0.5 + 0.5 * (time * 2.0).sin(); let title_color = Color::new(0.5 + 0.5 * pulse, 0.8, 1.0, 1.0); draw_text(TITLE_TEXT, 20.0, 40.0, 30.0, title_color); next_frame().await; } } </code></pre> What's happening in main()</code>? screen_width()</code> & center_x</code>: Recomputed every frame so it stays centered if you resize the browser.</li> get_time()</code>: Used for the pulsing title.</li> clear_background(...)</code>: Every frame is drawn from scratch; we must clear the last one.</li> 0.5 + 0.5 * (time).sin()</code>: Maps the sine wave (-1.0..1.0</code>) to a usable color range (0.0..1.0</code>).</li> </ul> Running the Engine</h2> Build the WASM target (use --release</code> for performance): cargo build --target wasm32-unknown-unknown --release cp target/wasm32-unknown-unknown/release/starfield.wasm web/starfield.wasm </code></pre> Serve the web/</code> folder (Python, Node, or basic-http-server</code> all work): basic-http-server web # OR: python3 -m http.server --directory web </code></pre> Automation (build.sh</code>)</h3> To make iteration faster, wrap this in a script: #!/usr/bin/env bash set -euo pipefail PORT=4000 cargo build --target wasm32-unknown-unknown --release cp target/wasm32-unknown-unknown/release/starfield.wasm web/starfield.wasm if lsof -i :"$PORT" >/dev/null 2>&1; then echo "Server running on $PORT. Refresh browser." exit 0 fi basic-http-server web -a 127.0.0.1:"$PORT" </code></pre> The Machine in Motion (The Polish)</h2> The "Core" version works, but it feels like a diagnostic test. Let's make it a finished visual. 1. Tighten the Spawn Volume</h3> Add const STAR_SPREAD: f32 = 20.0;</code> at the top. Use this range in init_stars</code> and the recycling block: star.x = rng.gen_range(-STAR_SPREAD..STAR_SPREAD);</code> This makes the field feel deeper and less bunched. 2. Increase Density and Speed</h3> In main()</code>, bump the count to 650</code> and the speed range in init_stars</code> to 0.012..0.032</code>. 3. Center the Title</h3> Use measure_text</code> to center the title perfectly: let title_size = 84.0; let title_metrics = measure_text(TITLE_TEXT, None, title_size as u16, 1.0); let title_x = center_x - title_metrics.width * 0.5; let title_y = center_y - title_metrics.height * 0.5; draw_text(TITLE_TEXT, title_x, title_y, title_size, title_color); </code></pre> Final Optimized Code</h2> rust-wasm-repo</a> use ::rand::rngs::SmallRng; use ::rand::{Rng, SeedableRng}; use macroquad::prelude::*; // One star in 3D space, plus a few values for motion and brightness. struct Star { x: f32, y: f32, z: f32, speed: f32, brightness: f32, } const STAR_DEPTH: f32 = 32.0; const STAR_SPREAD: f32 = 20.0; const TITLE_TEXT: &str = "RUST // WASM"; fn init_stars(count: usize) -> Vec<Star> { // Fixed seed so the initial field is repeatable while developing. let mut rng = SmallRng::seed_from_u64(0); (0..count) .map(|_| Star { // Spread stars across a wider 3D volume so the field fills the screen. x: rng.gen_range(-STAR_SPREAD..STAR_SPREAD), y: rng.gen_range(-STAR_SPREAD..STAR_SPREAD), z: rng.gen_range(1.0..STAR_DEPTH), speed: rng.gen_range(0.012..0.032), brightness: rng.gen_range(0.6..1.0), }) .collect() } #[macroquad::main("Starfield")] async fn main() { // Create the initial field once at startup. let mut stars = init_stars(650); // Time-based seed so recycled stars re-enter less predictably. let mut rng = SmallRng::seed_from_u64(macroquad::miniquad::date::now() as u64); loop { // Recompute dimensions every frame so the effect stays centered. let screen_w = screen_width(); let screen_h = screen_height(); let center_x = screen_w * 0.5; let center_y = screen_h * 0.5; let time = get_time() as f32; // Paint the background before drawing the stars on top. clear_background(Color::from_rgba(3, 4, 10, 255)); draw_rectangle( 0.0, 0.0, screen_w, screen_h, Color::from_rgba(18, 10, 36, 90), ); for star in stars.iter_mut() { // 1. Move the star forward along the Z-axis star.z -= star.speed; // 2. Recycle the star if it gets too close to the "windshield" if star.z < 0.2 { star.z = STAR_DEPTH; // Respawn across the full width of the field, not just the center. star.x = rng.gen_range(-STAR_SPREAD..STAR_SPREAD); star.y = rng.gen_range(-STAR_SPREAD..STAR_SPREAD); } // 3. Project to 2D screen: dividing by 'z' is the key. let sx = (star.x / star.z) * screen_w * 0.5 + center_x; let sy = (star.y / star.z) * screen_h * 0.5 + center_y; // 4. Scale size and brightness based on depth let depth_factor = 1.0 - (star.z / STAR_DEPTH); let size = 1.0 + 2.0 * depth_factor; let brightness = star.brightness * depth_factor; // Draw brighter, larger stars as they get closer to the camera. draw_circle( sx, sy, size, Color::new(brightness, brightness, brightness, 1.0), ); } // Smoothly oscillate between 0.0 and 1.0 for the title pulse let pulse = 0.5 + 0.5 * (time * 2.0).sin(); let title_color = Color::new(0.5 + 0.5 * pulse, 0.8, 1.0, 1.0); let title_size = 84.0; let title_metrics = measure_text(TITLE_TEXT, None, title_size as u16, 1.0); let title_x = center_x - title_metrics.width * 0.5; let title_y = center_y - title_metrics.height * 0.5; draw_text(TITLE_TEXT, title_x, title_y, title_size, title_color); // Present the current frame, then continue the loop next_frame().await; } } </code></pre> What's Next?</h2> We’ve built the universe; now we just need a way to pay for the fuel. The obvious next step is to make the effect more physical: star trails, camera drift, or mouse input. But even in this stripped-down form, the core lesson holds up: if you want a visual Rust project that feels rewarding quickly. References</h2> Macroquad Docs</a></li> Rust WASM Book</a></li> </ul>

Starklings-Cairo1: Primitive Types

Unknown — Wed, 12 Jun 2024 00:00:00 +0000

Overview</h2>
Cairo has several basic types that are directly implemented into the compiler, which are essential for building more complex data structures and functions. Understanding these primitive types is crucial as they form the foundation of Cairo programming. In this section, we’ll explore:

Boolean Types: • Booleans (`bool</code>) represent true or false values and are fundamental for control flow in programming. We will see how to define and use booleans in conditional statements. </li>`
`Integer Types: • Cairo supports various integer types, such as u8</code> and u16</code>, which represent unsigned integers of different sizes. We will learn how to use these types, perform arithmetic operations, and prevent common issues like overflow. </li>`
`Tuples: • Tuples allow us to group multiple values into a single compound value. We will practice destructuring tuples to access and manipulate individual elements effectively. </li>`
`Strings and felt252: • Cairo represents short strings as felt252</code> (field elements). We’ll explore how these representations work, how to convert between strings and numerical values, and the implications for printing and data handling. </li> </ol> By the end of this post, you’ll have a solid understanding of these basic types and how to use them in Cairo, setting a strong foundation for more advanced topics.`Further Information</h3> For more detailed information on data types in Cairo, you can refer to the official documentation: Cairo Data Types</a> Intro</h2> So let’s dive into the first exercise: primitive_types1.cairo</code>. Let's walk through these exercises so you get a better understanding of how Cairo works. primitive_types1.cairo</code></h2> // primitive_types1.cairo // Fill in the rest of the line that has code missing! // No hints, there's no tricks, just get used to typing these :) // I AM NOT DONE fn main() { // Booleans (`bool`) let is_morning = true; if is_morning { println!("Good morning!"); } let // Finish the rest of this line like the example! Or make it be false! if is_evening { println!("Good evening!"); } } </code></pre> Our instructions tell us to complete the bit of code above. Let's take a look at the error output for more context. primitive_types1.cairo</code> Errors</h2> 🟡 Running exercises/primitive_types/primitive_types1.cairo exercise... Compiling exercise_crate v0.1.0 (/Users/desmo/repos/starklings-cairo1/runner-crate/Scarb.toml) error: Missing token TerminalUnderscore. --> /Users/desmo/repos/starklings-cairo1/runner-crate/src/lib.cairo:15:8 let // Finish the rest of this line like the example! Or make it be false! ^ error: Missing token TerminalEq. --> /Users/desmo/repos/starklings-cairo1/runner-crate/src/lib.cairo:15:8 let // Finish the rest of this line like the example! Or make it be false! ^ error: Missing token TerminalSemicolon. --> /Users/desmo/repos/starklings-cairo1/runner-crate/src/lib.cairo:18:6 } ^ error: Identifier not found. --> /Users/desmo/repos/starklings-cairo1/runner-crate/src/lib.cairo:16:8 if is_evening { ^^ could not compile `exercise_crate` due to previous error ⚠️ Failed to run exercises/primitive_types/primitive_types1.cairo! Please try again. </code></pre> The compiler provides useful hints such as error: Missing token TerminalSemicolon.</code> and error: Identifier not found.</code>. These indicate that we haven't completed the line of code, making it an incomplete statement. Let's fix this. primitive_types1.cairo</code> Solution</h2> As mentioned, we're not done with the line of code on line 15. Observing the code above, we see that is_morning</code> is assigned a bool</code> value of true</code>: let is_morning = true; </code></pre> Let's do the same for is_evening</code>. We can assign a bool</code> value to it, either true</code> or false</code>. We'll start with true</code>. let is_evening = true; </code></pre> With this change, the code compiles successfully! The output is: Good morning! Good evening! ✅ Successfully ran exercises/primitive_types/primitive_types1.cairo! </code></pre> If we change the bool</code> value to false</code>, the output changes accordingly: Good morning! ✅ Successfully ran exercises/primitive_types/primitive_types1.cairo! </code></pre> Here's the full corrected code: fn main() { // Booleans (`bool`) let is_morning = true; if is_morning { println!("Good morning!"); } let is_evening = true; if is_evening { println!("Good evening!"); } } </code></pre> Explanation</h3> Variable Declaration and Initialization: Initially, the code uses let</code> but doesn't assign any value to a variable.</li> Correcting it to let is_evening = true;</code> initializes is_evening</code> with the value true</code> (or false</code> if you prefer).</li> </ul> </li> Conditional Statement: The if</code> statement checks whether is_morning</code> and is_evening</code> are true</code> or false</code>.</li> If either is true</code>, it prints the appropriate message: "Good morning!"</code> or "Good evening!"</code> or even both.</li> If both are false</code>, it prints nothing but still compiles correctly.</li> </ul> </li> Experimentation: Changing the values of is_morning</code> and is_evening</code> to different bool</code> values and recompiling will result in different outputs based on the if</code> condition.</li> </ul> </li> </ol> Great let's move on to the next exercise! primitive_types2.cairo</code></h2> // primitive_types2.cairo // Fill in the rest of the line that has code missing! // No hints, there's no tricks, just get used to typing these :) // I AM NOT DONE fn main() { // A short string is a string whose length is at most 31 characters, and therefore can fit into a single field element. // Short strings are actually felts, they are not a real string. // Note the _single_ quotes that are used with short strings. let mut my_first_initial = 'C'; if is_alphabetic( ref my_first_initial ) { println!(" Alphabetical !"); } else if is_numeric( ref my_first_initial ) { println!(" Numerical !"); } else { println!(" Neither alphabetic nor numeric!"); } let // Finish this line like the example! What's your favorite short string? // Try a letter, try a number, try a special character, try a short string! if is_alphabetic( ref your_character ) { println!(" Alphabetical !"); } else if is_numeric( ref your_character ) { println!(" Numerical!"); } else { println!(" Neither alphabetic nor numeric!"); } } fn is_alphabetic(ref char: felt252) -> bool { if char >= 'a' { if char <= 'z' { return true; } } if char >= 'A' { if char <= 'Z' { return true; } } false } fn is_numeric(ref char: felt252) -> bool { if char >= '0' { if char <= '9' { return true; } } false } </code></pre> In this exercise, we are dealing with short strings in Cairo. A short string is a string whose length is at most 31 characters, and it can fit into a single field element (felt). Short strings are actually felts and not real strings. We need to use use single quotes for short strings. primitive_types2.cairo</code> Errors</h2> 🟡 Running exercises/primitive_types/primitive_types2.cairo exercise... Compiling exercise_crate v0.1.0 (/Users/desmo/repos/starklings-cairo1/runner-crate/Scarb.toml) error: Missing token TerminalUnderscore. --> /Users/desmo/repos/starklings-cairo1/runner-crate/src/lib.cairo:25:8 let // Finish this line like the example! What's your favorite short string? ^ error: Missing token TerminalEq. --> /Users/desmo/repos/starklings-cairo1/runner-crate/src/lib.cairo:25:8 let // Finish this line like the example! What's your favorite short string? ^ error: Missing token TerminalSemicolon. --> /Users/desmo/repos/starklings-cairo1/runner-crate/src/lib.cairo:37:6 } ^ error: Identifier not found. --> /Users/desmo/repos/starklings-cairo1/runner-crate/src/lib.cairo:28:13 ref your_character ^^ error: ref argument must be a variable. --> /Users/desmo/repos/starklings-cairo1/runner-crate/src/lib.cairo:28:13 ref your_character ^^ error: Identifier not found. --> /Users/desmo/repos/starklings-cairo1/runner-crate/src/lib.cairo:32:13 ref your_character ^^ error: ref argument must be a variable. --> /Users/desmo/repos/starklings-cairo1/runner-crate/src/lib.cairo:32:13 ref your_character ^**^ could not compile `exercise_crate` due to previous error </code></pre> The compiler errors indicate missing tokens such as TerminalUnderscore</code> and TerminalEq</code> and TerminalSemicolon</code>. Additionally, a the key errors ofIdentifier not found</code> and ref arguement must be a variable </code> suggest that your_character</code> is not correctly defined and referenced. primitive_types2.cairo</code> Solution</h2> To solve this, let's complete the line that define's your_character</code>. Here's the solution: fn main() { let mut my_first_initial = 'C'; if is_alphabetic( ref my_first_initial ) { println!(" Alphabetical !"); } else if is_numeric( ref my_first_initial ) { println!(" Numerical !"); } else { println!(" Neither alphabetic nor numeric!"); } let mut your_character = 'E'; // Finishing the line here if is_alphabetic( ref your_character ) { println!(" Alphabetical !"); } else if is_numeric( ref your_character ) { println!(" Numerical!"); } else { println!(" Neither alphabetic nor numeric!"); } } fn is_alphabetic(ref char: felt252) -> bool { if char >= 'a' { if char <= 'z' { return true; } } if char >= 'A' { if char <= 'Z' { return true; } } false } fn is_numeric(ref char: felt252) -> bool { if char >= '0' { if char <= '9' { return true; } } false } </code></pre> Explanation</h3> Variable Declaration and Initialization: • Initially, the code uses let</code> without assigning any value to your_character</code>. • Correcting it to let mut your_character = 'A';</code> initializes your_character</code> with a short string value, which can be a letter, number, or special character. </li> Conditional Statement: • The if</code> statement checks whether my_first_initial</code> and your_character</code> are alphabetic or numeric. • If either is alphabetic, it prints "Alphabetical!"</code>. • If either is numeric, it prints "Numerical!"</code>. • Otherwise, it prints "Neither alphabetic nor numeric!"</code>. </li> Ref Keyword: • The ref</code> keyword is used to pass the variable by reference to the is_alphabetic</code> and is_numeric</code> functions. </li> Experimentation: • Changing the values of my_first_initial</code> and your_character</code> to different short string values and recompiling will result in different outputs based on the if condition. </li> </ol> You might have noticed that we used the mut</code> keyword in the line let mut your_character = 'E';</code> and if you tried to experiment with removing it, you'd notice that the code doesn't compile anymore so, let's make sure we understand why that is happening. Why Mutability is Necessary</h3> Exclusive Access: The ref</code> keyword indicates that the function requires an exclusive reference to the variable. This exclusive access might involve potential changes or ensuring that no other references exist to maintain data integrity during the function’s execution. </li> Compiler Enforcement: Rust and Cairo enforce immutability by default to ensure safety and prevent unintended side-effects. By requiring variables to be explicitly marked as mutable, the language ensures that developers are aware of where changes can occur, thus making the code more predictable and safer. </li> Function Semantics: The functions is_alphabetic</code> and is_numeric</code> in this context do not modify the variable, but the use of ref suggests a potential for future modifications or an exclusive read, necessitating the variable to be mutable. </li> </ol> By marking your_character</code> as mut</code>, you signal to the compiler and future readers of the code that your_character</code> may be modified or requires exclusive access, aligning with the expected semantics of using ref</code>. primitive_types3.cairo</code></h2> // primitive_types3.cairo // Destructure the `cat` tuple to call print on each member. // Execute `starklings hint primitive_types3` or use the `hint` watch subcommand for a hint. // I AM NOT DONE fn main() { let cat = ('Furry McFurson', 3); let // your pattern here = cat; println!("name is {}", name); println!("age is {}", age); } </code></pre> here we have a very simple piece of code and our instructions are to destructure the cat</code> tuple to allow us to call print on each of the members of the tuple. We already know the problem, but just so we are consistent, let's look at the errors. primitive_types3.cairo</code> Errors</h2> 🟡 Running exercises/primitive_types/primitive_types3.cairo exercise... Compiling exercise_crate v0.1.0 (/Users/desmo/repos/starklings-cairo1/runner-crate/Scarb.toml) error: Missing token TerminalEq. --> /Users/desmo/repos/starklings-cairo1/runner-crate/src/lib.cairo:10:12 println!("name is {}", name); ^ error: Identifier not found. --> /Users/desmo/repos/starklings-cairo1/runner-crate/src/lib.cairo:10:28 println!("name is {}", name); ^^ error: Identifier not found. --> /Users/desmo/repos/starklings-cairo1/runner-crate/src/lib.cairo:11:27 println!("age is {}", age); ^^ warn: Unused variable. Consider ignoring by prefixing with `_`. --> /Users/desmo/repos/starklings-cairo1/runner-crate/src/lib.cairo:8:9 let cat = ('Furry McFurson', 3); ^^ warn: Unused variable. Consider ignoring by prefixing with `_`. --> /Users/desmo/repos/starklings-cairo1/runner-crate/src/lib.cairo:10:5 println!("name is {}", name); ^*^ error: Type annotations needed. Failed to infer ?2 --> /Users/desmo/repos/starklings-cairo1/runner-crate/src/lib.cairo:10:14 println!("name is {}", name); ^^ could not compile `exercise_crate` due to previous error </code></pre> We get a bunch of errors, but we know the cause we don't have our tuple destructured to allow us to print name</code> and age</code>. So let's fix it! primitive_types3.cairo</code> Solution</h2> fn main() { let cat = ('Furry McFurson', 3); let (name, age) = cat; println!("name is {}", name); println!("age is {}", age); } </code></pre> Using the (name, age)</code> syntax we can destructure the ('Furry McFurson', 3)</code> tuple into something that we can use later on in our print statements. This seems simple enough and our code compiles with these changes, so let's move on -- but wait, what do we see on the print out!? Running exercises/primitive_types/primitive_types3.cairo name is 1429073786950451143196132410355566 age is 3 ✅ Successfully ran exercises/primitive_types/primitive_types3.cairo! 🎉 🎉 The code is compiling! 🎉 🎉 </code></pre> The name we have in our program is 'Furry McFurson'</code> but we get a print out that says: 1429073786950451143196132410355566</code>, so what's going on here? Why Does the Output Show Numbers Instead of Strings?</h3> In Cairo, short strings are represented as felt252</code> (field elements), which are large numerical values. This is why printing a short string directly might show a long number instead of the expected text. The value 1429073786950451143196132410355566</code> is the result of encoding the entire string “Furry McFurson”</code> into a single large integer. This encoding typically involves treating the string as a sequence of characters and converting each character into its corresponding ASCII (or Unicode) value, then packing these values into a large integer. For simplicity, let’s break down a smaller example manually to understand how it works. I’ll also show you how to do it with “F”. Example with a Single Character Let’s take ‘F’. The ASCII value of ‘F’ is 70. In decimal, it is 70, which is straightforward. You can try this in the exercise and you will see 70</code> Example with a String For a string like “Furry”, we need to consider how each character is converted and packed together. Here’s a basic explanation: Convert each character to its ASCII value:</li> </ol> • ‘F’ -> 70 • ‘u’ -> 117 • ‘r’ -> 114 • ‘r’ -> 114 • ‘y’ -> 121 </code></pre> Pack these ASCII values together into a single large integer. This packing depends on the specific encoding scheme used. A simple scheme would be to treat the ASCII values as bytes in a large number.</li> </ol> Alright, let's not dive in too deep into the weeds here and stay focused and summarize what we did here. Explanation</h3> Tuple Destructuring: • The original problem requires us to destructure the tuple cat to access and print its individual elements. The solution correctly uses (name, age)</code> to destructure the tuple. • By writing let (name, age) = cat;</code>, the tuple ('Furry McFurson', 3) </code>is split into name</code> and age</code>. </li> String Representation in Cairo: • In Cairo, strings are represented as felt252</code> (field elements), which are large numerical values. • When we print a string directly, it shows the numerical representation instead of the readable text. This is why 1429073786950451143196132410355566</code> appears instead of “Furry McFurson”</code>. </li> </ol> Let's move on to our final exercise! primitive_types4.cairo</code></h2> // primitive_types4.cairo // Modify the integer types to make the tests pass. // Learn how to convert between integer types, and felts. // Execute `starklings hint primitive_types4` or use the `hint` watch subcommand for a hint. // I AM NOT DONE use traits::Into; use traits::TryInto; use option::OptionTrait; fn sum_u8s(x: u8, y: u8) -> u8 { x + y } //TODO modify the types of this function to prevent an overflow when summing big values fn sum_big_numbers(x: u8, y: u8) -> u8 { x + y } fn convert_to_felt(x: u8) -> felt252 { //TODO return x as a felt252. } fn convert_felt_to_u8(x: felt252) -> u8 { //TODO return x as a u8. } #[test] fn test_sum_u8s() { assert(sum_u8s(1, 2_u8) == 3_u8, 'Something went wrong'); } #[test] fn test_sum_big_numbers() { //TODO modify this test to use the correct integer types. // Don't modify the values, just the types. // See how using the _u8 suffix on the numbers lets us specify the type? // Try to do the same thing with other integer types. assert(sum_big_numbers(255_u8, 255_u8) == 510_u8, 'Something went wrong'); } #[test] fn test_convert_to_felt() { assert(convert_to_felt(1_u8) == 1, 'Type conversion went wrong'); } #[test] fn test_convert_to_u8() { assert(convert_felt_to_u8(1) == 1_u8, 'Type conversion went wrong'); } </code></pre> In this exercise we are tasked with modifying the integer types and felt252 to make the tests pass, seems simple enough let's take a look at the errors for any hints on how to fix this problem. primitive_types4.cairo</code> Errors</h2> 🟡 Testing exercises/primitive_types/primitive_types4.cairo exercise... Compiling test(exercise_crate_unittest) exercise_crate v0.1.0 (/Users/desmo/repos/starklings-cairo1/runner-crate/Scarb.toml) error: Unexpected return type. Expected: "core::felt252", found: "()". --> /Users/desmo/repos/starklings-cairo1/runner-crate/src/lib.cairo:21:38 fn convert_to_felt(x: u8) -> felt252 { //TODO return x as a felt252. ^***^ error: Unexpected return type. Expected: "core::integer::u8", found: "()". --> /Users/desmo/repos/starklings-cairo1/runner-crate/src/lib.cairo:24:41 fn convert_felt_to_u8(x: felt252) -> u8 { //TODO return x as a u8. ^^ error: The value does not fit within the range of type core::integer::u8. --> /Users/desmo/repos/starklings-cairo1/runner-crate/src/lib.cairo:38:47 assert(sum_big_numbers(255_u8, 255_u8) == 510_u8, 'Something went wrong'); ^^ </code></pre> Here we see that we have 3 main errors Unexpected return type</code> which is for our unfinished functions, and error: The value does not fit within the range of type core::integer::u8</code> which is telling us that the value doesn't fit in a u8</code>. So let's fix this. primitive_types4.cairo</code> Solution</h2> Since this one is a little more involved let’s work through the solution step-by-step. As we know the tasks involve modifying types to prevent overflow and converting between integer types and felt252. Step 1: Prevent Overflow in sum_big_numbers The function sum_big_numbers</code> currently takes u8</code> types, which can hold values from 0</code> to 255</code>. Summing two u8</code> values that are close to their maximum can cause an overflow. To prevent this, we’ll change the types to a larger integer type, such as u16</code>, which can hold values from 0</code> to 65535</code>. Step 2: Implement convert_to_felt and convert_felt_to_u8 For converting between u8</code> and felt252</code>, we’ll use the .into() and .try_into() traits. Step 3: Modify Tests Update the types in the test test_sum_big_numbers</code> to reflect the changes made in the sum_big_numbers</code> function. Here’s the modified code: use traits::Into; use traits::TryInto; use option::OptionTrait; fn sum_u8s(x: u8, y: u8) -> u8 { x + y } // Modified the types of this function to prevent an overflow when summing big values // from u8 to u16 fn sum_big_numbers(x: u16, y: u16) -> u16 { x + y } // Return x as a felt252 fn convert_to_felt(x: u8) -> felt252 { x.into() // use .into() method on x } // Return x as a u8 fn convert_felt_to_u8(x: felt252) -> u8 { x.try_into().unwrap() // use .try_into() with .unwrap() methods on x } #[test] fn test_sum_u8s() { assert(sum_u8s(1, 2_u8) == 3_u8, 'Something went wrong'); } #[test] fn test_sum_big_numbers() { // Modified this test to use the correct integer types from u8 to u16 assert(sum_big_numbers(255_u16, 255_u16) == 510_u16, 'Something went wrong'); } #[test] fn test_convert_to_felt() { assert(convert_to_felt(1_u8) == 1, 'Type conversion went wrong'); } #[test] fn test_convert_to_u8() { assert(convert_felt_to_u8(1) == 1_u8, 'Type conversion went wrong'); } </code></pre> with these these changes our code compiles and tests pass! Compiling test(exercise_crate_unittest) exercise_crate v0.1.0 (/starklings-cairo1/runner-crate/Scarb.toml) Finished release target(s) in 1 second running 4 tests test exercise_crate::test_convert_to_felt ... ok (gas usage est.: 900) test exercise_crate::test_sum_big_numbers ... ok (gas usage est.: 1670) test exercise_crate::test_convert_to_u8 ... ok (gas usage est.: 2010) test exercise_crate::test_sum_u8s ... ok (gas usage est.: 1670) test result: ok. 4 passed; 0 failed; 0 ignored; 0 filtered out; </code></pre> Explanation</h3> Prevent Overflow: The function sum_big_numbers</code> originally used u8</code> types, which can only hold values from 0</code> to 255</code>. Summing two large u8</code> values could cause an overflow.</li> To prevent this, we changed the parameter types from u8</code> to u16</code>. The u16</code> type can hold values from 0</code> to 65535</code>, thus avoiding overflow when summing large values.</li> </ul> </li> Implement Conversion Functions: convert_to_felt</code>: This function converts a u8</code> value to a felt252</code>. Using the .into()</code> trait, the conversion is straightforward.</li> convert_felt_to_u8</code>: This function converts a felt252</code> value back to a u8</code>. The .try_into()</code> trait is used for this conversion, and .unwrap()</code> ensures the conversion is successful. If it isn't, the program will panic.</li> </ul> </li> Modify Tests: Updated the test_sum_big_numbers</code> test to use u16</code> types for the values and the expected result. This matches the updated function signature and ensures the test values do not cause overflow.</li> The tests for conversion functions test_convert_to_felt</code> and test_convert_to_u8</code> confirm that the type conversions work as expected.</li> </ul> </li> </ol> By modifying the integer types from u8</code> to u16</code>, we prevent overflow in the sum_big_numbers</code> function. We implemented the conversion functions using .into()</code> and .try_into()</code> traits, ensuring seamless type conversions between u8</code> and felt252</code>. The tests were updated to reflect these changes, verifying that the functions operate correctly and the integer operations are safe from overflow. Conclusion</h2> Alright, we've finished! Well done if you are still reading. In this post of Starklings primitive_types</code> exercises, we explored fundamental concepts of working with primitive types in Cairo. Here’s a recap of what we covered: Basic Variable Initialization: • We started with simple variable initialization and boolean checks. By defining and using boolean variables, we learned how to control the flow of our program based on conditional statements. </li> Tuple Destructuring: • We looked into tuple destructuring, which allowed us to break down composite data structures into individual elements. This helped us print and manipulate each member of a tuple effectively. </li> Understanding Cairo’s String Representation: • We discovered how Cairo represents short strings as felt252</code>, which are large numerical values. We examined how these numerical values correspond to the original string and learned why they appear as large numbers when printed directly. </li> Preventing Overflow: • We addressed the issue of overflow by changing the integer types in our functions. By upgrading from u8</code> to u16</code>, we ensured that our functions could handle larger values without running into overflow problems. </li> Type Conversion: • We implemented functions to convert between different integer types and felt252</code>. Using the .into()</code> and .try_into()</code> traits, we efficiently converted u8</code> values to felt252</code> and vice versa, ensuring compatibility and correctness in our operations. </li> Modifying Tests: • Throughout the exercises, we modified tests to verify the correctness of our functions. These tests ensured that our functions behaved as expected, handling edge cases and type conversions properly. </li> </ol> By working through these exercises, we’ve unlocked a deeper understanding of primitive types in Cairo and learned how to manipulate them effectively. We’ve mastered writing robust code that seamlessly handles various data types and skillfully avoids common pitfalls like overflow. These foundational skills are our stepping stones as we venture into more advanced and exciting topics in Cairo programming.

The Machine in Motion (The Polish)</h2>
The "Core" version works, but it feels like a diagnostic test. Let's make it a finished visual.</p>

1. Tighten the Spawn Volume</h3>
Add `const STAR_SPREAD: f32 = 20.0;</code> at the top. Use this range in init_stars</code> and the recycling block: star.x = rng.gen_range(-STAR_SPREAD..STAR_SPREAD);</code> This makes the field feel deeper and less bunched.</p>`

References</h2>

Macroquad Docs</a></li>
Rust WASM Book</a></li> </ul>

desmo

Minimal Starknet Wallet PoC in Leptos

A Rust-Powered Starfield in the Browser with Macroquad + WASM

Starklings-Cairo1: Primitive Types

Starklings-Cairo1: Variables in Cairo

`Now Available in Video Format</h3> If you prefer watching over reading, a video version of this post is available.</p>`

desmo

Minimal Starknet Wallet PoC in Leptos

A Rust-Powered Starfield in the Browser with Macroquad + WASM

The Machine in Motion (The Polish)</h2> The "Core" version works, but it feels like a diagnostic test. Let's make it a finished visual.</p>

1. Tighten the Spawn Volume</h3> Add const STAR_SPREAD: f32 = 20.0;</code> at the top. Use this range in init_stars</code> and the recycling block: star.x = rng.gen_range(-STAR_SPREAD..STAR_SPREAD);</code> This makes the field feel deeper and less bunched.</p>

References</h2> Macroquad Docs</a></li> Rust WASM Book</a></li> </ul>

Starklings-Cairo1: Primitive Types

Starklings-Cairo1: Variables in Cairo

The Machine in Motion (The Polish)</h2>
The "Core" version works, but it feels like a diagnostic test. Let's make it a finished visual.</p>

1. Tighten the Spawn Volume</h3>
Add `const STAR_SPREAD: f32 = 20.0;</code> at the top. Use this range in init_stars</code> and the recycling block: star.x = rng.gen_range(-STAR_SPREAD..STAR_SPREAD);</code> This makes the field feel deeper and less bunched.</p>`

References</h2>

Macroquad Docs</a></li>
Rust WASM Book</a></li> </ul>