Pixel City Redux #2: Unity Week 2

By Shamus Posted Tuesday Apr 17, 2018

Filed under: Programming 59 comments

On the first day(ish) of the project I made a working proof-of-concept demo. Today I’m going to pull a Nightdive by throwing everything away and restarting the project in Unity.

This isn’t as stupid as it sounds. I’m only a day or so into the project, so I’m not going to be throwing away a lot of code. Also, I think writing something in C++ and then re-writing it in C# is a good learning exercise. A year ago I took a swing at learning Unity. The problem is that once you’re done with the tutorials, you need to start making something real. But this leaves you with a three-pronged problem:

  1. Learning a new programming language.
  2. Working in a new programming paradigm, with strictly enforced object-oriented design structure.
  3. Trying to solve this new problem. (Whatever it is that I’m currently working on.)

That’s a lot of unknowns to juggle. Things go wrong all the time when you’re programming. In a situation like this if I do something and I don’t get the result I expect, I won’t even know where to look. Yes, maybe there’s a flaw in my design. But maybe the design is sound, but I’ve somehow expressed it incorrectly in the C# language. Or maybe that stuff is fine but I’m misunderstanding Unity. Even trivial problems can take ages to sort out if you don’t know how to find them.

But re-writing something I just wrote is a pretty good exercise. If nothing else, I’ll know the logic is sound.

If you just stick to doing the Unity tutorial programs you’ll end up focused on a very narrow workflow. Unity is built with the idea that you’ll import pre-made art assets and use simple, short scripts to move them around. And it’s pretty good at that. If you take some random models from the asset store and dump them into Unity, you can make something “playable” (in the sense that the player can push buttons and make things happen) in just a few minutes. This makes it feel like you’re making big progress towards “learning” Unity, but you’re not gaining a lot in terms of understanding how to make an actual game.

Creating a procgen city is a pretty complex task that pushes me into doing a lot of things not covered in the tutorials. At the same time, this work is familiar enough that I’m not getting lost in the program logic.

This re-write takes longer than the initial job. I wrote the original demo in one(ish) day, but the re-write / translation takes almost two. That sounds bad, but this is actually really good by the standards of what I’m trying to do. I’m throwing myself into a new language, a new coding style, and a new set of tools. That’s a huge learning curve to deal with. While I’d like to claim I was able to accomplish this because I’ve got a great big programmer brain, the truth is that a lot of the credit for this easy transition should go to Unity. While relentlessly strange, these tools are very easy to use.

What Makes Unity So Strange?

In the very old days – back in the 1970s and 1980s – coding was really inconvenient. You opened up your code in a text editor. You typed in code. Then when you were done editing you exited the text editor and typed some cryptic nonsense to the terminal windowObviously this was before the days of mouse-driven environments. to have it compile all of that code into a program you could run. Assuming it worked, you could then type the name of your program to run it, test it out, and then close it again. Then you’d run your text editor to go back to editing code.

All of this was before my time. When I arrived on the scene in 1990, we already had better tools for this, in the form of the Integrated Development Environment. (IDE.) To me, a “normal” programming environment looks like this:

I'll admit it doesn't look very sexy.
I'll admit it doesn't look very sexy.

You’ve got your IDE where you type your code. The IDE lets you browse through your source files, edit your code, and compile your program. It helps you look for errors when things go wrong. When you hit “run”, your program will start up as its own standalone program with its own window. If you’re making a game and you need (say) a level editor, then that would be another program you’d need to write yourself. Then you’d give that program to your artists and let them do their thing.

I spent my entire professional life using Microsoft’s programming tools. I started out using Borland’s Turbo C tools in 1990, but in 1994 I bought a copy of Microsoft’s Visual Studio for myself and never looked back. I dabbled with other languages and other tools over the years, but the bulk of my programming time was spent in VS.

In Unity, everything is a bit different. This is Unity:

Uh... where do I type the CODE?!
Uh... where do I type the CODE?!

Unity lets you browse the files in your project, it lets you test your program, and it acts as your level editor. When you run your game, it runs in a window inside the Unity environment. So I guess it’s an Integrated Integrated Development Environment? Everything is integrated now, right?

Well, no. The one thing Unity doesn’t have is a text editor, so you can’t use it to edit your code. When you click on the source file to edit the logic of your space marines, it opens in a separate program called MonoDevelop. I already wrote a bunch of complaints on the shortcomings of MonoDevelop a year ago, so I don’t need to repeat them here.

Having said that: Remember that annoying, glaringly obvious, widespread, easy-to-reproduce bug where you lose the ability to paste text? That is still present. That bug turns five years old pretty soon.

Just shameful.

So Unity integrates everything except source editing, and for that you have to use this fiddly external editor that is apparently abandonware? Or if not abandonware, then “apathyware”. Either way, it’s not a comfortable way to work. Even ignoring the bugs, there are many problems with Monodevelop that make it painful to use. I’ll probably gripe about them in a later entry when I need to do some debugging, but for now let’s just get back to work…

Texture Mapping

One of the first problems I have to deal with in these types of projects is texture mapping. Without a texture map, everything in the world would be a smooth polygon. It would look a bit like this:

The city wouldn't look EXACTLY like this, because this is a gun and not a city.
The city wouldn't look EXACTLY like this, because this is a gun and not a city.

Think of texture maps like wallpaper. Imagine you’ve got this wallpaper with a strong pattern on it, and you’re trying to cover all the streets with this pattern. Except, you need to be able to have the textures meet at intersections without forming obvious seams. You need roads to be seamless at two lanes and seamless at eight lanes. That would be a maddening job. Aside from being annoying and fiddly, it would make the code really complex.

Valve discussed a similar problem in the commentary for Episode 2. When designing the caves, the level designers had a hard time getting those square bits of wallpaper to flow naturally on those organically round cave surfaces. Sure, if you’ve got the time and patience you can make that kind of situation work. You make things match up as well as you canThankfully, texture maps can be stretched or squashed, which you can’t do with real wallpaper. and shove all the nasty seams into a corner. Then you can stick a boulder in front of the seams to hide the mess.

Ugh. I would NOT want to try to texture this using regular rectangular images.
Ugh. I would NOT want to try to texture this using regular rectangular images.

But then two days later, gameplay testing reveals we really need a side-tunnel in this one spot. That throws off all that tedious texture-matching, meaning you’ll have to start over.

The solution that Valve came up with is to use a shader program to make a “3D” texture that can wrap around any surface. The artist doesn’t need to line anything up. It “just works”. The trade-off here is that the artist can’t control where specific details go. But who cares? When it comes to caves, you generally don’t want to worry about where all those little surface details go. All you care about is that you don’t see any seams.

I don’t know exactly how Valve did it, but I had to come up with a way to accomplish the same thing during project Octant. You can read that entry to see how I did it, but the short version is that I projected the texture onto the surface along all three axes, and then used the surface normal to fade between these three projections. So a west-facing wall would have the texture mapped so that the polygon’s position on the north-south axis controls the horizontal mapping of the texture. A south-facing polygon will use the position of the polygon on the east-west axis. If the wall is a diagonal that faces southwest, then it would use both of these projections, blended together 50-50. This doesn’t work if the texture is (for example) a picture of words or something else that needs a particular orientation, but since we’re dealing with things like pavement and asphalt it’s no problem.

Back in project Octant, the result looked like this:

This bricklayer deserves a medal.
This bricklayer deserves a medal.

A brick texture has really obvious lines in it. And the spacing of those lines varies slightly across the surface and they vary drastically between each axisBricks are wider than they are tall.. that makes it a nightmare to get it to line up. But above you can see I was able to wrap it fully around an irregular surface. So this works, basically. At the bottom of that… pillar thing(?) in the archway you can see the crossfade where it transitions between different mapping systems. It’s a little weird when you do this with a brick texture, but I think this is good enough for a nighttime cityscape. The player would need to be very picky and be looking very closely to be bothered by this. Like all my projects, I’m looking for the 10-minute solution that solves 90% of the problem rather than the ten hour solution that solves it 100%.

This sort of texture mapping requires making a shader. This turns out to be amazingly hard because the Unity documentation is a disaster. For the sake of getting on with things, let’s save that rant for later and just pretend that this was a straightforward task.

Once I get the shader working, I wind up more or less where I was at the end of the last entry. I’ve got a grid of streets and a “city” of cuboids:

Hmm. Looks like the roof texture is hosed in this particular shot. Don't worry. I sorted that out later.
Hmm. Looks like the roof texture is hosed in this particular shot. Don't worry. I sorted that out later.

While a layperson might mistake this graphical feast for a Grand Theft Auto V screenshot, this is actually just my city generator. Who knows where the project could go next? Someday I may even have lighting!

