Hacker News Reader

Comment by bhouston | Hacker News Reader

The demo scene was so formative. Like many others of a certain age in the 3D industry, I was first a demo scene coder, because what else was one to do if you were good at math and computer science but still stuck in high school?

My 1997-era renderer did reflections, bump, color textures, etc all in 16 bit using x86 assembler rasterizers, no floating point, with 256 color palette - source can be found from this link: https://twitter.com/benhouston3d/status/1260346800176877571

Another demo from the same era (1996), also includes source: https://twitter.com/benhouston3d/status/1272530352070971397

Nearly 30 years later I am still doing 3D graphics, contributing to Threejs (which is run by mrdoob, another demo scene coder), glTF, VFX software, https://web3dsurvey.com and have run a computer-graphics company for the last ~20 years: https://threekit.com

View on HN

Agreed! I had so much fun as a teen-ager doing this!

I implemented real-time Phong rendering on 486SX (no FPU) with a chrome-like effect (see https://github.com/thbar/demomaking#obez-1995) and this still gives me chills.

I met great people back then, and had a ton of fun.

My only regret is that source code is lost, and decompiling properly is not easy!

The only reason I'm a software engineer today, is the scene. And I'm sure that's not just the both of us :)

It clearly had a huge impact on me too!

I was doing the same as you. Gouraud shading, texture-mapping, phong-shading.

I looked at your code and saw only .cpp files. I had to open your triangle renderer, and there it was - you'd inlined your x86. I don't think I ever inlined my assembler, even though I was using Borland C++ like you. I think I must have linked it in somehow?

> I was doing the same as you. Gouraud shading, texture-mapping, phong-shading.

Is your old code posted anywhere? I think many of us were working from the same example projects/tutorials. I wouldn't be surprised if the code is incredibly similar.

> I had to open your triangle renderer, and there it was - you'd inlined your x86.

Being able to inline asm was amazing. The code:

https://github.com/bhouston/3DMaskDemo1997/blob/master/src/N...

Being able to access C++ variables on the stack directly from assembler to read and to write to them was so nice. You get the speed benefits without adding significant complexity.

I think all of my code is lost now. My artist friend says he has a hard drive which might have the binaries on it.

I did find one of my commercial releases on the Internet the other day because it was on a magazine cover disk in 1994 which saved it from obscurity :)

I mixed TurboPascal (or C++) with Assembly for critical loops, and it changed everything :-) (high level for overall scripting, low level for rendering triangle loops).

I would love to be able to properly decompile my old demos, but it would require a bit of work.

For phong rendering, I remember I interpolated the full vector along each line (with an "integer" square root table stored in memory, taking 512k or something), it was fun times :-)

As someone born a bit after these demos, any tips for how to make this sort of thing? My C/C++/ASM skills are pitiful but I'd love to sharpen them, and this seems like a perfect way to do so

Is the 3D industry a good one to get into ? Or is it too full of crunch and low pays ?

It was horrible to work for a VFX firm in terms of work-life balance, but the pay was okay. I quit after 3 years. One crunch time lasted 27 days in a row many of which many were 10hrs per day. And then I didn't even get credit on the final film even though what I did was critical for it.

When I started my own firm in 2005 I adopted a no-overtime policy in reaction to that. This was more feasible since I was creating and delivering software and this was more predictable and containable than doing VFX itself. This has loosened a bit as the company grew, we got funding, then got other divisions, etc.

10 hours per day! You worked at one of the nicer places then. Next you'll be telling me they gave you more than one toilet break a day and even let you out from time-to-time to find food.

I couldn't take the hours, honestly. The place I worked I was ended up sleeping under the desk and doing 20hr days to make crunches.

> 10 hours per day! You worked at one of the nicer places then. Next you'll be telling me they gave you more than one toilet break a day and even let you out from time-to-time to find food. > I couldn't take the hours, honestly. The place I worked I was ended up sleeping under the desk and doing 20hr days to make crunches.

I think all of this is also completely unnecessary. Work-life balance is necessary if you want to have a family and enjoy it - that means you need weekends off, and you need standard business hours. Otherwise, it messes up daycare, evening children events and the split of chores between you and your significant other (which will lead to fights.)

I agree. I was pushed into those hours, but it was because of bad scheduling, for deadlines that didn't matter. And your productivity drops considerably the more hours you do.

There's something interestingly poisonous about the demoscene mentality. Write small, hacky, throwaway, non-reusable code, hand minified beyond readability. Unit tests aren't relevant. You can see this mentality infect WebGL systems and places like Shadertoy. There's a tension between "software engineering" (whatever you want to call it) and demoscene hackers.

Software 'engineers' see the demoscene as an annoying reminder that code can also be crafted like art, unconstrained from corporate concepts like 'design patterns' and 'clean code'.

not just crafted like art, but actually is art. it's an executable that runs just for the sake of lighting up some hardware. Not for collecting your email address or selling you a thing.

Annoying? You mean refreshing. I don't see why these 2 things have to be a conflict. For business software, of course correctness and maintainability are paramount. For demos and games, of course performance and "quick and dirty" are more important. I'd say most developers can do both and know when to do one or the other.

Huh?

The demo scene is a bunch of kids having fun and learning algorithms primarily. To tell them that they need to write unit tests is ridiculous. They will have time to learn about large scale architecture and unit tests in time - by why not try to have fun for a bit?

Shadertoy isn’t meant to be reusable/production code. It is meant to be a fun computer graphics algorithm place. A place to experiment and learn.

We can take the fun out of coding later - that is what paying jobs are for. Why not have some spaces for fun?

No, go the other direction. Once those kids start working on code that other people use, the poison can cause them to shun compile steps, types, tests, build processes, comments, module organization.

Hmm, I was a hang around back in the day. Not one of the big boys. But I got to say some of the young kids that I hung around with then had more skills than many I've worked with in the industry since. Going on my 25th year as a "professional" SW developer.

C=64 has a 1 MHz cpu and 64 KiB of memory but that doesn't stop magicians from creating things like this:

Booze Design - Edge of Disgrace

https://www.youtube.com/watch?v=nLIUkBa_mA0

If you just knew how shitty actually were lots of commercial releases with tons of crude and shitty hacks before a release...

Specially in commercial gaming.

Reply on news.ycombinator.com