What is the difference between a Sprite and a Texture?

Question

I have an assignment due for University, and my task is to discuss textures used within video games, and how they have evolved.

My main question is, what is the fundamental difference between using a sprite, or using other texture methods?

Having done a little research myself, I seem to be inclined that Sprites store images in a single file, and can be used for animations etc.. and were commonly used with older video games, generally using sprites as all of their game visuals. Now, with modern games, sprites I believe tend to be less used as technology advances and other textures are available such as bump mapping. Although sprites are still used today to accommodate features such as a health bar or long distance textures.

But what are the main advantages of using textures, over sprites?

Answer 1

At the end of the day, sprites and textures are just images - blocks of raster colour data (although sometimes we push the bounds a bit to put non-image data into them). The distinction is largely in how we use them.

We usually call an image (or a part of an image that contains many separate pieces) a "sprite" if its intended rendering purpose is to be drawn straight to the 2D grid of the screen, without perspective distortion. So what you see in the running game is basically what you see in the image file itself (apart from colour tinting/palette swapping/transparency effects). This applies to the background tiles and characters / interactive objects in 2D games, "billboard" cards like particles and older styles of tree & shrub rendering, and also to the user interface elements and icons in 3D games too.

Conversely, if we're using an image to provide surface detail for the polygons of a 3D object that might be drawn in perspective, we usually call that image a "texture." That name has carried over to other uses of image data to modulate rendering of something else, even if they're no longer about texture in the sense you could feel with your fingertips - things like reflections, distortion maps, overlays, masks, or any general-purpose use of images we don't feel like naming more specifically tends to get lumped under "texture" in our loose nomenclature.

That makes the bounds between the two fuzzy and not particularly strict. If I have an image containing a sequence of fire and smoke plumes to use in drawing billboarded particles for an explosion effect, I might call that a "spritesheet" or a "flipbook texture" interchangeably. Or if I have a tileset image comprising all the background tiles for a 2D game, I might call that a "texture atlas" today, by analogy with atlas textures developed for 3D games, even though its data and use in my 2D game is indistinguishable from what someone else would call a spritesheet. If I have a rectangle of geometry whose purpose is to present a single image to the screen, I might call that a "textured quad" or a "sprite" depending on what I want to emphasize about its use.

(Note here in this last example that "sprite" stands for both the source image segment in our game assets, and the instance of a rendered game entity that uses this image segment - another way we use this terminology a bit inconsistently)

You'll find some engines and libraries encode this distinction in rendering intent into their own nomenclature. For instance, in Unity, you can choose to import an image asset as a "Sprite" - this enables an extra set of options that are commonly desired for UI images or 2D game assets, like spritesheet slicing & packing, and the ability to reference parts of the image as discrete entities in your scene and object setup. In these cases "Sprite" often means "an image (texture) plus metadata" - but it's still rendered the same as ordinary textures under the hood. The extra packaging is a convenience so we don't need to micromanage UV offsets and the like everywhere we want to use the image; instead these frameworks conceptually pack that data in as part of the asset entity itself.

Answer 2

A sprite is a relict from the history of computer games. Think 8-bit Ataris around ca. 1980. A little image, usually with a coverage bitmask (or a special "transparent" color) that has a position on the screen and is combined onto the screen in some particular way. With holes where there be "holes" in the sprite, as per the coverage map. Usually in a "just works" way, and in a way that easily allows for the illusion of stuff moving around, usually by saving and restoring the overwritten original screen pixels.

Used to be that sprites were a hardware feature on computers, used to be you could draw/undraw them with screen contents being saved automatically, used to be you could only have a very limited number of them (and non-overlapping, yay!), and used to be that they're pretty darn small (like 16x16) and limited.

The mouse cursor is what comes closest to a sprite nowadays (and used to be it was an actual sprite on some systems until some ~10-15 years ago).

Nowadays, no such thing really exists, but the word remains. A sprite is basically a small 2D image that you draw (composite) somewhere. Usually by drawing a small textured quad.

A texture, on the other hand, is the concept of a readable image used in somewhat more modern graphics APIs. Or, more precisely, a region of memory ("buffer" in terms of modern APIs) with some associated extra data such as size, which can be sampled from via some means. Usually, but not necessarily by a shader running on a graphics processing unit. Usually, but not necessarily, with normalized coordinates, and usually but not necessarily with filtering (and mipmapping, and some particular border mode, and, and, and...).

Thus, a texture may be the source of the data what you use to draw a sprite.

Answer 3

It's sortof an apples and oranges comparison. A texture is just an image, while a sprite is an image and how it's used.

We still use sprites for 2d games, and they show up in 3d games in particle effects. Nowadays, sprites generally refer to a certain kind of textured quad, or (rarely, I think) a single triangle. Even UI elements are often still textured quads - which I would call sprites.

It used to be the case that sprites were preloaded into memory and blitted (byte-for-byte mem-copied) to points on screen (literally, screen memory), like stamps. In a way, we still do that. For sprite animations, we often alter the sample coordinates of the source texture to copy segments from textures to be rendered onto quads. Shader effects, such as bump mapping, sample from textures in the same way and thus are still usable for, say, glow effects in sprites.

More particular to 2d games, it's a stylistic choice. One could, for example, compose hand drawn or painted characters in a game using sprites. The South Park games would be an example of that, technically.

So, you can't really use just a texture in place of a sprite.

Answer 4

Here is a simple and short answer. I usually think of the sprite as the entire object itself alongside whatever functions and textures to have applied to it. As for texture, I pretty much consider it just a image that could be applied to something.