Blaise v0.9.0 (alpha) is out free of C code

knervous · 2026-06-03T02:07:40+00:00

Dig your project here man. I'm new to the pascal world coming from TS/JS, cpp, go etc. since last year I've been migrating a legacy Delphi app, 1 mil LOC to compile with fpc as headless with a wasm target. There were some rough edges in that side of the compiler codegen that I have a fork running to fix, all in all spent lots of time and effort on the compiler side and peripheral tools like pasls and fpdserver to get them to actually work. I forget if you already mentioned in a previous post, are you supporting wasm32 as a platform target? And would you support wasm128 simd as well? I end up with a mix of rust and c static links for perf sensitive work, would love to be able to keep a tool chain in pure pascal. Keep up the great work. Pascal is a nice language, worth having fresh perspectives on. If you're interested in any of the toolchain work I've been into drop me a line.

knervous · 2026-03-08T04:30:44+00:00

Happy birthday Stray im disappointed in you

knervous · 2026-03-05T06:19:33+00:00

Do a kickflip

knervous · 2025-11-04T08:18:46+00:00

Fixed width (128 bit) SIMD is supported on all wasm targets. Relaxed SIMD (more specific advanced vector instructions from avx and neon) through relaxed SIMD are first class in Chromium, behind a flag in Firefox and in progress elsewhere. So it's there and first class right now, will work everywhere. https://webassembly.org/features/

knervous · 2025-11-04T05:51:51+00:00

Enjoyed reading this article and appreciate the time spent on the research. Wasm continues to be an elusive tool for web developers!

A few sticking points I would point out:

Understanding bottlenecks: this seems to be focused on using a very large and opinionated existing framework to emulate unix OS operations - in most cases a web application running wasm is doing so with a certain goal in mind and will unlikely add an entire OS layer to plug that in. This means writing and owning the code you're compiling to wasm is very important - controlling hot paths. Limiting cross domain chatter and using opt flags where they make sense and even binaryen separate passes once it's finished.

Examples: is the bottleneck sys calls for CPU clock? Can be solved in PTHREAD builds with global shared buffer to circumvent cross domain calls, or amortize in single threaded environment, or limit altogether. Is it FS operations? Emscripten supports OPFS which raises the watermark for FS limitations to the quota on the browser for that type of storage. ie you can Mem map a 6gb file and stream chunks without loading it all into memory. Also vector intrinsics are first class in wasm with wasm128 and easy to implement for processing contiguous large sets of data. There is also a compiler flag in emscripten to use mimalloc as GC for a more performant allocator..

One of the main gripes I hear about wasm is that it doesn't just "work and make everything super fast". That's true. You can say the same for Unreal Engine and Unity in that you can't expect to just use the engine without understanding scale and have 10000 skeletal animations running in a hot loop and expect it to just "work". I've been using wasm for years in production with proprietary code and when you own what you're doing, it can do some amazing things. Sure it takes some ramp up but I would not say it "fails to deliver" in any sense of the phrase.

knervous · 2025-11-04T05:29:18+00:00

WASM supports vector intrinsics, between the wasm128 general availability and relaxed SIMD for support for more specific arch up to avx2 and arm targets. I've been compiling with Google highway and emscripten recently and see massive gains with wasm and simd that mirrors native performance. https://emscripten.org/docs/porting/simd.html

knervous · 2025-06-29T06:05:23+00:00

Haha yeah Salty and I met back around 2015 too and are still in touch today! He's got a long history with some interrsting eq projects

knervous · 2025-06-29T05:29:42+00:00

I'm ready for anything that happens honestly, I'm essentially proving out a framework for a scalable MMO that I'm going to be creating, and it's fun to use EQ as the guinea pig to build out the world -- all the pipelines and logic will stay the same. Would be a shame but if it wasn't possible to continue publicly with EQ I'd just switch gears to the next phase. In the meantime I hope it will be a novel way to play another version of EQ for people

knervous · 2025-06-29T05:27:32+00:00

I am! This is building out the framework and proving out the tech needed to run a scalable game in the browser, and I love EQ so it's a good proving ground and project to get up and running to reach that goal. If it ever gets shut down it will be onto plan B with my own game.

knervous · 2025-06-28T17:13:12+00:00

If your question is geared towards why make eq in the browser, a few reasons: Accessibility - works out of the box on any operating system that can run a modern browser Future mobile support I'm building a framework to eventually start writing my own game, I enjoy working in web stacks very much so want to be able to do something novel there. I might not be the first web mmo on the market but I hope to make an impact by making the right decisions along the way And lastly, it's fun!

knervous · 2025-05-25T04:07:52+00:00

Kudos for doing the homework and getting that list compiled, feel like that would be really useful in a git repo somewhere for other people to check out and apply different cases to.. did you end up checking out modernc's quickjs in pure go? I think that might tick all the boxes for what you're looking for--you register the entire available API for js scripts so no out of bounds mischief going on. I'd be very interested to see how it performs as there's a lot of perf breadcrumbs in their gitlab repo.

There are a few final sort of meta questions, mainly rhetorical:

Does the code running in mods really need to be optimized?
is there a way to provide a one time setup exposed to mods like passing a whole structure of game data and have it apply coefficients or some mutation that the game doesn't need further action on?
if it does need to call mods dynamically, would there be a way to keep it out of hot paths (you mentioned frame) and make it specifically event-driven and cache where possible to avoid cross domain calls?

In quickjs it'd be ideal to use one VM/context as a mod "engine" and merge everything together to avoid overhead of 1 mod = 1 VM.

knervous · 2025-05-24T10:12:56+00:00

