mntmoss

One of the topics that comes up in article praise for cap & trade, pointing to the success of existing pollution laws.

In practice - last I checked, and I admit to not having followed them closely - I don't think carbon credit schemes have had a big payout just yet. I'm not ready to dismiss them, on the other hand. This might just be because more of the CO2 emissions get exported to the developing world, and so a true ROI has to wait until global economic goals start aligning.

It takes a whole chapter to explain rhythm because I have witnessed people spend literally over an hour stuck on "counting out a measure" with varying note lengths. This series is starting where a from-scratch musical education must start.

An education for theory training does end up focused on note interval structures, and there's an endless amount to talk about there, but then, you don't need a great deal of traditional theory for simple songwriting - major and minor triads will suffice. This tutorial gets those but in my skimming of it seemed to stop short of trying to explain circle of fifths usage, which is probably the one most essential thing to make composition in the large go from "I have to guess and check" to "I have a guideline to work from that lets me calculate ahead."

As restrictions go, I'm OK with this. I looked into doing some Atari 800(XL/XE) coding and for most any graphics application, you're bottlenecked by what you can keep around in main RAM, plus the limits of what you can program ANTIC/GTIA to do per scanline. Programming the scanline interrupts, you can manage to do quite a lot, and similar tricks with VERA are likely(fingers crossed). A lot of the latter day demoscene work on Atari relies on aftermarket RAM upgrades to unleash more of the raw power of the graphics hardware.

Of course, the X16 already accounts for that with its banked 2Mb RAM. Large RAM effectively means that most software for the platform can be single load, streaming in whatever is needed 8k at a time instead of going to storage media. But even so, a full 640x480 256 color image is so large relative to the RAM size that it's likely to be relegated to splash screens and demo effects.

It is actually still 8-bit aligned with padding - we are talking about a system with a 68000 and Z80 here. The way the graphics systems of the era accomplished color depths like this was generally to do one of two things:

1. draw them in "planar" mode(multiple bitmap layers of a more convenient depth like 1-bit, then composited together into the full image) vs the "chunky" mode we are familiar with(all color information packed in each pixel of the bitmap). Planar graphics are much less convenient for ordinary drawing tasks, but they allow for a tradeoff between memory usage and fidelity. Put they ease a few kinds of raster effects if you carefully use your palettes. This is what the Amiga OCS had, and VGA in many of the custom modes.

2. Allocate the colors to sprite and tile hardware with limited palettes, so that you can achieve "n colors visible" by carefully combining all the different elements. Each element might be able to sample part of the 9-bit space with a palette of 4 or 16. In the case of the Genesis VDP your limit is ~64 colors visible of 512, with the special Shadow/Highlight mode allowing more. This is not as big of a limitation as it sounds like since the low resolution graphics of the time weren't suited for detailed color values: 4 is enough to do a shadow/midtone/highlight, and 16 allows for substantial color ramps with multiple hues.

The plight of the typical grad isn't just that they have overly general knowledge for any one task, but that they have just emerged from a system that filtered their thoughts for possibly several decades into completing assignments and taking tests for a grade.

And once you get into industry you have to unlearn that because the clear objective goals and grades disappear, and you are left with an array of subtle values and more pernicuous consequences to any action. And that stuff is absolutely vital to being good at intellectual jobs - it's mostly crushed out by the system, fostering the "narrow STEMlord" mindset that is constantly surprised by things blowing up when they followed the book exactly.

One thing that tends to be excluded in most analysis of rent control is the preference of landlords to operate fewer, more expensive units. When you have more units, you have more to keep track of - more tenants, more staff, more maintenance. A high-end luxury unit and a dirty fleabag mostly differ in some move-in amenities and services; rich tenants might demand more, but they don't trash the place faster. So every unit tends to be luxury by default since that's where the upside is.

If your rent increase gets capped by rent control, your ability to stay at a limited scale of operation and just add to the price gets squeezed, and that motivates making more capital investments in property(and specifically in vertical upgrades, since horizontal expansion puts them in a land bidding war). It hits investment properties run by large companies the most, and challenges them to use land more effectively to stay competitive, in the same way that higher minimum wage challenges companies to use labor more effectively.

