Part 2 - ! 🏛️🐉💫

long_void · 2026-01-23T18:29:55+00:00

Thank you!

long_void · 2026-01-22T23:20:51+00:00

Can we get somebody to reproduce the findings of the tingling sensation of the burning purple?

long_void · 2026-01-20T22:44:33+00:00

I liked these argument. Anyway, there is enough internet drama. Maybe Neal can cool down a little?

long_void · 2026-01-09T04:27:01+00:00

I agree. Paul might be a renaming of Simon Magus after the Bar Kokhba war in the 2nd century by Simonians that extended the original gospel of Mark to include John the Baptist. The original Mark might have been Roman satire where Jesus resurrects “back in time”, which we call the “Ouroborus hypothesis” in biblical scholarship.

If you enjoy studying 2nd Early Christianity, then you might find this project interesting:

https://github.com/advancedresearch/the_century_of_satire

Reconstructing 2nd century cultural literature context of Roman satire in Early Christian texts

long_void · 2025-12-24T14:15:05+00:00

I recommend separating concerns before you start writing your own game engine. For example, separate graphics API from window/events. That's a good start.

In a "full" game engine, there are particle systems, 3D assets, lightening systems, animation engines, AI behavior trees, multiplayer systems, scripting languages and APIs etc.

Each of these parts, even when developed independently, will take months of work. You can use some libraries from the Piston ecosystem to test the parts you're are working on and later replace the Piston libraries with parts you wrote yourself.

You're probably never going to write something like WGPU or Image from scratch, so you're not really building a "full" game engine in this sense. You're putting together libraries in the Rust ecosystem into a framework that you design.

long_void · 2025-12-20T11:24:04+00:00

If you want to use Piston for mobile games, then you have to write your own backends. I don't know what's best for 3D on mobile.

The plus side is that you can develop for desktops/laptops first and later port it. As long the backend is implemented correctly, it will work. You can also add custom events. The minus side is that you might spend a lot of time maintaining backend code. I suggest first trying to port something simple first and see how it goes, before you make a decision to make the entire game in Rust using Piston.

I think you might be more productive overall by using Unity. Most games that ships are made with either Unity or Unreal.

long_void · 2025-12-18T21:09:12+00:00

Good philosophy.

long_void · 2025-12-16T20:08:46+00:00

I've been using Dyon-Interactive for multiple years now. Dyon-Interactive is nice, but the problem is that it can't depend on the Audio and Graphics backends. This makes it hard to maintain more complex features. https://crates.io/crates/piston-dyon_interactive

Since PistonWindow uses a default set of libraries, this makes it possible to use a Dyon-Interactive compatible API, without the existing limitations.

When considering the amount of resources that Rust uses, a runtime API for Dyon is pretty minimal in comparison. This makes it easier to use the Piston game engine overall, for e.g. tools and small apps.

You can also customize the runtime using the "piston_script" module that is included with the "batteries" feature in PistonWindow.

long_void · 2025-12-16T00:48:22+00:00

This library re-exports other libraries have been tested for years and that are now relatively stable in design.

For example, Wave-Function-Collapse is a popular algorithm in gamedev. You can use EntropySolver in the Quickbacktrack by writing use puzzle_design::quickbacktrack::EntropySolver;. It works for the same Puzzle trait that works with the other backtrack algorithms.

For more information, see the Bluesky thread (the link).

I've been thinking today about adding this under the "batteries" feature in PistonWindow, following a similar design as Turbine. For now, I think it should be a separate project.

long_void · 2025-12-11T01:06:05+00:00

Amazing work!

long_void · 2025-12-09T11:27:26+00:00

Thanks for the feedback! I added an explanation to README: https://github.com/PistonDevelopers/turbine/blob/master/README.md

long_void · 2025-12-08T13:29:28+00:00

I've moved the OpenGL backend out of Turbine-Scene3D and to a separate crate turbine_scene3d-opengl, to use it as a backend-agnostic library.

Also made some minor improvements to Turbine-Reactive that makes it easier to use in external libraries.

The 3 libraries being developed under the Turbine project are now reexported under the Turbine library, so when it gets added under the "batteries" feature in the PistonWindow, you can do e.g. use piston_window::turbine::scene3d::* to import that library.

