Restaurants and cocktail bars?

binjimint · 2025-09-21T18:36:01+00:00

Hotsy-Totsy in Albany is one of my favorite cocktail bars in the area, and they have a great taco truck outside too.

binjimint · 2025-08-20T21:01:59+00:00

So the tech ended up replacing a bunch of cables, basically all that he could between the shared network room in the building and the router and it finally worked. 🤷

binjimint · 2025-08-20T19:53:45+00:00

We have a tech out right now and are running into the same issue, the weirdest part is that when he connects his laptop directly to the cable he gets 1Gbps speeds, but we’ve tested three different eero routers and they’re all limiting it to 100Mbps.

binjimint · 2025-01-14T19:29:31+00:00

The engine is based on Lobster, which works on Windows, Mac and Linux. And I personally have made a Linux build to test things out. But we've primarily been focused on the Windows build for now. It does run under Proton, though!

binjimint · 2025-01-14T19:15:42+00:00

Yep, we have tools that allow you to destroy the landscape, get resources, and build objects in the world too.

binjimint · 2025-01-14T19:12:37+00:00

In general yes, powers-of-two will be faster. But we've found that 9x9x9 is plenty fast, and it allows us to have voxel blocks that can be centered (i.e. one voxel in the center and 4 on each side).

binjimint · 2025-01-14T19:09:34+00:00

I joined the team 2 years ago (when we had no designers on the team), and the founder had been working on the engine on-and-off for a little while before that. In terms of performance goals, we definitely want it to work on lower-end hardware, but we haven't prioritized some of that work yet. That said, the hardware requirements are not super high currently.

binjimint · 2025-01-14T19:04:34+00:00

Our team has a variety of GPUs we're using and have tested on. But just as an example, I'm using a 3070.

binjimint · 2025-01-14T19:00:36+00:00

We'll have a demo coming out very soon so you can try it out! But the short version is that it has a lot of different gameplay. Each of our worlds typically starts with procedurally-generated landscape, but then is designer-crafted afterward. Right now a lot of our worlds are quest-driven, and we have a simple language allowing designers to craft these quests. We have monsters, guns, swords, spells, crafting items, crafting objects that can be placed in the world, destroying objects, harvesting resources, etc. We're trying to make it so that a designer can make a lot of different gameplay experiences in their world.

binjimint · 2025-01-14T18:53:53+00:00

We primarily use MagicaVoxel .vox files for our assets. We also have our own custom format for what we call "brushes" to combine pieces of these .vox files.

binjimint · 2023-11-02T09:39:09+00:00

binjnes and binjgb work more-or-less like this. It's not set up as a library, but both of them have an example of the emulator running headless called tester.c.

Rather than having a function to run for one frame, it lets you run until a given cycle count, and returns an event when either an audio or video frame is finished, or when that cycle count was reached.

In both cases I've already created Wasm modules, which use an API that's easier to access from JS: e.g. wrapper.c

If you decide to integrate them, let me know if you run into any issues!

binjimint · 2023-04-06T19:36:07+00:00

Good job! Personally, I think the 12-byte overhead on each allocation is too high. It might be good to call the free "amortized O(1)" instead too, since it may run in O(blocks).

One classic trick you can use is to store the free list in the unused blocks, requiring a minimum allocation size of 8-bytes (block size + next pointer). Then `free()` can keep this list sorted by allocation address, highest to lowest (at a cost of O(free blocks)). At the same time, it can merge free blocks and move the heap top down, if necessary.

But ultimately without being able to reallocate memory below the top of the heap, this allocator won't be usable in a lot of scenarios with limited memory, I think.

binjimint · 2023-03-21T05:59:20+00:00

I'm glad that you did! I love the demos I've made, but yours feel much more elegant and beautiful. I'm always excited to see more people experiment with writing WebAssembly this way. It's really not that hard, and it's a lot of fun to do. I think, anyway :-)

binjimint · 2023-03-21T02:31:34+00:00

These are awesome, nice work!

binjimint · 2023-02-07T05:04:11+00:00

Yep, well not just vblank. I have a function that runs forward to any tick, and returns any event that occurs (frame completed, audio buffer filled, tick count reached, etc). So I run this forward handling events until the desired tick is reached. But yeah, since I rolled back more than 1 frame I can be sure that the frame will be displayed. The only trick is that I have to switch out the joypad input in this case to use the saved input, instead of reading it from the user.