However, we still need an SB50 or successor bill to deal with the build restrictions. The landlords and developers can demand building big(and they do already in many cases) but they're held back by zoning laws put in place by NIMBY residents. The trick is that instituting rent control does something change the outlook of the NIMBYs too, since their property value has a relationship to the value of rentals. Rental rates and turnover slow down = property values slow down = their house becomes less of an investment.

So it's a good first step either way.

Game development eras and their style have a substantial correlation to locations and the teams assembled in them, but as you allude to, increasingly the demographics don't seem to matter as much as the culture, because the capital requirements have dropped so much.

A surprising amount of stuff, for example, came out of Chicago between the 80's and 90's. Why? Because amusement manufacturing was located there, so there was a direct crossover from solid state pinball to video games. Williams, Gottlieb and the rest all operated in the area. For similar reasons the bulk of Japan's game output in the 80's came from its three largest cities.

As the industry became more software-driven, it got easier to spread out, and with the merger mania of the 90's pooling up capital, you got the existence of studios with multiple offices in different cities. But you still needed some infrastructure and financing to run a studio, and so most large game studios are in "hip metros" even today.

But when you get down to the realm of current indie games doing digital distribution and Twitch streaming, your physical bottleneck is approximately the same as a writer: fast internet and basic city services. But writers benefit from having a creative circle, salon or similar gathering, and that creates an effect in indie games which I will forever remember from a TIGSource forum thread as the "globetrotting international hipster clique": creators who live very far apart and only see each other at big conferences. Often this ends in people from the same city learning of each other's existence by flying to a different city where a conference is. After you hit a critical mass of people aware of each other in a city, it's just a matter of running a regular local event.

And what I've noticed personally in some 9 years of attending or helping host those events is that while the games scene in a city will derive most of its people from other industries(e.g. in SF you get a lot of tech workers with a hobby project) the way in which it's shaped depends on the type of regular events held and their focus. Some events are focused on business or technical lectures; others are co-working of some form; still others are public-facing showcases. Each of those has their purpose and you do need a sufficiently large city to experience all categories, since without a balance you end up with an average game output that has too little creativity, is poorly shaped as a product, lacks in technical ability, etc. There is a lot of wasted time in indie games that results from someone, somewhere retreating into the work without other eyes on it.

With most categories of gear, there's a sharp quality threshold that hits below a given price range, and once you are above it, you need not go further to do professionally useful work. It's been a helpful rule of thumb for me.

One of the big asterisks with most D3 bone density studies(and is applicable to this one) is that they are studying older adults specifically, vs, say, athletes. There are bodybuilders, for example, who swear by high-dose D3.

Them being a gamer or developer doesn't actually add a great deal of value to their leadership abilities. Many are the examples of management justifying bad decisions as a "one of us" move.

What EA and any company of that scale needs most at the top is people who are interested in large-scale workflows, IP management, and labor issues. Some aspects of these things are tied to the creative and intellectual parts of the work, others aren't. But the point of being that big should be to capitalize on unique opportunities to do R&D or push larger-scope experiences. It's not the nickel and diming that makes for lasting success.

Everything does vary a substantial amount between districts and even individual schools since at the national level there are only a few guidelines(although standardized tests have crept in since No Child Left Behind), so even with the public system the schools vary between feeding the "school-to-prison" pipeline where students walk through metal detectors and have little breathing room, and "magnet" schools that soak up all the academic achievers and give them back-breaking workloads.

In general the school schedules are arranged for the benefit of the faculty more than the kids, though. The days start too early for most teens, and there's a lot of rushing between overly-short classes, to the point where I recall witnessing some students being marked persistently late simply because one teacher ends the class late and the other starts early. The upside of that is that you do tend to have a break because every single class has a few minutes of administrative work before it can really start.

Yes, and this kind of issue comes up a lot in computing when trying to find deep optimizations: If you make a processing pipeline that drops information and reduces quality as it goes along, you can always turn that into a speed-up, but some features become hard and others become impossible. So in the end most pipelines cohere into an unexciting but generalized-enough solution that retains some extra data, while the cool hacks and approximations are left as special cases used to get an effect in specific applications(and the history of real-time 3D is, in essence, a history of progressively fewer cool hacks and more generalizations).

