davidst

Never say never but I think it's unlikely. Our motivation was to restore pinball to Windows (with modern updates) so every Windows user could enjoy it. Any other form of distribution wouldn't have the same coverage or impact. It would have been great to not only please the fans of the old game but to introduce a new generation to pinball just as Space Cadet once did.

I'd be bold to ask why would you even need their blessing to release an updated or new version

My Cinematronics co-founders and I do not own the rights to any of the games we created. Cinematronics was acquired by Maxis, and Maxis was later acquired by Electronic Arts (who are being acquired, as well.) The rights would have to be untangled which was, I suspect, part of the hesitation Microsoft had in moving forward.

Would you ever consider going back to the drawing board in an attempt to produce an official follow-up to Space Cadet Pinball?

We reached out to Microsoft a few years ago and offered to create a new version at no charge if they would restore it to Windows but they turned us down. There appeared to be no interest on their part.

Someone with the user name "Hemiauchenia" edited the Wikipedia page shortly after I left my comment here.

Source: https://en.wikipedia.org/w/index.php?title=Full_Tilt!_Pinbal...

I looked at it today and it is more fleshed out but still incorrect. For example:

In 1994, the company began development of a port of Doom.

No, we were never porting Doom and we used none of Doom's code or resources. And I didn't propose to tone down the violence. The game was intended to be a fun first-person shooter in the same spirit as Doom but that was the only connection.

Microsoft was involved in a high-profile antitrust suit with the Department of Justice at the time. They were understandably sensitive about the potential PR impact of this type of game shipping with Windows and proposed gameplay design changes to reduce the violence.