Anyway, this means I can just lazily make polygons and not have to calculate texture coordinates as I go. I don’t have to worry about seams or solving complex mapping problems. Now, if my only goal is to wrap the entire world in concrete, bricks, and pavement, then this would be the end of it. But based on the research I’ve conducted by looking out my window, I’ve learned that cities have more detail than that. Buildings have windows, sidewalks have patterns, and streets have lines.

So what I’m thinking is that I’ll combine two different texture samples. One will put down the base surface, and the other will add the detail.

Shamus! What are you doing, man? You just said you didn’t want to worry about texture mapping and now you’re mapping two different textures onto an object. How is this supposed to be “easier”?

The problem I was trying to avoid was making disparate surfaces line up. So I can have two roads arrive at an intersection (or two walls meet on the side of a building) and not worry that we’ll end up with a seam. A seam would look like this:

*eye twitches involuntarily*
*eye twitches involuntarily*

Gross, right? And painstakingly planning out all the texture positions so that I never end up with seams would be a pain in the ass. This base texture system I’ve come up with solves the problem for me. Now I’m going to stick (say) a window on top of that. But when I’m making the window I won’t have problems with seams. Windows won’t form a continuous surface. I can put one window on one section of wall and that bit of wall doesn’t need to worry about what any of its neighbors are doing.

So let’s have our shader combine these two textures and see what we get:

There, it's done. Whaddya think?
There, it's done. Whaddya think?

Yeah. That’s basically what we’re going for. As a reminder, these buildings are just simple cubes that fill the footprint of the building site. A PROPER building would have surface detail and won’t always fill the entire volume of space. Basically, I need to write the next-gen version of the procedural building generator I created for the original Pixel City. But there was no point in writing that until I’d decided how texture mapping was going to work.

The other advantage of this system is that it lets me mix & match base textures and windows. So one building can have brick with window style #1, the next one can be brick with window style #2, then the next one can be concrete with window #1, and so on. I don’t have to make a unique texture entry for every possible combination of surface + window.

Like I said last time: This project is a little more ambitious than the last one, so we’re going to be stuck in these early experimental stages for a little longer. I know Pixel City showed us a cityscape almost right away, but it’s going to take us some time to get there with this project.

 

Footnotes:

[1] Obviously this was before the days of mouse-driven environments.

[2] Thankfully, texture maps can be stretched or squashed, which you can’t do with real wallpaper.

[3] Bricks are wider than they are tall.



From The Archives:
 

