Hi all! I have a question about the best way to structure a game object comprised of multiple modular sprites.
I have a base spritesheet that is animated frame-by-frame via a script. I also have several optional spritesheets, with the same animation frames, that should be drawn over the base sprite. Each is a different hairstyle or outfit that characters in my app might have. Because of the frame size of these animations, all these sprites cannot fit in one atlas (it’s not a pixel art style). Spine isn’t an option because the animations are drawn traditionally.
What would be the best way (for performance, ease of modification in the future, and general ‘best-practiceness’…) to unify all of these atlases into sprite objects inside a go or collection so that I could write a simple function – – that will them toggle on or off?
The approaches I’ve considered so far are:
- Include a different sprite component for each atlas – hair1, hair2, hair3 etc – inside the main character go/collection, then enable or disable them in
- Make gameobjects for each individual hair and outfit style, then create a factory for each inside the main character go/collection. Use on the appropriate hair and outfit factories for the desired hair, outfit, etc.
- Maybe there are other options I’m not experienced enough to know about!
I found a few oldthreads that have similar questions, but no definitive answer that fits my situation 100%. I’m a little hesitant to move forward since it will be a lot of setup work, so I want to make sure I’m headed down the right path first! Any advice will really be appreciated
2 LikesSours: https://forum.defold.com/t/best-way-to-organize-modular-character-sprite-sheets-solved/65920
Sprite (computer graphics)
For the technique of combining images into a single bitmap, see texture atlas.
For the process of drawing sprites, see pixel art.
A 2D bitmap displayed on top of a larger scene
In computer graphics, a sprite is a two-dimensionalbitmap that is integrated into a larger scene, most often in a 2D video game. Originally, the term sprite referred to fixed-sized objects composited together, by hardware, with a background. Use of the term has since become more general.
Systems with hardware sprites include arcade video games of the 1970s and 1980s; game consoles such as the Atari VCS (1977), ColecoVision (1982), Nintendo Entertainment System (1983), and Sega Genesis (1988); and home computers such as the Texas Instruments TI-99/4A (1979), Atari 8-bit family (1979), Commodore 64 (1982), MSX (1983), Amiga (1985), and X68000 (1987). Hardware varies in the number of sprites supported, the size and colors of each sprite, and special effects such as scaling or reporting pixel-precise overlap.
Hardware composition of sprites occurs as each scan line is prepared for the video output device, such as a CRT, without involvement of the main CPU and without the need for a full-screen frame buffer. Sprites can be positioned or altered by setting attributes used during the hardware composition process. The number of sprites which can be displayed per scan line is often lower than the total number of sprites a system supports. For example, the Texas Instruments TMS9918 chip supports 32 sprites, but only 4 can appear on the same scan line.
The CPUs in modern computers, video game consoles, and mobile devices are fast enough that bitmaps can be drawn into a frame buffer without special hardware assistance. Alternatively, modern GPUs can render vast numbers of scaled, rotated, antialiased, and partially translucent images in parallel with the CPU.
The use of sprites originated with arcade video games. Nolan Bushnell came up with the original concept when he developed the first arcade video game, Computer Space (1971). Technical limitations made it difficult to adapt the early mainframe gameSpacewar! (1962), which performed an entire screen refresh for every little movement, so he came up with a solution to the problem: controlling each individual game element with a dedicated transistor. The rockets were essentially hardwired bitmaps that moved around the screen independently of the background, an important innovation that allowed screen images to be produced more efficiently and providing the basis for sprite graphics.
The earliest video games to represent player characters as human player sprites were arcade sports video games, dating back to Taito's TV Basketball, released in April 1974 and licensed to Midway Manufacturing for release in North America. Designed by Tomohiro Nishikado, he wanted to move beyond simple Pong-style rectangles to character graphics, by rearranging the rectangle shapes into objects that look like basketball players and basketball hoops.Ramtek later released another sports video game in October 1974, Baseball, which similarly displayed human-like characters.
The Namco Galaxianarcade system board, for the 1979 arcade game Galaxian, featured animated, multi-colored sprites. It used a custom sprite system that animated pre-loaded sprites over a scrolling background, which became the basis for Nintendo's Radar Scope and Donkey Kong arcade hardware and home consoles such as the Nintendo Entertainment System. According to Steve Golson from General Computer Corporation, the term "stamp" was used instead of "sprite" at the time.
Signetics devised the first chips capable of generating sprite graphics (referred to as objects by Signetics) for home systems. The Signetics 2636 video processors were first used in the 1978 1292 Advanced Programmable Video System and later in the 1979 Elektor TV Games Computer.
The Atari VCS, released in 1977, features a hardware sprite implementation where five graphical objects can be moved independently of the game playfield. The term sprite was not in use at the time. The VCS's sprites are called movable objects in the programming manual, further identified as two players, two missiles, and one ball. These each consist of a single row of pixels that are displayed on a scan line. To produce a two-dimensional shape, the sprite's single-row bitmap is altered by software from one scan line to the next.
The 1979 Atari 400 and 800 home computers feature similar, but more elaborate, circuitry capable of moving eight single-color objects per scan line: four 8-bit wide players and four 2-bit wide missiles. Each is the full height of the display—a long, thin strip. DMA from a table in memory automatically sets the graphics pattern registers for each scan line. Hardware registers control the horizontal position of each player and missile. Vertical motion is achieved by moving the bitmap data within a player or missile's strip. The feature was called player/missile graphics by Atari.
The term sprite was first used in the graphic sense by one of the definers of the Texas Instruments9918(A) video display processor (VDP). The term was first used by Danny Hillis at Texas Instruments in the late 1970s. The term was derived from the fact that sprites, rather than being part of the bitmap data in the framebuffer, instead "floated" around on top without affecting the data in the framebuffer below, much like a ghost or "sprite". By this time, sprites had advanced to the point where complete two-dimensional shapes could be moved around the screen horizontally and vertically with minimal software overhead.
Systems with hardware sprites
These are base hardware specs and do not include additional programming techniques, such as using raster interrupts to repurpose sprites mid-frame.
|Computer system||Sprite hardware||Year||Sprites on screen||Sprites on line||Max. texels on line||Texture width||Texture height||Colors||Hardware zoom||Rotation||Background||Collision detection||Transparency||Source|
|Amstrad Plus||1990||16||16||?||16||16||15||1, 2, 4× vertical, 1, 2, 4× horizontal||No||1 bitmap layer||No||Color key|||
|Atari 2600||TIA||1977||5||5||19||1, 8||262||1||1, 2, 4, 8× horizontal||Horizontal mirroring||1 bitmap layer||Yes||Color key|||
|Atari 8-bit family||GTIA/ANTIC||1979||8||8||40||2, 8||128, 256||1||1, 2× vertical, 1, 2, 4× horizontal||No||1 tile or bitmap layer||Yes||Color key|||
|Commodore 64||VIC-II||1982||8||8||96, 192||12, 24||21||1, 3||1, 2× integer||No||1 tile or bitmap layer||Yes||Color key|||
|Amiga (OCS)||Denise||1985||Arbitrary||8||128||16||Arbitrary||3, 15||Vertical by display list||No||2 bitmap layers||Yes||Color key|||
|Amiga (AGA)||Lisa||1992||Arbitrary||8||512||16, 32, 64||Arbitrary||3, 15||Vertical by display list||No||2 bitmap layers||Yes||Color key|
|Colecovision||Texas Instruments TMS9918A||1983||32||4||64||8, 16||8, 16||1||1, 2× integer||No||1 tile layer||Partial||Color key|
|Texas Instruments TI-99/4A||Texas Instruments TMS9918A||1981||32||4||64||8, 16||8, 16||1||1, 2× integer||No||1 tile layer||Partial||Color key|
|Gameduino||2011||256||96||1,536||16||16||255||No||Yes||1 tile layer||Yes||Color key|||
|Intellivision||STIC AY-3-8900||1979||8||8||64||8||8,16||1||1, 2, 4, 8× vertical, 1, 2× horizontal||Horizontal and vertical mirroring||1 tile layer||Yes||Color key|||
|MSX||Texas Instruments TMS9918A||1983||32||4||64||8, 16||8, 16||1||1, 2× integer||No||1 tile layer||Partial||Color key|||
|MSX2||Yamaha V9938||1986||32||8||128||8, 16||8,16||1, 3, 7, 15 per line||1, 2× integer||No||1 tile or bitmap layer||Partial||Color key|
|MSX2+ / MSX turbo R||Yamaha V9958||1988||32||8||128||8,16||8,16||1, 3, 7, 15 per line||1, 2× integer||No||1 tile or bitmap layer||Partial||Color key|
|TTL||1980||6||6||96||16||16||3||No||Horizontal and vertical mirroring||1 tile layer||No||Color key|||
|TurboGrafx-16||HuC6270A||1987||64||16||256||16, 32||16, 32, 64||15||No||No||1 tile layer||Yes||Color key|
|TTL||1979||7||7||112||16||16||3||No||Horizontal and vertical mirroring||1 tile layer||No||Color key|||
|NintendoDonkey Kong, Radar Scope|
|1979||128||16||256||16||16||3||Integer||No||1 tile layer||Yes||Color key|||
|Nintendo DS||Integrated PPU||2004||128||128||1,210||8, 16, 32, 64||8, 16, 32, 64||65,536||Yes, affine||Yes, affine||4 layers per screen; each layer is independent||No||Color key, blending|||
|NES/Famicom||RicohRP2C0x PPU||1983||64||8||64||8||8, 16||3||No||Horizontal and vertical mirroring||1 tile layer||Partial||Color key|||
|Game Boy||Integrated PPU||1989||40||10||80||8||8, 16||3||No||Horizontal and vertical mirroring||1 tile layer||No||Color key|||
|Game Boy Advance||Integrated PPU||2001||128||128||1210||8, 16, 32, 64||8, 16, 32, 64||15, 255||Yes, affine||Yes, affine||4 layers, 2 layers, and 1 affine layer, 2 affine layers||No||Color key, blending|||
|1985||64||8||128||8, 16||8, 16||15||1, 2× integer, 1, 2× vertical||Background tile mirroring||1 tile layer||Yes||Color key|||
|Sega Genesis||YM7101 VDP|
|1988||80||20||320||8, 16, 24, 32||8, 16, 24, 32||15||No||Horizontal and vertical mirroring||2 tile layers||Yes||Color key|||
|Sega OutRun (arcade)||1986||128||128||1600||8 to 512||8 to 256||15||Yes, anisotropic||Horizontal and vertical mirroring||2 tile layers and 1 bitmap layer||Yes||Alpha|||
|Sharp X68000||Cynthia jr. (original), Cynthia (later models)||1987||128||32||512||16||16||15||1, 2× integer||Horizontal and vertical mirroring||1-2 tile layers and 1-4 bitmap layers||Partial||Color key|||
|Neo Geo||LSPC2-A2||1990||384||96||1536||16||16 to 512||15||Sprite shrinking||Horizontal and vertical mirroring||1 tile layer||Partial||Color key|||
|S-PPU1, S-PPU2||1990||128||34||272||8, 16, 32, 64||8, 16, 32, 64||15||Background only||Horizontal and vertical mirroring||3 tile layers or 1 affine mapped tile layer||Yes||Color key, averaging|
|Computer system||Sprite hardware||Year||Sprites on screen||Sprites on line||Max. texels on line||Texture width||Texture height||Colors||Hardware zoom||Rotation||Background||Collision detection||Transparency||Source|
Some hardware manufacturers used different terms, especially before sprite became common.
Player/Missile Graphics was a term used by Atari, Inc. for hardware sprites in the Atari 8-bit computers (1979) and Atari 5200 console (1982). The term reflects the use for both characters ("players") and smaller associated objects ("missiles") that share the same color. The earlier Atari Video Computer System and some Atari arcade games also used player, missile, and ball for sprites.
Stamp was used in some arcade hardware in the early 1980s, including Ms. Pac-Man.
Movable Object Block, or MOB, was used in MOS Technology's graphics chip literature. Commodore, the main user of MOS chips and the owner of MOS for most of the chip maker's lifetime, used the term sprite for the Commodore 64.
OBJs (short for objects) is used in the developer manuals for the NES, Super NES, and Game Boy. The region of RAM used to store sprite attributes and coordinates is OAM (Object Attribute Memory). This also applies to the Game Boy Advance and Nintendo DS.
- ^ abHague, James. "Why Do Dedicated Game Consoles Exist?". Programming in the 21st Century.
- ^Swalwell, Melanie; Wilson, Jason (12 May 2015). The Pleasures of Computer Gaming: Essays on Cultural History, Theory and Aesthetics. McFarland & Company. pp. 109–10. ISBN .
- ^Colby, Richard; Johnson, Matthew S. S.; Colby, Rebekah Shultz (27 January 2021). The Ethics of Playing, Researching, and Teaching Games in the Writing Classroom. Springer Nature. p. 130. ISBN .
- ^Video Game Firsts, The Golden Age Arcade Historian (November 22, 2013)
- ^Basketball Flyer (1974), Arcade Flyer Museum
- ^ abAkagi, Masumi (13 October 2006). アーケードTVゲームリスト国内•海外編(1971-2005) [Arcade TV Game List: Domestic • Overseas Edition (1971-2005)] (in Japanese). Japan: Amusement News Agency. pp. 40–1, 51, 129. ISBN .
- ^Smith, Alexander (19 November 2019). They Create Worlds: The Story of the People and Companies That Shaped the Video Game Industry, Vol. I: 1971-1982. CRC Press. pp. 191–95. ISBN .
- ^"スペースインベーダー・今明かす開発秘話――開発者・西角友宏氏、タイトー・和田洋一社長対談" [Space Invader, Development Secret Story Revealed Now―Interview With Developer Tomohiro Nishikado, Taito President Yoichi Wada]. The Nikkei (in Japanese). March 21, 2008. Archived from the original on March 23, 2008. Retrieved 3 May 2021. Lay summary.
- ^Thorpe, Nick (March 2014). "The 70s: The Genesis of an Industry". Retro Gamer. No. 127. pp. 24–7.
- ^Dillon, Roberto (19 April 2016). The Golden Age of Video Games: The Birth of a Multibillion Dollar Industry. CRC Press. ISBN – via Google Books.
- ^Making the Famicom a Reality, Nikkei Electronics (September 12, 1994)
- ^ abSteve Golson (2016). Classic Game Postmortem: 'Ms. Pac-Man' (Conference). Game Developers Conference. Event occurs at 20:30. Retrieved 2017-01-26.
- ^Wright, Steve (December 3, 1979). "Stella Programmer's Guide"(PDF).
- ^"Karl Guttag Conference on Delphi TI Net - comp.sys.ti | Google Groups". Retrieved 2009-11-29.
- ^Johnstone, Bob (2003). Never Mind the Laptops: Kids, Computers, and the Transformation of Learning. p. 108. ISBN .
- ^"Plus - CPCWiki". Cpcwiki.eu. Retrieved 2009-11-29.
- ^"Television Interface Adaptor". AtariArchives.com. Retrieved 2011-02-06.
- ^"Atari 5200 FAQ - Hardware Overview". AtariHQ.com. Retrieved 2011-02-06.
- ^"The MOS 6567/6569 video controller (VIC-II) and its application in the Commodore 64". Archived from the original on August 30, 2006. Retrieved 2006-01-08.CS1 maint: bot: original URL status unknown (link)
- ^"Amiga Hardware Reference Manual 4: sprite hardware". 1989.
- ^"Gameduino Specifications". excamera.com.
- ^"STIC - Intellivision Wiki". wiki.intellivision.us. Retrieved 15 March 2018.
- ^TEXAS INSTRUMENTS 9900: TMS9918A/TMS9928AITMS9929A Video Display Processors(PDF). Retrieved 2011-07-05.
- ^Montfort, Nick; Bogost, Ian (9 January 2009). Racing the Beam: The Atari Video Computer System. MIT Press. ISBN – via Google Books.
- ^"Galaxian-derived video hardware". GitHub. MAME. Retrieved October 23, 2018.
- ^"Galaxian-derived hardware". GitHub. MAME. Retrieved October 23, 2018.
- ^"Galaxian hardware family". GitHub. MAME. Retrieved October 23, 2018.
- ^Nathan Altice (2015), I Am Error: The Nintendo Family Computer / Entertainment System Platform, pages 53 & 69, MIT Press
- ^"Specifications". Nocash.emubase.de. Archived from the original on 2009-06-21. Retrieved 2009-11-29.
- ^"Microsoft Word - NESDoc.doc"(PDF). Retrieved 2009-11-29.
- ^"GameBoy - Spielkonsolen Online Lexikon". At-mix.de. 2004-06-22. Retrieved 2009-11-29.
- ^"Specifications". Nocash.emubase.de. Archived from the original on 2009-06-21. Retrieved 2009-11-29.
- ^Charles MacDonald. "Sega Master System VDP documentation". Archived from the original on 2014-03-18. Retrieved 2011-07-05.
- ^"Sega Master System Technical Information"(TXT). Smspower.org. Retrieved 2016-11-28.
- ^"Sega Programming FAQ October 18, 1995, Sixth Edition - Final". Archived from the original on January 22, 2005. Retrieved 2015-12-10.
- ^Staff, Polygon (2015-02-03). "How Sega built the Genesis". Polygon. Retrieved 2016-11-28.
- ^"Sega Out Run Hardware (Sega)". System 16. 2016-03-31. Retrieved 2016-11-28.
- ^"mame/segaorun.c at master · mamedev/mame · GitHub". github.com. 21 November 2014. Archived from the original on 21 November 2014. Retrieved 15 March 2018.
- ^"Out Run". 2001-02-27. Archived from the original on 2001-02-27. Retrieved 2016-11-28.
- ^"Out Run Hardware (Sega)". System 16. Retrieved 2009-11-29.
- ^"Version 0.3 - 7th February 1998". Coinop.org. Retrieved 2016-11-28.
- ^"Archived copy". Archived from the original on 2016-01-25. Retrieved 2016-02-09.CS1 maint: archived copy as title (link)
- ^"Sega "X-Board" hardware notes". Archived from the original(TXT) on 2014-03-18. Retrieved 2016-11-28.
- ^"X68000-Computer Museum". Museum.ipsj.or.jp. Retrieved 2016-11-28.
- ^"mame/x68k.c at master · mamedev/mame · GitHub". github.com. 21 November 2014. Archived from the original on 21 November 2014. Retrieved 15 March 2018.
- ^Yoshida, Koichi (12 September 2001). "超連射68K 開発後記". Yosshin's web page (in Japanese). Archived from the original on 12 May 2019. Retrieved 2016-11-28. (Translation by Shmuplations. Archived 2019-07-02 at the Wayback Machine).
- ^"Neo-Geo MVS Hardware Notes"(TXT). Furrtek.free.fr. Retrieved 2016-11-28.
- ^"Neo-Geo Programming Manual"(PDF). Furrtek.free.fr. Retrieved 2016-11-28.
- ^"Big List of Debug Dipswitches". Neo-Geo. 2014-07-09. Retrieved 2016-11-28.
- ^"De Re Atari". 1981.
- Hp support assistant download for windows 10
- Rebuilt atv engines
- Hanover college psychology department
- Colon cleanse poop pictures
- Average cpa salary
If you grew up in the 1980s playing 8-bit and 16-bit games such as Mario or Sonic, you might be familiar with their unique visual style. Which consisted of pixelated graphics and the usage of graphical tricks like “parallax scrolling” to provide an illusion of depth in what were otherwise simple 2D side scrollers.
The pixelated characters you saw on your TV screen were comprised of 2D bitmaps known as “sprites”. But sprites aren’t a forgotten technology of the past, which disappeared after the appearance of 3D models.
In fact, they are extremely popular in many of the 2D indie/ retro games you can play today. The methods by which sprites are drawn and animated have changed, but sprites themselves are still here. And if you’re interested in becoming an indie dev, you might want to check out how sprites are designed.
So, what are sprites? Sprites are two-dimensional images or animations overlaid into a scene. They are the non-static elements within a 2D game, moving independently of the background. Often used to represent player-controlled characters, props, enemy units, etc., sprites can be composed of multiple tiles or smaller sprites. They can also be used for pseudo-3D sprite scaling like in Super Scaler, Mode 7, or in pre-rendered movement. More recently, sprites are also being used in web design (like the CSS sprites which combine lots of small images into one sheet to improve web page load times).
Most home consoles back in the day were severely limited in terms of memory size and speed because RAM was so expensive. This meant that developers had to execute some really ingenious strategies to create these awesome gaming experiences.
Only a certain number of sprites could be displayed on-screen at any given time, and the main character’s sprites were often composed of multiple tiles.
Large bosses would take up all the tile budget, so developers reduced the tile cost by only using sprites for certain sections of the boss’s body (like wings) and creating the rest of the body from the game background itself.
This is why certain games would turn the entire background black during a boss fight to hide the fact that most of the boss is actually part of the background itself. They would scroll the background to make the boss move, a trick used in games like Mega Man.
In this article, we shall take a look at the history of sprites and the role they play in gaming today. We shall give you a basic idea of how sprites are animated, along with the reasoning behind the usage of sprite sheets to enhance performance.
The History Of Sprites In Gaming
It should come as no surprise that the very first sprites in gaming were used in arcades. But not until the mid-70s, which saw the first instance of sprites being used within a game when Taito released “Basketball” in 1974.
Initially launched in Japan, it was imported to America under the name “TV Basketball”. The first recorded instance of humans being represented in a video game, TV Basketball had a total of 6 sprites- 4 basketball players and 2 baskets.
Then came Speed Race, in the same year (1974). It took things a step further by implementing sprites with collision detection. This 2D game featured pixelated race cars moving along a vertically scrolling track. Later in 1977, the Taito Z80 arcade game board came out along with the game “Super Speed Race”.
Now you had support for up to 16 sprites via hardware, with the ability to display up to 4 sprites per scanline. Each sprite could be as large as 32 pixels, containing as many as 15 colors.
In the 1980s, pseudo- 3D graphics were implemented through sprite scaling which is an early form of texture mapping. Using this technique, developers would scale each line of pixels by a different factor, to provide the illusion of 3D.
They would also rotate the background in combination with scaling sprites to further enhance the optical illusion. After Burner, a flight game released for the Sega X in 1987 is a great example. Most of the early games that used sprite scaling were racers, like F-zero for the SNES (1990).
Moving on into the modern era of gaming, 2D sprites were often used within 3D environments to cut down on resource utilization. Billboarding is one such instance, in which objects that always face the camera are constructed with sprites to fool the player into thinking that it is 3D.
It is also a form of sprite scaling and was used to render objects like trees in early 3D games. Very rare in modern 3D games, but still found in low budget titles when stuff like smoke or foliage needs to be shown. Xenoblade chronicles and Catacomb 3-D are examples of modern games using sprites in this fashion.
How Sprites Are Drawn
Traditionally, there have been two main methods we use to draw sprites- Buffering/ Blitting, and Hardware sprites. Using the buffering tactic, a CPU or dedicated graphics processor chip will modify a frame-buffer held in RAM.
Sprites are processed through a display list, the background behind moving objects being constantly refreshed. Double buffering is required to prevent flickering and tearing, but the main advantage of this technique is that you can have more moving objects with higher complexity (larger sprites for example).
The downside? It requires a fast CPU or GPU, along with a high amount of RAM (back then 16KB was considered a lot of memory). In the 1980s, only arcades could afford to use this method since home consoles had limited processing power.
The second method of drawing sprites doesn’t use bitmap data from the frame buffer. Instead, it floats the sprites on top of the background. Much like a ghost, which is where the term sprite may have come from.
Using the hardware method you are reducing the processing power needed, which is why home consoles implemented this technique. But it also places severe restrictions on how many moving objects you can have on the screen at any given time.
Which forced developers to change render priority of sprites in real time, causing the distinct flickering effect that you see in many of the old console games. The Nintendo Entertainment System (NES) and Sega Genesis used this technique.
These days, computers and consoles have grown powerful enough to draw large high-resolution sprites. We have plenty of memory, really fast CPUs, and dedicated GPUs to handle hundreds of sprites within a single scene.
Artists back in the day would draw sprites pixel by pixel, using colored graph paper and custom-built hardware like the Sega Digitizer System. Now we have Photoshop, tablets, Unity, and various other tools to create sprites.
Some artists scan in hand-drawn artwork and trace it over to software. And not all sprites have to look pixelated unless you’re going for that retro look. One trick is to draw images at a high resolution and scale it down.
Krita and Gimp are popular tools for creating sprites, some developers will also create the graphics in 3D and convert them into 2D.
How Animating Sprites is Done?
We have talked about how sprites are non-static objects which can move independently of the game background. But it would be really weird if your protagonist just skied along the terrain without moving any arms or legs, like an inanimate object.
To breathe some life into your sprites, you’ll have to “animate” them. There are many ways to do this, and several tools which will give you different results with varying degrees of smoothness and detail. The most basic way to animate something is by showing multiple images in quick succession to create the illusion of motion, like movies.
Game developers often use sprite sheets for animation, by rendering different images contained within a single sheet in the correct order. The sprite sheet contains two parts- frames and cycles.
Say you have a character walking, there will be different images on the same sheet of the character with their limbs in different positions. A cycle refers to the activity that your character is doing, i.e. walking cycle, running cycle, attacking cycle, etc. Each cycle is composed of various images.
The more “samples” you have per cycle, the smoother your animation will be (and also consume more resources). You can get by with as few as 3 different sprites per cycle, like for idle animation when your character is just standing around (works in retro games with pixelated art design).
There are some basic rules to follow in order to create good looking animation. You need to make sure that your characters never feel stiff. The character needs to feel like it is moving even when standing still. Make things bouncy and try to animate hair or clothes blowing in the wind.
Give your characters facial expressions, which brings in some personality. Another really helpful tip is limiting the number of frames. This may seem counterintuitive at first, since more frames = smoother animation. But too many frames will reduce the impact of your character’s movement, over-flourishing the end product.
They will also spoil the timing and tone of your character. Finally, make sure that your animation has really good keyframes and silhouettes. Test stuff against a white background to ensure that you can read the movements easily.
If you are looking for assets for your game you can check out my post Best 21 Sites To Download Amazing Game Assets For Free
The Importance Of Using Sprite Sheets
A sprite sheet combines multiple sprites into one single image file. This improves performance significantly, by reducing the draw calls. Perhaps the strongest case supporting the usage of sprite sheets is all the rendering time you’ll save on textures.
Say you’ve got 60 textures for 60 different objects on the same sprite sheet, all of these objects can be drawn in one single draw call. With individual sprites, your graphics processor would have to do a lot more work preparing each sprite before drawing. It’s usually faster to draw 200 objects as part of one large sprite sheet than to draw one sprite 200 times.
Let’s explain this in simpler terms. Imagine the graphics API for your game is an artist, in our example it is OpenGL. So, OpenGL will paint a game scene by taking data from the frame buffer. Your game code will tell OpenGL what to draw, and where.
It will give OpenGL 3 important bits of info- which sprite to choose, what part of the sprite to draw, and finally the location on the scene where the sprite has to be drawn. The game will then wait till the sprite has been drawn, after which new commands will be processed. The faster these sprites are drawn, the higher your framerate.
This method of doing sprites one by one results in plenty of communication overhead. Instead, we could use a sprite sheet which contains all the sprites in one place. And an additional module called the sprite atlas. There is a list of source coordinates telling OpenGL which sprites to copy, and a list of destination coordinates telling OpenGL where on the display to draw them.
Now all the sprites within the scene can be handled with much fewer instructions, which gives our game time to do other stuff like handle player input or calculate collisions.
Reducing Memory Usage:
Now let’s take a look at how sprite sheets can help you save on memory usage. Say you’ve got a side-scrolling adventure game, and one of the scenes is made from several movable objects- trees, flowers, birds, animals, and the main character.
These movable 2D objects are made of sprites. And a sprite is typically represented as a rectangular image with a certain width and height, measured in pixels. In our case, let’s assume the main character’s sprite is 100 pixels tall by 100 pixels wide. Combine that with a color depth of 32 bits, and we get a total memory requirement of (32 bits/8) x 100 x 100 = 40kB. We divided 32bits by 8, since 8 bits= 1 byte.
And the result in bytes is divided by 1000 to give us kB. Here’s the deal- your graphics hardware is only going to support specific sprite sizes. This means that a sprite will often be padded with filler pixels to support hardware constraints. So your nice little 40 x 40 pixels might end up turning into a 256 x 256 pixel square sprite which takes up a lot more memory (over 256kB compared to 40kB previously).
Still not that big of a deal since modern hardware like an iPhone X or Galaxy S10 has plenty of RAM to go around. But games have several dozen sprites within each scene, ranging from characters and props to buildings and vehicles.
All of this adds up fast, and you end up wasting resources for no reason. A sprite sheet alleviates most of these problems by packing additional sprites into the wasted filler space. You now have a single unit- the sprite sheet, instead of bloated individual sprites.
Things are compressed further by removing transparent bits from the sprites. You can even reduce the color depth from 32 to 16 bits and make up for the loss in color accuracy by applying dithering.
You will need some specialized tools to create your own sprite sheet, here are a few- Texture Packer, ShoeBox, Zwoptex, and Sprite Sheet Packer. Or if you’re using Unity to develop your game, there are built-in features to assist you with the creation of sprite sheets (Sprite Editor).
Sprites are an indispensable tool when it comes to designing 2D indie games and retro games. They can be implemented in various game genres such as sidescrollers, platformers, 2D RPGs, and fighting games. A lot of web games that you play in the browser use sprites.
Learning how to create and use them will help you significantly on the path to becoming a professional game developer. There are plenty of online resources to help you along. Hopefully, our article provided a good general overview of what to expect.
There are websites where you can download free graphics assets, including sprite sheets- kenney.nl, OpenGameArt.Org, itch.io, etc.
Sheet character sprite
.How to make a Sprite Sheet in Photoshop? Learn how to make Sprite Sheets for your Unity game!
You will also like:
- Vitus bicycles
- Standard photocard size in inches
- Glass mirror strips
- Cyclone separator diy
- So funny crossword
- Pressure mount gates
- Apron sayings svg
- Novant sleep
- 2004 f150 flatbed