alright, pretty big update to the Tiny Emulators page: new KC85/2 family emulators, more subtypes for the existing emulators, more file loading support, more games (mostly KC85 stuff), and the emulator git branches merged back to master:
#WebAssembly
Alright! perfect6502 simulation hooked up to the chip visualization running though the visual6502 standard test program at one half-cycle per frame :D
Time to start with the UI :)
(cc
@pagetable
)
@kettlecorn
@natfriedman
...or as the saying goes "Poor planning on your part does not necessitate an emergency on mine.".
This should be the first thing hammered into the mind of newbies. There are very rare actual emergencies where staying late may be justified. Made-up deadlines are not an emergency.
I finally finished that blog post of how I'm using handles instead of raw- or smart-pointers in my C and C++ code, probably not very exciting for veteran coders, but hopefully useful for everyone not yet aware of the "C++ smart-pointer trap" ;)
I wrote a new blog post "Modern C for C++ Peeps":
Not the post about header-only libs I had in mind originally, that's still lying around half-finished. The post above was a lot easier to write in one sitting :)
@DanielcHooper
TBH, even machine code is a high level abstraction compared to what a CPU does internally (e.g. assembly code is a high level language which provides the illusion that instructions are processed in order).
OMG looks like it's possible to render the Visual6502 data set with Dear ImGui at a smooth frame rate! And that's just a quick adhoc experiment without any optimizations.
...I think the next steps are inevitable :D
(cc
@ocornut
)
AI chat tools would be alot less creepy (and time-wasting) if they would give short and crisp answers instead of that overly talkative "American" conversation style.
A simple: "No/yes, because: ...". would do. Give me a "German Engineer" conversation style option please.
Hey
@CrowdStrike
, if you think you need to inject yourself into other processes, could you please do this without crashing them?
This has happened to several of my customers, without them knowing what's going on.
Fix this!
Signed,
Windows Developers
a bare bones C64 emu written in C99, compiled to
#WebAssembly
in under 64K (43 KB WASM + 15 KB JS, compressed download size), sokol_app.h + sokol_gfx.h + sokol_time.h + 8-bit chip headers:
Interesting: the included line count of <vector> in Clang is roughly "C++ version * 1kloc" (via clang -E -std=c++..):
C++11: 12810
C++14: 13870
C++17: 16905
C++20: 23127
C++20 is clearly ahead of its time :D
Whoop whoop, Dear ImGui running on top of Chrome's current
#WebGPU
implementation via emscripten/WASM and sokol_app.h + sokol_gfx.h :D
A bit of code cleanup, then I should be able to put up a little sokol-samples-on-WebGPU preview page over the weekend :)
One of the many things that Rust and C++ have in common is that Rust peeps are just as quick to dismiss Zig as C++ peeps used to dismiss C. That sort of closed-mindedness never pays off in the long run 🙄
A procedural animated creature, raymarched SDF as usual in
@Shadertoy
. It's a first basic attempt to some character animation. Live-Stream with the Making-of and QA soon! In the meanwhile, source code:
Wow, with one can build simple installable Electron/WPA-style apps (with WebGL, WASM etc) in a single 27 KB(!) exe (on macOS), that's insane. Uses the system's browser engine instead of a Chromium+Node.js runtime.
If you're a new programmer please don't fall for bullshit like this:
...typing code into the machine is the least important aspect of programming (there *is* a bit of an argument for "staying in flow" though: not thinking about typing while doing it)
All 6502-based Tiny Emus now support stepping by single cycles in the CPU debugger, very useful for debugging the video system, interrupt timing etc...
Not yet for Z80 systems because Z80 emu isn't cycle-stepped yet.
Webpage also updated:
"Blinkenlights is a command line debugger that focuses on visualizing how software changes memory."
\o/
Why is it always underfunded individuals who move computing forward, while big organizations mostly just flail around helplessly?
I figured that running the assembler on each keystroke probably burns 100x fewer cycles than that same keystroke cost so far traveling up to my code through all the OS layers, so ¯\_(ツ)_/¯
Ooooh WASM debugging via DWARF works now in Chrome Canary (most notable improvement over source-map debugging is that symbol names and structs are properly resolved). Debug-stepping is pretty slow though, esp the view-panel redrawing takes forever.
Remember kids: in a C++ source file which includes stdlib headers, your own code is just a tiny little piece dangling off at the bottom.
(what's up with modules btw, weren't those supposed to be the silver bullet?)
What's going on with LLVM's libc++ project? I noticed yesterday that the header file containing std::vector<> expands to 2 to 2.4 megabytes of pre-processed header code! (of which >99% is overhead) This ...
I created a minimal standalone starter-project for Dear ImGui apps written in C for Windows, Linux and macOS (via cimgui and the sokol headers):
Yeah, cmake, I know... but Windows'n stuff. I tried to keep it as simple as possible though.
very cool: clang compiled to WebAssembly running in browser, compiling C++ programs to WebAssembly, and run the result in browser, a bit like
@mattgodbolt
's , but without server: (discussion thread: )
Wow nice, in today's Safari Technology Preview upate on Mac (Release 197), the sokol-gfx WebGPU samples suddenly started working (cc
@SebAaltonen
maybe also interesting to check your WebGPU renderer with this version)
I must say the more I code in plain C the less I miss C++, C has this almost python-like simplicity and "smoothness" to it, and there is never this "which of the thousand C++ features is the right one for this situation" anxiety...
It's really quite bizarre how switching from Win10+MSVC to Linux with KDE and a GCC toolchain feels like a beefy hardware upgrade.
On Windows+MSVC it's "geez I *really* need a new laptop", on Linux+KDE it's "nah, still fine".
What's really nice about Zig is that the whole toolchain is in a 40-ish MB download archive which has exactly one executable (zig) in the root directory, and it "just works" after unpacking without running scripts or setting up env-variables.
Just run
/path/to/zig build
Trace logger in "Visual6502 Remix" working now, each log item is the full chip state and the first 4 KB of memory, and it's possible to go back in time. The UI stuff for this is all so super-simple and pleasant with Dear ImGui :)
WASM version here:
Nice short article detailing the differences between C99 and C++20 designated initialization (also a nice example of how C++ takes a wonderfully simple, flexible and intuitive C feature and applies the "C++ treatment", essentially removing those three attributes ;)
Without people who "pirated" the games I made in the 80's, and later digitized the cassette tapes and "illegally" put them on the internet I wouldn't be able to put them on a web page for everyone to play now. The games would be lost since my own tapes are no longer readable :/
An actually nuanced article about C, Rust and memory safety by a "security dude". Did somebody check if hell froze over yet? :)
(haven't read the whole thing yet, will do now)
\o/
This is a C++ command line tool with fairly complex dependencies (SPIRV-Tools,glslang, SPIRVCross, ...) compiled with Zig as C++ toolchain and build system.
WIP build.zig script (a straight port from cmake, and a bit adhoc cobbled together:
Zig is basically fixing decades old C/C++ tooling problems as a side quest :D
(Rust should take note, this is how you lure C/C++ coders into your camp)
#ziglang
Phew, slowly getting there with the sokol_app.h multiwindow stuff. Still a lot of work ahead so don't hold your breath ;)
The Dear ImGui viewport mode is basically the "required feature reference".
I started working on the WebGPU backend for sokol_gfx.h, not much to see yet, but I'll track the work in this PR if anyone is interesting in learning how I go about adding a new backend to sokol-gfx:
I almost feel a little bit excited :)
First printed presentation of the binary number system, 350 years old (and not by Leibnitz, but a "Juan Caramuel y Lobkowitz"). If it weren't for the Latin, this could also be taken from an old computer manual :)
(via
@nyquist64
)
well that Raspi4 desktop experience is shockingly delightful for a computer that costs as much as a video game... there's a few things I need to fix in my workflow because the
@code
C/C++ extension doesn't support ARM, so I need to use different plugins, but otherwise great!
So Baldur's Gate 3 apparently is completely DRM free even on Steam? This game really destroys all the "established" PC gaming business myths :)
(if you're not aware yet, BG3 has an insane CCU which is still growing, despite being a hardcore single-player-focused RPG )
I started a new min-blog-series looking in detail at the different sokol_gfx.h backends (first: GL). A bit "dry" and more like a reference, but might be useful for getting an idea how expensive certain things are in sokol_gfx.h in the different backends:
Ok, I've added some intro documentation to the code and consider Pacman.c "done" now (might do another run over the code comments though). It's not a complete replica of arcade Pacman, but "good enough".
WASM version, link to C source is bottom-left:
Interesting, I wasn't aware that
@Blender
is mostly written in C. Some C++ sources sprinkled inbetween, but all behind C-APIs. Might be a good study case of how to structure a big C project:
This is one of the hottest graphs I've ever seen. Rewrote a
@nodejs
API in
@rustlang
. Pretty much an exact port. It gets roughly ~180 requests per second.
See if you can spot when I deployed it:
Sokol samples (well, most of them) running on WebGPU (still very wip though, and still in a branch), needs Chrome on macOS or Windows:
(a bit more info over on Mastodon: )
The fact that .at() even exists and is allowed to exist for so long (instead of fixing operator[]) is a pretty good indicator of how broken the C++ standardization process is :/
The same is true for moving from C++ to C, but in the entirely opposite direction than C++ to Rust ;)
(essentially, realizing that data should be "dumb" and not "smart", and that a lot of data in an application can and should have "static lifetime")
OH:
"After writing 10KLOC of Rust, I've become a much better C++ programmer. And that's having written C++ for over 15 years."
Rust's lifetime model reshapes the way your brain fundamentally approaches data structures and algorithms.
Rust boot camp for all!
Every discussion about immediate mode UIs should start with:
- no, "immediate mode" does *not* mean that calling a "button" function immediately draws that button
- yes, immediate mode UIs can keep any amount state between frames
- yes, widgets can have stable identifiers
😩
Looks like somebody wrote an honest-to-god 6502 + Apple I emulator in shadertoy (the real deal, not just a "fake" BASIC terminal like the previous "C64 in shadertoy"). The interesting parts of the CPU emulation seem to be in "Buffer A" and "Buffer C":
@tumult
I've been thinking for a while that the key to a really "slick" computing experience is running old software on new computers.
It didn't occur to me that running old software in an emulator on new hardware is still faster than running new software on new hardware ;)
I just merged a new utility header "sokol_shape.h" for quickly creating simple shape geometries and plugging them into sokol_gfx.hl, along with a few new samples.
Header is here:
Samples with source code are here:
@blu51899890
@FlohOfWoe
They ran an A/B test that showed an increase in site usage while people were desperately trying to figure out where their shit went.
Using WASM outside the browser has become delightfully simple, and the "runtime" is just a single self-contained 7 MB executable (the other handful of installed files are things like readme, license, changelog...).
I just stumbled over an incredible series of blog posts of the inner workings of the Z80 CPU, most detailed I found so far, builds on the die analysis work by Ken Shirriff:
Oh man, Xcode13 is the gift that keeps on giving.
This is the typing performance in a 16kloc source file (about one or two characters per seconds, even slower if the CPU is busy - in Xcode12 this was completely fine).
This is awesome because GLSL is essentially "C without pointers", it demonstrates how far one can get without pointers (raw or smart) or references. Shadertoy was a tipping point for me to explore more into a "pointer- and allocation-free" direction when coding in C or C++.
This year I changed the last 2 assignments in my CG class
@dartmouth
to use
@Shadertoy
instead of C++. Overall it was a fantastic experience. Students implemented
@Peter_shirley
’s first ray tracing book, and then ray marching + sphere tracing of SDFs. Thanks
@iquilezles
!
.
@github
automatically blocking repositories which had contributions from (e.g.) Iranian developers is complete and utter madness (and besides, how can a repository maintainer even know what country a PR is coming from?)
Proposal: make such repos inaccessible to US devs only
A new project written in C by a Microsoft team. Maybe there *is* a glimmer of hope for an updated Microsoft C compiler that isn't two decades behind the standard.
(yeah, I'm a naive optimist)
It's remarkable how D3D12 and Vulkan came up with DescriptorSets and DescriptorTables and Root Signatures and what not to fix the traditional slot-based binding model, and Metal 2 just says "here's ArgumentBuffers" and everything is clear by just looking at this one slide: