That said, gaming laptops cooling issues are so often around the GPU so it'd also require a seasoned manufacturer to make it correctly.

Biggest difference perhaps where 68000 is more complicated is postincrement but considering all the cruft 32bit X86 already inherited from 8086 compared to the "clean" 32bit variations of 68000 I'd make it a toss at best but leaning to 68000 being easier (stuff like IP relative addressing also exists on the RISC-y ARM arch).

Apart from addressing the sheer number of weird x86 instructions and prefixes has always been the bane of lowpower x86.

Remember, Intel also barked up the wrong tree with Itanium for 64bit and didn't really let go until AMD forced their hand with x64.

1: https://forum.amiga.org/index.php?topic=51616.msg544232#msg5...

Had the Amiga retained relevance for longer and without a push for PowerPC I don't see a reason why 68k wouldn't have been extended. Heck the FPGA Apollo 68080 would've matched end of 1990s P-II's and FPGA's aren't speed monsters to begin with.

If it's a sin or feature can of course be debated but I remember playing games on an Amiga in the early 90s and until Doom the graphics capabilities didn't look outdated.

By 1992 with AGA however I agree, flicker and planar graphics(with 8 bitplanes any total memory bandwidth gains were gone) was a downside/sin that should've been fixed to stay relevant.

The Aga chipset of the 1200/4000 stupidly only added 2 more bitplanes. The CD32 chip actually had byte-per-pixel (chunky) graphics modes but the omission from the 1200 was fatal.

Reading in hindsight there was probably too many structural issues for Commodore to remain competitive anyhow, but an alt-history where they would've seen the needs for 3d rendering is tantalizing.

1: https://news.ycombinator.com/item?id=47717334

Flat framebuffers and "powerful" CPU's also enabled easier software rendering (Doom/Duke) of 3d, compared to the Amiga where writing textured rendering for an Amiga is a PITA due to video memory layout with separted bitplanes spreading bits of each pixel into different memory locations (the total memory bandwidth reduction in 1985 by using 5 or 6 bitplanes became a fatal bottleneck at this point).

It wasn't really always full framerate though and the 2d chipsets did help in "classic" actiongames that were still much in the rage.

The Pentium further widened the gap, but at the same time consoles gained hardware 3d acceleration (PSX/Saturn/Jaguar) yet the Pentium could do graphics better in some respects (As shown with Quake).

Once 3d accelerators landed, PC's has more or less constantly been ahead apart from when it comes to price (and comfort/ease).

The motivation was partially to solve processing on PS3's, the 7 usable Cell units have small memories of 256kb each so processing had to be moved to a compact/streamable memory format but developers were also concurrently fighting larger cache latencies caused by Entity Component hierarchies that had arisen as a solution to problems with inheritance using dislocated object hierarchies (ie separated linked objects).

Out of this grew the Data Oriented Design paradigm (that's intrinsically built on mechanical sympathy) that suited both Cell like streaming as well as minimizing cache effects for main-memory code where Entity Component Systems were reorganized to use cache efficient array processing instead of linked objects.

https://gamesfromwithin.com/data-oriented-design

Was the outside world oblivious? I'd say so to a large part, CPU's had gotten faster, more cores and memory latencies were masked to a certain degree for other kinds of code!

The Java people even pushed out their biggest mistake just as these effects started to become visible, the erased objects for generics that kind of locked in a design that requires generic list types to have disaggregated storage due to separate objects. In hindsight, this is IMHO the single biggest benefit that C# got over Java as their paths diverged as generic struct List<> object's have radically more efficent storage in C# compared to a Java ArrayList<>.

Afaik Project Valhalla still hasn't become mainstream even after almost _12_ years at this point, had they gone with proper generics at day one it would've been a trivial compiler upgrade.

8bit like Nes (Nesjam late may/june), Gameboy(GBJam was last year, bi-annual), Atari,etc, but also for MSDOS, Amiga and more "mid-school" platforms together with semimodern like PS1.

Now, even with modern tools it's plenty of work to get impressive things working on older platforms (I had a Gameboy techdemo last time there was a compo that's due to grow ridiculously much).

Funniest thing perhaps is that Smash was a musician back then for 2 things where I did the code (one musicdisc and one joke intro), Smash then went on to become a damn accomplished coder of quite a few famous Fairlight demos, Sony tools and made the commercial Notch visual toolset/editor/player that has roots in the Fairlight demoeditor codebase (Notch startup logo often pops up in democompos for those that haven't followed the scene).

Razor, Fairlight and some others became more of continious groups with evolving memberships (I was briefly a member of the demoteam back in 1999 and did one production in association with the people that moved over to Fairlight).

But I did notice some 64k's and small synths-executables had singing this year, I've added small voice-samples (compressed) but that's just seconds whilst these entries had longer sequences so I'm a tad curious as well.

It's sad since these kinds of numbers are interesting, but when there's blatant misrepresentations it just create a stink.