Two Stop Bitsnew | comments | tags | ask | submitlogin
  • Yesbox 595 days ago | parent | on: Developing a 2D Isometric City Builder like its 19...
    Thanks!
  • Yesbox 595 days ago | parent | on: Developing a 2D Isometric City Builder like its 19...
    Cool! Thanks for sharing. I imagine back then it was a lot more work than it is now
    • qingcharles 595 days ago
      Yeah, the hard bit was the IDEs weren't as nice. You didn't have the Internet to look up the syntax of some function when you needed it. No Stack Overflow. No ChatGPT. No-one else's code to look at to see how they solved it.

      Even something as simple as "what is the algorithm to determine which isometric tile the user is clicking on in 2D/3D space" had to be solved from scratch :(

      • Yesbox 594 days ago
        I hear you. I've ended having to implement many of my solutions from scratch because 2D isometric knowledge is so arcane now. No one talks about it or designs an engine like this. From what i've gathered, most people use a 3D engine with a fixed orthographic camera perspective.
  • Yesbox 596 days ago | parent | on: Developing a 2D Isometric City Builder like its 19...
    Hehe. C++ is the modern version of assembly, right? Its been ~30 years after all ;p
  • Yesbox 596 days ago | parent | on: Developing a 2D Isometric City Builder like its 19...
    There's a lot of challenges developing a 2D game that is 3D on screen.

    Recently I added multi-floor buildings, which transitioned the game into 3D space (where as before, flat terrain and single story buildings meant the Z (height) position of everything was 0). Some of the functionality of the game relied on looking up what pixel (object) was under the mouse. This was relatively easy to do before building height. I looked up all the objects in a cone moving towards the camera (so down in screen space) and determined which one was "closest" to the camera by sampling the sprite image and comparing the world.y position.

    This method falls apart when there are multi-story buildings, since a really tall building could be blocking the view of something further up the map. I came up with a solution that uses a 2nd buffer that draws everything to a tiny 3x3 texture, but instead of drawing the sprite, it draws a UUID encoded as pure color (by using the Vertex shader color property). On the CPU side of things, I take this color, convert it back into an unsigned int, look up the element position in a (C++) vector, and grab the basic properties of the object from there. The reason the texture has to be so small is because it is stored on the GPU, and needs to be converted into an image format for the CPU. It would be very expensive to send back the entire screen as an image to the CPU every frame.

    • qingcharles 595 days ago
      This algorithm killed me even when it was 2D on a 2D screen with 3D characters back in the 90s. And I had no-one to help as there was no Internet access and no-one really developing online in those days.
lists | rss | source
Search:
Two Stop Bits is a discussion web site about retro computing and gaming.