Real Time Software Rendering

Lesson 5 Source Files
Resource Files

I have been banging my head against the wall trying to render floors. There’s a standard equation floating around the internet that I had previously tried using but for some reason it would just not work with the Wolf5K raycaster. The solid bright green floor in previous tutorials was the most I could get the work. If you look closely the green gets darker towards the edges of the map.

1
2
3
4
5
6
7
8
9
10
11
12
13

	for(y=l;y<s_y;y++)
	{
		currentDist = (double)s_y / (2.0 * (double)y - (double)s_y) * 64.0;
		weight = currentDist / f;
 
		currentFloorX = weight * o + (1.0 - weight) * player.x; 
		currentFloorY = weight * p + (1.0 - weight) * player.y; 
 
		floorTexX = currentFloorX - ((int)currentFloorX/64)*64.0; 
		floorTexY = currentFloorY - ((int)currentFloorY/64)*64.0; 
 
		PlotPixel(v,y,textures.get_pixel(13,floorTexX/64.0, floorTexY/64.0));
	}

Above is the floor rendering code now in use. There were two key mistakes I was making in my previous attempts. The big giant one was currentDist. The scale was wrong. currentDist was calculating the map distance. Not the pixel distance. f is the pixel distance from the camera to the wall slice that was hit. All I had to do was multiply by 64.0 and I had floors that moved the same speed as the player. One of the things I like to see in tutorials is what happens when you do it wrong. In this case, if currentDist is calculating based on a different scale than f, the floor moves way out of sync with the camera. It moves in the correct direction, it just moves significantly faster.

Now that the scale was right the second problem was the texture location. The original code was using a simple multiply and mod. That works great when you’re working with integers. You may notice the equation I use is the same format as the equation used in the wall rendering. That equation is a quick way to mod a double. It leaves you with a value between 0 and 64. We then divide by 64 to get a value between 0 and 1 which is what we use to stretch textures.

I highly recommend messing around with the floor equations because they are a big pain and I think it would help you to see what goes wrong when you start changing things around. Once I got it right I saw pretty clearly what I was doing wrong to get the various effects I was running into earlier.

In the next tutorial we’ll show how to render the ceiling and define a floor and ceiling map so we don’t have to use a single repeating texture. The grass texture is a large grass texture I found at Gamasutra.com.

The other big addition is the ability to play sound effects. Currently no fancy formats are being used, just simple wav files. You can load all the sound effects at once at the beginning and then play any number of sounds at the same time just by calling the play method with the file name. No need to keep track of numbers. The bunny object now has a sound_effect string. When that is set, the sound handler attempts to play the referenced sound effect. The sound is started every frame so make sure that sound_effect is set to null the frame after the sound effect is set. In the bunny code you will see that the sound effect is defaulted to null (not an empty string) and only set to the file name when the bunny first initializes the hop.

I’m using some basic math to adjust the volume of the sound effect based on distance from the camera. The balance is also supposed to be adjusted but that seems to not actually work. If it did, the sound effect would play mostly out of the left speaker when the bunny is to the left of you and the right speaker if the bunny is to the right of you.

All in all this a good start with sound and floors. The next tutorial will finish up the floor and ceiling rendering and maybe have some more advanced sound playing. I’d like to use Ogg but I’m not sure what is available to do that. The way the sound effect code is organized it should be rather easy to modify the sound effect loading code without affecting anything else.