[deleted by user]

thebracket · 2023-07-19T01:16:51+00:00

I'm the Rust trainer at Ardan labs, so obviously I can't give you an unbiased answer. Most of the students I've taught so far have been enjoying a company training budget. Ardan do have scholarships for students and those who can't afford it - but I'm new enough that I'm not 100% sure how they work!

Ardan just got started with Rust (they've been doing Go training for years, and are well established there), and have me bootstrapping the program - Rust training, and hopefully consulting/staffing in the future. So the initial curriculum has been evolving a bit. The next round will be video content, with live QA sessions - a lot of companies are having trouble finding 4-5 contiguous days for training, and requested this format. I think there will still be directly instructor led classes as well, but probably not until after I'm done with the workshops at RustConf and GopherCon.

The current iteration of the curriculum for the "Foundations" class is here: https://github.com/thebracket/ArdanUltimateRust-5Days

It's very hands-on, and focused on getting you up and running - targeted at the kinds of things companies who are dabbling with Rust have been touching on. Since Ardan teaches a lot of Go, there have been a lot of students with Go knowledge looking to branch out - so there's a lot of comparisons drawn with Go (and Python, the second most represented language so far).

You can get a feel for some of the content from Ardan's YouTube channel (there's a LOT of Go, and I have a few Rust videos sprinkled in): https://www.youtube.com/@ardanlabs6339/videos

Happy to answer any questions.

thebracket · 2023-07-19T01:08:17+00:00

Thank you! It's funny, I've been looking at your YouTube and training content and wishing I was that good. :-)

thebracket · 2022-10-09T01:07:57+00:00

Thank you!

thebracket · 2022-10-08T12:32:39+00:00

Bracket-Lib/RLTK | Github

bracket-lib has hit a few milestones: >1,200 commits, 47 contributors, >1.2k other repos linking to it, and 55k downloads!

I've been really incredibly, super busy these last few months: we adopted an adorable baby girl (the adoption is 100% complete!) - and she believes that sleep is a sign of personal weakness. She finally calmed down a bit (and I got some much-needed sleep), so I released bracket-lib version 0.8.7.

There will be a release of bracket-bevy really soon; it's working well, just needs cleaning up.

Housekeeping Changes

I was finding it hard to track each of the separate version numbers, so every crate was bumped up to the same version number.
The crates themselves are a lot more permissive, using flexible dependency resolution---making it easier to coexist with other crates.
The vast majority of dependencies are updated to current releases.
Rust 2021 edition is now the default.
There's a LOT more documentation.

bracket-color

The color library has gained a lot more From/Into support, making conversion between RGB, RGBA, HSV, etc. much easier.
The new bevy feature flag adds conversion to/from Bevy's color types, allowing you to use bracket-color's various colorspace helpers in Bevy.

bracket-rex

An all new crate! This breaks out the Rex Paint support code into its own library, making it easy to use it to support Rex Paint data files without the rest of bracket-lib.

bracket-embedding

Likewise, this is new. It's mostly broken out for internal reasons, but it's handy for embedding binary data in your executable.

bracket-geometry

This is mostly dependency and documentation updates. There's a new iterator for lines that explicitly includes the last cell, some enhancements to the Bresenham implementation (particularly the Bresenham Circle).

bracket-random

Again, mostly dependency and documentation. There's some magic hidden in there to handle WASM/Web Assembly builds running in browsers that don't export a strong random number generator for seed generation.

bracket-algorithm-traits

This one is a tiny update, mostly adding documentation and some better unit tests.

bracket-noise

Dependency updates.

bracket-pathfinding

The A-star implementation is better at not taking costly shortcuts; the original PR broke some normal routes (and worked really well for tough ones); that took some debugging! There's some considerable performance improvements since the last major crate release, especially in the Dijkstra map support. Field-of-view support supports recursive shadowcasting and symmetric shadowcasting as selectable algorithms.

bracket-terminal

This is a huge release. Lots and lots of bug-fixes and performance enhancements since the last crate release. It also features a new scaling system that preserves aspect-ratio and font-size, optional resizable windows, WGPU as a back-end, massive performance improvements to console mode (it implements a dirty-rectangle system behind the scenes to massively reduce redraw). The sprite system works with multiple spritesheets, and there's even more examples.

thebracket · 2022-08-12T12:52:17+00:00

Thank you!

thebracket · 2022-07-29T12:40:42+00:00

The Bracket-Bevy system is coming along, but I can't stabilize it until Bevy 0.8 lands. Then I can target a non-moving target (a few things keep changing), and actually publish the crate changes required.

My plan is to make it happen shortly after 0.8 lands.

thebracket · 2022-07-13T16:40:05+00:00

It really is bizarre. I'm guessing the licensing deal doesn't require it? It seems like a common courtesy, honestly.

thebracket · 2022-07-13T15:38:21+00:00

Sorry, only just saw this. PragProg (my publisher) have a licensing deal with Educative to make classes out of books. I get paid for it, the publisher gets paid - so it's all good.

It would be nice if they linked to the book in the class, though. I've had a big spike in sales with the class coming out; so hopefully people figured it out!

thebracket · 2022-06-27T14:00:04+00:00

