Профиль

Really enjoyed this thread of the broad early development steps of Poinpy. If you haven’t played it yet you should absolute banger of a video game! Downwell has been my public transport mobile game for years but this will likely take its place (I really value that I only need one hand to play)

Fuck! Denshattack! is really good, my brain loves the moment to moment gameplay loop! I’m multiple hours in and they are still dropping mechanics on me and every time it’s like oh this makes combos flow even better!! I do wish restarts were faster on steam deck for when I mess up a starting combo

God superluminal may just be the best piece of software I have used in years, just absolutely amazing. Buttery smooth, amazing tooling for timings, finding duplicate calls, distribution, histograms & amazingly a in text code breakdown of how long func took. Makes me want to profile everything.

penguin

I ended up finding it by screenshotting both my atlas and the final render, after looking at a glyph closer it was something like 4px taller, a very very large sigh followed after that.

So started writing a cursor based immediate mode gui for my home engine based on a prototype I made in raylib. Was absolutely losing my mind that my gylphs were blurry no matter what I did, eventually I found it was window dpi awareness being off causing my rects to render at a different size . . .

Hell yeah! We’re seeing them next weekend, incredibly excited!

Me, a wizard: Where hast my scrying orb gone? I cannot seem to find it anywhere in the tower... perhaps this is a cruel trick from my dark warlock rival! My Capricious and Gluttonous Familiar:

I’m happy to announce the release of a new open source 3D physics engine called Box3D. I’ve been working on this project for a few years now, but it represents over 20 years of experience writing physics engines for games. Read more here: box2d.org/posts/2026/0...

So turns out VGA is limited to 18bit 6bits for r,g & b I’m still going to keep the palette buffer at 8bit at a minimum.

Absolutely brilliant, a really approachable algorithm I loved that a bunch of difficult problems for fonts are precomputed away, every step is like yeah obviously we should be doing that! And huge fan of it calculating the coverage even if this means that post effects will need an additional step

I think it would be quite funny to do something like 10/10/12 rgb in the pallets as you can get really cheap 12 bit dacs these days

In general this works out quite well, as it’s all software first and hardware section can be extracted from software to hardware. Eg 3 streams of r g and b from the esp32 to parallel dacs that write the colour out as a 0-1 voltage. And then the pallet buffer indirection memory chip etc etc

Decided now it’s time for me to continue my 90s console/PC thing. (As if I don’t have enough going on) Been designing a mode 13h vga display adapter that double buffers pallet indices. I want that second esp32 core doing some fucked up deferred software rendering instead of just vga emulation.

Apologies I missed the single player part my bad. While mostly the same reply a combination of both. SP doesn’t have the same constraints as MP e.g. it doesn’t need to send/receive entity state to a non client server so they can get away with a bunch of collision/trigger events on ents/scripts.

Totally depends on the games design & also the weapon type. I’ve read about combinations too, where at close range the server will evaluate a ray but after a distance a projectile is used from the ray endpoint. I believe that’s what battlefield does, I think I remember there being a paper on it??

If you are interested in cod tech it’s built on quake 2? and inherits many of the core design decisions from that era & 25+ years of new tech built on top. While quite outdated cod BO3? zombies shipped the Radiant level editor (I don’t know if that provides a way to run custom scripts or not)

So for example if one was to build a “indie first” engine whatever that means :3 One may make tech decisions to make “instant” iteration times for editor/runtime, be that hot script/node reloading and real/runtime prototyping level tools. These decisions may want to driven by designers needs.

I’m not specifically saying one shouldn’t do many generic things within an engine to improve flexibility. but different types of games drive different core tech to built first, the same way unreal is “generic” but it’s tailored to build shooters and has a bunch of tech to help with that.

I think FOSS has quite a few problems for game engines specifically. Mainly how do you scale up enough to even pay the salary of 1-3 programmers. Designing your engine to be generic instead of for a specific type of game has many tradeoffs. Proprietary/3rd party code becomes a little awkward.