Well, long ago the first thing people wrote was often a sprite editor, which tagged along with them from project to project gaining features over time. Using art packages came a lot later.

In the days before that, you were into designing stuff on graph paper and doing sums to get the magic numbers for SYMBOL statements...

Don't forget that in general, games often didn't use that many sprites and images; With memory around 64k, the screen could occupy a quarter of that. You need some space for level data, some for code, the stack... You might only have a total of 10k for sprites. Call it 20,000 pixels. For a decent sized sprite of 256 pixels, you don't get very many of them.

This is why a lot of 8-bit games "stretch" sprites, usually vertically by doubling pixel rows (because it was easier) to get more use out of the same data.

Games were hardly ever art-constrained; they were almost always limited by RAM and CPU speed.



If you really want to have a go at working in that environment, there's a programme called "SpritePad" which from the screenshots at http://www.coder.myby.co.uk/spritepad.htm looks not entirely unlike the sort of editors people used.

Back in the Commodore 64 days we would design the sprites on graph paper and then punch in the data statements.

Later we would do sprite editors and use existing drawing packages to do backdrops etc. (Koalapaint for instance)

On the Amiga we used the kickass Deluxe Paint package. Pro motion is definately it's successor in more than one way. Many of the old DP shortcuts even work! ;)

On the PC again Deluxe Paint and own font/sprite editors.

Nowadays it's photoshop mostly. We still use Pro motion for GBA and similar stuff. Even for cellphones.

mtPaint's a good free pixel-art solution. It has some options for dithering and simple animating that might help you out.

Most of the old videogame pixel art was likely hand coded from graph paper drawings and such. IIRC, NES used 2-bit patterns for 8 by 8 pixel tiles and sprites, which were filtered through a number of limited color palettes for something like a maximum of 16 or 24 colors onscreen at once.

I recall useing a graphics tablet at school on a Apple II. But the software at the time made Windows 3.1 MS-paint look extreamly robust in comparison.

Quote: Original post by zer0wolf
Back in the day a lot of people used DPaint and similar software. Nowadays there are more sophisticated programs that make it a bit easier than artists had back in those days. One application that is used today for sprite work, such as for DS games, is Pro Motion.

This.

DeluxePaint was *the* art package back in the day. When you heard that it was programmed in, it works for small/limited numbers of sprites. Remember that images are just data -- doesn't matter if you encode it all in a C array or if you packed a bunch of image files after your executable on the rom using a resource linker or binutils. In fact, the former was usually easier, so most art programs had the option of saving images out as C arrays that you would just include or copy/pase into your code.

ProMotion is an excellent, more-modern alternative to something like DeluxePaint, I've used it for years and its very capable. It's not free, but its reasonably priced (I think $70ish) for software that's for commercial use. I've heard decent things about GraphicsGale (and the free version should be enough for your needs) but I've not used it myself. GrafX2 looks promising also, and there's also the Pixel Image Editor which runs on just about every OS under the sun.

You can use almost any graphical application to create game sprites. All you need is a simple application that can change the pixel colors, some good knowledge about sprites and a little talent. I've seen on many forums people using windows paint to create cool sprites. Photoshop or gimp are as good as paint because you'll use only a limited set features.

Once you have decided to a specific application to use you could read some sprite tutorials. The 8/4/16 bit sprites were just a limitation of the existing game hardware. Those days you could have such limitation on mobiles. In order to have that look you just have to use less colors for creating your sprites. But you have to take in consideration that sprite creation is a job for an artist. You need to exercise a lot for getting some nice sprites. If you are a developer and you just want to use them in your games you can look for some free sprites.

DeluxePaint. Easy as that. Programming art? No way, not from the early 80's. (maybe in some zx basic, where you "poked" the pixels, but professionally I did never do any art programming).

Like back in the genesis, nes, snes days. What did Devolepers use to create sprites? I heard that you got to program it and stuff. Do you really have to create it like that without seeing it? Also what is a good simple program to use related to what game developers used to create 2d sprites that looks like it's from a 8 bit game, 4 bit game or 16 bit game?

Sorry If I sounded real dumb. I'm a kid with a big future dream and doing the best I can to learn all I need to know.

Thank you

There were no 4-bit games, unless you mean to suggest the Atari 2600 is 4-bits which is a myth of course.

As for how they did sprites, it depends what era you're talking about. In the discrete logic (pre-microprocessor) days all graphics were actually drawn by the circuitry of the game. These games had no game code, and all behavior (including graphics) were created by what's called a "state machine". A specialize grouping of circuits that reacted the various input stimuli to set up various states overall. Each aspect had a control circuit. In the case of PONG for instance, you had a circuit that controlled the hoizontal motion/drawing of a paddle, another circuit for the vertical motion of the ball, a flip-flop circuit that tracked which direction the ball was going and if changed would changed how the relevant circuits interacted and so on. And each of these had to be synced to timer circuits or IC's. I.E. the width of the paddle you see on the scree was defined by a length of time rather than pixels. The previous game, Computer Space, actually used a diode matrix circuit to create it's "sprites". For convenience of repair, the diodes were collectively laid out on the board in the shape of the actual object they represented (see upper left corner of the PCB):



That changed in 1974 when Atari/Kee released Tank, the first game to use ROMs to store graphic data. Once microprocessors were added to arcade games, you then had everything that was needed to turn these in to computer structures complete with bitmaped graphics and the ability to program games and store said programs. Each game PCB was still custom designed as most of it's capabilities were still hardware based, leading to in effect a "new" computer for every game. By the late 70's they of course got smarter and started using a custom hardware pcb for a series of games, creating an arcade "platform". In relation to your question, during this time (which is also the time microprocessor driven home consoles were introduced) you had graphics literally planned out ahead of time on graphing paper. Each box would represent the pixel, which it would then be the job of the programmer to translate in to the actual display data for the custom platform it was running on.

Here's an example of said procedure used in both the Atari 2600, Atari 5200, Atar Computers (400/800 etc.) and typical Atari arcade hardware at the time:

http://www.atariarch...gd/chapter5.php


In the case of arcade game development, you usually had a compiler running on a mainframe you connected to through a terminal (and usually a CPU simulator on there as well to test base compiled code). You'd then burn a rom of the compiled code and go and plug it in to the test hardware to test. It was then you'd actually get to see your graphics, game play etc. If it was wrong or you needed to make changes, you'd go back to the mainframe and make code changes and repeat the process. In console development, you'd be lucky to have a burner in the same room. Here's an example of a typical setup of the time period, this one from the offices of GCC (designers of Ms. Pac-Man, Food Fight, and Quantum to name a few):




Click here for an article that captures the typical development process by the early 80's for console/computer games.


It was the early 80's really when the industry first started using actual artists to design said graphics (or "sprites"). And with the arise of these types of non-coder job positions came the need for more specialized graphics programs to help in direct computer based sprite design, as some of the other posters mentioned. In arcade and big budget software houses, these generally included access to drawing tablets as well.

It wasn't until the mid through late 80's when mouse driven computer platforms became more prevalent that you had the rise of more standard general drawing packages that could be used to generate graphics that more freeform graphics/sprite generation arose (depending on the intended platform's capabilities of course, sometimes you still had to plan for a system's sprite generation limitations).


Marty