Skip to content

Instantly share code, notes, and snippets.

View WarpspeedSCP's full-sized avatar

wscp WarpspeedSCP

11 followers · 2 following
View GitHub Profile
@WarpspeedSCP
WarpspeedSCP / bfvm.rs
Created July 5, 2019 12:57
A brainfuck interpreter in rust. Takes input from stdin.
use std::env::args;
use std::io::{stdin, Read, BufRead};
use std::u8;
use std::fmt::{self, Display};
struct BFVM {
data: Box<u8>,
instr_data: Vec<u8>,
loop_stack: u32,
data_ptr: usize,
@WarpspeedSCP
WarpspeedSCP / GSoC_mid_report.md
Last active July 9, 2019 18:23
A mid-project report of what i've done in GSoC 2019

About this project

Godot engine is pretty easy to use for most things and is becoming a better competitor to unreal engine and unity by the day. But one area where it's lagging behind is in the way it handles file and network IO on various platforms, especially on systems like consoles.

Nowadays, all IO operations are cached to speed up access to data from hard drives or the network. The cache sits in RAM and holds on to information that is frequently accessed so we don't need to wait a long time for the data. For desktop and mobile systems (like android and iOS), this may be less of a problem because the OS can provide caching for disk and network IO. But consoles and other more specialised systems may not have an OS that does this for us, which means we may need to do the caching ourselves.

@WarpspeedSCP
WarpspeedSCP / GSoC_2nd_update_report.md
Last active August 13, 2019 17:27

Current progress

Since the last update, I've fixed a lot of bugs and made a bunch of simplifications to the design of the cache module.

  • Lots of bug fixes.
@WarpspeedSCP
WarpspeedSCP / GSoC_end_update_report.md
Last active August 26, 2019 19:44
GSoC 2019 end report

Motivation

The goal of my project was to replace the already existing FileAccessBuffered class with a more flexible and robust solution for caching IO without relying on the OS, on any platform including desktop and consoles.

The old solution to the problem of cached IO was to use FileAccessBuffered. This was a problem because FileAccessBuffered only supported reading ahead and did not allow for seeking.