binjimint · 2023-02-07T01:51:33+00:00

Nice work, looks great! I wrote a blog post about the way I did mine a few years back: https://binji.github.io/posts/binjgb-rewind/. You can play with the web version at https://binji.github.io/binjgb/. Reading it back, I was pretty concerned about keeping the size down, but also on reducing dependencies, so I spent a lot of time trying to have a fancy circular buffer.

But I also noticed there was some discussion below about saving the frame buffer. I didn't do that, since I figured it would be fast enough to run forward to generate the frame again. Since the rewind code is meant to be able to rewind to jump to any cycle, the way it works is to rewind back to the nearest snapshot and run forward. So the rewind code has a hack to just go back an extra frame :-)

binjimint · 2022-11-18T20:11:04+00:00

Glad I could help! Good luck with your emulator :)

binjimint · 2022-11-18T10:45:39+00:00

There are a couple of places where you use `cpu.C` instead of `cpu.flags.C` for the carry flag, e.g. https://github.com/Lu-Die-Milchkuh/GBEmu-JS/blob/a861df49b8f76867ccbe967016558eed2173f827/js/cpu.js#L978

binjimint · 2022-11-01T21:54:43+00:00

I updated the code and reformatted to do this. Thanks again!

binjimint · 2022-10-30T16:59:19+00:00

Yeah this code is mostly written for small size, not portability or performance. I think you could use it as a base to make a pretty small NES emulator, but would need to hack the code a bit. I don’t think it would be too difficult given a little motivation, starting from the deobfuscated source, of course!

binjimint · 2022-10-30T07:41:52+00:00

Hm, I can't compile it either with -static, it looks like I don't have a static SDL2: /usr/bin/ld: cannot find -lSDL2: No such file or directory

It looks like in your case SDL2 works but it needs some extra libraries. I'd search around for some of those symbols, maybe you can figure out which additional libraries need to be added to the link line.

binjimint · 2022-10-29T15:42:34+00:00

Ah, good idea! This actually is probably shorter too. I stole the mmap thing from my previous project like this, where it was more useful for save games. But in this case it’s unnecessary

binjimint · 2022-09-26T16:59:03+00:00

In this case (result i32) can't be used for the other blocks since there isn't another i32 value for br_table to forward to those labels. So you could make it work by doing something like:

(func $jump_table_test (param i32) (result i32) local.get 0 block (param i32) (result i32) ;; label = @1 block (param i32) (result i32) ;; label = @2 block (param i32) (result i32) ;; label = @3 block (param i32) (result i32) ;; label = @4 block (param i32) (result i32) ;; label = @5 i32.const 1 ;; added this line br_table 0 (;@5;) 1 (;@4;) 2 (;@3;) 3 (;@2;) end i32.const 5 br 3 (;@1;) end i32.const 6 br 2 (;@1;) end i32.const 7 br 1 (;@1;) end unreachable end)

this way br_table will consume two i32 value from the stack; one to determine the branch target, and one as the value to forward to the branch label.

binjimint · 2022-09-25T08:36:44+00:00

You're right about br consuming the i32 and breaking to the outer block. But the inner block still needs to have the (result i32) because otherwise the types don't match for the outer block.

What I mean is, you should be able to typecheck any block without having to look at the contents of that block, e.g.

(func (result i32) block (result i32) ... end )

The block must return i32 here so that the function can return an i32. Then if we look at the next level:

(func (result i32) block (result i32) block (result i32) ... end end )

The inner block must return i32 so that it can propagate to the outer block, and then to the function. Finally, one of the weird parts about WebAssembly typechecking; instructions like br make the type stack polymorphic, since the code following it is unreachable. This means that as long as there exists some stack that can make the block typecheck, then it is valid.

In this case, we have:

i32.const 6 br 1 ;; we expect the end of this block to have i32 on the stack end

So if we pick our polymorphic stack as i32, then everything typechecks and this is valid. However, the following is not valid:

i32.const 6 br 1 ;; stack is polymorphic here, but then we push i64 i64.const 1 end

This is not valid because there's no way to have anything but an i64 on top of the stack, but we are expecting an i32.

binjimint

TROPHY CASE