No videos found
No videos available in the uploads directory. Check the connection to the server.
No videos available in the uploads directory. Check the connection to the server.
The Living Computer: From Grown Neurons to a Self-Developing Biological-Computational Organism The Living Computer From grown neurons to a self-developing biological-computational organism What would happen if we stopped thinking of artificial intelligence as something that has to exist entirely inside conventional computer hardware? Instead of building every neuron as a mathematical function running on silicon, imagine building a computational system around living neural tissue. The computer would still contain processors, memory, sensors, databases, artificial intelligence and communications hardware. But part of the actual computation would occur inside living neurons. Now take that idea further. Give the neural system sensory information. Give it a body. Give it a simulated environment. Let it make mistakes. Let it learn from consequences. Give it memory. Give it a mechanism for deciding what it wants to investigate. Give an external AI the ability to explain things and search for information. Let the system gradually construct its own model of the world. Then connect that system to biological sensory organs. Then imagine connecting parts of it to an animal nervous system. Then imagine its artificial body, biological nervous system and digital intelligence becoming parts of the same continuously interacting loop. At the farthest edge of the idea, the system could recognize that it lacks some capability, research how that capability might be created, design a solution and eventually interact with biological fabrication systems capable of producing new tissue. SENSATION → PREDICTION → ACTION → CONSEQUENCE → LEARNING → MEMORY → EXPLORATION That final organism does not exist. But remarkably, many of the individual technologies needed to begin exploring the architecture already exist in primitive or highly specialized forms. The interesting question is therefore not whether someone can build the entire system tomorrow.The interesting question is how far the pieces could be connected before the system...
Loading LLMs with C++ – BrainFile AI and Evolving NPC Intelligence 🧠 ARTIFICIAL INTELLIGENCE ⚡ C++ / GAME AI ⏱️ 12 MIN READ • OCTOBER 2026 Loading LLMs with C++:BrainFile AI and the Evolution of Intelligent NPCs Large language models are changing how we think about game intelligence, but running an LLM is only the beginning. By combining C++ inference, persistent BrainFile-style memory, spiking neural systems, and genetic algorithms, developers can build characters that do more than respond to dialogue. They can remember experiences, develop behavioral traits, and evolve into distinct NPCs and companions over time. We explore how this architecture could work in practice. 📐 Part 1: Loading the Intelligence – C++ and Local LLMs C++ offers game developers a direct route to integrating artificial intelligence into an existing engine. Unlike external AI services that require internet connectivity and remote processing, local LLM inference allows a game to run its language model directly on the player's hardware. This opens the door to offline conversations, responsive character behavior, and AI systems that can interact with the game world without sending every request to an external server. One of the most accessible approaches is llama.cpp, an open-source C/C++ inference implementation designed to run large language models across a variety of hardware configurations. It supports GGUF model files and provides CPU and supported GPU acceleration, allowing developers to select models based on available system memory and performance requirements [1]. The important distinction is that loading an LLM does not mean rebuilding the model every time a character speaks. The model is loaded into memory, receives a structured prompt containing relevant context, and generates a response. The game engine then interprets that response and decides which actions are permitted. This separation allows the language model to provide intelligence while C++ retains control...
Quantum Logic Gates and Japan's Room-Temperature Quantum Computing Breakthrough ``` ⚛️ QUANTUM 🇯🇵 JAPAN ⏱️ 12 MIN READ • OCTOBER 2026 Quantum Logic Gates: Inside Japan's New Room-Temperature Quantum Era Quantum computers have traditionally been associated with enormous cryogenic refrigerators, fragile hardware and temperatures approaching absolute zero. Japan is now pursuing a different architecture. Neutral atoms and photons can retain and manipulate quantum information without putting the entire computing system inside a dilution refrigerator. In 2026, Japan began operating new quantum systems designed around this idea, including the full-stack neutral-atom computer Shunkai and the optical quantum computer MoQuren. ⚙️ Part 1: What Is a Quantum Logic Gate? A classical computer processes information using bits that normally have one of two values: 0 or 1. Quantum computers instead manipulate qubits, which can exist in combinations of quantum states. A single qubit can be represented mathematically as: |ψ⟩ = α|0⟩ + β|1⟩ |α|² + |β|² = 1 The values α and β are probability amplitudes. A quantum gate changes these amplitudes in a precisely controlled way. This makes a quantum gate fundamentally different from simply switching a transistor on or off. Quantum gates manipulate the mathematical state of the qubit, including its phase, allowing later operations to interfere constructively or destructively. The X Gate — Quantum NOT The X gate is the quantum equivalent of a classical NOT operation: X|0⟩ = |1⟩ X|1⟩ = |0⟩ Its matrix representation is: X = [ 0 1 ] [ 1 0 ] The H Gate — Creating Superposition The Hadamard, or H gate, is one of the most important operations in quantum computing. Starting with a qubit in the state |0⟩, it produces an equal superposition: H|0⟩ = (|0⟩ + |1⟩) / √2 Applying the H gate again reverses the operation: H(H|0⟩) = |0⟩ The important...
Google Earth for Game Makers – Tark and Modern API Approaches 🌍 TARK 🎮 GAME MAPS ⏱️ 15 MIN READ • AUGUST 2026 Google Earth for Game Makers:Tark and the Modern API Landscape For years, game developers have dreamed of using Google Earth's vast real‑world data as a playable map. The path has evolved from browser plugins to modern APIs and third‑party tools like Tark, which converts any location into a game‑ready 3D mesh in minutes. This article explores how to turn the planet into your game world using Tark and Google's current mapping ecosystem. 🗺️ Part 1: The Dream of a Real‑World Game Map The concept of using Google Earth as a game world is not new. As early as 2011, projects like Travel Game used the Google Earth API to build online social games where players navigated a 3D globe. The API allowed developers to control Earth movements, place targets, and track user positions relative to real‑world coordinates. Similarly, educational games like Penn State's Amazing Race used the Google Earth plugin to teach geography by having students identify countries and landmarks on a 3D globe. These early efforts relied on the Google Earth Plugin – a browser‑based NPAPI component that rendered the Earth inside web pages. However, the plugin is now largely obsolete, as modern browsers dropped NPAPI support. The plugin's core functionality – placing markers, controlling camera views, loading KML data – still influences how we think about Earth‑based games, but the technical foundation has shifted. 🌐 Part 2: Tark – The Modern Solution for Game Developers Tark (GitHub – rickytang666/tark) is an open‑source web application built specifically for game developers who want to use real‑world locations as game maps. It is not a Google Earth plugin; it is a standalone tool that generates game‑ready 3D...
Engineering · Cryptography Pinwheel: One Encrypted Chatroom,Two Front Doors secupgrade.com and secupgrade.com/live look like two different sites with two different chat widgets. They aren't. They're two doors into the exact same end-to-end encrypted room — and the server behind both of them structurally cannot read a word of it. By JJustis Engineering deep-dive secupgrade.com 💬 secupgrade.com Bottom-right "Live.Private.Discuss" widget. Sign in, register, or join as a guest — same accounts as /live. ↔ 🔒 secupgrade.com/live The Secure Chat panel — the original Pinwheel implementation, same encrypted session. Because both surfaces share one PHP session cookie and call the identical secure_chat_* API on /live, signing in on either page authenticates both. A message typed in the root site's widget and a message typed in /live's panel land in the same session row, decrypt with the same group secret, and render for every member of the room — because they are, cryptographically, the same conversation. The core design decision The server relays bytes. It does not hold a key that opens them. Most "encrypted" chat features you'll run into generate the encryption key on the server and hand a copy to every client that asks for it. That's confidential against someone sniffing the network — it is not confidential against the server itself, since the server minted the key. Pinwheel does the opposite: every key that can decrypt a message is generated in the browser, using the Web Crypto API, and the server never receives a copy in usable form. "The server relays opaque encrypted data — it never holds a key that can read your messages." This is the literal on-screen copy shown during setup. It is also, mechanically, true. Architecture Two independent layers, two different trust models Pinwheel isn't one encryption scheme — it's two, stacked, each doing a...