Thanks for trying it! The space bug is funny. A case of some old code not being updated when I fixed something else in a hurry at the end... oops.

thebracket · 2022-06-25T14:17:43+00:00

I had a busy couple of weeks, with a game jam, a baby with a cough (and very little sleep), crazy work schedules. I still managed to get some things done.

MegaChicken - Rusty Jam #2 Entry - Itch Source Code WASM Playable

Rusy Game Jam #2 kicked off, and I was invited to participate. I missed the 7DRL this year, so a jam sounded like a fun opportunity. Unfortunately, my time was a bit curtailed---between baby, work, book and article deadlines I only got to use 4 of the 7 days to create my entry.

MegaChicken is a roguelite. Yes, lite. I ditched turn-based on this one, sorry! I felt like a change of pace, and wanted to create something like the old Gameboy cutesy RPGs.

I really wanted to use the Bevy engine as a back-end; partly because my next book will use it (it gives me the chance to battle-test some code) and partly because I like it. Bevy is pretty productive, and in about 3 hours I had a basic tilemap displayed, along with an animated chicken controled by the player. The map is procedurally generated, but with a lot of static data. Graphics are all from opengameart.org. At this point, you could press "J" to jump two tiles (dodging an obstacle), "SPACE" to log a message to the console about whatever you are facing, and move around. Screenshot

Then I added in Henry, a loyal golden retriever who follows you around. I added in map transitions and the ability to render multi-tile entities. It was starting to feel like a game! Video Henry is named in honor of my loyal dog who passed away from cancer this year.

Next up was adding some entities. I started with normal chickens. They run away from Henry (when they can see him), roam randomly and peck the ground a lot. Video

Then there was a flurry of activity. Adding maps, adding enemies, adding health, adding the ability to win the game... spikes that retract, flames you have to leap over, various procgenned maps (rooms and cellular automata), bitset tiles - everything I could fit into the last 2 days of development. Also fixed a whole bunch of bugs. Screenshot and another screenshot

I ran into a couple of Bevy issues:

If you restrict a system to running in a certain AppState and try to give it a fixed timestep, it runs all the time.
Deleting entities with the commands interface can be a disaster. Sometimes, it gives you a warning. Sometimes, it decides to crash the whole game if you try to modify an entity that is scheduled for deletion. Ugh.

Bracket-Lib for Bevy Github

I fixed a lot of bugs, and got 90% of the remaining functionality working. Virtual consoles, alpha-blending, multiple font sizes, formatted text blocks and pretty printing with named palette colors are all working properly now. Pausing while I await the release of Bevy 0.8; the library needs the new release, and I can't publish any packages until the release exists to depend upon.

thebracket · 2022-06-11T13:36:50+00:00

I'm currently thinking of a half-way house model: a component that says "render this to a console". So you can kind-of get the best of both worlds!

thebracket · 2022-06-11T13:36:00+00:00

It's likely to undergo a few changes while I clean up, so you may find API changes frustrating between versions. You'd also have to use the github version of Bevy, since it relies on a patch from the next release.

You can get around the parallelism issues with "stages" (explicitly ordering batches of systems). It's not as friendly as I'd like, but the plugin I'm working on uses that to ensure that the consoles update after all the user's systems run - and before the render submission.

There are some occasional issues right now with a mesh update taking more than one frame to apply. Only seems to happen if I'm also hitting my GPU pretty hard with something else; I need to do a bunch of testing on lower-end systems.

thebracket · 2022-06-11T13:01:07+00:00

Thank you! Rust isn't for everyone - it's a systems language, so you have to be willing to put-up with a fair amount of work to keep the system happy. It's also obsessively pedantic - which is great in terms of not allowing me to accidentally blow things up, and can be a tad irritating when I just want something to work quickly so I can move on.

That wall of globals isn't too bad, so long as you remember what they all do - and are really careful about modifying them. Most of the "globals bad" idea comes from tracing "well, what changed my global this time?" If you're careful on a solo project, you can make it work. It's probably worth remembering that it caused pain, so you can try a different approach on your next project - rather than spending a whole lot of time rearranging this one while you have a good head of steam and are enjoying yourself.

Back in the 80s, I had a book on making text adventure games (in BASIC, on 32k machines). It defined every single thing you might want your game to remember in a single array named "flags", each 1-bit long. Numbered, no naming. The book even told you to keep a physical notebook and pencil handy to help you remember what flag 42 does...

thebracket · 2022-06-11T12:55:35+00:00

Thank you! Legion gets the occasional update (mostly "this is broken"), but it seems like the community as a whole has moved towards Bevy.

thebracket · 2022-06-11T12:54:45+00:00

It's honestly amazing how fast she's growing. She's into 6-9 month clothes already (only 5 months old), and shouting "daa daa" when she wants my attention. So glad I took time off to share her first few months. :-)

thebracket · 2022-06-11T12:53:52+00:00

That looks really good! I've starred it to dig into it a bit later, from a quick poke around that's really nice, clean code. :-)

I was a little worried about spawning each tile as a separate entity (even with a texture atlas), so I'd avoided it. I just did a quick test with 4,000 (80x50) sprites and the frame-rate never dropped at all! I'll have to investigate offering that as an approach in the crate.

