| // Handle-based array. Used like this: | |
| // | |
| // Entity_Handle :: distinct Handle | |
| // entities: Handle_Array(Entity, Entity_Handle) | |
| // | |
| // It expects the type used (in this case | |
| // Entity) to contains a field called | |
| // `handle`, of type `Entity_Handle`. | |
| // | |
| // You can then fetch entities using |
| package main | |
| import "core:fmt" | |
| import "core:math" | |
| import "core:math/linalg" | |
| import rl "vendor:raylib" | |
| main :: proc() { | |
| rl.SetConfigFlags({.VSYNC_HINT, .WINDOW_RESIZABLE, .MSAA_4X_HINT}) | |
| rl.InitWindow(800, 600, "collision") |
This git include a list of programs, tools, engines and libraries free and open source intended to make videogames.
NOTE: This gist is a support material for the talk "Open Source and Videogames" given by me, Ramon Santamaria, on October 26th 2021 in Canòdrom, Barcelona. All the materials listed here were explained in detail in a +2 hours talk.
| # Blender Python script for converting a mesh to GLB with Draco compression. | |
| # Tested on Blender 2.82 | |
| # Usage: | |
| # blender --background --factory-startup --addons io_scene_gltf2 --python blender_compress_mesh.py -- -i #{source_path} -o #{out_path} | |
| from os import path | |
| from contextlib import redirect_stdout | |
| from sys import argv | |
| import argparse | |
| import io | |
| import bpy |
A couple of weeks ago I played (and finished) A Plague Tale, a game by Asobo Studio. I was really captivated by the game, not only by the beautiful graphics but also by the story and the locations in the game. I decided to investigate a bit about the game tech and I was surprised to see it was developed with a custom engine by a relatively small studio. I know there are some companies using custom engines but it's very difficult to find a detailed market study with that kind of information curated and updated. So this article.
Nowadays lots of companies choose engines like Unreal or Unity for their games (or that's what lot of people think) because d
State machines are everywhere in interactive systems, but they're rarely defined clearly and explicitly. Given some big blob of code including implicit state machines, which transitions are possible and under what conditions? What effects take place on what transitions?
There are existing design patterns for state machines, but all the patterns I've seen complect side effects with the structure of the state machine itself. Instances of these patterns are difficult to test without mocking, and they end up with more dependencies. Worse, the classic patterns compose poorly: hierarchical state machines are typically not straightforward extensions. The functional programming world has solutions, but they don't transpose neatly enough to be broadly usable in mainstream languages.
Here I present a composable pattern for pure state machiness with effects,
Orthodox C++ (sometimes referred as C+) is minimal subset of C++ that improves C, but avoids all unnecessary things from so called Modern C++. It's exactly opposite of what Modern C++ suppose to be.
| in vec2 v_texcoord; // texture coords | |
| in vec3 v_normal; // normal | |
| in vec3 v_binormal; // binormal (for TBN basis calc) | |
| in vec3 v_pos; // pixel view space position | |
| out vec4 color; | |
| layout(std140) uniform Transforms | |
| { | |
| mat4x4 world_matrix; // object's world position |
| #include <ao/ao.h> | |
| #include <sndfile.h> | |
| #include <signal.h> | |
| #define BUFFER_SIZE 8192 | |
| int cancel_playback; | |
| void on_cancel_playback(int sig) { | |
| if (sig != SIGINT) { |
