Same, I've added a .#screenshots derivation. High up-front effort but almost zero maintenance afterwards.
Bonus: since you're generating screenshots programmatically anyway, you can generate a pair of each with your app's light/dark theme, and swap them in/out depending on prefers-color-scheme: dark. <picture> elements work in GitHub READMEs, too: https://github.com/CyberShadow/CyDo#readme
willm 16 minutes ago [-]
I approve of this approach.
The docs for Textual (TUI library for Python) build screenshots along with the docs. Technically not really screenshots, they are SVGs, but principle is the same. They never get out of date.
For the small casual games I've been vibe coding, I always start from a place where the application has a CLI where it can run headless, rendering to offscreen texture, with a a screenshot command as well as performance instrumentation. It takes no time to include all this, and gives the agent a way to automate the ui and inspect important things. It also lets me trivially have the agent update screenshots.
Not as neat as being part of the build process, but I will now add that.
sho_hn 2 hours ago [-]
I do the same :-)
I have an offscreen screenshot path, as well as a CLI arg for world pos/camera view vector, and scripted benchmark runs with a simple text-based input format that has rows of named segments of n game ticks length with control inputs per segment. Use that extensively for A/B testing of visuals and performance while working on the game code.
avaer 26 minutes ago [-]
> It takes no time to include all this
In some cases it does. Which engine?
_fzslm 2 hours ago [-]
Would you mind sharing a link to some of these casual games? I ask cuz I'm also interested in how vibe coding can make game development easier.
We had such a vibrant indie game scene when Adobe flash was about and since then nothing's really touched that level of ease of development. I think vibe coding is the first tool that actually exceeds it.
merelysounds 2 hours ago [-]
This is very useful in mobile projects.
App stores require screenshots, but generating N images for NUMBER_OF_SCREEN_SIZES times NUMBER_OF_LOCALIZATIONS can be a chore.
In the past I wrote my own scripts for that, today tools like Fastlane[1] help.
I use Fastlane for my logic puzzle game Nonoverse[2], you can see sample screenshots in its App Store page.
I also automated App Preview video recording, complete with multiple scenes. If anyone wants to read more let me know, perhaps this is a good topic for an article.
I've needed this so many times. BTW this should be a meme: "I think this might be the neatest thing I’ve built in X that nobody will ever notice."
bobek 42 minutes ago [-]
Plus we had a visual diff on the top of that as a part of the CI pipeline. It prevented a bunch of mishaps ;)
schneems 3 hours ago [-]
This is neat. I wrote https://github.com/zombocom/rundoc. It has a similar feature. The main driver is to produce tutorials so it also puts the output of commands run back in the document.
Xmd5a 56 minutes ago [-]
> Then you change the UI slightly – tweak a colour, move a button, update some copy – and suddenly every screenshot that includes that element is stale. You know they’re stale. Your users might not notice, but you know, and it gnaws at you.
Read the article you’re linking to, it is not relevant here.
xp84 1 hours ago [-]
Bravo. This is incredibly useful, and really improves the quality of documentation, especially for many applications whose design and UI are always in flux.
maderalabs 3 hours ago [-]
Nice! I actually started to build this exact thing a couple years back, and ended up abstracting it out to something more generic with https://picshift.io/. That said, I still love the screenshot use case - the original name of this project was ScreenSync ;)
Barbing 1 hours ago [-]
Neat, good job, and good to have these different approaches out there
kalb_almas 2 hours ago [-]
I'm sometimes getting
NoMethodError at /self-updating-screenshots
undefined method `name' for nil:NilClass
Ruby title-for: in handle, line 12
Web GET interblah.net/self-updating-screenshots
followed by a very detailed traceback when I try to access the page
efortis 19 hours ago [-]
same here, but linking to the screenshots used for pixel diffing, which get committed to the repo.
I’ve wondered about doing screenshots from the e2e test run, even keeping docs/ all together in the same repo so when you update the documentation and need a new screenshot you add a new test
est 4 hours ago [-]
I maintain an internal wiki, the contents were generated by each CI/CD and always reflects from latest running code.
I wrote a gui app once that ran on a safety-critical platform. I ended up stuffing a rendering of the gui (rendered offscreen) into shmem at I think 24hz, and rendered that screenshot into the safety critical application. I passed clicks (no typing for this gui) back from the statically rendered image updating on a cadence, to the offscreen GUI.
Worked well. Not quite the same as this, but that’s what this reminds me of.
yjftsjthsd-h 2 hours ago [-]
I don't think I follow. What is that giving you that you wouldn't get by just having the user click in the application and see its real interface directly? Or are you saying you were embedding one application inside another?
jfim 2 hours ago [-]
My guess is that it's to ensure that the UI logic crashing or hanging doesn't bring down the safety critical process.
immanuwell 22 hours ago [-]
nice, embedding the capture instructions right in the markdown as comments is a dead-simple solution that'll age way better than any fancy external tooling
TranspectiveDev 2 hours ago [-]
[dead]
Rendered at 05:11:45 GMT+0000 (Coordinated Universal Time) with Vercel.
Bonus: since you're generating screenshots programmatically anyway, you can generate a pair of each with your app's light/dark theme, and swap them in/out depending on prefers-color-scheme: dark. <picture> elements work in GitHub READMEs, too: https://github.com/CyberShadow/CyDo#readme
The docs for Textual (TUI library for Python) build screenshots along with the docs. Technically not really screenshots, they are SVGs, but principle is the same. They never get out of date.
https://textual.textualize.io/widgets/markdown/#example
For the small casual games I've been vibe coding, I always start from a place where the application has a CLI where it can run headless, rendering to offscreen texture, with a a screenshot command as well as performance instrumentation. It takes no time to include all this, and gives the agent a way to automate the ui and inspect important things. It also lets me trivially have the agent update screenshots.
Not as neat as being part of the build process, but I will now add that.
I have an offscreen screenshot path, as well as a CLI arg for world pos/camera view vector, and scripted benchmark runs with a simple text-based input format that has rows of named segments of n game ticks length with control inputs per segment. Use that extensively for A/B testing of visuals and performance while working on the game code.
In some cases it does. Which engine?
We had such a vibrant indie game scene when Adobe flash was about and since then nothing's really touched that level of ease of development. I think vibe coding is the first tool that actually exceeds it.
App stores require screenshots, but generating N images for NUMBER_OF_SCREEN_SIZES times NUMBER_OF_LOCALIZATIONS can be a chore.
In the past I wrote my own scripts for that, today tools like Fastlane[1] help.
I use Fastlane for my logic puzzle game Nonoverse[2], you can see sample screenshots in its App Store page.
I also automated App Preview video recording, complete with multiple scenes. If anyone wants to read more let me know, perhaps this is a good topic for an article.
[1]: https://fastlane.tools/
[2]: https://apps.apple.com/us/app/nonoverse-nonogram-puzzles/id6...
F
Related: Sabotaging projects by overthinking, scope creep, and structural diffing – https://news.ycombinator.com/item?id=47890799
NoMethodError at /self-updating-screenshots undefined method `name' for nil:NilClass
Ruby title-for: in handle, line 12 Web GET interblah.net/self-updating-screenshots
followed by a very detailed traceback when I try to access the page
https://github.com/ericfortis/mockaton/tree/main/pixaton-tes...
https://github.com/simonw/shot-scraper
Worked well. Not quite the same as this, but that’s what this reminds me of.