I think your practices are fine - coding even a limited prototype reveals a lot of unanswered questions in a mental model. Once you have the model, you can apply it in a theoretical sense, but in my experience it takes longer to build one by not coding than it does by doing some coding, then some thinking. The only limitation on prototyping is that it's difficult to communicate what is being accomplished in the middle of the process, because you'll make something that looks negligent or incomplete - it isn't trying to answer all the concerns yet(that's what you do in production code).

The world feels very uncertain for the middle-class these days, especially in an economic sense, which is one that strikes right at the heart of one's "locus of control". It doesn't offer the same kind of promise or opportunity as it did 40 years ago, and risks are advertised constantly. Stoic teachings have broad applicability: Epictitus(my favorite flavor) says to control the things you can control, and to not worry about the rest.

There is a patriarchal thread to some of this, as Stoicism could be interpreted in a "men's rights" sense of asserting dominion and gender roles. But focusing on "the way things should be" is rather a false way of going about it, since there's also a thread of mutually respecting struggle and self-mastery in the Stoic philosophers. There isn't a point in Stoicism where the status quo ever becomes OK, where you are "good enough". There is only another form of struggle to be had.

I would definitely recommend going for calisthenic training with an emphasis on isometrics around young kids, rather than weights(equipment and prep time) or intensive cardio(too much time-on-task). Holding a bridge, squat-and-reach, or a downward dog for 30 seconds while the kid crawls around is feasible, and a few rounds of that daily will do a huge amount of good.

It's a good illustration of the difference between consumer products and simulators.

What reads as authentic to consumers is the moment-to-moment aesthetics like how guns handle or whether there's a percievable "stat" being modeled. The actual scenarios can be implausible or eliminate an inconvenient-but-important element, but if the overall experience repeatedly hits on the belief structure, it gets the "realism" moniker.

As a training tool, what matters is the big picture of how it supports key skills, conveys specific technical information, and enables new kinds of exercises to take place. A lot of consumer boardgames are great at developing strategic thinking even though their material is unrelated to any specific warfighting skill and the technical detail has been streamlined out; the reduction pushes the players to grapple with the consequences of every single move and play as far ahead as possible, often resorting to diplomatic options(deception or coalition-building) to get an advantage. Likewise most simulation tools do not require total simulation at fidelity, they need only the elements relevant to the training, so they can be incomplete as a portrayed experience of the scenario.

The most accurate answer w/r to the thing you linked is: All binaries used to be much smaller, by a factor of 100x or more. And so on this aspect of performance we have had a kind of regression where most things have a bigger footprint than necessary. Some of it is to be expected since 64-bit code is larger, and Unicode handling is larger, and we support more features even in the smallest CLI tools, but there's also an element of the tooling making an optimization that is locally sensible - expand code size to get some runtime performance benefits - and globally useless, since as the featuresets increase an increasing percentage of all code is "run once/run never" and not a hot loop, and so it's just wasting disk, memory and cache to have it in that configuration.

Something that never seems to come up when one of Jeff's art defense posts come up is that an RPG has a considerably higher asset load than most types of games, not just graphically but all around.

And historically, the genre has responded to this by sacrificing some aspect of polish - typically animation, but also often by just telling you about a thing with text.

What Jeff has done by stocking up and reusing generic assets is essentially a way of reducing that load so that the game actually gets produced on his microbudget targets. And what's really lost in that is any sort of "wow" moment where a distinctive scene, magic item or character design can make an impression visually.

However, I do think he could stand to leverage technology better. 3D might not be nostalgic, but it is the overwhelming preference of devs trying to use generic assets, since it gives you so much more utility(take the sword model and reskin it - new sword! same building with different decor - new scene!) and even puts some stock animation within reach, when relying on Mixamo or similar.

Jeff is already using these kinds of stock assets in the new game, it's just that faithfully implementing them into an old-style 2D tile renderer system makes them look worse than they actually are, since it guarantees that they look inconsistent in scale, perspective, lighting etc.