I was CEO of Cinematronics (to be clear, we were a tiny startup so a CEO title didn't mean much - everyone pitched in wherever they could help.)

I negotiated the contract with Microsoft. My engineering contribution was not in the gameplay itself but in the game's memory manager and low-level rendering code. That was all performance-critical X86 assembly. I doubt any of that code lives on today.

Yes, there were a lot of anecdotes and the story on Wikipedia is both incomplete and incorrect in some ways. One day, I'll get around to editing it.

My memory is of promising it would be ready in time for Windows 95's launch, working excessively long hours, and focussing hard to make it fast enough so it would be fun to play on the minimum hardware requirement for Microsoft Plus.

I am one of the original authors of Space Cadet Pinball and I just want to say it is absolutely wonderful there are people who love our old pinball game enough to keep it alive. You made my day.

I am forwarding this post to my Cinematronics co-founders and friends, Mike Sandige (lead engineer) and Kevin Gliner (designer and product manager). They will enjoy seeing this as much as I did.

"We've uploaded a fruit fly. We took the @FlyWireNews connectome of the fruit fly brain, applied a simple neuron model (@Philip_Shiu Nature 2024) and used it to control a MuJoCo physics-simulated body, closing the loop from neural activation to action."

Additional description here: https://x.com/michaelandregg/status/2030764512488677736

I have been making this mistake for decades. I am upvoting your comment to show thanks!

Scaling from a small-format store with limited item selection (where the tech worked well) to a large grocery format would come with many challenges. A previous comment touches on a couple of them:

https://news.ycombinator.com/item?id=46793253

I don't know how the store clerk staffing changed over time but they were not directly involved with the underlying tech (that is, clerks did not annotate data.) Stores had to comply with state laws for certain kinds of items (e.g., a live person must verify ID and age for alcohol) so the store automation had the ability to summon a clerk when needed. And there were the usual things all stores must do: restocking, cleaning, safety, and customer relations. I expected customer relations to decrease over time as people became accustomed to the just-walk-out shopping experience.

It wasn't real-time. Recorded events were entered into a queue and latency would vary depending on the size of the queue and the number of annotators.

The first iteration of the tech reached the accuracy needed to support just-walk-out for a small-format store. It did achieve that goal. I left the project before it went further.

I imagined, at the time, future goals would be to scale store size and product variety while reducing the cost of the technology, but I have no insight into how that progressed. I am sorry to learn it's been shut down.

I don't have insight into what ultimately transpired at Amazon Go so take the following as speculation on my part.

It is unlikely the tech would be frozen when an acceptable accuracy threshold is reached:

1. There is a strong incentive to reduce operational costs by simplifying the hardware infrastructure and improving the underlying vision tech to maintain acceptable accuracy. You can save money if you can reduce the number and quality of cameras, eliminate additional signal assistance from other inputs (e.g., shelves with load cells), and generally simplify overall system complexity.

2. There is business pressure to add product types and fixtures which almost always result in new customer behaviors. I mentioned coffee in my prior post. Consider what it would mean to add support for open-top produce bins and the challenge of complex customer rummaging. It would take a lot of high-quality annotated data and probably some entirely new algorithms, as well.

Both of those require maintaining a well-staffed annotation team working continuously for an extended time. And those were just the first two things that come to mind. There are likely more reasons that aren't immediately apparent.

I left the following comment some months ago, duplicating it here:

[Disclaimer: Former Amazon employee and not involved with Go since 2016.]

I worked on the first iteration of Amazon Go in 2015/16 and can provide some context on the human oversight aspects.

The system incorporated human review in two primary capacities:

1. Low-confidence event resolution: A subset of customer interactions resulted in low-confidence classifications that were routed to human reviewers for verification. These events typically involved edge cases that were challenging for the automated systems to resolve definitively. The proportion of these events was expected to decrease over time as the models improved. This was my experience during my time with Go.

2. Training data generation: Human annotators played a significant role in labeling interactions for model training-- particularly when introducing new store fixtures or customer behaviors. For instance, when new equipment like coffee machines were added, the system would initially flag all related interactions for human annotation to build training datasets for those specific use cases. Of course, that results in a surge of humans needed for annotation while the data is collected.

Scaling from smaller grab-and-go formats to larger retail environments (Fresh, Whole Foods) would require expanded annotation efforts due to the increased complexity and variety of customer interactions in those settings.

This approach represents a fairly standard machine learning deployment pattern where human oversight serves both quality assurance and continuous improvement.

The news story is entertaining but it implies there was no working tech behind Amazon Go which just isn't true.

It's a wonderful problem for optimizing code. Michael Abrash hosted a performance contest for word counting back in... 1991? (If my memory serves.) The article and code can be found here:

There Ain’t No Such Thing as the Fastest Code: Lessons Learned in the Pursuit of the Ultimate Word Counter

Article: https://www.phatcode.net/res/224/files/html/ch16/16-01.html

Code: https://www.phatcode.net/res/224/files/html/ch16/16-05.html

[Disclaimer: Former Amazon employee and not involved with Go since 2016.]

I worked on the first iteration of Amazon Go in 2015/16 and can provide some context on the human oversight aspects.

The system incorporated human review in two primary capacities:

1. Low-confidence event resolution: A subset of customer interactions resulted in low-confidence classifications that were routed to human reviewers for verification. These events typically involved edge cases that were challenging for the automated systems to resolve definitively. The proportion of these events was expected to decrease over time as the models improved. This was my experience during my time with Go.

2. Training data generation: Human annotators played a significant role in labeling interactions for model training-- particularly when introducing new store fixtures or customer behaviors. For instance, when new equipment like coffee machines were added, the system would initially flag all related interactions for human annotation to build training datasets for those specific use cases. Of course, that results in a surge of humans needed for annotation while the data is collected.

Scaling from smaller grab-and-go formats to larger retail environments (Fresh, Whole Foods) would require expanded annotation efforts due to the increased complexity and variety of customer interactions in those settings.

This approach represents a fairly standard machine learning deployment pattern where human oversight serves both quality assurance and continuous improvement.

The news story is entertaining but it implies there was no working tech behind Amazon Go which just isn't true.

I wrote Qlife, a game of life "compiler" that generated X86 asm code, for one of Michael Abrash's optimization challenges in the early 90s.

Description: https://www.phatcode.net/res/224/files/html/ch18/18-01.html

Code: https://www.phatcode.net/res/224/files/html/ch18/18-03.html

Hashlife is far superior so while Qlife was interesting it wasn't the best implementation.

I don't think you're missing anything. Years ago, I made the same observation, and ran a test to compare independent hash functions vs salting. It showed no difference. I would be interested if someone here has a different opinion and a rationale to explain what I might have missed.

This memory goes back almost thirty years. In 1993, most products still shipped on floppy disks, and costs were increasing as products grew in size. Shrinking a popular product by even one disk could save over a million dollars. Publishers were using data compression but the tools were of the same class that were intended for regular users. That is, compression and decompression required roughly similar compute resources. I noted a few things:

1. Software products would be compressed just once but decompressed millions of times.

2. It should be possible to create an asymmetric codec that expended tremendous resources on compression but still kept decompression light.

3. Publishers didn't care how much compute compression would require as long as it was still tractable and would save them money. If they had to buy an expensive computer and let it run overnight it would be fine.

I didn't know anything about compression at the time but the premise seemed strong. I took unpaid time off to tackle this problem and in a few months (after a lot of trial-and-error learning) I began to have a workable product.

Borland, Novell, and Microsoft (for the .CAB files) were the first licensees. The compressor was called Quantum and was typically 20-30% better than PkZip. My sales technique was to take a product, recompress it with Quantum, and show the company how much money they could save. (As I recall, I was able to demonstrate reducing Windows for Workgroups by two disks.)

I was responsible for the Turbo C (later Borland C/C++) run-time library in the late 80s and early 90s.

Tanj Bennett created our original 8087 floating point emulator. It was real mode, 16-bit code, that kept an 80-bit float in five 16-bit CPU registers as a working value during its internal math calculations. If you ever coded for the PC you will appreciate just how precious register space was on the 8086/8088.

It's been a few decades and my memory is fuzzy but I don't recall any critical places where the registers had to be saved and restored. He choose math algorithms and code paths specifically to keep all five live at all times. Tanj's code flowed with an economy of motion that brought to mind the artistic performance of a professional dance troupe. I did not have the math skill and could not have ever created it as he had. It brought me genuine pleasure just to read his code.

Eventually, it came time to port it to 32-bits (real and protected modes.) I wrote new exception handlers and replaced the instruction-decode logic with a nice table-driven scheme but did not touch the core math library. It still ran in 16-bits under the hood exactly as Tanj designed it.

Tanj, if you happen to see this, I have fond memories of your emulator. It was beautiful.

You are right! This is why I appreciate HN so much. I don't see how to edit my comment but thank you for the correction.

This is a great interview question I don't want to be 'that guy' by picking at what may be a detail but there is another response to look for from a candidate.

We should think very carefully about adding a multiplication command because it introduces a failure mode that may be unanticipated by the client. Code that previously worked could begin to fail after this command goes into use.

Specifically, if the client needs to revert a series of operations on integers, and if the operations are transitive, there is no need for a mechanism to ensure they occur in any particular order (the usual caveat about working within the limits of precision applies.) This holds true for addition and for multiplication, in isolation, but is not true if they are combined. Change the order and the end result will change. Adding multiplication puts a burden on the client to understand this risk and be explicit in the ordering.

Some people may argue that the client should already understand it and they have a point. We can't defend against every possible misunderstanding. I think there is a good discussion to be had on this question and if the candidate were to go there, it would be a favorable sign of experience on their part.

David Stafford here. Microsoft has the rights to publish it with Windows. My former Cinematronics co-founders (Mike Sandige, Kevin Gliner) and I would be happy to help it return, gratis.

The rights belong to Electronic Arts today. They acquired Maxis who had acquired us (Cinematronics.) Microsoft may still have rights to continue publishing a version with the Windows operating system.

Microsoft, if you're reading this, we would be glad to provide assistance in getting 3D Pinball running again on the latest Windows OS.

Thanks!

There were a couple of interviews with gaming magazines years ago. They would be hard to find today and didn't cover the topics you mentioned. Mike, Kevin, and I, really need to get together to tell the story some day.

I am one of the original authors of Space Cadet pinball (along with Mike Sandige, lead programmer, and Kevin Gliner, producer and designer.) It is surprising and gratifying to see interest is still alive for our old game. And I can't help but be impressed by the ingenuity shown by both the decompiling effort and the playable web-based game.

I remember this, Dave. I was confident I had the fastest possible algorithm and you proved me wrong. It was a humbling experience but it forced me to throw out my assumptions and start over. It taught me to assume there was always a faster or better way just waiting to be discovered. TANSTATFC

You should post your code when you get a chance.

The article makes a good point but I wonder if it is an incomplete explanation. What would happen if Linus Torvalds walked away and there was no single leader to guide (or "dictate", depending on your point of view) its development? Would it begin to fragment and exhibit signs of Conway's Law?

I believe the answer is, yes, it would. While Linus is a stubborn and opinionated leader ("Benevolent Dictator For Life") it is those qualities, coupled with his extremely high standards, that have preserved the coherence of Linux's system architecture all this time.

You just brought back old memories for me. I wrote the heap manager for Borland C. I chose the next-fit algorithm for its balance of speed and reasonable fragmentation under common use cases. Best-fit performs exactly as you described.