Amusing glitch gallery

I was working on a very simple distance fog function. Artists say that want blue fog in one direction, orange fog in the opposite direction.

Ok. I set orange-dir to point towards the sun, and blue dir to point away from it.

The result; not quite a bug, not quite a feature... accidental rainbows:

I don't have a screenshot or video of this (and it's been fixed now), but I was working on a physics-based walk cycle for a 2D character a little while ago. Spamming the left and right buttons would cause you to lift off the ground and fly away...

Nice idea. I actually collect the graphical glitches, since after a fix one cannot reproduce them easily. Here we go:

Everybody doing skinning for the first time has probably seen something like this: This should be tiny_anim.x from the D3D SDK samples:



Forward-Backward FFT shader test. First image is a (complex) test source. Second image should be exactly the same, but has now "artistic value" added:




Playing with Bezier patches. This should be a wireframe view of the Teapot:


"Better" (one shouldn't use the same parameter for both dimensions):



Playing with marching cubes. This should be a perfect sphere:

Again "better":



Debugging a shader for light accumulation (deferred rendering). The (point light range) spheres in the middle and top right are diffs of the reconstructed view ray and the expected one (abs and scaled). Both should be perfectly black. They're not, but sort of pretty now.



This one is actually intentional. Playing with conservative depth. These are billboarded spheres with depth output. Using a wrong start depth gives this. I think one can now see Hi-Z at work.

Though this doesn't beat some bug I caused some time ago while rewriting some climbing enemy, basically I forgot a check and the enemy would literally hump the wall, suitable animation and all o_O I'm not sure I'm allowed to show that here without getting banned though XD

Assuming the enemy is clothed, or some kind of animal clothed by its fur/scales/whatever, I don't think anyone would have a problem with that. But when in doubt, you can link to an image instead of pasting it right into the thread and mark the link "possibly NSFW" or otherwise explain why people may not want to click it.

*recreates bug*

You all have been warned (NSFW?). Sorry for framerate, I wasn't going to pull off a 60FPS animated GIF. Amusing how the background loop is near perfect (should have waited a few more frames I guess?)

Also what the— it seems to have gotten worse since the last time o_O

*recreates bug*

You all have been warned (NSFW?). Sorry for framerate, I wasn't going to pull off a 60FPS animated GIF. Amusing how the background loop is near perfect (should have waited a few more frames I guess?)

Also what the— it seems to have gotten worse since the last time o_O

that's totally safe for work mate...also, very funny.

In a previous GameDev community contest - a 72 hour one - I was rapidly trying to add enemies to the game about halfway through the contest, just wanting to have spiky enemies slide back and force horizontally across the screen that you have to dodge.

To my delight, they started moving around in smooth but erratically swirling patterns making for a much more interesting game. I left the bug in there.

The bug was caused by me calling Rotate() on the enemies, constantly spinning them around (so they look like spinning blades), and me also calling Move(x, y) on them. I didn't realize that the API's Move() function was relative to the orientation of the enemies, and so was moving them "forward" and "sideways" of the direction they were currently oriented in. For awhile it even looked like they somehow gained collision detection (they were bouncing off walls) - though I knew that wasn't possible, because they had zero collision code! The bouncing off walls was just coincidently the time their continual rotation made them turn around, and other enemies I saw later were going through the walls.

One graphical glitch I had in a space TBS game I made was an invalid pointer accidentally replacing a planet with my game's logo - which was about three times the size of what the planet was supposed to be. The logo was already unloaded from memory too, so as a new programmer, I was really surprised. That was the first real invalid pointer error I encountered - and since it wasn't crashing the game, it was very hard for me to pinpoint what had occurred.

The greatest bug I've ever witnessed was when I was working on Sims 2 DS. We had this thief character whose getaway vehicle is a shopping cart, which is spawned some distance away from him and races toward him, he jumps in, and rides off. But due to a combination of steering code, obstacle avoidance, and high speed, the cart ended up orbiting him at a long distance, trying to turn toward him but then moving forward so it needed to turn more. Every few seconds, you'd see the cart zip past on the horizon.

Kind of funny, but what amped it up to hilarious is that it turned out it was actually getting a tiny bit closer on each lap, and about 20 minutes later it was finally making small circles around him. We all watched as it spiraled in, and he finally hopped in and rode off into the sunset.

To my delight, they started moving around in smooth but erratically swirling patterns making for a much more interesting game. I left the bug in there.

The bug was caused by me calling Rotate() on the enemies, constantly spinning them around (so they look like spinning blades), and me also calling Move(x, y) on them. I didn't realize that the API's Move() function was relative to the orientation of the enemies, and so was moving them "forward" and "sideways" of the direction they were currently oriented in. For awhile it even looked like they somehow gained collision detection (they were bouncing off walls) - though I knew that wasn't possible, because they had zero collision code! The bouncing off walls was just coincidently the time their continual rotation made them turn around, and other enemies I saw later were going through the walls.

That's awesome! It's always hard to purposely design enemy behaviors that use cumulative effects like that, but it makes surprisingly fun gameplay. Predictable enough that you can accept it was your own fault if you get hit, but not predictable enough that it's easy to dodge.

Something that so happend to me today, playing around with some alpha blending settings:

Not, I did not feed my PC acid, though it looks like it ;) This is the effect of a certain alpha blending setting, which should result in subtractive blending. Well, almost.

