4 ms·

Agree with everything you said. We used x87 though and paid extreme attention to fpu stalls to ensure nothing wasted clocks. As developers, we were also forced

Agree with everything you said. We used x87 though and paid extreme attention to fpu stalls to ensure nothing wasted clocks. As developers, we were also forced to give the graphics guys a really hard time: "no that texture is too big! 128x128" & "you need to do it again with less polygons". We used various level of detail in textures and models to minimise calcs and rendering issues. Eg. A tank with only 12 vertices when it would only be a pixel or three on screen. I think it only used 2x2 texels as part of a 32x32 texture (or thereabouts)... This was around mid 90's.

Dave_Rosenthal 5y ago
Ha. Yeah, there was not a lot of memory. The toolchain we built at the the time automatically packed all individual game texture maps into a single 256x256 texture (IIRC). If the artists made too many textures, everything started to look bad because everything got downsampled too much. Any yeah, the design of the game content was absolutely affected by things like polygon count concerns: "Say, wouldn't it be cool to have a ship that shaped like a torus with a bunch of fins sticking out? Actually, on second thought... How about one that looks like a big spike? :)"
- lostgame 5y ago
  A fantastic early example of memory limitations in games are that the clouds and bushes in Mario 1 are the same sprite with a different palette. Those were certainly different times. :) It was so much cooler to see what developers and artists did within those limitations than what we are doing today. The entire game dev community was like a demoscene in a way.
- kqr 5y ago
  > If the artists made too many textures, everything started to look bad because everything got downsampled too much. That's really clever. On the surface of it, it's "just" about dynamically adapting fidelity to fit in the available memory. But really, it's a deeper organisational solution: it pushes the breadth vs fidelity of assets trade-off back to the designers, who are the ones that should decide along that curve anyway. It provides a cheap way for them to visually evaluate various points on that trade-off curve. Very clever.
  - lupire 5y ago
    why would you assume the designer would choose the optimal graphics config, instead of the artists who are the visual experts?
Agentlien 5y ago
Honestly, though the numbers are bigger and floating point arithmetic is fast on a modern GPU this still sounds a lot like how we work nowadays. I recently spent two years on the performance team for a large indie title and a huge portion of it was asking artists to simplify meshes, improve LODs, increase the amount of culling we could do on the CPU, etc. My own work was mainly optimising the rendering itself.

Dave_Rosenthal 5y ago

Ha. Yeah, there was not a lot of memory. The toolchain we built at the the time automatically packed all individual game texture maps into a single 256x256 texture (IIRC). If the artists made too many textures, everything started to look bad because everything got downsampled too much. Any yeah, the design of the game content was absolutely affected by things like polygon count concerns: "Say, wouldn't it be cool to have a ship that shaped like a torus with a bunch of fins sticking out? Actually, on second thought... How about one that looks like a big spike? :)"

lostgame 5y ago
A fantastic early example of memory limitations in games are that the clouds and bushes in Mario 1 are the same sprite with a different palette. Those were certainly different times. :) It was so much cooler to see what developers and artists did within those limitations than what we are doing today. The entire game dev community was like a demoscene in a way.
kqr 5y ago
> If the artists made too many textures, everything started to look bad because everything got downsampled too much. That's really clever. On the surface of it, it's "just" about dynamically adapting fidelity to fit in the available memory. But really, it's a deeper organisational solution: it pushes the breadth vs fidelity of assets trade-off back to the designers, who are the ones that should decide along that curve anyway. It provides a cheap way for them to visually evaluate various points on that trade-off curve. Very clever.
- lupire 5y ago
  why would you assume the designer would choose the optimal graphics config, instead of the artists who are the visual experts?

Agentlien 5y ago

Honestly, though the numbers are bigger and floating point arithmetic is fast on a modern GPU this still sounds a lot like how we work nowadays. I recently spent two years on the performance team for a large indie title and a huge portion of it was asking artists to simplify meshes, improve LODs, increase the amount of culling we could do on the CPU, etc. My own work was mainly optimising the rendering itself.