Posts Tagged ‘Textures’

Tools

Making a Texture Tool

Posted

At the start of this year I started working on a new texture tool called Retro FIT, a fast and intuitive texture editor for retro games.

I wanted to create a non-destructive tool that simplifies the creation of textures, but also encouraged experimentation, that could provide results good enough to be used as finals or as a base.

I’ve had this idea for years, from working on various projects and encountering very specific little problems where it’s always been like “That’s cool, if I expanded on that idea I could do more with it!” but never did.

But this year I decided to finally try to make it real, and get it out there. Seeing if I can consolidate those ideas and experiences into a useful tool that others can use. And since coding AI assistance is becoming pretty normal in tooling (for indies and industry), I thought, “fuck it!” Let’s see what I can do with it, and with what I know.

I know there’s a lot of contention about AI usage in various fields at the moment. But as a person who does way more things than they should, using it to learn more about the work I’m already doing, just helps get to the “making” a little sooner. It’s like greasing and tuning an engine to go faster, but you still need to have the skills to drive sensibly to a destination.

I wanted to keep the tool simple, give enough room to try whatever you wanted, without losing too much time. The focus has been on the “Fast and Intuitive”, using that as a philosophy to help iterate on the tools UI and the demands of projects I’m working on with it.

Another focus was on development moods to help simplify working with it at different levels of creative friction. You can get into a mood, or mode, where doing anything else can be frustrating especially when you’ve done like 5 different things in one day, but you know you need to get that one more thing done.

Maybe you can relate to these?

  1. “I’m looking for something” – you’re actively looking for something different, but it’s only a vague idea in your head, so you duct tape it all together, mess around with things you shouldn’t, until you discover something you like and want to repeat.
  2. “Just use THAT” – you know what you want, you don’t want to use any more brain power than you should, and just make a few adjustments to something you already have, to spit out something new-ish.
  3. “Keep it simple” – you don’t want to open everything, and you just want to sit down and focus on one thing for an hour or two.
  4. “At least start it” – you don’t have any brain power left, but you want to at least start it, knowing that you’ll come back to it tomorrow.
  5. “I can’t be fucked today” – decorum goes out the window, nothing is placed in, everything is thrown in and shaken about until you see something you like, you kick it out the door and save the regrets for later.

Taking as much friction out of the creative process is important, and creating tools that do that in a balanced approach is essential. You don’t want to make it so easy that the work basically doesn’t exist anymore (because you ultimately introduce different problems later), but you also don’t want to make it so difficult that you want to throw your computer out a window.

I feel like a lot of modern tools can add more friction in places then they remove. There can also be a huge skill ceiling especially for some of the best tools available for game developers. The ask always feels like mastering a song on the piano before you even know how to play.

There is a lot of resistance, especially since some of these tools are designed to solve the “BIGGER” and broader problems. Couple that with a price tag (or a protection fee, a.k.a. a subscription), and you create a lot of unnecessary questions to what is usually just “I want to make a thing.”

The opposite can also happen with more readily available tools, where the demands of your work begin to exceed the bounds of what the tool was made for. So you make do with what you have when you sense there has to be better way to do it, but no time to do anything about it.

Sometimes in situations like this you even end up with like 10 other little tools to solve a problem, resulting in a blatant disregard to file management and self preservation.

I’m not saying these tools are bad, they are great at what they do. But they solve a different set of problems at different entry points. Where the former isn’t accessible to (or for) everyone especially because the initial entry point is on a mountain of piano concertos. And the latter can feel a lot like an elevator that opens to a flight of stairs.

But rant aside…

I’m hoping I’m at least trying to solve both those problems. Creating tools that are fast and easy to learn, but powerful long enough that when you really do need more power, the other tools and the investment of time becomes meaningful and with purpose.

It still has a few things to improve, but it’s at a point that I’m happy with it and would love to see it used in other projects.

It has been great to see the outputs of my tools around. Seeing projects online that are using the Prototype Texture Generator has always been great to see, because it’s just the background of someone’s work, knowing they are focused on the meat of their own projects.

If you’re using one of my tools, give the tool a shout-out. The idea that people are using what I’m working on, and that it’s allowing people to create more freely, always feels good, and it would be great to see that happen more.

I’m also working on a few other tools just because I want to get those ideas out of my head and see what I can do. My next tool is called Retro ATLAS, which is a texture atlas creation tool that simplifies the process of creating trim sheets, layouts and adjustments in a non-destructive way. It’s coming along pretty well, so keep an eye out if you’re interested.

Windows 11

If you got to the end of this, congrats!

Now go make shit.

Programming

Texture Generation

Posted

This past week I’ve been experimenting with Texture Generation to learn more about procedural generation and apply what I learn to The Maze Where The Minotaur Lives.

To start out, I created a simple editor window in Unity to let me create and test new Texture Generators easily, providing a simple way to adjust their values and see the results.

The editor window to help create and test new texture generators.

The first generator was a basic checker pattern. I wanted to figure out the basic interfaces needed to create the window editor and how to generate textures, before moving onto anything more complicated.

A simple black and white checker pattern.

I then experimented with generating gradients, creating a UV gradient, and a diagonal color gradient.

UV Gradient
Black and white diagonal gradient.

Next, I tried a variety of noise algorithms. Using Unity’s Random class, to generate a random texture.

Random noise generated using Unity’s Random.value.

I also added support for Value and Perlin noise.

Value Noise
Perlin2D Noise

I’ll be using these textures to help generate and visualize variations that will be used in The Maze Where the Minotaur Lives for walls and other effects.

Improving Performance

When adjusting the settings for the Perlin noise, there is a delay between the slider being changed and when the texture is generated. This is even more noticeable when adjusting the noise’s octave to higher levels.

This isn’t too big of a problem while loading and generating a map in-game, especially when the maps are small. But I couldn’t help wonder if I could tweak the code to increase the performance by using Unity’s Job System in the editor.

I have dabbled with it in the past, but I’ve never found much use for it, at least until now.

My initial attempt was to take the code and put it inside a “Job”, to see what would happen. Surprisingly, it ran slower. My best guess is that moving work to another thread and waiting for it to complete is just that, moving it somewhere else to wait for it.

I then converted the code to use an “IJobParallelFor” instead. Parallel jobs can be used to schedule batches to run the same job across multiple processes. And since the noise is calculated per pixel, it’s safe to generate the noise using batches.

There was a decent improvement in the GUI, with less delay when generating a 512×512 texture.

Even with some minor tweaks to the code and number of batches, the changes in performance were minor, with still noticeable delays in the GUI.

So I decided to take it one step further, and try out Unity’s Burst compiler.

I’ve heard and seen a few examples of it in action, and it looks a lot like black magic. So this felt like a good opportunity to try it out myself.

The top line is what black magic looks like.

Adding one line at the top of the job struct to use the Burst compiler with the job, the performance gain was incredible. The GUI now has no delays at all when adjusting the parameters for a 512×512 noise texture.

With a 1024×1024 texture, the Burst version has similar responsiveness as the CPU-bound version. With the CPU-bound version at 1024×1024 giving you enough time to make a coffee and come back.

Next, I’ll be updating the procedural framework to make use of these textures. I’m not entirely sure how long that will take with my current workload, but I’m looking forward to putting these to use and seeing what kinds of results I can get.