Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The 1987 game “The Last Ninja” was 40 kilobytes

twitter.com

Post reply on HN
Print view View original

61–70 of 199 posts

Re: The 1987 game “The Last Ninja” was 40 kilobytes

#61

Post by pjc50 »

teamonkey wrote: post #58
pjc50 wrote: post #53

Earlier quoted context omitted.

I would also add internationalization. There were multi-language games back in the day, but the overhead of producing different versions for different markets was extremely high. Unicode has .. not quite trivialized this, but certainly made a lot of things possible that weren't. Much respect to people who've manage to retrofit it: there are guerilla translated versions of some Japanese-only games. > this is all befor…

The framebuffer size for a single 320x200 image with 16 colours is 32k, so nearly the same amount of memory as this entire game. 320x200 being an area of screen not much larger than a postage stamp on my 4k monitor. The technical leap from 40 years ago never fails to astound me.

The 48k Spectrum had a 1-bit "framebuffer" with colours allocated to 8x8 character tiles. Most consoles of the time were entirely tile/sprite based, so you never had a framebuffer in RAM at all.

I think it's a valid view that (a) we have way more resources and (b) sometimes they are badly used in ways that results in systems being perceptibly slower than the C64 sometimes, when measured in raw latency between user input and interaction response. Usually because of some crippling system bottleneck that everything is forced through.

Re: The 1987 game “The Last Ninja” was 40 kilobytes

#62

Post by eviks »

hnlmorg wrote: post #32
YZF wrote: post #6

I was looking at a production service we run that was using a few GBs of memory. When I add up all the actual data needed in a naive compact representation I end up with a few MBs. So much waste. That's before thinking of clever ways to compress, or de-duplicate or rearrange that data. Back in the day getting the 16KB expansion pack for my 1KB RAM ZX81 was a big deal. And I also wrote code for PIC microcontrollers th…

Sure, if you don’t count safety features like memory management, crash handling, automatic bounds checks and encryption cyphers; as anything useful. I do completely agree that there is a lot of waste in modern software. But equally there is also a lot more that has to be included in modern software that wasn’t ever a concern in the 80s. Networking stacks, safety checks, encryption stacks, etc all contribute massively…

> all contribute massively to software “bloat”.

Could you point to an example where those gigs were really "massively" due crash handling and bounds checks etc?

Re: The 1987 game “The Last Ninja” was 40 kilobytes

#64

Post by jnpnj »

YZF wrote: post #6

I was looking at a production service we run that was using a few GBs of memory. When I add up all the actual data needed in a naive compact representation I end up with a few MBs. So much waste. That's before thinking of clever ways to compress, or de-duplicate or rearrange that data. Back in the day getting the 16KB expansion pack for my 1KB RAM ZX81 was a big deal. And I also wrote code for PIC microcontrollers th…

Long ago working for a retail store chain, I made some excel DSL to encode business rules to update inventory spreadsheets. While coding I realized that their excel template had a bunch of cells with whitespace in them on row 100000. This forced excel to store the sparse matrix for 0:100000 region, adding 100s of Kb for no reason. Multiplied by 1000s of these files over their internal network. Out of curiosity I added empty cell cleaning in my DSL and I think I managed to fit the entire company excel file set on a small sd card (circa 2010).

Re: The 1987 game “The Last Ninja” was 40 kilobytes

#65

Post by hnlmorg »

bayindirh wrote: post #52
hnlmorg wrote: post #49

Earlier quoted context omitted.

> Electron is doing none of that. I agree. I even said Electron was one piece of bloat I didn’t agree with my my comment. So it wasn’t factored into the calculations I was presenting to you. > Did you watch or ran any of these demos? Some (if not all) of them scale to 4K and all of them have more than two colors. You mean the ones you added after I replied? > I didn't say they are waste. That quote is out of context.…

I did no edits after your comment has appeared. Yep, I did edits, but your reply was not visible to me while I did these. Sometimes HN delays replies and you're accusing me of things I'm not. That's not nice. > writing cool effects for the demo scene is very different to writing software for a business which has to offset developer costs against software sales and delivery deadlines. The point is not "cool effects" a…

> I did no edits after your comment has appeared. Yep, I did edits, but your reply was not visible to me while I did these.

Which isn’t the same thing as what I said.

I’m not suggesting you did it maliciously, but the fact remains they were added afterwards so it’s understandable I missed them.

> Yet, we designed some part of that thing together, and I had the pleasure of fighting with GPU drivers with them trying to understand what it's trying to do while neglecting our requests from it.

That is quite a bit different from your original comment though. This would imply you also worked on game engines and it wasn’t just your friends.

Re: The 1987 game “The Last Ninja” was 40 kilobytes