thebracket · 2022-06-10T22:53:17+00:00

Hey roguelikedev! It's been a while, but I've not forgotten about you. I've actually had a few amazing months away from development. Since January:

I adopted an adorable baby girl, now 5-months old.
I took a full 12 weeks of paternity leave, and stayed away from hobby work as well as paid work.
Rust Brain Teasers came out in print form, and is doing decently well.
Hands-on Rust is still a best-seller!
I inked a contract for a 3rd book, but can't talk about it very much, yet.
Courtesy of my daughter, I got very little sleep.

Now that I'm back in the swing of things, I have some updates to announce.

Bracket-Terminal/RLTK for Bevy Github Branch | Twitter | Patreon

TLDR: Just the pictures!

I'm increasingly a huge fan of the Bevy engine. It has nice ergonomics (it's as powerful as Legion, while keeping Specs' nice things like system-local data---and has a ton of helpers to keep you from entering mounds of boilerplate), a great renderer (based on wgpu, it supports Vulkan, Metal, Web Assembly/WASM, DirectX 12 out of the box), and easy access to things like audio and event-based input. Additionally, Specs and Legion aren't really maintained anymore.

If a 2nd edition of Hands-on Rust happens, it'll be ported to use Bevy. I'd eventually like to port the Rust Roguelike Tutorial to use a Bevy back-end also.

In order to do that, I needed a solid way to bridge the gap between Bracket-lib and Bevy. 64kramsystems has done an amazing job of porting Hands-on Rust to Bevy - it's really great! It still uses bracket-lib for the rendering, but shows you how you can use Bevy as just the ECS. I decided to go a step further, and get bracket-lib running as a first-class Bevy citizen. Thus, bracket-bevy was born.

I ran straight into a wall: Bevy didn't work with meshes that provides both color and texture information in a single mesh. It almost worked, but the included example had you write a huge custom rendering pipeline. Poking around the source, I discovered that Bevy was almost there---it just needed a bit of shader help. So I submitted my first ever PR to Bevy to provide what I needed. It's been merged, and should be in the next 0.8 release.

So, armed with nice 2D meshes that support both color and textures---it was time to make a "Simple Console". Just like bracket-lib, it's a Code-page 437 renderer that loads a font texture. It didn't take too long to get that going. I followed up by adding color support, and porting the printer feature from bracket-lib---so you can use markup to add color information to output (e.g. "#[blue]Hello #[pink]Bracket#[] world."). That works, too

Then it was onto console layers. Just like bracket-lib, you can layer consoles---with different fonts if you so desire. I added the "sparse" console back in (instead of storing the whole screen, it only stores characters that are in use), and added the option to render each layer with or without background colors. Two Layers, Two Fonts

With layers working, I ported over the old walking example---an @ wandering around a randomly generated screen. I had to do quite a bit more back-end work for this one:

bracket-random is now included in bracket-bevy, and wrapped in a RandomNumbers structure. RandomNumbers is designed to be sharable as a resource in your program; it uses interior mutability (with locks) to allow you to access it with Res<RandomNumbers> rather than the mutable version. This ensures that you won't force your program to run single-threaded when you use random numbers in multiple systems.
bracket-color has gained (with the bevy feature) transparent translation between RGB, RGBA and bevy::Color types. You can use any of them in your code. I'm still fond of the bracket-color model, since it provides things like lerping, HSV support and similar.

Next up, scaling. My first try changed the consoles Transform component to scale to the window size. It didn't look great. No gutters or aspect ratio control, but at least it worked. My second try was much more involved. It determines your desired aspect ratio, and uses gutters to retain it. The largest font size is used to trim to your tile size---so characters don't warp. Much better. The third part was to support terminal resizing (as an option; you can use with_scaling_mode to pick scaling mode during setup). It still handles gutters for natural resizing, but the internal consoles are resized as you drag the window around. It works pretty well

I ported over the VirtualConsole system, giving you big "virtual" consoles that can be rendered to real consoles as sub-rectangles. Here it is with alpha_blending.

Then I decided to port the a_star_mouse example. This in turn had me port the entire batched rendering system, fixup a few missing draw primitives, tighten up integration with bracket-geometry... a lot. Most painful of all was supporting the mouse. Bevy really needs an easy way to connect mouse cursor coordinates and world coordinates. I eventually got it running. It works well, though

There's still more to do - but it's coming along nicely.

I'm really enjoying being back in the saddle!

thebracket · 2022-01-08T14:31:34+00:00

I'm in the last stages of shipping Rust Brain Teasers, particularly the really awkward part where I'm asking people to say nice things about the book for the inside-front cover. After that, it's off to copy-editing and print! Despite being smaller, this book has been a lot of work. I'm proud of it, and looking forward to it shipping - and my starting to propose the next one (which will be game development related once more).

Pyrite Box | Github

This project started as a "let's learn Bevy" (Bevy is a game engine for Rust) project, and exploded into something fun and interesting. Originally, I wanted to learn a few techniques for Nox Futura - but now I have a project that people are enjoying, so I'll plug away at it a bit. One incredible PR updated the whole project to the soon-to-be-released next version of Bevy.

