 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : CMM2: Creating Sprite Sheets
| Author | Message | ||||
vegipete Guru  Joined: 29/01/2013 Location: CanadaPosts: 1132 |
Creating Sprite Sheets Many programs, games in particular, benefit from detailed graphic shapes. Simple shapes can be drawn with drawing primitives, such as LINE, BOX, CIRLE and PIXEL, but this is not a practical method of generating more intricate ones. Enter the sprite sheet! A sprite sheet is simply an image containing a whole bunch of shapes, packed together in whatever pattern is practical. The entire image, or sheet, is loaded into memory, and sections of the image can either be turned into sprites or copied onto the screen with a BLIT command. PNG files are a good choice for the CMM2 computer. To keep things simple, a sprite sheet should be no larger than the screen resolution being used. Smaller is fine. This allows the sprite sheet (or many of them) to be loaded into extra display pages. Here is the sprite sheet I created for the game "RocksinSpace":  Note there are various different sizes of shape, and while the shapes are organized in patterns to some degree, there is no single rule to extract any particular shape. The key to using the shapes is knowing where each is actually located on the sprite sheet. This is determined when the sprite sheet is created. A pixel based paint program is the best tool for this job, although I also use other types of drawing programs (including CAD) along with screen captures to generate the shapes. My paint program of choice is Paint.Net on Windows. This program has a nice set of features plus many plug-ins have been written to extend its capabilities. A bit of thought goes into placing the shapes as they are created. Using the Rocks in Space sheet, we can see that the first large asteroid is located at (0,0) with size 64x64. This pattern is repeated for the next 3, every 64 pixels to the right. This allows the 4 large asteroids to be extracted mathematically, starting from the base location of (0,0)  Knowing where the large asteroids are, the two rows of player ship can be added. The base location is (0,64). Remember, the large rock is 64 pixels, from 0 to 63. Each player ship is in a 32x32 pixel box. The use of a fixed pattern makes the individual shapes easy to extract mathematically.  Similarly, all remaining shapes are added to the sprite sheet, and the locations are noted. Usually I have the sheet open in the paint program as I am writing the code that will use the shapes. That way, I can quickly put a selection box around the shape of interest to ensure I know exactly where it is. When the sprite sheet is complete, it can be saved as a PNG image file. To use it, the MMBasic program needs to load the sheet to an otherwise unused page. It is not necessary to ever actually show the sprite sheet on screen. Rocks in Space uses the following: ' load sprite sheet page write 3 : cls load png "grayscaleRocks2.png" Then, for example, large rocks can placed on screen with ' draw big asteroids In this case, 'an' holds the rock number, 0 to 3, so (an*64,0) calculates theblit an*64,0, ast(i,1),ast(i,2), 64,64,3,4 top left corner of the desired shape. The ast() array gives the location to draw the shape, the size is 64x64 and the source is page 3. (The last parameter indicates to treat black as transparent.) Using the shapes as sprites works much the same. The SPRITE READ command is used to pull display areas into particular sprite numbers. Don't forget to specify the correct page to read from. As far as creating the shapes themselves goes, that is up to your creativity. For example, many of the shapes for Rocks in Space were created mathematically on the CMM2 and saved as a BMP image. The BMP was then loaded into Paint.net for manipulation and adding to the sprite sheet. However, even the CMM2 was used for some image manipulation - much of the anti-aliasing was actually done on the CMM2. As a closing note, a CMM2 paint program would allow this sort of work to be done entirely on the CMM2. Perhaps in time, someone will create such a program. Visit Vegipete's *Mite Library for cool programs. |
||||
| mclout999 Guru Joined: 05/07/2020 Location: United StatesPosts: 490 |
This is a very nice primer on Sprite sheets. It is worthy of inclusion in the manual or the graphic programming PDF. I feel I understand this subject better now than I ever have. I am going to append it to my programming graphics PDF. Edited 2021-02-17 05:39 by mclout999 |
||||
RetroJoe Senior Member  Joined: 06/08/2020 Location: CanadaPosts: 290 |
Vegipete, this is EXACTLY what I was looking for - thanks VERY much !! Quick Question: assuming square sprites are the normal convention (i.e. 64x64, 32x32, 16x16 and 8x8), would it make sense to put all sprites of the same size on their own sprite sheet? That way, the "math" to get at any particular image would be really simple, as they would always be even multiples in both the X and Y direction. I echo mclout999's sentiment, but see it more as a foundational chapter in the "CMM2 Game Development, Unleashed" book :) Just like the Graphics Programming PDF started life as a series of Peter's TBS monographs, this too could evolve organically e.g. tips and tricks for sound generation (e.g. the recent how-to posts on creating and using MOD files for sound effects), animation techniques (e.g. the "pixel shower" to create an explosion effect), techniques for object and boundary collision detection, pros/cons of using the MMBasic SPRITE commands versus "DIY" graphical elements, user input considerations, etc, etc. Whatever course and speed this evolves on, thanks very much. I already use the excellent Paint.NET, and am trying to learn GIMP - oy vey! Enjoy Every Sandwich / Joe P. |
||||
| mkopack73 Senior Member Joined: 03/07/2020 Location: United StatesPosts: 261 |
Agreed... I knew all this stuff already but I'm sure a lot of newbie types would never think to do things this way. Really good info here that should get added to the graphics programming manual! |
||||
| vegipete Guru Joined: 29/01/2013 Location: CanadaPosts: 1132 |
How should you arrange your sprites? One sheet, many sheets? That's really up to you. It certainly does make sense to assemble all interchangeable sprites the same size together in neat rows. As long as you know where the first one is, you can calculate the rest of them. As you can see by the Rocks in Space sheet above, I just laid them all out in one. The program knows where to find each piece. The dispersing wreckage cloud is interesting, because the shape grows for each step along the animation cycle. The y-coordinate of the source shapes is constant. The x-coordinate and the size are stored in arrays, so finding a particular shape becomes easy. It's worthwhile to test which is faster: use values stored in a pre-computed array, or compute on the fly. I use both. Also, it makes certain sense to use square sprite sheets if you need sprites rotated at 0, 90, 180 and 270 degrees, given that the SPRITE and BLIT commands can't rotate. (They can only mirror.) This way, you can load a given sheet and use the IMAGE ROTATE commands to rotate the entire sheet and generate the extras. My implementation of Lunar Lander way back when used this idea to generate the lander at various rotations, although that resulted in a huge pain when the command changed direction. Visit Vegipete's *Mite Library for cool programs. |
||||
panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1114 |
Vegipete, Can I use your introductory post explanation of using Sprite sheets in the Graphics Programming Manual please. I will need to do a bit of formatting and possibly expand on some of the explanations if that's OK? Regards, Doug. ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
| vegipete Guru Joined: 29/01/2013 Location: CanadaPosts: 1132 |
Certainly. Visit Vegipete's *Mite Library for cool programs. |
||||
CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2170 |
while we're at it - an aside... this popped up in my feed the other day. Nice. https://www.youtube.com/watch?v=smStEPSRKBs Edited 2021-02-17 19:08 by CaptainBoing |
||||
| RetroJoe Senior Member Joined: 06/08/2020 Location: CanadaPosts: 290 |
OMG, that video is a work of art! The animation at the end sequencing through the display list is brilliant! I loved (and still love, via MAME) all the Atari vector games - Star Wars was a stunning achievement in its day, but even the early "Asteroids" was thrilling in its own way, and remains utterly engaging 40+ years later. It's interesting that with a high enough DPI, vector games can be emulated so convincingly on raster displays. Just seeing the "vector font" invariably triggers massive nostalgia :) But the real magic of all early video games, IMHO, is the clever use of the human imagination to fill in the missing pieces e.g. the addition of a small triangle on the tail of the Asteroids ship tricks your brain into recalling the fiery cone of a rocket engine. PONG is the ultimate example of this - two line "paddles" and a bouncing square "ball" were all you needed to imagine you were Borg or McEnroe at center court. By comparison, modern video games leave nothing to the imagination, but pumping ever-higher numbers of polygons to the screen doesn't create immersive game play. Thanks for sharing - made my day :) Edited 2021-02-18 00:02 by RetroJoe Enjoy Every Sandwich / Joe P. |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