#66

Post by eviks »

bayindirh wrote: post #33
hnlmorg wrote: post #32

Earlier quoted context omitted.

Sure, if you don’t count safety features like memory management, crash handling, automatic bounds checks and encryption cyphers; as anything useful. I do completely agree that there is a lot of waste in modern software. But equally there is also a lot more that has to be included in modern software that wasn’t ever a concern in the 80s. Networking stacks, safety checks, encryption stacks, etc all contribute massively…

Yes, but this doesn't prevent you from being mindful and selecting the right tools with smaller memory footprint while providing the features you need. Go's "GC disadvantage" is turned on its head by developing "Zero Allocation" libraries which run blazingly fast with fixed memory footprints. Similarly, rolling your own high performance/efficient code where it matters can save tremendous amounts of memory where it ma…

Your third example seems to generate 2G of data at runtime, so misleadingly minimalistic

Re: The 1987 game “The Last Ninja” was 40 kilobytes

#67

Post by hnlmorg »

cyberpunk wrote: post #56
hnlmorg wrote: post #32

Earlier quoted context omitted.

Sure, if you don’t count safety features like memory management, crash handling, automatic bounds checks and encryption cyphers; as anything useful. I do completely agree that there is a lot of waste in modern software. But equally there is also a lot more that has to be included in modern software that wasn’t ever a concern in the 80s. Networking stacks, safety checks, encryption stacks, etc all contribute massively…

I implemented a system recently that is a drop in replacement for a component of ours, old used 250gb of memory, new one uses 6gb, exact same from the outside. Bad code is bad code, poor choices are poor choices — but I think it’s often times pretty fair to judge things harshly on resource usage sometimes.

Sure, but if you’re talking about 250GB of memory then you’re clearly discussing edge cases vs normal software running on an average persons computer. ;)

Re: The 1987 game “The Last Ninja” was 40 kilobytes

#68

Post by hnlmorg »

eviks wrote: post #62
hnlmorg wrote: post #32

Earlier quoted context omitted.

Sure, if you don’t count safety features like memory management, crash handling, automatic bounds checks and encryption cyphers; as anything useful. I do completely agree that there is a lot of waste in modern software. But equally there is also a lot more that has to be included in modern software that wasn’t ever a concern in the 80s. Networking stacks, safety checks, encryption stacks, etc all contribute massively…

> all contribute massively to software “bloat”. Could you point to an example where those gigs were really "massively" due crash handling and bounds checks etc?

Most software doesn’t consume multiple gigabytes of memory outside of games and web browsers.

And it should be obvious why games and web browsers do.

Re: The 1987 game “The Last Ninja” was 40 kilobytes

#69

Post by bayindirh »

eviks wrote: post #66
bayindirh wrote: post #33

Earlier quoted context omitted.

Yes, but this doesn't prevent you from being mindful and selecting the right tools with smaller memory footprint while providing the features you need. Go's "GC disadvantage" is turned on its head by developing "Zero Allocation" libraries which run blazingly fast with fixed memory footprints. Similarly, rolling your own high performance/efficient code where it matters can save tremendous amounts of memory where it ma…

Your third example seems to generate 2G of data at runtime, so misleadingly minimalistic

All of them generates tons (up to tens of gigabytes or more) of data during runtime, but they all output it, and don't store them on disk or RAM.

They are highly dynamic programs, and not very different from game engines on that regard.

> misleadingly minimalistic.

That's the magic of these programs or demoscene in general. No misleading. That's the goal.

Re: The 1987 game “The Last Ninja” was 40 kilobytes

#70

Post by shakna »

hnlmorg wrote: post #59
shakna wrote: post #50

Earlier quoted context omitted.

> Actually this systems didn’t. In the early 80s most protocols were still ASCII based. DES was standardised in '77. In use, before that. SSL was not the first time the world adopted encrypted protocols. The NSA wouldn't have weakened the standard, it was something nobody used.

DES wasn’t common place though (or at least not on the mainframes I worked on). But maybe than says more about the places I worked early on in my career? Also DES is trivial to crack because it has a short key length. Longer keys require more compute power and thus the system requirements to handle encryption increase as the hardware to decrypt becomes more powerful.

The box size at IBM was larger before standardisation. DES is trivial to break, because of NSA involvement in weakening all the corners. [0]

> In the development of the DES, NSA convinced IBM that a reduced key size was sufficient;

Minitel used DES, and other security layers, and was in use for credit cards, hospitals, and a bunch of other places. The "French web" very nearly succeeded, and did have these things in '85. It wasn't just mainframes - France gave away Minitel terminals to the average household.

[0] https://www.intelligence.senate.gov/wp-content/uploads/2024/...

Post reply on HN