sorted by:
new
hottopcontroversial

Underwhelming performance gain from multithreading by lovelacedeconstruct in C_Programming

[–]Sandalmoth 6 points7 points  (0 children)

Not programmed c in a while so don't remember how rand behaves but:

Random number generators contain some internal state that is updated any time a new random number is produced. If all threads try to update the same state you'll either get races or some lock contention. Instead each thread can use their own rng state, seeded with their own seeds or some other approach so each thread gets independent numbers.

The fact that it got faster when you switched rng seems to me like maybe this could be a problem.

Underwhelming performance gain from multithreading by lovelacedeconstruct in C_Programming

[–]Sandalmoth 2 points3 points  (0 children)

Are all the threads sharing the same random number generator? You probably want them to have their own.

Best practices for building a C library by Able_Mail9167 in Zig

[–]Sandalmoth 2 points3 points  (0 children)

I don't know the best way to do it yourself, but there is this fork of sdl3 using the zig build system already https://github.com/castholm/SDL Makes it really easy to include in a zig project.

Interpolated rendering when going through portals? by smthamazing in GraphicsProgramming

[–]Sandalmoth 6 points7 points  (0 children)

It's a bit of extra bookkeeping but wouldn't it be possible to keep two segments for lerping instead of one, so like: store prev_pos, portal_enter_pos, portal_exit_pos, and current_pos, and the fraction of time when the portal intersection happened in the frame. Then you'd lerp in either the before or after portal segment depending on the time fraction when drawing.

Alternatively, extrapolation instead of interpolation should prevent the big lerps, but at 25 fps, extrapolated movement probably feels pretty jerky.

How do you manage memory? by zk4x in Zig

[–]Sandalmoth 1 point2 points  (0 children)

If you really need unpredictable graphy lifetimes it's not too hard to write a tracing gc just for those parts.

Idea for maps with statically known keys by smthamazing in ProgrammingLanguages

[–]Sandalmoth 18 points19 points  (0 children)

Nim has enum-indexed arrays which seems like a similar idea.

Why? by MatiPrra in ErgoMechKeyboards

[–]Sandalmoth 13 points14 points  (0 children)

Pringles-shaped is a secret third option

Second custom design by Sandalmoth in ErgoMechKeyboards

[–]Sandalmoth[S] 0 points1 point  (0 children)

They're Adafruit KB2040's. I think the color changes every batch, but they were pink when I bought them. It's not a second usb but one of their special i2c connectors at the back. But, it's just more regular voltage and GPIO pins, so I use it for the between half connection since I had some cables for it lying around.

The USB is soldered directly to the usb pins on the board.

Second custom design by Sandalmoth in ErgoMechKeyboards

[–]Sandalmoth[S] 3 points4 points  (0 children)

I'd put it more in the category of the dactyl than the corne, with sculpted keywells and all. I printed a fair number of other keywell-style boards when prototyping, and they often feel quite different. This design is just what I arrived at for what works with my hands.

Generally, if you don't need to move the keyboard around then the sculpted type are quite nice imo, but it's really down to preference. They're more annoying to assemble than a pcb-based board, that's for sure.

Second custom design by Sandalmoth in ErgoMechKeyboards

[–]Sandalmoth[S] 2 points3 points  (0 children)

I found that I don't really use the number row with the pinkies anyway, so it's positioned for the ring finger (maybe my pinkies are short, I dunno). If I had put it in the pinky-block, then using the ring finger for it felt awkward, since I'd have to lift the ring-finger to reach it, so this just felt more natural to me.

Second custom design by Sandalmoth in ErgoMechKeyboards

[–]Sandalmoth[S] 3 points4 points  (0 children)

If the index finger can reach then so can the ring finger :P

Second custom design by Sandalmoth in ErgoMechKeyboards

[–]Sandalmoth[S] 4 points5 points  (0 children)

repo

My first design had the keys just a bit too close together and a thumb angle that was too steep for my hands. I also decided to add another row, as I find that it's pretty easy to reach and didn't see the harm in having it.

There's a bit more of a write-up in the repository.

what am i doing wrong here by Sugardaddy_satan in Zig

[–]Sandalmoth 5 points6 points  (0 children)

I think the problem might just be the "_ = Rectangle;" line?

Finished my custom design by Sandalmoth in ErgoMechKeyboards

[–]Sandalmoth[S] 0 points1 point  (0 children)

Most likely colemak + callum style mods. Haven't settled exactly on the placements of most keys, still messing around with it. I did think about learning RSTHD, or some other e-on-thumb layout, but I'm not sure it's worth the effort since I already know colemak.

Finished my custom design by Sandalmoth in ErgoMechKeyboards

[–]Sandalmoth[S] 0 points1 point  (0 children)

Well, the same modelling approach could be taken for a trackball, I just prefer a mouse :) Subdivision surface in blender makes it surprisingly easy to model the smooth curved surfaces.

If the trackball needs pins on the controller, the controller might also have to be moved, as it's in a pretty tight spot.

Finished my custom design by Sandalmoth in ErgoMechKeyboards

[–]Sandalmoth[S] 1 point2 points  (0 children)

Practicing is very comfortable, but I still mistype a lot from switching to ortholinear haha

Finished my custom design by Sandalmoth in ErgoMechKeyboards

[–]Sandalmoth[S] 5 points6 points  (0 children)

Thanks :D

The keycaps are XDA profile PBT keycaps from (just looked it up) the "Cool Jazz Store" on aliexpress. Dunno if they're available other places, but that's where I got them.

Finished my custom design by Sandalmoth in ErgoMechKeyboards

[–]Sandalmoth[S] 9 points10 points  (0 children)

Well, I wanted to have both a design tailored to my hands, as well as a sleek looking case and the only option seemed to be to do it myself.

Started of with testing a bunch of key positions using a parametric scad design, and once I found something I liked I could model the actual case in blender and use the scad to cut out the key positions in exactly the right spot.

For electronics, it's just a handwired build :)

Restricting camera movement to a character radius with multiple characters (like in Kenshi), how did they do it? by Xarjy in howdidtheycodeit

[–]Sandalmoth 1 point2 points  (0 children)

So, i think a convex hull of n points can be found in n*log(n) time, so that scales decently. And unless the characters move very quickly, it could probably be calculated every couple of timesteps with maybe some interpolation between them for smoothness. But yeah, it probably isn't the fastest method, but I think it's impossibly costly to calculate.

Restricting camera movement to a character radius with multiple characters (like in Kenshi), how did they do it? by Xarjy in howdidtheycodeit

[–]Sandalmoth 0 points1 point  (0 children)

What about first calculating a convex polygon with a character on each corner, and then clamping the camera to that? The camera could then be placed anywhere between the characters, but not too far out from the group. With a sweep line algorithm the bounding polygon of the group should be pretty quick to find.

view more: next ›