I wholeheartedly agree with you that TIC-80 is not as great as PICO-8 is, and I would never recommend it over PICO-8 to someone who wants to start their adventure with game development.
But it is not a clone of PICO-8. It offers a resolution that's very similar to that of the Game Boy Advance, so it serves as a nice transition stage towards GBA development. You can then enjoy your games on a console like Anbernic RG351P that's optimized for GBA games (2x integer scaling, same screen ratio). It's a specific use case, but one where TIC-80 shines.
Yep. I bought a yellow one with the intention of making it a dedicated PICO-8 machine, and it is wonderful. It's not as perfect as 351p is for GBA, as 5x integer scaling leaves you with some unused screen space, but still, an absolute joy to play.
That's just a single data point, but here's my experience. I have severe myopia, and I experience discomfort when reading from a screen over a prolonged period of time. I read a lot, and I can't read for more than two hours even on a quality LCD screen. With e-paper, three hours of continuous reading are not an issue. If my reading habits were as simple as reading for an hour before bedtime, I don't think I would need anything more than a tablet.
You pay for the console, and the games are open by design. You can load any pico game into the console, go into edit mode, and see / edit assets, music, levels. The console only supports lua, which gives you the advantage that every game you open to see the source code will be written in the same language. A wonderful little thing. I used it to introduce kids to game development with good results.
To add to this - each game is stored self contained into a png image file [0], where the assets and code take up predictable sections. Each image is the entire game.
It's pretty easy to build your own tools to generate the format, if you were inclined to build an IDE or something along those lines.
The data is hidden in the image data itself, it seems(!) Does this mean that an accurate screenshot can be used to clone the cartridge? For fun, of course.
Unfortunately, no, I don't think that's possible. There's a few null bytes used here and there, like marking the Lua offset, and your screenshot can't capture those, no matter how accurate the rendering of the actual bytes is.
You're assuming someone places value on proper documentation because they need proper documentation to make it "accessible to you". That doesn't have to be the case.
For me, lack of proper documentation constitutes a red flag, and says something very negative about the project. The question "Is it properly documented?" serves as a simple and convenient way to filter out projects that have a low chance of being mature enough to fit my needs.
> my point is there are dozens of other convenient questions you can ask to filter out projects
Absolutely. And I agree with you that "Is it widely used in production?" is a better filter. But that does not diminish the value of the filtering done by "Is it properly documented?". After all, it's not like we're limited in the number of criteria we can use to filter out bad projects.
> My problem is, I know that we are missing information, what I don't know is how to tease out that information from myself and other coworkers.
I would start by reflecting on the way in which getting that knowledge out of the coworkers into the knowledge base is incentivized.
I keep my notes in markdown files. A lot of my coworkers use Obsidian, CherryNotes, OneNote, and I'm sure that there's a dozen other solutions out there. Keeping notes locally is actively encouraged by the fact you can't rely on the Confluence server to be up after business hours and the fact that the centralized knowledge base upgrades destroyed our documentation efforts twice over the past 10 years.
I also keep my notes short, omitting everything that's obvious to me. This makes them less valuable when it comes to knowledge sharing, but makes them better for me - short notes mean less visual noise to filter out. Writing a version of those notes that's more comprehensive is extra effort. That extra effort needs to be visible, treated as 'real work', encouraged and valued. Otherwise, I will prioritize other tasks that are visible, treated as 'real work', encouraged and valued.
The first thing I would worry about is making sure the central knowledge repository is as convenient as the local notes. Then, I would examine if creating / updating documentation in the central repository is encouraged, and in what way.
Not to dismiss his achievement, but, why do people always think programming in assembly is ultra hard? This was just how we wrote games back in the day. I still know people using Assembly for a wide range of development, it's not particularly harder than any other programming. A bit tedious, yes, but with FASM and Fresh it's a lot better.
Noclip did a documentary[1] on RCT and successor games, and tried to interview Chris. The response passed through his representative is stated in the 2nd to last segment (The Legacy of RCT at 30m55) in the video.
I can provide answers to the last two questions, based on my limited experence.
> What are "local HR laws"?
I think this refers to the fact that regulatory compliance is different depending on where your business is located. Which brings me to my anecdotal experience with:
> What do you mean by "scaring employers re: regulatory compliance"? "Scaring" reads like you're implying some kind of manipulation, but "regulatory compliance" is something a company should already be in; what is there to fear?
A company I worked for was located in a country where it was the legal duty of the employer to keep track of the people on the office premises. Most companies used a time tracking system for this, the punch-in, punch-out kind. The thing is, the purpose of the regulation was to make sure that when evacuated, there is always a list of people that were in the building - so it could be referred to after the evacuation to see if everyone is accounted for. This law did not require keeping track of the time someone entered the premises, or the time someone left - the requirement could be satisfied with a simple paper list with checkboxes - one for when you enter, one for when you leave. And that's exactly what was done in this office. Every month or two, the company got an offer from a business trying to sell a time tracking appliance or service, and many, if not all of those offers were using manipulatory tactics - "If you're not using a time tracking system, you might be violating the law" was a common phrase. The manipulation here was that it was true that a system like that would satisfy the legal requirement, but the offers strongly implied that a having a system like that was necessary to satisfy the legal requirement. Which was not the case.
> "If you're not using a time tracking system, you might be violating the law" was a common phrase.
This seems a reasonable thing to say. If anything it's helpful by perhaps providing the employer with information about requirements they were ignorant of.
> but the offers strongly implied that a having a system like that was necessary to satisfy the legal requirement. Which was not the case.
But coupling it with this is a sleazy sales tactic.
One can nullify the affect though by having at least one person on your staff tasked with being knowledgeable of all of your industry's employment requirements and your company's current state of compliance with them.
> That's not typical Java code. You could do that in quick & dirty code, but I haven't seen such code in production code.
It sounds to me like you're an extremely lucky person. I've seen too much of that sort of thing in production code, including a catch-all for Throwable at the top that didn't even dump a stacktrace.
Here's where having a teacher helps a lot. I started out as an adult beginner, and I remember that in one of the first study books (Duvernoy or Burgmuller), there was a passage in the left hand with a sequence of six eights, it went like C-F-Bb-F-A-F. Because of the slow tempo, I could have easily done it 5-1-5-1-5-1, where my thumb would just repeat the F, and my pinky would go down the C-Bb-A sequence. This is where my teacher stepped in - he told me that this is a great learning opportunity, and I should play it 5-1-4-1-5-1, fifth finger on the C, fourth over it to the Bb, fifth to the A. The main reason was that this would be more comfortable at higher speeds, but also that it would allow to do a finger legato on the sequence of three notes.
A lot of the fingering remarks at this stage were about legato. In the easy Beethoven Sonatina in G, you have sort of a reversal of my earlier story - the downward movement is in the top notes here. There's a sequence of two chords, D-A and D-G in bar three. You could easily do both of those 51-51, but then the possibility of joining the two upper notes would be lost. The "correct" fingering would be 51-52, lifting the pinky and doing a nice legato on the top notes, one that follows into bar 4 with 53. It makes a world of difference when you hear how it sounds with a proper chord legato applied.
If you don't have a teacher, the next best thing would be to make sure you have a good edition with the proper fingerings added. Something like Alfred Masterwork, or the newer Schirmer Performance - both are relatively inexpensive and nicely edited. But then you will get just the fingering without the reasoning behind it.
Thank you very much for such detailed description and recommendation. I think "legato" reasoning is a good example for how reasoning works in general and so one can guess what correct fingering would be when there is no teacher around.
> and so one can guess what correct fingering would be when there is no teacher around
At least in some cases, yes. For me, that's the real point of having a teacher - learning the thought process, not the pieces.
One thing worth mentioning is that sometimes the correct fingering for a piece is contextualized. There are pieces that you might treat as a goal in their own right, but they might also be just a stepping stone to other pieces. For example, you might see a sequence of three notes in the left hand, and there will be a "correct" fingering that's most comfortable for just those three notes. But the teacher that suggested this piece knows that those three notes can be seen as a simplified version of a six note pattern that occurs throughout a more difficult piece you will tackle later. So the "correct" fingering they suggest to you is the fingering that's most comfortable for the more difficult version you haven't played yet. You're not looking at the piece as-is, you're thinking of it in the context of what you'll eventually play and optimizing the fingering for performance of the target piece.
You will often hear that "correct" fingering is the one most comfortable. This is only partially true when you're in the early stages. Often, you go for something that's suboptimal in a particular piece because it will be more comfortable in another piece down the road.
But it is not a clone of PICO-8. It offers a resolution that's very similar to that of the Game Boy Advance, so it serves as a nice transition stage towards GBA development. You can then enjoy your games on a console like Anbernic RG351P that's optimized for GBA games (2x integer scaling, same screen ratio). It's a specific use case, but one where TIC-80 shines.