I didn't find any noise or whining in the post. The text mentions "effort to keep the apps updated" which is more than just updating the API number. You are frequently requested to adapt the app, the signing process, fill in the ever increasing compliance data. Every request for change is accompanied with a threat.
My app had no privacy concerns, didn't collect any data or even require internet access.
I was still expected to jump through all kinds of hoops every few months. Even after I gave up and my app was delisted I still get regular requests for new hoops they came up with with more threats that they would delist (even more?).
And yes, the app was moved to F-Droid which makes it invisible for just about 100% of Android users. I still think these kinds of posts serve as a good deterrent so others don't invest the effort in the Google Play store. The store is meant for corporations. If you are enthusiast or a non-profit considering the app a one-time investment, it will pester you and wear you down.
How difficult is it to clean the syringe after the liquid passes through it? Does the leftover gum stick to metal and glass? Would it be possible to just pour the liquid into the mold (maybe through a a metal funnel), and use vibration on the mold to make sure all the creases are filled in? How important is the pressure?
You ask for vegan recipes from a website. AI ignores actual content and instead offers "helpful" tip. This qualifies as hallucination. The system should help you access the web and instead it implies that the content is missing. This is actually why I prefer Edge over Chrome, they are similarly hostile to users but they are also utterly incompetent.
I agree about the nutritional yeast. Tastes great but has only a single texture that can't really stand in for most of cheese types. Apparently there was a recent breakthrough with E coli producing milk proteins that sounds very promising.
Personally I hated the NXP's docs for the ARM M4 core. Bunch of dry tables listing each register in details, lacking the juicy diagrams and descriptions on how the bits integrate to work as a subsystem. I constantly needed to cross-reference 3+ documents (most of which describe the whole family and not the specific IC). Their HALs and code samples were obviously written by students/interns.
I liked working with Microchip uC, but this was back when the whole IC (PIC24) was described in a single ~1000 page document. I found it very readable and instructive in general.
If I had to pick something today it would be with RP2040/2350. The docs look awesome and there's a huge community that is not locked down in some corporate moderated forum but spread organically, with actually useful GitHub projects. It is the only embedded product where it felt like the open source community is along for the ride and not just picking up the scraps. I hope they continue this line of products.
Yeah, NXP in my experience had an issue with having too much documentation. In the sense that you get drowned in a 3000 pages PDF that lists every detail but becomes hard to parse unless you want to base everything around that specific platform for years. Though that sounds like an awesome "issue" to have in some circumstances.
The PIC24 was actually my first large project. I learned awful lot from reading its docs, for example setting the DMA to read 32 samples from ADC and let CPU know when done. Putting it together felt like playing with LEGO blocks. There were many annoyances with the toolchain and the clumsy memory addressing but I enjoyed it overall.
The NXP was downright unpleasant compared to it. I don't think a junior could be handed a NXP dev board and all the docs to hone their craft. It requires significant patience and expertise to pick out the relevant details in the vastness of their documentation. Of course the NXP product line is huge and I can only comment on few uC models I had contact with. The sensors and other less complex ICs were vastly better and docs were quite digestable.
Sometimes, doing something is worse than doing nothing at all.
> For that matter, using licensing to restrict government abuse obviously isn’t going to work, because licensing relies on state enforcement of rights anyway. If the state itself is compromised, having a clever little license isn’t the failsafe the OES thinks it is. It’s really just asking the police to arrest ICE with extra steps. This isn’t hypothetical, this is already codified in the law: even the international treaties that govern copyright have explicit exemptions for government action related to security interests. A license like this one can only ever possibly do harm.
> It is worse than ineffective; it is wrong too, because software developers should not exercise such power over what users do. Imagine selling pens with conditions about what you can write with them; that would be noisome, and we should not stand for it. Likewise for general software. If you make something that is generally useful, like a pen, people will use it to write all sorts of things, even horrible things such as orders to torture a dissident; but you must not have the power to control people's activities through their pens. It is the same for a text editor, compiler or kernel.
Lol. I would like a pen that could not be used to torture a dissident through any means. We have no way to build such a pen, but if we could, I would like it. I agree I don't want Meta or Google making pens that don't let me do things Meta or Google doesn't approve of. But indie dev restricts against war and gambling with their pens is hardly the same thing. Context matters in this case. The difference between resistance and oppression comes down to context, in this case.
To go a step further. DRM is the bad kind of this, and it exists and is used by corporations to restrict freedom. You can't use an indie devs code for war or gambling is the good kind of this. More that and less corporate DRM, please.
The entire video game industry is presently mostly indistinguishable from the gambling industry, and cryptocurrencies are just a special case of cryptographic authentication.
That means these rules are subjective.
Does “military use” include selling games to soldiers to play them whilst on base? Seems like a strict interpretation would say “yes”.
Licenses like this are complete and total nonstarters for anyone serious. It’s risk and potential liability nightmares for no benefit.
The art style looks really great! It is cohesive and makes the most of the low poly art. I would definitely play this (in single player).
Your stack seems very reasonable and stable. I've also worked on similar things (Gerstner waves, god rays, grass, dynamic skyboxes) from comfort of Lua and nice API over Vulkan. Implementing each of those visual components was very satisfying work. Alas, I never managed to weave more than ~3 together into the same project.
How does the AI work? There must be a lot of it for a factory builder?
Thank you! That's awesome, I look forward to trying Vulkan eventually. There's actually no AI in the game; no pathfinding either. The player has full control of creating routes for the drones (e.g. like building conveyor belts). And there are no enemies in the game other than storms - the game intentionally just focuses on weather as the "enemy"!
I would rather recommend this video [1] from SimonDev. It is much more enjoyable to watch. But all of these explain the exact same approach of rendering instanced geometry, with wind dynamics made in vertex shader.
I used this as reference to implement an infinite grass world in ~300 LoC of Lua and GLSL.
I enjoyed the "Medieval Demographics Made Easy" (as well as other materials from John Ross). It is a 6-page article made for GMs to aid in crafting believable medieval worlds. It's not enough on its own for your needs but it touches on relevant topics with just the right amount of details.
It is a common pattern in rendering. You achieve your desired results, but it is nowhere near realtime. You try to lower the sampling resolution which helps a lot with speed, but you end up with ugly visual artifacts. Introducing the blue noise in the right place helps with attenuating these sampling artifacts. Only usually you would sample the premade "blue noise" texture rather than using the shader to compute it.
This article does a good job of explaining how it helps in raymarching:
And for an IMO much better explanation how it can be used more or less everywhere, this presentation by Playdead games on how it's used in INSIDE: https://www.youtube.com/watch?v=RdN06E6Xn9E
IMO the linked article by Casey Muratori is actually kind of weak: a lot of waffling, doesn't actually show the results of using this point set in the original problem, just using the sampling pattern isn't enough to eliminate aliasing, and there are more important properties for point sequences to have (discrepancy), etc. It's somewhat unpopular these days to link dense texts instead of "softer" articles, but IMO one should just go straight to PBRT for this topic, there's an entire chapter with excellent presentation: https://pbr-book.org/4ed/Sampling_and_Reconstruction
Final note: the Don Mitchell mentioned in this article is one of the authors on the go-to reconstruction filter used in a lot of software, Mitchell-Netravali (the latter recently passed away): https://en.wikipedia.org/wiki/Mitchell%E2%80%93Netravali_fil...
