It’s done! Finally, after over a year since its completion, Mop of Destiny gets its own webpage!
I had a really difficult time trying to figure out what the webpage should even look like, so I just kept putting it off, until last night when I was almost asleep, I had that “eureka!” moment immediately before dozing off. Luckily, I remembered my idea in the morning!
Also DrilNES 1.10 is released. I fixed up a few very minor emulation issues, added support for all of the 6502’s “undocumented” opcodes (i.e. the opcodes that just happen to work even though they’re really not supposed to), and modified the display a bit.
Now you can even make it look like a crappy old TV, if you choose! For, uh..nostalgia’s sake.
Enjoy!
HERE COMES A NEW CHALLENGER!
Inspired by Scet’s Tub of Awesome, I opted to continue work on my old emulator, DrilNES.
And here it is! DrilNES in all its glory! Note that it does not support PAL NES timing, it only runs NTSC games (so US and Japanese games only).
A Brief History of the World
I first attempted to tackle NES emulation back in 1999. I had the goal of getting three games to be playable: Castlevania 3, Startropics, and Crystalis. Turns out, these three games are some of the harder games to emulate, due to the tricky nature of the cartridge hardware that they run on. However well it ran at the time, it was woefully inaccurate, and this bothered me. In mid-2004, I apparently decided to try again.
No real dev updates. I’m still working on the behind-the scenes stuff. I got a bit bogged down with the asset management – turns out, handling on-the-fly asset streaming on the 360 using XNA is a tricky proposition, due to the garbage collection (which triggers every megabyte or so of allocation, grinding everything to a halt if your heap is too complex) and the XNA content management system (you can’t dynamically unload any given individual component – it’s all or nothing).
Because it’s been rather frustrating, I didn’t feel like coding tonight.
Instead, I did some image editing based on a dumb idea I had.
That’s all.
I’ve gotten less done recently that I would have liked, due to a lack of time to sit down at my computer. However, I did implement tiling perlin noise in-shader.
It uses the same basic technique as I used to set up the tiling noise (so you can read it in one of my earlier posts).
Basically, I can generate perlin noise that tiles at any given (integer) position.
Quite handy for generating tiling textures (because not everything I’m generating needs to be 3d)
Here are some examples. It’s hard to tell that they tile without actually tiling them yourself, but they do. So there.
So I used it to put together a seamless version of my earlier brick texture:
Finally, I did the same basic trick with the Worley (cellular) noise.
The first screenshot is a large area repeating Worley, the second repeats at a very small level so it should be obvious how it tiles, even looking at the thumbnail:
Next up: Maybe I should actually do something useful with these things.
So I put off working on this entry long enough that it’s now two entries worth of data in one.
Too Many Instructions: Cutting Down On the Noise
So, the implementation of Improved Perlin noise from GPU Gems 2 boils down to 48 pixel shader instruction slots (9 texture, 39 arithmetic). That’s one octave of noise. What I needed, desperately, was a faster implementation of noise, where the base quality doesn’t matter (especially useful for things such as fBm and the like).
In the FIRST GPU Gems, in the chapter on Improved Perlin Noise, Ken Perlin makes a quick note about how to make a cheap approximation of perlin noise in the shader, using a volume texture. The technique is straight forward, but it took me some effort to understand exactly what was supposed to go into the volume texture.
In my case, I ended up using a 32x32x32 volume texture to simulate an 8x8x8 looping sample of perlin noise space. Essentially, when sampling this texture, divide the world position by 8, and use that as the (wrapped) texcoord into the volume.
(Discussion of multiple noise types and some screenshots after the fold)
So yesterday I got the crack filling up and running.
Tonight, I improved the routine dramatically.
The Trouble With Texcoords
The problem was, the edge-expanding algorithm I used was detecting way more edges than it needed to. Here’s an image of a normal map generated using this (old, bad) method (I made it render ONLY the skirts, for illustration):
As you can see, way more edges through the UV charts were getting expanded than necessary. This was messing up the maps, because there were angles and edges where there didn’t need to be, and it was introducing artifacts, especially at lower mip levels.
The problem arose because each of those “extra” edges marked areas where the vertex positions were the same, but the texcoords were different. Since the original algorithm was using the vertex’s index as the identifying feature, each time there was a texcoord change meant that the indices for neighboring triangles were different, blah blah blah, you get the point.
I took it easy today, so I was barely near the computer, but I did make some awesome progress.
Last night, I was able to finally get a prototype of my texture caching setup going.
Diffusing the Procedural Situation Using Bad Puns
Right now, it’s a command-line tool that does the following:
- Loads up a mesh and UV atlases it to get unique texture coordinates for the entire mesh (similar to what you’d do for lightmapping
- Loads a D3DX effect
- Renders the mesh into the a render target, using the UV atlas texcoords as position, using the actual model’s position/normal as shader inputs to generate the noise
- Writes both the UV atlased mesh and the rendered texture to file
Simple enough. What I ended up with was as follows:
Not bad, but for two things:
- No normal mapping (per-vertex normals only)
- Cracks along the seams of the UV maps.
Both are solvable problems, and I opted to tackle the normal mapping first.
Return of the chairs!
I needed a quick test to make sure that the noise textures work well in 3D, since that’s their intended use, so I decided to run them on some chairs.
A few things to note:
- These aren’t currently being written to texture first (which is the ultimate idea) so the chairs in the background have a certain amount of…sparkle.
- Also, this means that this is SLOW. This scene brought my 8800GTX to its little silicon knees. The concrete shader is 1906 instructions (way over the sm3 guaranteed min spec of 512), 306 texture and 1600 arithmetic, so it’s a bit…intense.
- The lighting looks a little weird. I’m not sure if it’s an artifact or if it’s right and I’m just imagining things, but there you go.
That’s all!
PS – broken finger: still sucks.
This’ll be a short update. I came up with a better pavement texture, and, while trying for the stones, came up with a nice method of star generation, so I refined that as well. Hooray for happy accidents!
The stars one really looks best zoomed in (the thumbnail looks kinda lame), but I like them both!
All 100% pixel-shader generated. Both of these use pure improved perlin noise modifications to generate their look…no custom patterns like the brick and tile textures from earlier.
If you want to play around with the generator, the binary, code, and shaders are in a zip in the previous post. Have at it and let me know if you make anything awesome!
The Most Communicative Of Fingers
This entry was going to be a bit longer, but:
Yeah. It’s the classic tale of “boy meets girl, girl rejects boy,” except you replace “boy” with “finger,” “girl” with “wall,” and “rejects” with “breaks.”
Sometimes playing wallyball can be considered dangerous.
Procedural Textures
As part of the framework for the game I am currently writing, I’m going to have as much texture data as possible be procedural and cached in on the fly. There are a few reasons for this choice (many of which should be obvious):
- Less disk usage – very useful if I hit my target of, oh, say, a certain game console
- Non-repeating textures – textures don’t have to tile. I can keep caching in new ones.
- Seriously, I suck at texture art – This way, the computer does it for me!
I’m still working on the method, but here are a few examples:
These are all generated on-GPU, using ps_3_0 shaders. The noise implementation comes straight (thank you, copy-and-paste) from GPU Gems 2, which is an awesome book.
The idea is that objects (especially static world objects) will have unwrapped UV coordinates (like you’d use for lightmaps). To generate the textures onto the objects, I’ll do the following:
- Create a texture that is the requisite size (or pull it out of a pool, which is more likely
- Render the objects into the texture, using the UV coordinates as the position (scaled from [0,1] to [-1,1] of course).
- Pass the position and/or normal to the pixel shader, use it to generate the texture data
- Repeat for as many textures as the object needs (some combination of diffuse color, normal, height, glossiness, etc).
Should be pretty easy. Obviously, there are some patterns that are ridiculously difficult or even maybe impossible to generate efficiently on the GPU, so I’ll probably still use some pre-made texturemaps. But as much as I possibly can do on the GPU, I will. The main gotcha will be keeping the amount of texture info that needs to be generated to a minimum, so there aren’t any render stalls. That’s more of a level design/art problem though (which, because this is being developed lone-wolf, is also my problem).
