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

171–180 of 199 posts

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

#171

Post by OkayPhysicist »

miki123211 wrote: post #166
eleveriven wrote: post #134

Earlier quoted context omitted.

I think you're right about the waste, but I'm not sure it's entirely "accidental"... a lot of it is traded for different kinds of efficiency

At some point, you just stop measuring the thing until the thing becomes a problem again. That lets you work a lot faster and make far more software for far less money. It's the "fast fashion" of software. In the middle ages, a shirt used to cost about what a car does now, and was just as precious. Now, most people can just throw away clothes they no longer like.

Shirts used to be expensive, but "nice clothes" expensive in today's money, not "1st/2nd most expensive thing most people own" type expensive. $200-$1000 in today's money, scaling to wages.

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

#172

Post by jasomill »

hnlmorg wrote: post #141
bayindirh wrote: post #139

Earlier quoted context omitted.

All demos I have shared with you are designed to run on resource constrained systems. Using all the resources available on the system is a big no no from the start. Instead, as you guessed, these demos generate assets on the fly and stream to the respective devices. You cite inefficiencies. I tell they run at more than 60 FPS on these constrained systems. Remember, these are early 2000s systems. They are not that pow…

> You cite inefficiencies. That’s not what I said. I said you’re trading memory footprint for CPU footprint. This is the correct way to design a demo but absolutely the wrong way to design a desktop application. They are marvels, I agree. But, and as I said before, there’s no such things as a free lunch. at risk of stating the obvious; If there wasn’t a trade off to be made then all software would be written that way…

You’re not entirely right or wrong.

Memory access is frequently a bottleneck on modern CPUs, so reducing memory footprint can often be a time and space optimization.

More importantly, unlike demos, production code is often optimized for interrelated factors of development cost, maintainability, and the use of familiar or popular tools and techniques over runtime efficiency.

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

#174

Post by msephton »

My game YOYOZO is 39 KB and was listed as one of the "Best Games of 2023" alongside Mario & Zelda & Baldur's Gate 3. So it's still possible to do this sort of thing if you care enough and have the right constraints! If you don't have those constraints, simply impose some on yourself. https://news.ycombinator.com/item?id=38372936

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

#175

Post by msephton »

boptom wrote: post #34
socalgal2 wrote: post #26

Most games back then where small. An C64 only had 64k and most game didn't use all of it. An Atari 800 had max 48k. It wasn't until the 1200 that it went up. Both systems are cartridge based games, many of which were 8k. Honestly though, I don't read much into the sizes. Sure they were small games and had lots of game play for some defintion of game play. I enjoyed them immensely. But it's hard to go back to just a f…

The modern classic, Animal Well, is only 35mb in size! https://store.steampowered.com/app/813230/ANIMAL_WELL/

That's multiple factors larger than my game YOYOZO which is only 39 KB

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

#176

Post by kazinator »

It's not just that programs had small images. The noteworthy thing is that they weren't small due to externalizing their dependencies. They relied on no third party code other than a few meagre services of the operating system. They did their own sound and graphics down to the pixel level.

We can't compare 40 KB image today to a 40 KB image from 1980 something, if the contemporary one relies on 100 MB of external cruft, like a rich programming language runtime (fetched and install separately) and packages.

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

#177

Post by hcs »

makapuf wrote: post #113
hcs wrote: post #24

Earlier quoted context omitted.

Chris Crawford called this "process intensity", he noted it at least back to 1983 with Dragon's Lair, discussed in this 1987 article https://www.erasmatazz.com/library/the-journal-of-computer/j...

Funny because I rewrote a bad port of dragons lair for a custom console with a tiny engine and huge dataset relatively, each frame having one "if press X goto frame Y" instruction.

I phrased that badly, Dragon's Lair was the example of low process intensity.

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

#178

Post by zahlman »

1970-01-01 wrote: post #115
y-curious wrote: post #112

Earlier quoted context omitted.

The LLM-use witch hunt accusations are rampant on every single article. That snippet doesn’t sound like an LLM to me. Have your coffee and consider that this person was just complimenting coders from back in the day.

[flagged]

The text you quoted is not an example of the trope you highlighted. It genuinely comes across like you're calling it LLM generated purely because of the "em-dash", except it isn't even an em-dash.

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

#179

Post by pjmlp »

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…

We had safer programming languages fitting into 640 KB with MS-DOS, which is why I keep repeating youngsters don't get how much they can do with an ESP32.

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

#180

Post by pjmlp »

hnlmorg wrote: post #55
anthk wrote: post #43

Earlier quoted context omitted.

Back the day people had BASIC and some machines had Forth and it was like print "Hello world" or ." Hello world " / .( Hello world ) for Forth. By comparison, giving how they optimized the games for 8 and 16 bit machines I should have been able to compile Cataclysm DDA:BN under my potato netbook and yet it needs GIGABYTES of RAM to compile, it crazy that you need damn swap for something it required far less RAM 15 ye…

BASIC was slow in the 80s. Games for the C64 (and similar machines) were written in machine code. > By comparison, giving how they optimized the games for 8 and 16 bit machines I should have been able to compile Cataclysm DDA:BN under my potato netbook and yet it needs GIGABYTES of RAM to compile, it crazy that you need damn swap for something it required far less RAM 15 years ago for the same features. That’s not cr…

Some BASIC was slow, Darthmouth BASIC was compiled to machine code before execution, and to make it fit as the machine shell on 8 bit computers, the only option available on ROM was an interpreter.

Machines using CP/M had BASIC compilers available, and professional devs had the option to buy BASIC compilers for 8 and 16 bit home computers, when the 16 bit home computers came to be, BASIC compilers became common again.

It was only during the glory 8 bit days, with most users being students with limited budgets, and the pain of switching tapes all the time, that made using BASIC compilers a no go option for most, thus we ended up using DATA blocks for Assembly code within our budget, or if lucky to get a hexdump monitor or proper Assembler, use those instead.

Post reply on HN