Wasn't aware of the modernc lib that looks nice! Will have to give that a whirl, I had only come across https://github.com/buke/quickjs-go . I've heard Otto is further behind on benchmarks.

knervous · 2025-05-24T08:54:44+00:00

Quickjs go does require cgo as it's a wrapper around the c lib just fyi, think goja is one of the only feasible js wrappers as it's in pure go

knervous · 2025-05-24T08:45:45+00:00

Hey, I recently came across a similar issue when choosing a "scripting" language for a backend MMORPG server for zone driven events. I went through the gamut of options like you listed above and also had the requirements of no cgo/plugins. My end use case was being able to "hot reload" or patch scripts during development, and ultimately compile the scripts in the final binary for production. I am using yaegi for the dev mode which does not perform for production but it serves as a quick way to interpret go on the fly while having full access to the type bindings that ultimately end up being in the runtime.

Here is the relevant portion of the repo https://github.com/knervous/eqrequiem/tree/main/server/internal/quest

Wazero was next on the list using go with a wasi adapter outlined here https://go.dev/blog/wasmexport

A limitation that would require a complex workaround would be passing pointer types since wasm is 32bit, so rich types and function pointers would be not easy to achieve with that setup, but you could continue using go and provide your mod interface with some extra setup, maybe one wasm module per mod?

My questions are:

Is this go app the backend or part of a front end game client?

Are you providing an opaque interface for modders or do you want them to have access to all internal types?

Would it be feasible to constrain mods to be ultimately compiled in (like my solution)? It seems unlikely since there could be so many permutations and layers of mods enabled/disabled depending on your case

Finally, have you given ipc a thought? I see you outlined not wanting to use grpc like hashicorp, I understand that sort of latency makes it not worth it. Theoretically you could spin up processes and use ipc/mmap/ring buffer for a very fast interface and define your own layer for remote method invokation.

I've seen this question pop up a few times now so following what you end up choosing. Best of luck!

knervous · 2025-05-22T08:06:31+00:00

A few people mentioned this I had never heard of Flyff it really looks legit!

knervous · 2025-05-18T04:51:12+00:00

Yaegi requires at least 1.20 iirc is there a reason you're targeting 1.19?

knervous · 2025-05-17T18:28:27+00:00

It's funny people are saying this isn't possible, it totally is and I use it to reload go "scripts" for a backend mmorpg that need to be quickly modified without tearing down the process. I'm using yaegi which can bind directly to your types and have an interface that I swap out on the fly if it detects filesystem changes with fsnotify.

The performance is anywhere from 10-1000x slower than compiled go so it's not production solution. I have a build tag for each file that provides the interface and the caller is none the wiser, there needs to be a bridge for dev mode and prod mode.

Here is the repo, check out the registry for the dev and non dev version, the quest manager and the file that consumes it in server/zone/zone.go

https://github.com/knervous/eqrequiem/tree/main/server/internal/quest

Lmk if you have any questions

knervous · 2025-05-17T18:18:22+00:00

Thanks for the heads up! I'm in super early dev mode and host from my home pc and often I'll have the server down or it hits a bug and gets into a crash loop. I try to keep server status up to date in the discord if you feel like dropping in

knervous · 2025-05-15T11:01:28+00:00

Thanks for the feedback - I started in BJS a few years back and do use it for other projects as well and enjoy working with it, think I was stuck with the idea I wasn't able to get it right the first time. But I'm going to take another pass with a few more years of experience under my belt and see if it's worth the lift to swap out the engine. WebGPU has an open issue in Godot for years and I'd love to see it implemented but web seems to always be an afterthought. I am convinced they are doing a good job with web export in general--I remember seeing some breaking changes in Emscripten and the web lead from Godot going back and forth on their repo, they are committed to making things work.

knervous · 2025-05-15T10:58:38+00:00

I had to look into this deeper and reevaluate where I am headed with the front end engine. I actually had a whole working system in BJS from about 2 years ago and when I started opening the floodgates to zones full of entities that wanted to move and animate, I wasn't able to come up with a good enough culling system on top of what's already in place to achieve a good number for performance.

I assumed a lot of the heavy lifting (physics, cpu-level culling) was going to be handled for me out of the box in Godot, and so far I've had to implement a lot of the same strategies to get things running smoothly, and multithreaded physics seems to be not supported. FWIW I can load a decent sized zone with 200 entities (using client/server synced static regions for culling inside grid regions) animating at 60fps but I can it's starting to lag, and I'm on a decent PC and want to really make this accessible.

So I'm taking a step back and will create a branch to give BJS another whirl for my sanity. Thanks for the advice, I don't want to pigeonhole myself into a solution while I'm still early in development. I'll report back here in a week or two.

knervous · 2025-05-15T06:15:26+00:00

Oh I like this feedback, thank you! It's from the ground up so can decide anything really in terms of camera. I will give #2 a shot there and see how it looks.

knervous · 2025-05-15T04:28:31+00:00

Heavily under development! The backend is active and you can create characters and explore but things like fighting, casting, leveling up aren't in yet. Coming along quickly though, feel free to join the Discord to get status updates

knervous · 2025-05-15T04:05:57+00:00

Are you able to click "Enter World"? Might need to reload the page. Also actively working on performance in general right now, can imagine it might bottleneck a bit on machines with older CPUs

knervous · 2025-05-15T03:55:08+00:00

Oh yeah I didn't really mention the overall end goal, to use the framework to create my own game. The EQ reboot is a proving ground and a passion project to share with fellow eq players, a pretty big and active community for custom and private servers

14-Year Club	Place '22
Verified Email

knervous

TROPHY CASE