Game Development Reference
In-Depth Information
I_Error("S_SetMusicVolume: Attempt to set music volume at %d", volume);
// JNI Changes: Send a volume request to Java
// volume = [0..100]
jni_set_music_volume (volume);
I_SetMusicVolume(volume);
snd_MusicVolume = volume;
}
Video Buffer Changes
Here is where the toughest changes must be done. The file
i_video.c
is the one that renders the video
buffer and uses SDL heavily. All SDL references must be removed and replaced with structures
compatible with Android.
Down to the pipe, a video buffer is simply an array of packed colors, represented as either bytes
indicating the index of a color in a color palette or integers specifying an RGB color. SDL uses a structure
called
SDL_Surface
to encapsulate the video buffer as an array of bytes plus a palette used to map colors
to the buffer. Consider the next fragment, which replaces the SDL screen with a similar structure called
XImage
(actually taken from the X11 structure of the same name).
static SDL_Surface *screen; // OLD CODE
static XImage * image; // NEW CODE
In Doom,
SDL_Surface
will be replaced with the equivalent
XImage
that holds the array of bytes for
the video buffer. Note that the video buffer cannot be rendered directly to a display. Instead, it must be
cascaded back to Java using the C to Java callbacks, where Android will take care of the actual rendering.
Because
XImage
doesn't exist, it must be written. This isn't difficult, as
XImage
is simply a C struct
holding the width, height, and array of bytes for the video buffer, as shown in Listing 7-22.
Listing 7-22.
Video Buffer Image Object from i_video.c
/**********************************************************
* Class XImage
**********************************************************/
typedef struct Image XImage;
struct Image
{
int width;
int height;
byte * data;
};
/**
* Class Color
*/
typedef struct Color XColor;
struct Color