One productive way to respond to his challenge would be to give him an A/B: license his existing work to a small self-funded team, have them remake it aesthetically without changing how it plays. Have it launch on consoles and mobile. Then we'd really know if the assertions match the reality.

This feeling has swept over me, too. We didn't fully realize it at the time, but it was the twilight of our culture being transmitted through "big", tangible products with a distinct publishing apparatus like those demo CDs, VHS tapes, books, newspapers, TV programs etc. Everything went online and became both more available and harder to appreciate - although the old stuff has never gone away entirely, it's just waiting for us to look up from the screen now and then.

I have a little landing page on itch.io which can be followed if you have an account (but the content is getting embarassingly out of date): https://triplefox.itch.io/galapagos

Current release plan is to get some builds out late August/early September, both free and paid(paid simply gets the updates faster). Then later on, I can think about plans to open up development. PICO-8 took about two years from conception to release and I'm getting to around the end of year one of mine, and just about everything has had multiple iterations, but the first release will be a basic "run at the command line, code in your text editor, store assets in the file system" kind of environment. Releasing means I think the basic design is mostly settled, so after that all the UI and IDE functions will become possible.

I'm working on something like this, but as time has gone on I've made technical constraint less of a priority and focused more and more on the I/O and "bus" model itself, because that's where the ultimate bottlenecks lie. If you have all the processing power in the world but only a 256x256 space to draw in and a limited number of commands to draw with, you still have an interesting constraint.

One of the things I found myself doing with PICO-8's setup was prematurely optimizing code for size, which presented a new kind of puzzle(how to express things in fewer Lua tokens) but didn't feel good in terms of authoring finished work(I made a nice 3D maze wireframe renderer - and then stopped there). So with my own fantasy console I'm prioritizing other things beyond size/retro aesthetic, while still thinking about limitations. "Diversity" has become one of those things: you will have some ability to swap out graphics and sound cores, and use a variety of programming languages. The fixed spec approach makes it harder to make each part really distinctive and not just another "tiles and sprites and chiptunes" doddle.

Since I made the foolish decision to support 3D cores it's taken a while to get a renderer going, though, and I finally decided to speed things up by releasing with 2D first and adding more later.

The raw throughputs are definitely better but there is concern regarding latency even at the lowest levels, since today's CPUs have complex cache, power state and frequency throttling mechanisms. You cannot guarantee that something will perform with identical runtime in all expected use-cases unless you take care to use hardware that is optimized in that direction. And because the software environments are more complex a lot of capability is just dropped on the floor because the intermediate layers get in the way.

W/R to buffers in front of things, a decent number of the micro systems of the 70's were so memory starved that they would make these tradeoffs to retain video sync - that describes the Atari 2600("racing the beam" is the name of a book about the console), and Cinematronics vector games(if it did not complete drawing at 60hz, it reset). Most early arcade games did work with DACs(or rather ADCs) but ran their own calibration and button debounce code - and even with layers of abstraction that's still basically true today.

With graphics, the move towards desktop environments doing GPU compositing impacts graphics coders, since they now often have window manager buffers in front of them instead of direct access to a rectangle of pixels.

Web browsers are a more extreme example of this. Because the graphics model revolves around document presentation, things that aren't really documents, or are extremely customized documents, often get burdened by latency that they wouldn't have if it weren't for the browser.

The rules don't change because of the scale or timelines. You still iterate, from the smallest poem to the largest moonshot, but on big pieces of work, you iterate the most on the abstract bits of groundwork principles and process so that you can deliver good, detailed and coherent specifications when you go to delegate the work. "Man on the moon" was thousands of years of scientific iteration, followed by about a decade of focused engineering.

What the article rails against the most is blind iteration, the "make it fun," or "make it pop," "just change this one thing," type of vague sentiment that critiques but doesn't really direct. Blind iteration happens because the leads(or even on a solo project, the author as lead) ran out of templates to follow, and when you run out of templates you have to begin using trial and error to get results. But it's immensely cheaper(to the point of it being required in many types of project) to focus trial and error around finding a new template with better, clearer rules, than it is to send the order to make something to finished quality and then decide that it won't work and start over. However, the latter tends to happen every day, in all sorts of scenarios, from a poorly considered dinner plan to high-profile software projects.