59 thoughts on “Pixel City Redux #2: Unity Week 2

  1. Olivier FAURE says:

    This is probably way too technical to be included in the blog post, but I’d be interested to know how you’re converting code into visible building shapes with custom texture in Unity.

    My level in Unity is very low, but I’m pretty sure it doesn’t give you a primitive to display a geometric shape with a custom texture a la “spawnShape(Points[], Texture)”. So how did you do it?

    1. Echo Tango says:

      I would also like to know this. The reason I’m going through tutorials for Panda3D and not Unity, is that I had one too many problems to juggle. Not good at C#, plus new to Unity, plus on Linux instead of Windows, plus actually trying to make the thing I want to make. Python sucks for larger projects, and Panda3D is only graphics (not sound, networking, or anything else) but I already I know the language, have my IDE set up, and the library works fine in Linux. If the docs were better for things more complex than pre-made assets, but less complex than expert knowledge of the totality of Unity, I’d have started using Unity.

    2. PeteTimesSix says:

      It pretty much does have exactly that. See MeshFilterand Mesh, which allow for a primitive using arbitrary mesh data and supplying that data with runtime code respectively.

      1. Echo Tango says:

        The really useful part of that documentation page, is the link to an example project, of which there are many. This stuff has gotten a lot better since the last time I messed around with Unity! (Or else I missed it entirely somehow…)

      2. Shamus says:

        Just to confirm: Pete is correct. This is what I’m using.

        It’s not documented very well (or at least, the tutorials don’t really teach you about it) but once you know about it, it’s really powerful.

  2. Rick says:

    I’m really enjoying reading having new programming posts to read. Thanks!

  3. Daemian Lucifer says:

    If you take some random models from the asset store and dump them into Unity, you can make something “playable” (in the sense that the player can push buttons and make things happen) in just a few minutes. This makes it feel like you’re making big progress towards “learning” Unity, but you’re not gaining a lot in terms of understanding how to make an actual game.

    And yet you can still sell it for $$$ on steam.

  4. Piflik says:

    Haven’t read the whole thing yet (at work), but don’t use MonoDevelop. Unity is ending support for it anyways. You can change your preferred IDE im the preferences, and Visual Studio has a good Plugin to make the integration with Unity nearly seamless (in the sense that you can use breakpoints for debugging and they actually get hit). If you use ReSharper (which I would advise for anybody writing C#) it also has a handy Unity Plugin to display nice information, like which functions are called by the engine or which fields are visible in the inspector.

    1. Echo Tango says:

      I was going to suggest PyCharm, then remembered it’s focused on Python. Good thing that company makes editors for pretty much every language, paradigm, etc! :)

      1. Tim Keating says:

        JetBrains, who make ReSharper and PyCharm, have a full-fledge C# IDE called Rider. I strongly recommend it over MonoDevelop. (Or anything else, frankly. It’s that much better.) Getting it setup is a bit of a pain, frankly, but it offers so many more modern IDE features for doing Unity development.

  5. redsoxfantom says:

    Newer versions of Visual Studio integrate very nicely with Unity if you’re sick of MonoDevelop (https://docs.unity3d.com/Manual/VisualStudioIntegration.html). I’ve been using VS Enterprise Edition 2017 and it works really well for me.

    1. redsoxfantom says:

      I just reread your old Unity post where you said VS had weird linker errors. I had those too way back when, but the new plugins in VS seem to work a lot better

      1. Shamus says:

        Thanks. I’ll give it another look.

      2. Shamus says:

        It works!

        Thank you. This is going to save me a ton of headaches going forward.

        I’m still going to post my MonoDevelop rant, though.

        1. PeteTimesSix says:

          MonoDevelop absolutely deserves it. Just uh, dont add to the mountain that is people declaring Unity inferior for issues that have already been fixed years ago if you can help it? Pretty please?

          …I may be a bit of a fanboy. In my defense, I made my master’s thesis (huh, turns out its on the internet? link for the suicidally curious, I guess) in Unity and it was an absolute joy to work with, so…

          1. Droid says:

            “University of West Bohemia”

            Ooh, I didn’t know people wrote theses in Unity in the 19th century!

          2. default_ex says:

            They more than deserve it. There was a short period where I had some weird problems getting Visual Studio to run due to tampering too much with it (took a month to unravel the mess I made). Tried to use MonoDevelop, really tried hard to give it a shot and live with it. Ultimately used Notepad++ to write code, edit project files and msbuild’s command line compiler. It was so much less painful despite having to deal with things we normally don’t even think about in C# like what order to compile our files in.

          3. Pylo says:

            I agree, there is no need to “declare Unity inferior for issues that have already been fixed years ago” when there are SO MANY issues that have not yet been fixed. I could probably fill a 100 page essay on everything that is (still) wrong with Unity.
            That being said, Unity is pretty great for prototyping, which may be just what Shamus needs so I hope it works out for him.

        2. Olivier FAURE says:

          If you’re not satisfied with Visual Studio, you can just use any other text editor (my favorite is Atom) and compile from Unity, by the way.

        3. DivFord says:

          I’ve been using MonoDevelop with the Mac version of Unity for years, and it has none of the problems you mentioned in your old post. Given that Unity was originally Mac only, I guess it’s a problem with the port?

          Both times I installed Unity on Windows, it defaulted to VS, so your situation is perplexing to say the least…

        4. MichaelG says:

          I didn’t even realize you were doing this without using VS — you poor guy!

          I still thought the integration between VS and Unity was a bit of a pain.

        5. Xeorm says:

          Was going to suggest this too, but really. I don’t think anyone that reads this blog will be sad about reading another rant.

        6. Mistwraithe says:

          I figured I would find this thread in the comments somewhere. I’ve been using Unity for a while now and never even considered installing MonoDevelop, VS is sooo much nicer.

        7. Rack says:

          When I was using Unity the (unofficial) tutorial suggested using Visual Studio from the off, so I didn’t even remember Monodevelop was the default. Still Unity shouldn’t push and include as default stuff that doesn’t work. So I’ll still enjoy it being given both barrels.

  6. Daemian Lucifer says:

    Obligatory typo collection comment:

    In a situation like this if I do something and I don’t get the result I expect, I won’t even know where you look.

    where to look

    but for new let’s just get back to work…

    for now

    1. Nick-B says:

      Wasn’t going to post a typo correction, but your post encouraged me to point out the one I found:

      For the sake of getting on with things, let’s save that rant for later and just pretend it this was a straightforward task.

      One of those two needs to go. You can do
      “pretend it was”
      “pretend that was”
      “pretend this was”
      or combine some, for a
      “pretend that this was”

      Isn’t English great?

      1. MelTorefas says:

        Hmm. Textures give otherwise blank or ’empty’ objects a specific appearance. Seams exist when code fails to line textures up properly, such as when they are mapped to an irregular object.

        If conversations are objects, then text is the texture applied to give that object it’s appearance. Typos are the seams where the text texture does not line up properly.

        Shamus is the one producing that text.

        Shamus == Program, confirmed?

        1. default_ex says:

          You can test that conclusion in C#. “if (Shamus is Program) Console.WriteLine(“Confirmed!”);”

  7. MattR says:

    Honestly surprised that MonoDevelop is still going, what with Visual Studio Community Edition, VS Code and VS for Mac (which is built on MonoDevelop). Microsoft actually has some good docs on setting up Unity with Visual Studio Community Edition (assuming you don’t already have Pro).

    1. Chris says:

      I’ve really fallen in love with VS Code as of late, especially in combination with dotnet Core. It still feels a little surreal to be running a bunch of Microsoft tools on my Linux laptop and have everything work so smoothly. Old Microsoft this ain’t.

      I just wished they’d named it something more distinct so that I didn’t have to wade through a ton of VS search results whenever I’m trying to look something up.

      1. Echo Tango says:

        If you search for it as one word vscode it seems to work better.

        1. Chris says:

          Duly noted. Thanks!

  8. Daemian Lucifer says:

    You make things match up as well as you can[2] and shove all the nasty seams into a corner.

    Or,you have your artists draw a single texture that will cover the whole thing.

    And thinking of that has made me think about ai.Since there have been ai that paint stuff already,has anyone tried making an ai that would “manually” mesh all the textures together and make a single megatexture that you can then use for your game?Of course,this would not work for a procedural game,but for an already premade level such a thing could theoretically work and cut down the time when the level is being tweaked.

    1. Echo Tango says:

      You don’t need anything as complex as AI to do this, though. If you’ve already got the textures, and they’ve already been placed on objects in your game, then you just make some program that stitches all the single image files together, and translates all the coordinates. Your last point, that this would speed up development; Can you describe more what you mean here? This should actually slow down development, since you need to shove all your textures back through your megatexture process, when you change something in the level.

      1. Daemian Lucifer says:

        I shouldve refined my thinking a bit before posting that.

        What I had in mind was an actual painting ai that can fill in the mundane stuff.For example,one that knows how to paint walls from a vast library of various walls,internal and external.So whenever you need to build a level in whatever game you are making,you just fire it up and it gives you a bunch of interesting walls,with cracks,stains,bricks for outside and wallpaper for the inside,…Basically an artificial artist.

        And yes,I know that current ai tech is not fully up to the task of doing this for a big budget “photorealistic” game,but still I cant be the only one who had such a thing in mind.

        1. Echo Tango says:

          AI / machine learning can do this, but it’s more complex than you need to fill in this detail automatically. See my other post below.

    2. Echo Tango says:

      If you want to save time with texturing, you do what Shamus did, or make a texture-generator (usually implemented as a shader program, but you can have it be offline too), or make textures from high-res photos in real life. This is actually what Star Wars: Battlefront did for its textures / bump-maps – all photos from the real world, plus some programs that map that onto existing models, or create new models straight from the real-world objects.

  9. Cubic says:

    “While a layperson might mistake this graphical feast for a Grand Theft Auto V screenshot, this is actually just my city generator. ”

    Looks a lot like the GTA III games actually. The scene in question could almost be the yard next to the car shop in San Fierro.

  10. Cubic says:

    “In the very old days – back in the 1970s and 1980s – coding was really inconvenient. You opened up your code in a text editor. You typed in code. Then when you were done editing you exited the text editor and typed some cryptic nonsense to the terminal window[1] to have it compile all of that code into a program you could run. Assuming it worked, you could then type the name of your program to run it, test it out, and then close it again. Then you’d run your text editor to go back to editing code.”

    Heh, I’m still using Make and all that, both at home and at work (Linux, of course). And who doesn’t want to type in various git rituals while developing?

    However, IDEs are slow, huge messes that just ooze aggravation and waiting for the screen to update when you click something. Ugh no.

    1. Olivier FAURE says:

      Oh yeah. Until IDEs get their act together, I’m still using command line utilities with a text editor.

      1. MichaelG says:

        I don’t use Linux enough to have bothered to learn an IDE there. So it’s gedit, make and gdb for me on Linux. Usable, but VS on Windows is so much nicer…

    2. Droid says:

      “git rituals”

      Rituals take at least 10 minutes to complete, so this is completely accurate.

      1. Cubic says:

        And when you’re done, you end up with a detached head.

        1. I’m in a doctor’s office waiting room and am laughing way too hard at this XD

          1. sab says:

            Are you there for your detached head?

    3. Echo Tango says:

      The slow parts of IDEs (at least the ones I commonly encounter) are what you pay, to have fast searching, and the ability to click through function calls, class hierarchies, etc. :)

    4. default_ex says:

      Perhaps give CodeLite a try. Best IDE I’ve used in Linux. Like it enough that I rather use it in Windows for C and C++ than Visual Studio despite being significantly less feature heavy. CodeLite is so close to command line that you really have to know how to work gcc and it’s utilities to get the most out of it.

      1. Richard says:

        On Linux and Mac I’d definitely recommend Qt Creator for C, C++ and other supported languages.

        But if it doesn’t support your language, an IDE can often be worse than useless.

  11. Joshua says:

    I wish you could use these little projects to score yourself some contract gigs with real companies. They’d probably pay better than us peons. :(

  12. Decius says:

    What does HerpesDevelop do to talk to the rest of the development environment, and why can’t eg notepad++ do that part of the thing, or some other text editor that doesn’t fail so horribly at being minimially functional.

  13. Paul Spooner says:

    Looking forward to seeing how you integrate Global Illumination to tie the whole thing together.

    1. Paul Spooner says:

      Should be able to get global illumination effects like this without too much trouble. Especially since the buildings are static, so you can bake it into a multiply texture.

      1. Echo Tango says:

        Neat!

  14. Lazlo says:

    ’m looking for the 10-minute solution that solves 90% of the problem rather than the ten hour solution that solves it 100%.

    Correction: the 10 hour solution solves it 99%.

    1. krellen says:

      10 days gets you to 99.9%. 10 weeks will yield 99.99%. 10 months gets 99.999%. 10 years gets 99.9999%. I think you see where this is going.

  15. kikito says:

    Just FYI, a lot of us still work by “changing something in the editor, then going to the console and writing some magic command to re-execute everything”.

    Consoles have gotten better. I understand they might not be everyone’s cup of tea. Their biggest upside is that I don’t need to learn a new environment every time I switch technology stacks – I keep using the same editor and console.

    1. Echo Tango says:

      Lots of command line stuff also watches for file changes, and only re-does work for those files instead of everything. Is how a lot of new IDEs actually do their thing, under the hood. Makes it pretty easy to use your program of choice for editing, and keep using good, solid command line stuff.

  16. Vi says:

    I know what you mean about trying to track down problems in that kind of development environment. I’ve been stuck for months on bugs I thought were in my code; sometimes they really were, and sometimes they were from some obscure setting on some obscure GameObject that I hadn’t realized was so important! And that’s how I got into the awkward habit of creating a fresh scene full of fresh testing GameObjects at the drop of a hat. I’m sure it’s worse for me because I lack the real-world coding experience that would help me spot logic problems more intuitively, but the level editor strangeness is definitely contributing.

  17. default_ex says:

    I certainly know that pain of learning a poorly documented system. Recently taken to developing my own shaderpack for Minecraft. Encountered a lack of any real documentation on how shadermod actually works. Have had to resort to things like rendering all of the stuff from a particular shader to a buffer and seeing what exactly it draws. Different combinations into a buffer to see what orders they are executed in and what states (like depth testing and the like) are being set. Shotgunning ideas at how things are done in vanilla Minecraft using what data is available in a given shader (like the sky was a nice day long poking and prodding to figure out). It would have probably been easier to just reverse engineer my own shader system for the game.

Thanks for joining the discussion. Be nice, don't post angry, and enjoy yourself. This is supposed to be fun. Your email address will not be published. Required fields are marked*

You can enclose spoilers in <strike> tags like so:
<strike>Darth Vader is Luke's father!</strike>

You can make things italics like this:
Can you imagine having Darth Vader as your <i>father</i>?

You can make things bold like this:
I'm <b>very</b> glad Darth Vader isn't my father.

You can make links like this:
I'm reading about <a href="http://en.wikipedia.org/wiki/Darth_Vader">Darth Vader</a> on Wikipedia!

You can quote someone like this:
Darth Vader said <blockquote>Luke, I am your father.</blockquote>

Leave a Reply to Joshua Cancel reply

Your email address will not be published.