coreh

Bevy Remote Protocol (BRP)

The Bevy Remote Protocol (BRP) is a transport-agnostic and serialization-agnostic protocol for communication between a Bevy application (acting as a server) and a remote (or local) client. It's a request/response-style protocol (similar to HTTP), meaning that every communication is always initiated by the client, and the server only responds to the client's requests.

Example Uses

• A editor/inspector, allowing the user to inspect and modify the Bevy application's state in real time, both locally and remotely;
• “Gameshark“-style cheats, allowing the user to modify a game's state in real time;
• JS/HTML-based UI interacting with an embedded Bevy application running in a browser;
• Non-Bevy/Rust applications (e.g. a C++/Python/Java application) interacting with embedded Bevy modules;

nwtnni

//! Bevy Version: 0.10
//! Original: https://gist.github.com/GianpaoloBranca/17e5bd6ada9bdb04cca58182db8505d4
//! See also: https://github.com/bevyengine/bevy/issues/1515

use bevy::ecs::system::Command;
use bevy::prelude::*;

pub struct CloneEntity {
    pub source: Entity,
    pub destination: Entity,

SanderMertens

// Draft for low-level macro-less API
// 
// The goal of this draft is to explore a full-featured minimal API that does not rely on macro's. That should make it easier to port 
// flecs to other languages, and allow for more straightforward integration with other frameworks / engines. This is not meant as a
// full replacement for an application-facing API, though should be able to coexist with one.
//
// Inspiration for naming conventions & declarative design comes from Sokol Gfx

// Create world as usual
ecs_world_t *world = ecs_init();

javan

const files = {
  "m1.js": `import {func} from './m2.js'; console.log(func());`,
  "m2.js": `export function func() { return 'abc'; }`
}

const urls = new Map

function getURL(filename) {
  let url = urls.get(filename)
  if (!url) {

WebReflection

const env = {
  m1: `import {func} from './m2.mjs'; console.log(func());`,
  m2: `export function func() { return 'abc'; }`
};

const inlineModule = (env, text) => `data:text/javascript;base64,${
  btoa(inlineModules(env, text))
}`;

const inlineModules = (env, text) => text.replace(

dakom

Intro

The below is a breakdown / bird's eye view of how a sparse-array backed ECS like EnTT or Shipyard works.

Please see the thanks and references at the bottom - without their help I would not have been able to share this breakdown with you... everything here is really just notes and rephrasing of what they've written already :)

Also, these notes do not cover archetype systems (like unity) nor adaptations of archetypes (like in Flecs). Though there's a couple comparative footnotes at the end.

Here we go!

getify

"use strict";

[foo,bar] = TNG(foo,bar);
// NOTE: intentionally not TNG(..) wrapping useBaz(), so that it's
// basically like a "custom hook" that can be called only from other
// TNG-wrapped functions

function foo(origX,origY) {
   var [x,setX] = useState(origX);
   var [y,setY] = useState(origY);

alexey-bass

/**

Useful links
https://wiki.wemos.cc/products:d1:d1_mini
https://cdn-images-1.medium.com/max/1400/1*YKc8KpAfMrlhrOLmNjdRwQ.png (D1 full pinout)
https://github.com/Jorgen-VikingGod/ESP8266-MFRC522
https://github.com/miguelbalboa/rfid

d1 mini rc52 wiring
https://discourse-cdn-sjc1.com/business5/uploads/mydevices/original/2X/e/ecedba79dc05f2c0b02b7fba8b3da2681590a11a.jpg

timj-unity

System update order

In ECS all systems are updated on the main thread. The order in which the are updated is based on a set of constraints and an optimization pass which tries to order the system in a way so that the time between scheduling a job and waiting for it is as long as possible. The attributes to specify update order of systems are [UpdateBefore(typeof(OtherSystem))] and [UpdateAfter(typeof(OtherSystem))]. In addition to update before or after other ECS systems it is possible to update before or after different phases of the Unity PlayerLoop by using typeof(UnityEngine.Experimental.PlayerLoop.FixedUpdate) or one of the other phases in the same namespace.

The UpdateInGroup attribute will put the system in a group and the same UpdateBefore and UpdateAfter attributes can be specified on a group or with a group as the target of the before/after dependency.

To use __UpdateIn

claudiopro

/node_modules/
module.js