Some nice updates over the weekend for sokol_app.h on Windows (TL;DR: D3D11/DXGI swapchain resizing during window resizing is enabled now, and a presentation-mode fix for Win10+ when vsync is disabled).
Details in the changelog:
github.com/floooh/sokol/blob/master/CHANGELOG.md
8 likes
"Mixing initialized and uninitialized data bloats the executable size"?
I was reading the source for this pacman game written in Zig and Sokol, and there's a comment on line 401: "keep the big undefined data out of the state struct, mixing initialized and uninitialized data bloats the executable size". From what I gather, this has to do how static memory is stored in the binary, which is a little beyond me but makes sense. But what should I do about it? The repo has it segregated into its own top-level struct, but why can't it be a sub-struct like the other things in State? It doesn't seem very ergonomic to have a second state struct of members whose only unifying feature is that they're "too big".
15 points · 3 comments
Small update for sokol-gfx: it's now allowed to initialize the content of images and buffers that have copy_dst usage with CPU-side data (this was an accidential leftover in the validation layer from the old resource update API):
github.com/floooh/sokol/blob/master/CHANGELOG.md
10 likes
For me it's simply that iTerm2 got really fat over the years, and Ghostty was a nice and slim alternative - plus it has one of the better Kitty Graphics Protocol implementations which is fun to tinker with. e.g.: floooh/chipz-kitty (needs zig-0.17.0).
> but I wish there was a middle ground between it and VK
There's WebGPU (probably the best option for teaching), D3D11 and Metal.
And (shameless plug): sokol-gfx tries to find a balance between simplicity and modern 3D APIs:
floooh/sokol
Demos with links to C source and shader code:
WebGL2 backend: floooh.github.io
WebGPU backend (has a couple more demos which use features not available on GLES3.0/WebGL2, like compute shaders): floooh.github.io
New sokol_gfx.h update: copy data between image objects (next step in the new resource update API), some minor breaking API cleanup, and a couple of fixed bugs from recent updates.
Changelog: github.com/floooh/sokol/blob/master/CHANGELOG.md
New sample: floooh.github.io
17 likes · 1 repost
The README mentions floooh's implementation which is a bit more simplified, there is no complete netlist so the smaller TTL glue chips will not be considered. It does work in real time though. The common interface between emulated ICs is a 64-bit integer that maps logic levels of interest at a given simulation step to its individual bits:
- github.com/floooh/chips/blob/master/README.md
- github.com/floooh/chips/blob/9e88298ce56319953ac7…
- floooh.github.io (use the "Hardware" menu to get activity views similar to Salvatore's emulator)
はえ～…CPUコアに使ってるのはこれか… floooh/chips
ハードウェア寄り（制御信号のエミュレーション）でCヘッダのみの各種チップエミュレータ…
33 views
New sokol_gfx.h feature: fragment shaders can now write into storage buffers (previously writing to storage resources was only allowed in compute passes).
Changelog item: github.com/floooh/sokol/blob/master/CHANGELOG.md
New sample (needs WebGPU): floooh.github.io
11 likes · 2 reposts
Just learned about this crazy-ass browser MMO using Sokol for rendering:
slopa.io
Some more details:
sokol#1618
9 likes · 1 repost
Mentions
Some nice updates over the weekend for sokol_app.h on Windows (TL;DR: D3D11/DXGI swapchain resizing during window resizing is enabled now, and a presentation-mode fix for Win10+ when vsync is disabled). Details in the changelog: github.com/floooh/sokol/blob/master/CHANGELOG.md
"Mixing initialized and uninitialized data bloats the executable size"? I was reading the source for this pacman game written in Zig and Sokol, and there's a comment on line 401: "keep the big undefined data out of the state struct, mixing initialized and uninitialized data bloats the executable size". From what I gather, this has to do how static memory is stored in the binary, which is a little beyond me but makes sense. But what should I do about it? The repo has it segregated into its own top-level struct, but why can't it be a sub-struct like the other things in State? It doesn't seem very ergonomic to have a second state struct of members whose only unifying feature is that they're "too big".
Small update for sokol-gfx: it's now allowed to initialize the content of images and buffers that have copy_dst usage with CPU-side data (this was an accidential leftover in the validation layer from the old resource update API): github.com/floooh/sokol/blob/master/CHANGELOG.md
For me it's simply that iTerm2 got really fat over the years, and Ghostty was a nice and slim alternative - plus it has one of the better Kitty Graphics Protocol implementations which is fun to tinker with. e.g.: floooh/chipz-kitty (needs zig-0.17.0).
> but I wish there was a middle ground between it and VK There's WebGPU (probably the best option for teaching), D3D11 and Metal. And (shameless plug): sokol-gfx tries to find a balance between simplicity and modern 3D APIs: floooh/sokol Demos with links to C source and shader code: WebGL2 backend: floooh.github.io WebGPU backend (has a couple more demos which use features not available on GLES3.0/WebGL2, like compute shaders): floooh.github.io
New sokol_gfx.h update: copy data between image objects (next step in the new resource update API), some minor breaking API cleanup, and a couple of fixed bugs from recent updates. Changelog: github.com/floooh/sokol/blob/master/CHANGELOG.md New sample: floooh.github.io
The README mentions floooh's implementation which is a bit more simplified, there is no complete netlist so the smaller TTL glue chips will not be considered. It does work in real time though. The common interface between emulated ICs is a 64-bit integer that maps logic levels of interest at a given simulation step to its individual bits: - github.com/floooh/chips/blob/master/README.md - github.com/floooh/chips/blob/9e88298ce56319953ac7… - floooh.github.io (use the "Hardware" menu to get activity views similar to Salvatore's emulator)
はえ～…CPUコアに使ってるのはこれか… floooh/chips ハードウェア寄り（制御信号のエミュレーション）でCヘッダのみの各種チップエミュレータ…
New sokol_gfx.h feature: fragment shaders can now write into storage buffers (previously writing to storage resources was only allowed in compute passes). Changelog item: github.com/floooh/sokol/blob/master/CHANGELOG.md New sample (needs WebGPU): floooh.github.io
Just learned about this crazy-ass browser MMO using Sokol for rendering: slopa.io Some more details: sokol#1618