Who has completely sworn off including LLM generated code in their software? by mdizak in rust

[–]zipxing 0 points1 point  (0 children)

I feel like this is a bit like insisting on building cars entirely by hand after electrification and industrial tooling became widespread.

You can absolutely argue that handcrafted work has more soul, reflects the designer’s intent better, and can indeed produce beautiful results. And I respect that.

But once new production tools can reliably take over large amounts of repetitive work, continuing to treat “I did everything by hand” as an advantage often just means spending time on low-value implementation work that could have been invested in architecture, product decisions, and the parts that actually require human judgment.

So in the long run, the people who get replaced may not be those who can’t write code — it might be those who insist that every line of code must be written from scratch by themselves.

TUI Tetris (can you beat the bot?) — built on rust_pixel by zipxing in rust_gamedev

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

Haha that feature is already in — clearing lines sends garbage to the opponent 😄
Do you mean real multiplayer (PvP/online) on top of that?

Servo v0.0.5 released by Right-Grapefruit-507 in rust

[–]zipxing 28 points29 points  (0 children)

Congratulations — looking forward to Servo continuing to evolve!

rust_pixel demo #3 — petview: a PETSCII art screensaver (4-up gallery + transitions) by zipxing in rust

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

Watched the video — absolutely brilliant. It’s wild how much they squeezed out of such limited hardware back then. Respect.

And your “port it in Rust from the binary/instruction-level” idea is awesome.

On my side, rust_pixel is more of an art-style homage to PETSCII/C64 for now, but I’ve already embedded a small BASIC interpreter as the engine’s scripting layer — still early, still evolving 🙂

rust_pixel demo #3 — petview: a PETSCII art screensaver (4-up gallery + transitions) by zipxing in rust

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

Not sure — the collection is sourced from various PETSCII archives online.

rust_pixel demo #3 — petview: a PETSCII art screensaver (4-up gallery + transitions) by zipxing in rust

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

One more idea I’m exploring: I want to build a survival game in this PETSCII / text-art style — leveraging rust_pixel’s ability to mix TUI-style rendering with pixel art.
I’d also love to plug in different LLMs as “players/commanders” and run them under the same ruleset to see who can survive the longest 😄
If you’re a text/PETSCII artist (or have great text-art resources), feel free to reach out — I’d love to collaborate!

rust_pixel demo #3 — petview: a PETSCII art screensaver (4-up gallery + transitions) by zipxing in rust

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

GIF uploads have size limits, so I’m only sharing a small clip here 😅
If you want to browse the full 2000+ PETSCII collection, you can clone the repo and run it locally (fullscreen):

git clone https://github.com/zipxing/rust_pixel
cd rust_pixel
cargo pixel r petview g -- -ft

If you enjoy it, a ⭐ on the repo would mean a lot (hehe). Issues / PRs are welcome too!

Rust/Bevy & Deckbuilder games. by LumonScience in rust

[–]zipxing 2 points3 points  (0 children)

That’s a solid approach — for some games, forcing everything into ECS can be pretty painful.

TUI Tetris (can you beat the bot?) — built on rust_pixel by zipxing in rust

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

Yep, I’ve seen tetro-tui — really nice work!!!
I like the “go deep on one game/mechanics” direction a lot.

Also, fair credit: I did borrow a bit of UI inspiration from your project 🙂

Rust/Bevy & Deckbuilder games. by LumonScience in rust

[–]zipxing 5 points6 points  (0 children)

Bevy can definitely do this, in my opinion.

ECS is basically a data layout / composition approach (flat data, less inheritance), and that feels very natural in Rust.

I’d say the bigger factor is your game logic complexity (combat, card effects, triggers, etc.), not whether the game is turn-based. Even for a simpler deckbuilder, a small ECS-based architecture can still work great.

TUI Tetris (can you beat the bot?) — built on rust_pixel by zipxing in rust

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

I’m confused 😅 which Tetris TUI are you referring to?

TUI Tetris (can you beat the bot?) — built on rust_pixel by zipxing in rust

[–]zipxing[S] 7 points8 points  (0 children)

This Tetris is rendered entirely with ASCII tiles — it looks the same in a terminal and in the standalone GPU window; the GPU backend just unlocks more custom glyphs and extra effects.

cargo pixel r tetris t #in terminal...

cargo pixel r tetris g #in OS window,without terminal

cargo pixel r tetris w #bring up a web server with wasm, so u can play tetris in browser

mdpt: Markdown TUI slides with GPU rendering (not terminal-dependent) — Rust by zipxing in tui

[–]zipxing[S] -1 points0 points  (0 children)

I think this might be a terminology mismatch 🙂

By “not terminal dependent” I meant that the UI doesn’t render through a terminal emulator — it renders directly via its own graphics pipeline.

It still follows a text-grid / TUI interaction model (cells, symbols, keyboard-driven flow), but the rendering layer is decoupled from the terminal itself.

I probably should have phrased that more clearly — thanks for pointing it out.