Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It blows my mind how genius these game engineers were. They dealt with so many limitations and created such imaginative and brilliant solutions.


Limitations demand and produce extraordinary creativity. That's the secret behind pico8 and Animal Well and so many amazing games.

I wish I didn't think of a significantly better architecture for my 2d-pixel-art-game-maker-maker this weekend. Now it'll be another month before I can release it :(


What were the limitations for Animal Well?


- 320 x 180 screen size for starters

- Limited map size

- Limited color palette I think

- and more!


Were those imposed as artistic choices rather than due to hardware limitations etc? I just asked because it shipped on PC and the major consoles, so any limitations seem like they were by choice.


Yeah he talks about how it was a choice he made simply so he could get stuff done and have some end in sight.


Limitations, and, popularity


Popularity comes from utility. Utility comes from the right trade offs. Limitations demand careful trade offs.


The tradeoff was that the N64 was cheap and had Pokemon on it


Cheap? In its generation the Nintendo 64 was the expensive choice. Maybe not because of the console itself (price varied across its lifetime relative to the competition) but because of the cost of the games (and nearly complete lack of piracy).

As for Pokémon, the Nintendo 64 launched in June 1996 and the first Pokémon game was Pokémon Snap released nearly three years after the console in March 1999.


The N64 is older than Pokemon.


Not true, the N64 was released a couple of months after the first Game Boy games.


Pokémon in Japan came much earlier. Also, the PSX was the cheap choice, among the rampant CD piracy vs the very expensive N64 cartridges.


This is new stuff, not stuff done during the reign of the N64.


Only recently did we figure out how to make Mario64 run at 30fps.

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


Around the end of the PS2’s lifetime, some engine dev friends of mine figure out to do palletized spherical harmonic lighting on the PS2. That was pretty straightforward.

What was tricky was a separate technique to get real cubemaps working on the PS2.

Unfortunately, these came too late to actually ship in any PS2 games. The SH trick might have been used in the GameCube game “The Conduit”. Same team.


I always thought triace had shipped sh lighting on ps2 but maybe it was just a demo?

http://research.tri-ace.com/Data/Practical%20Implementation%...


They were doing per-vertex SH. That was a much more practical approach :)


> What was tricky was a separate technique to get real cubemaps working on the PS2.

Any details on that?


If you lay out a cubemap as a 2d texture that looks literally like https://www.turais.de/content/images/size/w1000/2021/05/Stan... it's not hard, given the VU1-based triangle processing (like proto-mesh-shaders 25 years ago), to set the UVs of triangles independently to use the correct square even in the case of dynamic reflections. This doesn't do per-pixel spherical UV normalization. But, with a dense enough mesh, a linear approximation looks good enough.

Except... The triangle UVs will often cross over between multiple squares. With the above texture, it will cross over into the white area and make the white visible on the mesh. So, you fill the white area with a duplicate of the texels from the square that is adjacent on the cube. That won't work for huge triangles that span more than 1.5 squares. But, it's good enough given an appropriate mesh.

Probably would have been better to just use a lat-long projection texture like https://www.turais.de/content/images/size/w1600/2021/05/spru... Or, maybe store the cubemap as independent squares and subdivide any triangles that cross square boundaries.


Interesting, thanks!


I'm sure they were but, as noted, this specifically is 2025 stuff, and demoscene, not gamedev.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: