8-bit Sprite
Vannessa Rataj
I'm looking to create a sprite sheet for an 8 bit, 2D RPG I'm making. All I need to do at the moment is render in some textures. To do this, I want to make an 8x8 sprite sheet. Now, I am really bad at using anything to do with GIMP or Paint.NET, so I came here for some help.
Note: This question specifically asks how to make an 8*8 sprite sheet using 8 bit graphics. A sprite sheet is a series of images meaning more than one image on a single image(not 8px*8px). You can do all the editing and creating you want to do before changing the image to the indexed format using Gimp which will convert the image to the required 8 bit format. Palettes are used when pictures are 1 bit, 4 bit, or 8 bit. Both, Paint.net and GIMP 2 have there own unique good and bad qualities. Where one is lacking the other usually does not so I use both for a single sprite sheet. Some of the features the manipulation programs have are not simple and require some time and effort to acquire a working knowledge of the tools.
Make sure you pay close attention to the measurement on the top and left of the screen so that you keep your sprites within the boundaries you set when creating the 8*8 sprite sheet. If you choose 32*32 then each sprite should stay within those measurements with a total of 64 sprites to use in your RPG which should be plenty to work with for your first RPG. You can make your sprite sheet with as many pixels of your choosing and still use the 8bit per pixel rule. Also, with Gimp you can choose to use the rectangle tool which can be very useful making your sprites the right size. You can drag the rectangle/square to size and then work within the boundaries of the rectangle/square without worrying about drawing over another sprite which keeps them all perfectly square and neat. Good Luck. Your sheet should look something like the following image made with gimp for 8*8 pixel sprites on a 64px*64px layer . Each square represents a space for a sprite...
There is a workaround that some of my students were able to use. You can save the image as an animated GIF, rename it to be a JPG file, upload it, and you should see all the frames in the animation tab. In order to make it work, you have to make a small change to a frame, just adding a dot or something, then once you draw the sprite inside the draw loop, it will animate.
I have tried the work-around by bringing in a gif that was re-saved as a jpg file. It was animating while in the Game Lab animation library as you said, however, the two lower layers were not showing up for me to get to, only the top. When I clicked on the picture it stopped animating and just stopped on the first layer remained visible. I changed one dot on the top of the picture and then put the picture into the draw loop function, hoping it would re-animate and it did not animate. Is there any way that you can share a video of some short showing the process you described that is the work-around? This is coming up a lot for my students.
What I'm not sure is whether I should make the sprites on a 1920x1080 canvas or if I work with a smaller canvas like 192x80 (which would be a lot easier) will we be able to scale them without losing quality (on Photoshop or the developer on Unity)?
Set your canvas size so it correlates to the pixel size you want to use. That way you can use 1:1 pixel tools in photoshop. When it comes time to use the actual images, you can then re-scale in Photoshop or possibly in the app framework itself.
In the style of games made the 8-bit generation of game consoles & computers, or sometimes authentically created to run on original hardware. Common 8-Bit consoles include the Nintendo Entertainment System, Sega Master System, and the Commodore 64
I have seen some pretty impressive stuff on this forum (Like this: )So I wonder if anyone could point me in the direction of the "ultimate" sprite multiplexer in 2022? Something that does both horizontal and vertical multiplexing, with minimum use of CPU cycle....
It sounds like you are looking for a general-purpose library (or routine) to handle the sprite multiplexing, but you are going to find that the only general-purpose implementations will lead to the flickering you have now. A flicker-free multiplexor will need to be designed around your specific game, with clever in-game constraints allowing you to reuse the same players/missiles on different scan lines.
In fact I'd go one step further to say that if as an retro computer owner you are regularly playing on/supporting a retro computing platform like ours 3-4 decades after the platform officially stop being mainstream - I'd class the majority of A8 owners as enthusiasts by definition. Certainly that is the case on AA as far as I can tell.
On a related note one of the reasons I started my A8 RAM poll here last month - to guage the "rough" landscape of A8 owners with regards to the stock machine RAM range (16k through 128k) and 256K and upwards RAM A8s - was to see how many owners have A8s of over 256K of RAM. This was with game developers in mind.
*I say not unsurprisingly because 256K, 320K, and 576K upgrades have been around for decades an have been installed by many. Some of those machines have then been sold on and recirculated within the community. (More recently of course the U1MB and similar sized 1088K upgrades have been becoming more popular.)
Interestingly still a good amount of the 101 owners who completed the poll own a 128K machine. So to also have such a high number of people in the poll having both 64K and 256K or higher machines is very encouraging IMHO and hopefully helpful to those creating games for the platform.
Whilst I totally get why anyone coding and creating games and software for our beloved platform would ideally wish to code for 64K, I think given a lot of Atarians own higher RAM A8s than one might first assume/was generally thought the case, 128K is still a totally viable RAM size to code for and still have a significant audience.
Globe, (creator of the amazing Final Assault 3D raycasting game), amazingly crammed that game into 64K which is fantastic. (I also totally get the personal challenge that comes to a coder wanting to cram it into 64K as well).
However his next engine by all acounts is promsing to be amazing and is targeted for 128K RAM A8s which is already looking something special and is improving greatly on Final Assault's engine as a result.
I guess all I'm saying is, even BITD there were a decent amount of people with memory-expanded machines. Today if you can read this forum you probably have the ability to run whatever you want on an emulator even if you don't physically own an upgraded Atari. So you're really only excluding the few who insist on only running everything on unmodified original HW, no exceptions.
I think @bazza would like to reduce his image into basic building blocks that he could reuse. These blocks would be a part of a general sprite sheet. Ubiquitous among early video games where memory was scarce.
As I said before, I know what you want and that it is possible, but this is outside of my league. If the tools already exist, why not use them instead and then import the resources to your app of choice?
I know peeps would think "well there's PX9 and it keeps all 16 colours" but it's a different concept here. You could REUSE some tiles several times to even fill the entire screen and have the basic spritesheet only occupy a few tiles.
The intent here is to take advantage of single monochrome tiles to have graphics like this (also with the help of 8bit drawing sw like Multipaint):
It is a fundamental problem in computer vision to turn a collection of 2D images into a 3D model. There are a number of ways to formulate this problem, but for this article I am going to focus on the following specialization of the problem which is known as multiview stereo reconstruction:
While space carving is quite far from being the most accurate multiview stereo algorithm, it is still noteworthy due to its astonishing simplicity and the fact that it is such a radical departure from conventional stereo matching algorithms. The underlying idea behind space carving is to reformulate the multiview stereo matching problem as a fairly simple geometry problem:
Of course there is still one small problem. The shape we get at the end may have some small gaps that were not visible in any of the 6 views and so they could not be reconstructed. To get a decent looking reconstruction, we have to do something about these missing points. One simple strategy is to start from the edges of all these holes and then work inwards, filling in the missing pixels according to the most frequently occuring colors around their neighbors. This produces pretty good results for most simple sprites, for example:
Well said.
This is no different than emailing your favorite author and asking them to email you a word doc of their new book cause you have a printer at home and could just print it out without compensating them for their hours of work.
Could you please fix the link/app. I have tried both master and gh-pages from GiT, tried with IE, Firefox and Chrome. On Win 8 and Linux Mint. I have also tried , but none are working. Would love to use this app.
c80f0f1006