Jump to content

  • Log In with Google      Sign In   
  • Create Account


How did/do game developers create 2d sprites? How did it work?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
17 replies to this topic

#1 bigbadbear9885   Members   -  Reputation: 177

Like
0Likes
Like

Posted 24 November 2010 - 04:28 PM

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

Sponsor:

#2 owl   Banned   -  Reputation: 364

Like
0Likes
Like

Posted 24 November 2010 - 04:59 PM

Pixel Art

#3 sunandshadow   Moderators   -  Reputation: 4670

Like
0Likes
Like

Posted 24 November 2010 - 05:16 PM

Program it? The only computer art I've heard of being programmed directly was back in the really primitive days of things like Pong. Well, and I think they assign C++ homework of drawing some simple shapes on the screen with programming. But from Atari, Apple II, Commodore 64, NES, original Gameboy, and forward it's all been pixel sprites. The oldest pixel sprites had a limited color palette (in some cases monochrome because the screen they were being displayed on was monochrome) and each pixel had to be a solid color, but that limitation was quickly overcome as improving technology allowed screens to be higher resolution and greater color depth, and more sophisticated graphics file formats were invented. Currently unless you are making a game to be played on a handheld device of some kind there are basically no technological limitations on 2D art - you can even make your art in 3D and take screenshots for frames, or you can make your sprites with vector art then choose whether to use vectors natively or export them as bitmaps of any desired size.

So, is your dream to create modern games that look retro? Or are you wanting to create games that actually run on old hardware? Or what? You can use Gimp or Photoshop just as well for retro sprites as modern ones. You could also use something like MSpaint, or I imagine there are several programs available which make sprites in one specific color palette and format. There are many collections of sprites people have ripped out of actual games available around the internet; while you can't legally use them in a game, they are very helpful to look at as an example. You can get a sprite or animated gif of exactly the style you want to copy and see how many pixel wide and tall it is, and what color palette it's using.

#4 ernow   Members   -  Reputation: 728

Like
0Likes
Like

Posted 24 November 2010 - 05:22 PM

I remember pixel-arting in my math exercise book 24 years ago. You know, the one with the tiny squares (5mm grid paper). Later switching to 1mm grid because it resembled the screen beter. Colors? Way too advanced back then.


#5 bigbadbear9885   Members   -  Reputation: 177

Like
0Likes
Like

Posted 24 November 2010 - 05:29 PM

My big future dream is actually a very bigger thing but creating a system is a part of it.

I wanted to develop a system that is as powerful as ps3 or xbox 360 or more powerful actually I wanted to it to have many many games that range from the most weakest graphics to the pressence.

#6 FlameTheLoner   Members   -  Reputation: 100

Like
0Likes
Like

Posted 24 November 2010 - 09:42 PM

Creating Sprites

#7 dbaumgart   Moderators   -  Reputation: 138

Like
0Likes
Like

Posted 25 November 2010 - 08:27 AM

I've no idea how those old games did their pixel art. Crude software, no doubt - doing pixel art (and all sorts of art) nowadays, I use Photoshop for everything.

Here's a decent pixel art tutorial: http://www.petesqbsite.com/sections/tutorials/tuts/tsugumo/

But I advise learning all art as a comprehensive skill rather than just pixel art.

#8 CodeMunkie   Members   -  Reputation: 805

Like
0Likes
Like

Posted 25 November 2010 - 08:59 AM

Quote:
Original post by bigbadbear9885
My big future dream is actually a very bigger thing but creating a system is a part of it.

I wanted to develop a system that is as powerful as ps3 or xbox 360 or more powerful actually I wanted to it to have many many games that range from the most weakest graphics to the pressence.


With the state of emulation you can achieve this today with a moderate pc setup. Just build it in a shuttle or htpc case to get that console form factor and load it up with emulators. Write a little app to let you browse your games with a joystick, plug it into your tv and play!

#9 zer0wolf   Members   -  Reputation: 1018

Like
0Likes
Like

Posted 25 November 2010 - 10:17 AM

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.
laziness is the foundation of efficiency | www.AdrianWalker.info | Adventures in Game Production | @zer0wolf - Twitter

#10 Bearhugger   Members   -  Reputation: 549

Like
0Likes
Like

Posted 02 December 2010 - 08:40 PM

Wow I wasn't aware of Pro Motion, it looks pretty good! Shame there's no free version. :(

I use GraphicsGale, which is free. It can be somewhat buggy, but the lastest version seems fine so far.

#11 Katie   Members   -  Reputation: 1302

Like
0Likes
Like

Posted 02 December 2010 - 10:17 PM

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.


#12 ozak   Members   -  Reputation: 155

Like
1Likes
Like

Posted 02 December 2010 - 10:37 PM

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.

#13 Portugal Stew   Members   -  Reputation: 129

Like
0Likes
Like

Posted 03 December 2010 - 04:22 PM

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

#14 MSW   Members   -  Reputation: 151

Like
0Likes
Like

Posted 04 December 2010 - 05:13 PM

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.


#15 Ravyne   Crossbones+   -  Reputation: 6908

Like
0Likes
Like

Posted 04 December 2010 - 06:07 PM

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.

#16 adiian   Members   -  Reputation: 100

Like
0Likes
Like

Posted 11 December 2010 - 10:35 AM

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.

#17 Peter Szabo Gabor   Members   -  Reputation: 152

Like
0Likes
Like

Posted 27 December 2010 - 09:12 PM

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).



#18 Martyg   Members   -  Reputation: 104

Like
1Likes
Like

Posted 11 January 2011 - 12:39 AM

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):

Posted Image

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):

Posted Image


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




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS