Lovely Salsa
Banned
How was original super mario bros made? I always wondered this
Ancient photoshop?
Ancient photoshop?
How is this still on OT?
nice contribution man, way to go.
I thought it was art related.
(sorry mods)
This is impressive, but wouldn't it have been a lot easier and less expensive to have animators draw the characters ala Skull Girls? Can't understand why they felt the need to bankrupt themselves with the high res pixel art approach. I mean for KOF14 I thought for sure they'd use the KOF12/13 sprites and simply add five or six new characters into the mix along with a few new backgrounds; the fact that they decided to completely abandon all of those assets and start from scratch in 3D is rather telling.
Bit by bit. Literally. There were only like 64 colors. They just used hex numbers for the colors they wanted and put them in a grid.How was original super mario bros made? I always wondered this
Ancient photoshop?
I've never seen this before and it's really interesting. What really intrigued me the most is that the two render planes are used for the main character and the enemies, and they constanly flicker between them. It's like the even frames of animation (or sync refresh) are drawn on layer one, and odd frames are on the layer two.also interesting video for the thread on metal slug sprite layering
https://www.youtube.com/watch?v=-2PiaH8CO64
Bit by bit. Literally. There were only like 64 colors. They just used hex numbers for the colors they wanted and put them in a grid.
I know on C64 at least there were some sprite editors. You'd get a grid and you put colors in there, then it saves the sprite into the data stream that you can then use in your game. But early on, I'm pretty sure sprites were made using pen and paper grid, then entering numbers accordingly. I did that for a few sprites on C64, it wasn't that time consuming tbh. because sprites were small.How was original super mario bros made? I always wondered this
Ancient photoshop?
They could have. It would have been proprietary and probably output it as code they could put in the game code as assembly.I can't imagine that software developers would not write a simple tool for drawing sprites before actually coding them directly through hex numbers.
I can't imagine that software developers would not write a simple tool for drawing sprites before actually coding them directly through hex numbers.
Was phothoshop even available to these guys at that time?
What software did they use?
What method did they use, did they draw than scan the art and turn it into pixels?
![]()
Man, as it sways back and forth, the detail never loses its sharpness. Every line is perfect on every frame, there's not a sign of some unnatural looking pixel jitter anywhere, even though there's like a thousand animated components in just that one sprite...
Now imagine if you take a static image from that animation, load it in Photoshop and rotate by one degree. Lol.
I might be wrong about this particular sprite, but I believe the neo geo could free transform sprites via code without any need for the artist to animate rotating sprites or angled sprites.
for example there is this one part on metal slug where you can use the tank on the very edge of a cliff and you will notice that the sprites are completely different when the tank is tilted.
Also some interesting sprites effects can be seen whenever the player chooses to continue, the character sorta scales from the sky to the ground into position.
If you see the bridge gif from metal slug snow stage, is something out of this world.
The neo geo has no support for sprite rotation.
Okay, now I'm not sure if your familiar with nearest neighbor options on phothoshop
but if you rotate any metal slug sprite by one degree it would destroy the look, how is it possible for the neo geo to keep the sprite in it's actual uniformed sequence? 0_0
er, because they're drawing it all by hand.
The sprite you're looking at isn't many individual sprites being rotated and tweened, it's all one sprite that has many frames of animation.
Sorry, perhaps I didn't explain myself properly,
I wasn't referring to any sprite in particular, I was talking about how if you rotate (say) the tank of metal slug via phothoshop using Nearest neighbor (only tech I know that keeps the pure pixels format) it destroys the sprite. but when the neo geo does the rotating (via code,using only one sprite) the sprite remains perfectly drawn with very little to no destruction of the actual place of the pixels.
I hope that made more sense :/
Sorry, perhaps I didn't explain myself properly,
I wasn't referring to any sprite in particular, I was talking about how if you rotate (say) the tank of metal slug via phothoshop using Nearest neighbor (only tech I know that keeps the pure pixels format) it destroys the sprite. but when the neo geo does the rotating (via code,using only one sprite) the sprite remains perfectly drawn with very little to no destruction of the actual place of the pixels.
I hope that made more sense :/
I forget what game, but there was one that basically rotoscoped 3D models. It looked very, very nice. I don't mean cell-shading, they went in by hand and pixelized the image the 3D model was creating for them.
I know what you mean, but even if NeoGeo had some hardware based sprite rotation support (which I don't think it did, it had scaling though) or if they used a CPU for sprite rotation like some Amiga games did - that would usually create some stray pixels around the edge that I don't see on that sprite. Still, I'm not excluding the possibility that the cannon tower was made to sway using a technique like that. Still, seeing how many other things are animated on that tower (like changing shadows etc) I doubt it.I might be wrong about this particular sprite, but I believe the neo geo could free transform sprites via code without any need for the artist to animate rotating sprites or angled sprites.
I think that's what nearest neighbour does. It doesn't interpolate pixels creating blurry looking pixel art. Actually, surprisingly enough, that metal slug sprite rotated by 2 degrees in Photoshop using nearest neighbour, looks very respectable. Rotating it by 1 pixel however introduces some stray pixels around some of the edges - but only very few. I don't think it's entirely impossible that the gun tower on that lobster sprite was swaying using some CPU-driven sprite rotation (some Amiga games were able to accomplish that, despite hardware having no support for it - MC68000 had enough grunt to do it), although I think it's unlikely.You can apply a pure, non-interpolated rotational matrix to pixel positions and not produce any visual artifacts at all if you wish. It all depends on the rotation algorithm one is using, and which algorithm you are using depends on many circumstances, such as speed and accuracy.
Very obviously layering of some sort.
Very obviously layering of some sort.
Probably the most notable game to do this is the modern King of Fighters games.
For whatever reason this post made me lose my shit for like 10 minutes. :lolGiven the amount of care you put into your OP, I'm surprised at what you expect of the people responding to your thread.
- where for were
- Metal slug
- put in OT instead of Gaming
Way to go, OP.
While that may be so, I think the end result is rendered as a sequence of single layer images. You can see the rendered layers on the video posted earlier in the thread. Maybe it was just animated in a more layered fashion to preserve the sanity of whoever had to do it. To make the job at least a bit more bearable. Keep in mind also that the metal slug tank itself would animate using stretch and squish to some degree, so that was clearly done with every new frame having to be entirely different.Very obviously layering of some sort.
I think that's what nearest neighbour does. It doesn't interpolate pixels creating blurry looking pixel art. Actually, surprisingly enough, that metal slug sprite rotated by 2 degrees in Photoshop using nearest neighbour, looks very respectable. Rotating it by 1 pixel however introduces some stray pixels around some of the edges - but only very few. I don't think it's entirely impossible that the gun tower on that lobster sprite was swaying using some CPU-driven sprite rotation (some amiga games were able to accomplish that, despite hardware having no support for it - MC68000 had enough grunt to do it), although I think it's unlikely
Yeah, edited my post with similar findings just before you posted that. You can see practically both things at work in Photoshop, before and after you apply the final transformation. That makes me wonder which technique was in use by the arcade hardware that had built-in rotation.Nearest neighbor itself actually describes the interpolation method. It interpolates the final pixel output using a single "nearest neighbor" pixel to a considered pixel. This produces a minimal amount of noise (you get 1 final pixel for every pixel considered) but you still interpolate your data.
What I was saying is that there are numerous ways to rotate, including ways that don't interpolate at all. The problem with doing that is your rotated image produces holes when doing this:
This type of artifact is called Speckling. And it might be acceptable in certain situations. Really, the result of your rotation depends entirely on method and the method depends on the needed speed and accuracy.
Very obviously layering of some sort.
How was original super mario bros made? I always wondered this
Ancient photoshop?
Yeah, edited my post with similar findings just before you posted that. You can see practically both things at work in Photoshop, before and after you apply the final transformation. That makes me wonder which technique was in use by the arcade hardware that had built-in rotation.
Hardcoding. There weren't that many pixels, and the hardware was limited, so they hardcoded the sprites in using binary, from my understanding.
Oh, I don't really have a central repository of links to hand out, but you are pretty mistaken about EWJ. The sprites were not cleaned up between ports, and that's actually a really big problem with the SNES port. The two machines run at different resolution, and the machine rasterization they employed (called Digicell animation) was configured for the Genesis resolution. As a result of minimal touchup, the sprites actually run way too fat on the SNES. EWJ SNES looks really weird when running on a CRT, like everything is way too fat.
I forget what game, but there was one that basically rotoscoped 3D models. It looked very, very nice. I don't mean cell-shading, they went in by hand and pixelized the image the 3D model was creating for them.
This is awesome. Glad I kept reading (first few posts kinda turned me off the thread.)The sprites were created on paper, and then refined pixel by pixel using graph paper
![]()
![]()
![]()
from there they would code each pixel in one by one on a grid (I would imagine, going that far back to the first Donkey Kong and Mario Bros. 1).
from there they would code each pixel in one by one on a grid (I would imagine, going that far back to the first Donkey Kong and Mario Bros. 1).
bitplane 1: 1 0 0 1 0 0 1 0
bitplane 2: 0 0 1 1 0 0 1 1
b1: 1 | 0 | 0 | 1 | 0 | 0 | 1 | 0
b2: 0 | 0 | 1 | 1 | 0 | 0 | 1 | 1
Re: 1 | 0 | 2 | 3 | 0 | 0 | 3 | 2
It's a single layer sprite, and the number of independently rotating segments would be impossible to perform in software on the m68k inside the Neo Geo.
Now, what is likely is the sprite was drawn in segments and combined using something like deluxe paint, but each segment would be hand tweaked. This is not tweening.