Some of XML's biggest achievements lie in written documentation formats(DocBook, DITA) where fine-grained markup control is needed and the presentation of the content is secondary to semantic features like footnotes, indexing, etc. These are formats that professional technical writers turn to when Markdown, Word docs or PDF won't quite do the trick.

For a lot of data, XML isn't the right form and buries too much data in hierarchy and tag soups - but it's flexible enough to make it into whatever you want, and since XML was buzzworded and XML libs were some of the easiest things to reach for in the 90's, it got pushed into every role imaginable.

The main issue with rule of seven in an abstract field is that you can always invent more complex words and concepts, which chunk less readily:

1. Name ten types of animal

2. Now name ten programming constructs

The first will surely come more quickly than the second, and that indicates that our working memory is related to our experience: familiar ideas can be recalled and reused faster and more fluidly.

The trade is the same one when choosing between copy-pasted and abstracted code: Lots of obvious steps, versus one big black-box step which has been given some name. You need to justify the new vocabulary to start justifying the black-box.

You make an argument for empiricism, which is only one way of evaluating the truth of arguments. For example, mathematics traditionally doesn't involve empirical study: It begins with a pragmatic premise instead, like "assume the following..." and then proceeds to expand on that assumption or find its inherent contradictions.

One of the "crises of mathematics" is that computerized proofs by exhaustion, by applying brute force to find all possibilities, make the field more empirical in nature and hence subject to experimental error.

When pragmatic arguments are used to create a premise like "this design will work best for the software", the question that needs asking is whether all stakeholders can buy into the most core assumptions, and whether all assumptions retain conceptual coherence when taken together. If the UX designer, the developer, the product manager, and the end user agree on a pragmatic theory, and all theories in play align without issue, there isn't an problem as to whether it's "really" true - and with software, the concepts and data are thoroughly enmeshed in pragmatic thinking from the very beginning: numbers are modelled to limited ranges or precisions, strings are encoded according to arbitrary mappings, and so forth.

I have to agree that it's a difficult read, and I'm someone who has done a fair share of looking at these different architectures.

But the broad-strokes recommendations seem approximately like these things I would say(which are not exactly the things the author says):

* Some things are best done in an incremental fashion rather than a big "update"

* You often need to copy state in your UI code

* It helps to focus on building explicit synchronization points(which I turn to FSMs to do)

* Modelling abstract cursors on data is a helpful UI idiom

The players of the video games made by Activision-Blizzard complain every day about trivial and inconsequential aspects of the products and how they play. We don't say about them, "oh, but that is just the way the game is made, you should adapt to it." They are systems of rules akin to law enforced with computer code, designed, among other things, to demonstrate superior player skill, and one of the most common sources of player complaint is that they reward "wrong" skills that are not part of the competitive premise.

I say, if players are right to complain about rewarding the wrong skill in the games, the public is right to complain about business being rewarded for their tax evasion skills.

It's not just that the raw encoding that becomes easier to relax with higher system resources - it can also be generically compressed using those same resources. I run my Windows machines with disk compression enabled, and that tames most "bloated" files and lets me fit a lot more into a 256Gb SSD.

However, there is some appeal in defining the format to a fixed low fidelity, too, since it shapes the authoring process around conveying the content through the limitations - "the medium is the message." But they're more likely to be the source format than thr transmission format, in the same way that old video games designed for 8kB of working memory now end up with terabytes of video footage streamed to online audiences.

Yes, this kind of "naive coding technique" occasionally pops up, and I think it's a good discussion topic, because its mere existence demonstrates that you can get extremely far in terms of delivering features with a minimal amount of abstraction: "sometimes all you need is a function."

Further, that the code probably would not really be hideously miserable for a more experienced coder to refactor(it's just very duplicated) shows that copy-paste is reasonable for deferring some kinds of architectural decisions. It's not what you would bias towards if you have a whole team pounding away at the same file and rapidly evolving it, but as a solo practitioner who wants to get the feature out and put it away for the day, this style is convenient for letting the code as a whole develop some maturity and functionality before it gets refactored with abstraction.