This is a cube.


The camera was inside it. I learned about the importance of the near plane that day.
It got better though.



Oops, range checking fail.


(Plug) Here are more screenies of its successor:
http://imageshack.us/a/img231/9179/fastbread.png
http://imageshack.us/a/img62/8483/torus.png


EDIT:
I don't remember imageshack being so hard to use...

Yay, console/"ASCII" rasterization. I like that!

I'm a little late, but here's my first 2D animation program:

This is the intended result:

If you look at the time (7:44 AM on glitch, 7:40 AM on working), I actually glitched it up after I was finished with it (must've been the pink background, holding everything together like a bro)

I'm a little late, but here's my first 2D animation program:

This is the intended result:

If you look at the time (7:44 AM on glitch, 7:40 AM on working), I actually glitched it up after I was finished with it (must've been the pink background, holding everything together like a bro)

i have serious questions on how you achieved such a glitch=-).

Taking a quick guess, the sprite was moving around without the background being erased properly.

Taking a quick guess, the sprite was moving around without the background being erased properly.

Another guess, considering the origin of the sprite, is that time travel was somehow involved.

LOL, time travel was definitely involved! Let's see if I can clone the repo at that time and see what was wrong...

UPDATE: I couldn't get the code at that period in time, but it was probably unrelated to not erasing the screen due to the way I always start projects. I'm pretty sure all of it was drawn every frame!

I tried to reproduce it editing only the settings, but I believe it may have been a bug in the code when I made the settings configurable from file. Here's the original spritesheet if you want to see it. I don't think it's possible to draw this without redrawing the image at least twice per frame, so the screen might not have been updating (although that wouldn't make too much sense because every time I update the window I clear it; it's impossible to not to with my API).

If you really want to know, check out the repo (tester working and animation working code; use history in top right to see older code; the bug happened April 10 at 7:44 AM) and figure it out yourself :)

Taking a quick guess, the sprite was moving around without the background being erased properly.

if that were true, the entire screen would be smeared, unless he teleported to random positions, rather than smoothly scrolling around, that's unlikely the reason.

I found another old screenshot (or photo on my phone...) of an early "IK" / "look at an object" system.

This is what happens when you try to accumulate relative rotations in a matrix (instead of making the matrix from scratch each frame, or renormalizing it periodically).

The matrix represents both scale and rotation in the same variables, so over time, numerical errors in the rotation accumulate and begin to affect the scale

Hilarious. I'd keep that code around. Might prove useful for some toon effect called "anabolic transformation".