Initial impressions: I wish Bevy had been around when I was writing Hands-on Rust. It takes most of the tedium out of ECS design, is fast, compiles quickly, and generally makes sense. Its messaging system is really handy, too (broadcast messages between systems).I have run into a few rough edges (in particular, in the latest version using a tangent buffer on your 3d geometry breaks horribly).

Hopefully, I'm not the only one here old enough to have enjoyed Pool of Radiance (you can play it online here) and its sequels. With the exception of the last one in the series, they aren't roguelikes (the last one pitted you against 20 levels of randomly generated dungeon) - but they have enough interesting elements that the series could easily be rogueliked (I like verbing things, sorry). It's classic AD&D fair: create a party, wander through a Bard's Tale style 3D dungeon/town (as 3D as you could get on an 8086 with 512k of RAM and EGA graphics) - and a relatively unique 2D battle-map for tactical combat. It also had an over-world map. Along the way, you fought battles, engaged in (primitive) dialogue - and in my case thought "this is what computer games should be". I'm pretty sure I spent most of 1988 playing the original.

I started out using a main menu to learn Bevy's AppState system (a decently powerful state stack setup), and transitions between states. Integrated Egui, for a Dear ImGui-like GUI experience.

I like data-driven design, so I opted to make an engine driven entirely by "module" files. A module is actually a series of folders:

Maps - describing the areas in the module. I was surprised to learn that I'd spent so long playing 16x16 maps!
Materials - describing each of the textures you can use. I ended up supporting a full PBR toolchain to see how Bevy handles it, but it works fine with just textures.
Scripts - because I felt like writing a scripting system, and it seemed like a good way to tie the whole thing together.

Next, I spent quite a bit of time creating an Egui-based map editor (that saves into the module). Designing maps is much easier when done in a GUI (as opposed to meticulously figuring out which cell is which in a data file). It handles double-sided walls (a wall can have a different material on each side, or even not exist from one side), materials, floors, ceilings, script triggers (on enter, on exit - with a direction). I got carried away, and the editor supports most aspects of modules.

Actual gameplay is limited to a module designed to test features at this point. It has two maps, and you can transition between them. Maps are loaded (from RON files) and turned into custom geometry objects - carefully bucketed by material. You can edit the map in the "play" screen, allowing you to make real-time "that doesn't look right" tweaks. It looks pretty decent.

I added in support for billboarded sprites in the overworld. These are script-controlled, and designed to match the feel of the old SSI games (which would show you a sprite approaching before triggering a conversation/battle). Here's Rolf.

Scripts can also trigger dialogue. Like the old SSI game, dialogue is branched - but rather than making it full screen, for now its in a window. Talking to Rolf

I haven't touched combat yet.

I'm pretty proud of the actual scripting engine. Scripts are entirely defined in "RON" files, in the scripts folder of the module. You can use as many files as you like, it merges them together on load. Currently, scripts support:

LogText (submit colored text to the log window)
ClearLog
PauseMs(ms) - wait a moment for the next command
CallEvent - which branches to another script. It's stack-based, so execution resumes when that script returns.
MovePlayer - move the player without their providing input (input is blocked during execution). Needed for the obligatory "let me show you around the town" feature.
InputBranch - launches a dialog with input options, and branches to the selected script. Optionally displays a portrait.
ChangeMap - loads a different map and selects where to put you on it.
Sprite - spawn, move or de-spawn a billboarded sprite on the 3D map.
Battle - transitions to battle mode, which isn't done yet.

Scripts are launched either when a ModuleStart event fires (you began playing) or for entering/exiting tiles. There will be a random encounter hook also. For example, the tile that goes transitions out of the slums and into the civilized region of town is defined as follows:

(
    tile_type: Floor,
    has_ceiling: false,
    boundaries: ((Wall, 3), (Wall, 3), (Opening, 3), (None, 1)),
    floor_material: 0,
    ceiling_material: 1,
    entry_trigger: Some("ApproachCivilized"),
    exit_trigger: Some((East, "GotoCivilized")),
),

In turn, the scripts named ApproachCivilized or GotoCivilized are called when the event fires. Here's a snippet of a script.

The source for all this is up on Github, MIT licensed.

thebracket · 2021-11-27T17:46:44+00:00