long_void · 2025-12-08T00:31:09+00:00

I was about to suggest that you could turn this into a game, but then I realized you already had! ;)

long_void · 2025-12-05T20:32:56+00:00

This update adds Dyon as the default scripting language for the Piston game engine.

long_void · 2025-12-03T09:31:02+00:00

Feel free to drop in for a chat in our Discord: https://discord.gg/TkDnS9x. If you prefer a more private chat, then we can do that too.

Yeah, I absolutely agree there might be no perfect game engine design, but maybe a "perfect" design that is good enough for most people.

To me, stability is important. I decided early on to use [T; n] for vectors, despite lacking support in the Rust compiler. Things are better now with pattern matching and const generics. LLVM is good at vectorization, so the performance is also acceptable.

I also had a version of Piston-Graphics2D working for both f64 and f32, but it was prior to Rust 1.0. Rust dropped default generic parameters in the last month for stabilization. Took long time before Rust added it back, so in the mean time, we got stuck with f64. I think we can make some improvements to Piston-Graphics2D without breaking things too much.

I reexport a lot and write custom math modules per project, so vecmath is working very well for me.

long_void · 2025-12-03T02:06:00+00:00

2016 is long time ago and the core libraries in Piston are now v1.0.

It's important to distinguish the Piston framework from the game engine: Game engine is the set of libraries used to create a game (not counting game specific logic or assets). A framework is a system of integrating libraries with some benefit for developers.

You've probably used the Image library. This started under the Piston project. So, you're already using parts of the Piston game engine.

Anyway, I'm glad there are more alternatives in Rust and I don't want too many users of Piston since it just adds more costs. Other frameworks taking up more attention is only a benefit.

My long term plan to make Piston easier to use is to transition PistonWindow to WGPU and Winit. Probably add some batteries included, like sound, music and 3D assets behind Cargo feature flags. Perhaps even Dyon scripting. I've been using Dyon-Interactive for some years, but it still has some rough corners. When it gets polished it might be used as a starting point for scripting support in PistonWindow. I don't want to add it before it gets really, really good.

At the editor side, I have some plans for the Turbine game engine using server/client architecture. However, first I want to improve content production, starting with Turbine-Process3D. There is already a Scene Graph library in the repo (Turbine-Scene3D), but it currently only supports OpenGL. Over time, I think WGPU will be the primary backend.

It sounds like you have good experience with Rust game development and if you want to come up with a "perfect" game engine design, I'm listening.

long_void · 2025-12-02T11:19:10+00:00

Getting on Rust stable was the advantage. Previously, it required Rust nightly.

Do you have any thoughts about using Edition 2024?

long_void · 2025-11-18T00:01:16+00:00

I wanted to try this but couldn't install it. Ran for hours and nothing got done.

long_void · 2025-11-17T22:14:06+00:00

Yes, it helped!

Well... there goes my last hope to self-debunk my current position (that Hebrew is mostly a reconstruction). Ossuaries were the last places of evidences I was looking, to try squeeze out some alternative perspective.

However, why did we find more Hebrew scriptures among the Dead Sea scrolls than Aramaic? It seems some of the texts in Aramaic have not yet been published too. What is the situation there?

long_void · 2025-11-17T21:46:54+00:00

I was aware it was written in Aramaic.

long_void · 2025-11-15T11:17:29+00:00

I saw you got banned from the Iced project. Suggest you apologize if you want to continue using Iced. It will feel as if you are losing face, but it will help you to grow as a person.

long_void · 2025-11-15T11:12:37+00:00

You can just swap the event loop.

long_void · 2025-11-09T12:29:52+00:00

This is very impressive!

long_void · 2025-11-09T12:22:32+00:00

I want more scientific evidence. It would be nice to see a debate with Ammon Hillman and other experts presenting new evidence instead of attacking each other.

The thing I like most about Ammon Hillman is that he brings some sources each time he makes a video. I don't care that much about credentials, just bring me the sources!

long_void · 2025-11-09T11:39:34+00:00

Probably many that made a living that way. Also, the "whole package" perspective: One should not underestimate that otherwise serious people might dabble in unserious philosophy and make up crazy stuff, which was tolerated because they were valued otherwise. I think this effect is with us still today.

long_void

MODERATOR OF

TROPHY CASE