Bitmaps, Sprites and Textures: Difference between revisions
→First part: Bitmaps, Colors And Compression: Using italics instead of bold for emphasis per style guide. Please revert if I have misunderstood.
m (Mass update links) |
(→First part: Bitmaps, Colors And Compression: Using italics instead of bold for emphasis per style guide. Please revert if I have misunderstood.) |
||
| (11 intermediate revisions by 5 users not shown) | |||
Line 1:
{{
''Note: this is a WIP''
== First part:
A bitmap is the term for how computers see a picture. It's a grid of squares of various colors, used like a mosaic to form an image. Just open up any picture in an editing program (
So, each picture is formed of tiny squares (pixels). To make a picture file, the only information strictly necessary is the number of pixels in each dimension, and the "color" of which. Where it gets complicated is that there are several ways to do that, which affects two factors:
Line 14:
In its simplest form, a ''monochrome'' picture has actually two different colors: Usually black and white. If you take a black marker pen and draw on a white sheet of paper, you create such a monochrome picture. Each individual pixel can be black or white: Two possibilities, which can fit into a single bit of information. Your picture is now said to have ''one bit per pixel'', and this information is called the ''color depth''.
[[File:Amstrad CPC464.jpg|thumb|200px|Amstrad CPC464 showing yellow and blue.]]
If you are satisfied with having only two colors but want something else than black and white (like, say, [
But what if you want more than two colors? Well, a single bit can't hold that, then the solution is to use several bits for each pixel. If you decide to use ''two bits per pixel'', each pixel can now have one of four colors. Your palette will now have four entries.
Line 34 ⟶ 35:
A problem with pictures is that pictures a big. A 1024*768<ref>The size of a 15-inch screen</ref> RGB picture needs 2359296 bytes (2.25MB) just for the pixel data! And an uncompressed HD video (1920*1080) would need 5.93 MB per frame, meaning 142MB per second. A solution to that is to use compression. From there, there are two kinds of compression available:
''Lossless compression'' is compression that always preserves all the data. It's the only compression admissible for contents such as text, executable files, etc. The drawback is that there is absolutely no guarantee the data in question can be made smaller. A prime example of incompressible data is data that was already compressed. That's why if you add some GIF/JPEG/etc. pictures to a ZIP archive, you're likely to see their ''compression rate'' at 0% or 1%. That's not to say it's inappropriate for all pictures, though: Drawings with flat colors and text (think [[MS Paint]] and screenshots of office applications) benefit greatly from lossless compression. Picture formats such as GIF, PNG, and
''Lossy compression'' is compression that sacrifices some data to compress better. This is acceptable mostly for pictures and sounds (and by extension video) and relies on the eye not "minding" a few minor differences with the original pictures (unless you sacrifice too much data and ruin the picture quality). The main advantage of lossy compression is that it can be set to sacrifice juuuuust as much data as it takes to fit some mold: This is called ''fixed-rate compression''. Time-critical applications such as audio and video absolutely love it, that's how you get audio/video data at ''X kilobits per seconds'' (meaning X/8 kilobytes). Video game graphics hardware is fond of that too: e. g., the [[Nintendo
==
This article details how [[Bitmaps Colors And Compression]] are made transparent and how this is used in video game graphics.
Line 61 ⟶ 62:
* Applying the bitmap on the result with the AND operator will make it so: "0101010000110101".
* Success!
This technique is still used in Windows icons and cursors,<ref>A quirk in how the monochrome icons worked allowed for ''four'' possibilities: Black, white, transparent and ''invert''.</ref> though Windows XP and higher allow the use of Alpha blending instead.
Line 91:
Without compression, it's a matter of carefully choosing between space and detail. With compression, there is a lot more leeway. The most common form of compression is to drop data for squares the same color as another. So if you have 100 brick red squares, the file will just count one (but put the others back when the file is visualized).
With "lossless" compression,
With "lossy" compression, they don't have to be exact, but it does mean the exact color is lost, and detail isn't as fine. But with higher color depth files, it's the best way to get the picture to a reasonable size. If you were wondering what a jpg (or jpeg, which is the same thing) is, it's a lossy compression format.
Line 105:
[[The Law of Conservation of Detail|The size of the area, and the number of enemies, affects how much detail the player character will have]]. If you have a game like ''[[Castlevania]]'', the detail of Simon Belmont is pretty low. Since you have large areas with a lot of enemies, each enemy is not that detailed. If the game is ''[[Street Fighter]] II'', you just have two characters, and a background barely two screens wide (anyone in the background is just part of that picture). So you have tons of detail in all of those.
When it comes to 3D graphics, it's a lot more complicated. You not only have textures over the polygon objects, but shading and mapping to add further depth to the textures, and effects like shadows and lighting - e.g. bump map adds shallow "relief" over flat surfaces, which allows to increase amount of visual details that don't ''look'' just painted on cardboard while keeping polygon count low.
Those will be covered in their own pages.
{{reflist}}
[[Category:Bitmaps, Sprites
[[Category:
| |||