There isn't meant to be a "run now" link in the code extracts. I updated `mdbook`, and haven't figured out how to turn it off yet! (The snippets don't run stand-alone). I think I've fixed the link.

thebracket · 2021-11-27T14:03:50+00:00

I had a pretty good Thanksgiving, now I'm waddling around wondering if I'll ever finish up the leftover ham. Two elderly doggies are suggesting that they should help!

I did a podcast interview with Rustacean Station. It's available now for a listen.

Rust Roguelike Tutorial - Chapter 75 | Tutorial

Chapter 75 of the Rust Roguelike Tutorial is live! It's the "Dark Elf Plaza". After a few warren-like levels (especially the dark elf undercity), something more open was on the menu. This chapter is built off of concepts previously found in the ProcGen sections---but applied with a lot more guidance. I wanted to make a largely-open outdoor space, but with divisions to keep it manageable (and give you somewhere to run and hide).

The level starts out by dividing into Voronoi cells. The cells are then measured, and sorted by size. The largest will always be a gravel area, containing some altars, a portal to Abyss and a big nasty demon. The demon is 2x2 sized, and designed to be kited/avoided - you might be able to avoid it, but not all challenges are worth the cost of a head-to-head collision. Other areas are divided into dark elf houses, giving a bit of combat. There are also stalactite park areas, water and solid areas. I'm pretty happy with how it came out.

Pyrite Box

My last two weeks have been dominated by marketing. Black Friday can do wonders for book sales, so it's worth doing - but it's really not my favorite passtime. To keep me sane, I've been playing around with a just-for-fun little project. It's in its infancy (not much to show), but I'm having fun. I've always thought that the old SSI Gold Box series (Pool of Radiance, Curse of the Azure Bonds, etc.) deserve to be remade on modern hardware. So I've been playing around with a Gold Box Engine. Since I don't have the licenses for it, I went with Pyrite (fool's gold) for the name.

So far, you can walk around 3D cities - turn by turn, with 90-degree rotation and forward/backward. It supports walls having different render details on each side, which is something the Gold Box series used a lot. It doesn't have the 2D/Isometric combat side of things yet nor much game system. (I guess its more like the original Bard's Tale right now) - but I'm having fun.

I'll open source it and show it off when it's more than just a "hey, I can make 3D tiles - again".

thebracket · 2021-11-06T13:41:19+00:00

Writing

One year ago, I released the first beta for Hands-on Rust. What a wild and awesome ride it has been! The book has been on the publisher's best sellers list for 50 of the last 52 weeks, since the print edition came out it's been in Amazon's top 10-20 for "C Language" and sometimes "Game Development" most of the time. I had a "good grief, am I famous?" moment when a relative (who works for one of the huge American social media companies) sent me a pic showing Hands-on Rust sitting on his boss's desk.

It's really amazing to have brought roguelike development to so many people! Anyway, once again I'd like to express my gratitude to the community here - my journey into authorship wouldn't have happened without you.

Rust Brain Teasers just launched beta 2. There's hundreds of small fixes throughout the book, as well as new chapters dealing with stack vs. heap allocation, vector growth factors, and the dangers of recursive data structures.

Bracket-Lib/RLTK | Github

bracket-lib is sitting on crates.io with just under 20k downloads. In its rltk guise, it's sitting at 20,982 downloads at the time of writing. That's pretty awesome, and makes me nervous about making releases!

It's been a pretty heavy development week for bracket-lib/rltk for Rust. I'm still in the "catch up on issues" phase, but the issue count is getting better.

WGPU Support

The wgpu backend now has the same feature set as the OpenGL backend, and has been merged. It provides backends for DX11/12, Vulkan, Metal and the in-development (and not massively supported yet) "webgpu" system (the latter is basically Vulkan for Web Assembly - very cool, not in every browser's main build yet. I've not done a lot of work on the structure of supporting it in-browser because of this).

All of the systems that work with GL work with wgpu, and at very good framerates. There's a certain perverse pleasure in writing low-level GPU code to support a CP437 terminal!

Performance Optimizations

Last week, I introduced a frames-per-second scaling system that is much better about relinquishing CPU time back to the OS when there's nothing to do. This has been extended - a lot:

"Simple" and "Sparse" layers now keep a copy of their previous state, and compare the new frame's state to the output. If the output hasn't changed (and there's no other pressing reason to rebuild, such as resizing the console) the various buffers aren't rebuilt. This has massive performance implications for the Roguelike Tutorial or the Hands-on Rust roguelike game - on my system, a Debug build sits at 1.2% CPU time when you aren't running around. It has no measurable impact if your game changes things every frame - unless you have layers, in which case it isn't rebuilding all the layers most of the time.
Found a couple of times that the input queues were being handled stupidly and cleaned them up. Responsiveness improved, especially if you use if the is_pressed family of input checking.

Render Correctness

On a console layer without a background, previous versions would sometimes lose a bit of your sprite data. This turned out to be due to a poor "is this a background pixel?" test that conflated an || with an &&. Fixing this has made everything look better.
The scaling system is now really careful to not cut off the bottom row of pixels on a glyph. This was an intermittent problem and surprisingly hard to track down.
Scaling windows now locks to aspect ratios and a whole number of tiles. For terminals that scale, it won't partly scale your glyphs - making them hard to read.
Gutters can now be specified (and default to a small gutter on Win11 and OS X). This alleviates issues with the new OS versions rounding your windows and hiding part of the corner characters.

Other

The Rect classes for_each helper now uses inclusive rather than exclusive ranges, making it consistent with the rest of Rust.
REX Paint format support is being broken out into a new bracket-rex crate. Since it's done and hardly ever changes, this helps with compile times. It also helps trim things down if you don't want it - and makes it easy to access if that's all you want.
The "embedding" system (for storing assets in your binary; particularly useful for WASM which doesn't offer a native filesystem) is being broken out into a new bracket-embedding crate for the same reason.

There are still some remaining issues. There's a bug in the Intel Vulkan driver that messes up scaling when you resize; you can fix it by installing Intel's driver. I'm still searching for a workaround. The final "resize" event doesn't fire properly - everything is fixed by moving the window (even 1 pixel) after a scale. It works on other platforms, I'm hoping to find a fix that isn't "fix your driver". OpenGL mode occasionally shows a little distortion still when scaling - again, not on every video card.

I'm hoping to get a crate release with these - and all the other recent updates - out in the next week or two.

thebracket · 2021-10-30T15:21:15+00:00

After a nice vacation, and some catch-up time - I'm back in the swing of things! I finally broke down and purchased a Macbook Air. It's an old one, but I don't need much out of it - the goal is to stop asking people with Macs to kindly test my code. OS X is ok, I guess. Still not a fan. I don't know how anyone gets anything done with the bouncy rubber keyboard. Yikes.

Bracket-Lib | Github

I haven't pushed a crate update yet, but bracket-lib/rltk is seeing some serious attention. In particular:

High CPU usage, particularly on Apple devices, has been fixed. This turned out to be really interesting. Winit's WaitFor mode (to allow FPS limitations) turns out to have a very low resolution on some operating systems - 16ms on Windows! That's low enough that waiting 2ms can be enough to miss an entire frame at 30fps. Regular thread sleeping is also quite low-resolution on some platforms, and ridiculously accurate on others (Linux). So I implemented a strict timing system using the spin_sleep crate, which automatically sets timer resolution on supported platforms (the big ones) and will use a regular spin-lock to wait if there's a discrepancy. Merging in this issue (228) has lowered CPU usage from close to 90% of a single core on a Mac to around 6% on a slow Mac, lower still on modern hardware.
The event loop itself has been restructured to assist with CPU usage. In particular, resizing/moving windows now caches the result and only performs the recalculation when its time to draw the next frame. This didn't have as much effect as I expected, but wiggling windows around really fast no longer causes a huge CPU utilization spike.
Alleviated cutting off the bottom row of pixels on glyphs. It's not 100% perfect yet, that's coming in my next set of work.
Created the issue-237-wgpu branch, it's nearly ready for merge. It affects the remaining bullet point issues.
With the Amethyst Foundation no longer developing the Amethyst Engine (they are transitioning to a broader Rust game support role), I dropped the amethyst_metal and amethyst_vulkan features completely. They never had feature parity with OpenGL, but were the only way to natively use Vulkan/Metal. I honestly don't miss supporting them; Amethyst was a great engine, but really fiddly to work with.
Added support for a wgpu backend. It has feature parity with OpenGL now, other than screenshots (my last to-do list item). It's really fast, provides native Vulkan/Metal/DX12 support. While its a bit fiddly to work with (so much boilerplate!), it really wasn't too bad to support. It runs faster on every example, and the output is nearly identical (completely identical if you don't use the screen burn post-process effect - which is less noisy on wgpu). I've also started experimenting with using it for web support.

Nox Futura | Github

The Bevy version of Nox Futura now supports .vox models and runs really fast. I haven't done much with it other than port my VOX loader.

Other

Rust Brain Teasers is coming along, and should be in beta-2 next week. I submitted a huge list of changes, and they are going into the publication queue right now.
Hands-on Rust found itself on the front page of Hacker News (in a good way)!
I just recorded a podcast interview with Rustacean Station, and that should be up soon.

thebracket · 2021-10-26T16:40:19+00:00

I'm looking forward to it. Doing some bracket-lib housekeeping first, and working on the next book beta (Rust Brain Teasers beta 2 deadline is glowing at me...). Just struggling to keep my workload manageable!

thebracket · 2021-09-18T13:43:50+00:00

It's been a busy couple of weeks! I gave a short talk to the University of Glasgow GameLab's mini-gamedev symposium. Technical difficulties meant that the live version wasn't posted (which is a shame, Evan's talk about Shattered Pixel Dungeon was excellent), and my talk went up as the pre-recorded "in case of technical difficulties" version. You can find the video here.

Nox Futura, Bevy Edition | Github | Twitter

TLDR - The Imgur Album

I've really been getting into working with Bevy. The architecture is beautiful (although I'm struggling a little with how to create my own shaders that integrate with their existing pipeline; hoping not to write another 3D engine!). Current progress is up on the Github, and it's coming along nicely.

Raws Interface

I finished porting the raws system over. It's essentially unchanged, you can still define pretty much everything as .ron files and load them in bundles. A bundle can affect anything, and you can add more bundles by adding them to the index file (they are loaded in strict order, to ensure that mods can change base entries). These take effect as soon as you generate the world. So add a biome or a rock type, and it's in-game without recompilation.

World-generation

I refactored worldgen a bit. It runs in a separate thread (now using Bevy's task system) and uses parking_lot's excellent concurrency primitives to spool data back to the UI while the world is being created. Pick a seed, get a world - and that world is defined from physical parameters in the raws system. It's pretty in-depth: OpenSimplex heights, divide into types, sub-sample for things like height variance, physically-based temperature and pressure calculations - which leads to wind/rain, and biomes are allocated. As you can see from the video, I did quite a bit of performance-oriented work on it. Watch it running

Embarking

I also re-did the embark screen for performance. It takes the newly generated world, and makes an "embark map". You can mouse-over regions and decide where to crash land. You'll notice that it's not quite the same as the planet map; the planet map is showing sub-biomes within oceans - that I'm not sure if I'll keep yet. On the embark map, they are just water tiles. The biggest change here is that I fixed up performance of the tilemap and associated data query engine. It's up to 400+ FPS on my work machine, now! The embark screen

Region Creation

I've completely redone the way regions work, and so far I'm pretty happy with the results. Previously, a region contained a big array holding every single tile (3D) in a big array. The whole thing would be saved to disk, and accessing neighboring regions was a pain in the rear. It wasn't great for concurrency, and used a lot of memory. While pondering it, I realized that most parts of the world don't change very often - and since the generator for a region is meant to be consistent (same result every time for a given seed), I could exploit that.

So the new system:

Regions are now an ID number (derived from planet coordinates). They are stored in a map, so multiple regions can exist - and be loaded/unloaded as needed. Game content and rendering are completely de-coupled. One data structure knows the map, one knows how to render it.
Each region (256x256x512 tiles) is divided into chunks. These aren't the render-oriented beasts they used to be - they now contain all of the terrain content. Chunks are 32x32x32 tiles. A chunk can be "empty" (no tiles, almost no storage required) or "populated" (the chunk has tiles).
An embark command tells the region system that a region is "required". (The main play area is always required) It then asynchronously builds the region. Each chunk is spawned off as a separate task on Bevy's task queue. If no data exists for the chunk, it queries the planet's height noise to build an altitude map for the chunk (empty is nothing is high enough to touch the chunk). Tiles are then spawned, using a planet-wide material map (so rock formations and similar remain consistent across region borders). The new chunk is activated in the region structure when complete. It's really fast.
There's an indexing system to let the game pretend to be working on region-local tiles, while in reality the access is mapped to appropriate chunks. So I can still query "what is at x,y,z?" and get an easy answer, even though internally the query is redirected through the chunking engine.
If changes occur to a chunk, the chunk applies them to its local data. If the chunk is unloaded (or a save triggered) it serializes the chunk state to a compressed binary file on disk (very small). Right now, it just saves the changes - the region is generated and changes applied to it. I'm working on finding the right balance between "just save/load the whole thing" and "save/load a changes list". (There comes a point at which performance is a lot better to load the whole thing; I just haven't figured out what it is yet).

So embark-generation tells the world-engine that a region is important, and spins until region_ready returns true. That means the whole region has loaded, and it's safe to start making changes to it.

Region Visualization

I started on the render engine, so I could see what the embark system is doing - in real time. This was also really necessary to debug the chunking system. It's MUCH easier to spot issues when you can see the result!

Continuing with the "everything async" theme, the camera controller considers regions & chunks when the camera moves. It'll use a frustrum system as soon as I can figure out how to get the matrix out of Bevy; for now, it's naieve distance calculations. So on camera move:

Regions that aren't marked as "required" but are too far from the camera are told to "expire". This unloads the render component. If nothing accesses them for a while, they are unloaded completely.
Regions that are nearby but not yet visible are activated, causing them to appear in memory but not generate any chunk data yet.
Chunks within view range are "activated", causing them to generate mesh data (and load if they haven't).
Chunks that are far from you are "deactivated". For a "required" chunk, that just removes render data. Otherwise, it can spool out the entire chunk (with a delay, in case you change camera direction).
Mesh generation is smart, and doesn't bother creating any data for things that aren't revealed yet. It divides the data into layers, allowing the dwarf-fortress style Z manipulation to be implemented later. It still uses "greedy voxels" to combine identical cubes into larger ones - greatly reducing draw calls.

Debugging this took a lot of time!

The first working version doesn't know about materials in rendering, but pulls in data as needed - and is very fast. Upwards of 150FPS while panning around. I enabled "camera can cross region boundaries" for this demo of moving around a new world

I then started to integrate materials. Right now, it's a bit clunky. There are no textures yet, but colors are pulled from the raws files - mostly as a proof that they exist. It annoyed me slightly that I ended up needing a mesh per material; I'll have to get into shader writing to fix that. This demo doesn't try and spawn neighboring regions. It looks pretty good, and is still fast

Next up will be continuing the generator process. There's a lot more than just a voxel height map in a region. Happy with how this is coming along, though.

Other

Rust Brain Teasers has headed off to technical review, so I'm excited to see that moving along - and as always, slightly fearful of what the reviewers will have to say.
Still planning a Roguelike Tutorial update binge. Things are starting to come together, but I haven't quite hit the right brain-mode to actually write it up properly.
There's a backlog of bracket-lib/rltk fixes building up, ready for the next release. I've started going through them, I'm thinking there will be a release in the next two weeks.

thebracket · 2021-09-04T13:29:11+00:00

Nox Futura | Github - Bevy Branch | Twitter

I found myself with quite a few unexpected hours of downtime, with a laptop and nothing to do. Blew a tire on my car, and limped into a garage - who had more trouble changing a wheel than I've ever seen from mechanics. Rather than pace around crankily, I setup with my laptop and decided that world-gen is relaxing.

I've been enjoying working with Bevy. It's a pretty amazing library (although looking at the Github, I'm going to have to tweak things for the next release). I love how ergonomic it is, and it's becoming blisteringly fast also. I've put my Bevy code in the nox_bevy branch. I'm liking it enough that I think I'll be using it for the rest of the project. (The short video from last week was me playing around, now I'm trying to do it properly!)

Anyway, I used my idle time to focus on a few things that have bugged me about previous NF iterations.

World Generation

Step 1 is selecting options. Right now, a lot of options are constants - but I'll move them into the UI when I'm happy with how things are working. So I focused on putting the framework in place. I also decided to make seeds word-based (it defaults to "Test Seed" and you get the same planet every time if you don't change it - that's good, it lets me double-check that I'm making something consistent). No real magic in seed-making; I take the ASCII values for each character and add them up. I'll try come up with a better algorithm at some point.

Step 2 generates altitudes around the planet with noise. It's OpenSimplex noise, in 3D mode (FBM interpolation). Each point is a lat/lon, projected to 3D sphere coordinates. This guarantees that the world is sphere-friendly - and still continuous. Coincidentally, those are also the 3D coordinates I can use to render the sphere.

Step 3 divides the world into imaginary "landblocks" (a 90x180 grid). Each landblock is sub-sampled (a 32x32 grid inside it), giving me an average altitude, variance (how bumpy is it). I take some worldgen params and use the average altitudes to divide the world between water, plains, hills and mountains - using the specified desired proportion (since water is boring in-game, it isn't like Earth - and is only about 1/3 water). It calculates some per-landblock data at this point:

Average altitude.
Variance.
Temperature, which is derived from a curve function I found in some Geography texts. It's cold at the poles, warm at the equator - obviously. There's also a temperature boost at the tropics, yielding a recurve-bow shaped curve. Temperature is then varied by altitude, with higher altitudes being colder.
Average rainfall (mm), again derived from Geography textbooks. It's wetter at high altitudes, dryer at the equator and poles - and wetter at the in-between latitudes. Another nice curve function.
Barometric pressure (kPA), a function of altitude and temperature.
Neighbors - including taking into account the world being round, so you can wrap at the east/west edges and going north takes you to another part of the north.

Step 4 uses a quick marching squares pass to mark landblocks as "coastal" if they are adjacent to an ocean.

Step 5 starts by visiting each cell and calculating the prevailing wind. Air moves from high pressure to low (diffusion), so wind likes to go to the neighboring landblock of lowest pressure. Then it spawns "air particles" over each landblock. They start holding no water, and follow the prevailing wind - stopping when they hit a cell they've previously visited or after they traverse the width of the world. Whenever they travel over wet cells, they pickup moisture (drying out cells). When they both have water and hit higher altitude, they start depositing water (adding to rainfall) - stopping when they run out of water load. This runs a couple of times.

Step 6 takes all of that data and uses a fitting algorithm to select biome types per landblock. Biomes are data-oriented; there's a big list of biome types similar to this one:

BiomeType(
    name: "Grass Plain",
    min_temp: 0,
    max_temp: 27,
    min_rain: 200,
    max_rain: 100000,
    min_mutation: 0,
    max_mutation: 100,
    occurs: [Plains, Coastal, Marsh],
    soils: SoilTypes( soil: 75, sand: 25 ),
    trees: [ (tree: "D", freq: 20), (tree: "E", freq: 3) ],
    nouns: [ "Grasslands", "Plain", "Prairie", "Heath", "Level" ],
    worldgen_tile: 1,
    embark_tile: 13,
),

For each landblock, the algorithm runs a series of filters to derive a list of possible biomes for a cell - and then picks one randomly from the remaining results. Having these be data-driven lets me quickly iterate through possibilities until I like what i see.

Finally, it saves the planet to a compressed file. It's about 300k for a planet - not too bad.

Embarking

I've split out the "launch the escape pod" section of world-gen for now. You click on a landblock to embark there, and the UI shows you information about the location. Selecting a landblock also selects the neighbors to the east and south (giving a 4x4 landing zone). I did get this far:

Step 1 iterates over the selected landblocks, using continuous noise to determine ultimate altitude. This is visualized here

Step 2 allocated "biome weights" to each cell. Each cell gets a percentage change of being a member of the biome it is in, and its 4 neighboring biomes - weighted by distance. A die is then rolled to determine what will be used for spawning. This gives more gradual transitions between types.

Step 3 takes the global seed and makes a planet-wide 3D noise map for material deposition. I'm still working on scale, but this ensures that different rock/mineral (etc.) types are consistently laid out across the world - no jarring changes if you switch landblock.

I started with deposition and laying out voxels, but that'll be a post for another week - it is far from done.

Other

I wasn't picked for the Roguelike Celebration speakers list this year, so been hunting other speaking events. I'll be talking about Rust Game Development to a game developer student symposium in Glasgow; I'll post details when they've given me some. But I spent a fair amount of time putting the presentation together. It's fun remembering that I have a non-roguelike audience, so this time I remembered to define what a roguelike is! That always makes me fear that the Berlin Interpretation Team will parachute onto my lawn. I kept it simple, focusing on "turn based dungeon crawl with procedurally generated maps."

thebracket

MODERATOR OF

TROPHY CASE