How did people develop games for tthe Super Nintendo and Sega Genesis? were there Game Engines? Did they have to straight up program? Most of all were there Sprite editors to make the sprites and backgrouds???
0
How did development of the Super Nintendo and Sega Genesis go
Started by bigbadbear9885, Mar 12 2011 11:27 PM
3 replies to this topic
Sponsor:
#2 Members - Reputation: 2758
Posted 14 March 2011 - 11:21 AM
It wasn't all that different than nowadays really, except that a lot less was done for you -- for example, there wasn't anything like an OS to speak of, in the way that an Xbox/360, Gamecube/Wii or PS2/3 have an OS. What the old consoles had, if anything at all, resembled more of a BIOS than anything else.
You were on the bare metal, as they say, instead of calling a library function to draw a sprite, you'd write to a special area of memory that the GPU would look in to find out about each sprite it was supposed to draw. Basically each piece of hardware had its own area of memory, and in that memory was a table describing how the hardware was to act or what data is was to act upon -- so you'd manipulate those tables to get the desired graphics or sound effect. This is exactly the way that, really, all processors/computers work -- its just that the operating system hides all that from us today, and takes care of these low-level details for us. If you work in small, embedded systems, you still work in the old ways -- if you've ever played with a PIC or AVR microcontroller (or indeed, any other microcontroller) then you've already done this style of programming. The NES and SNES were pretty strictly an ASM-affair (macro assemblers were about as good as it got). The genesis could be programmed in C since there were enough registers to go around, but anything speed-critical had to be written in assembler, and it was most common to just write the whole thing in assembler since you needed basically all the juice you could get anyhow.
As to engines -- not typically formally, and certainly not anything resembling the middle-ware engines we have today. Each studio might have its own loose collection of functionality scraped together, parhaps this code was shared amongst other studios with the publisher, but you certainly couldn't go out an purchase a turn-key solution.
Sprites and backgrounds were made in the art tools of the day. A package called DeluxePaint was popular back then (a modern successor is Cosmigo's ProMotion). Artists had to understand the hardware limitations and couldn't just paint freely with any color because each sprite might only get 16 or even 4 colors, with one of those colors reserved for transparency. If you absolutely needed more color, sprites could be layered, or large sprites could be composed out of pieces with different palettes, but that would eat into your sprite budget because the old systems had hard limits on the number of sprites that could be rendered -- perhaps 64 8x8 sprites on-screen at once, with no more than 10 on a single scan-line (IIRC, those are the numbers for the NES). You could do clever tricks like palette animation, or changing the palette between scan-lines to get more colors or other graphics effects.
One of these days, I'm going to get around to writing my "virtual console" -- basically it is a library for retro games which can be programmed in C or C++, but which has an interface and hard limitations like an old console, so you would have to employ all the same techniques and clever tricks that NES and SNES programmers did. I think it would be really interesting to see what people would come up with -- basically most of the fun of homebrew (less being able to play on real hardware) without the headache of setting up cross-compilers and bintools, and with full, accurate, official documentation.
You were on the bare metal, as they say, instead of calling a library function to draw a sprite, you'd write to a special area of memory that the GPU would look in to find out about each sprite it was supposed to draw. Basically each piece of hardware had its own area of memory, and in that memory was a table describing how the hardware was to act or what data is was to act upon -- so you'd manipulate those tables to get the desired graphics or sound effect. This is exactly the way that, really, all processors/computers work -- its just that the operating system hides all that from us today, and takes care of these low-level details for us. If you work in small, embedded systems, you still work in the old ways -- if you've ever played with a PIC or AVR microcontroller (or indeed, any other microcontroller) then you've already done this style of programming. The NES and SNES were pretty strictly an ASM-affair (macro assemblers were about as good as it got). The genesis could be programmed in C since there were enough registers to go around, but anything speed-critical had to be written in assembler, and it was most common to just write the whole thing in assembler since you needed basically all the juice you could get anyhow.
As to engines -- not typically formally, and certainly not anything resembling the middle-ware engines we have today. Each studio might have its own loose collection of functionality scraped together, parhaps this code was shared amongst other studios with the publisher, but you certainly couldn't go out an purchase a turn-key solution.
Sprites and backgrounds were made in the art tools of the day. A package called DeluxePaint was popular back then (a modern successor is Cosmigo's ProMotion). Artists had to understand the hardware limitations and couldn't just paint freely with any color because each sprite might only get 16 or even 4 colors, with one of those colors reserved for transparency. If you absolutely needed more color, sprites could be layered, or large sprites could be composed out of pieces with different palettes, but that would eat into your sprite budget because the old systems had hard limits on the number of sprites that could be rendered -- perhaps 64 8x8 sprites on-screen at once, with no more than 10 on a single scan-line (IIRC, those are the numbers for the NES). You could do clever tricks like palette animation, or changing the palette between scan-lines to get more colors or other graphics effects.
One of these days, I'm going to get around to writing my "virtual console" -- basically it is a library for retro games which can be programmed in C or C++, but which has an interface and hard limitations like an old console, so you would have to employ all the same techniques and clever tricks that NES and SNES programmers did. I think it would be really interesting to see what people would come up with -- basically most of the fun of homebrew (less being able to play on real hardware) without the headache of setting up cross-compilers and bintools, and with full, accurate, official documentation.
#3 Members - Reputation: 404
Posted 04 April 2011 - 03:16 PM
Hey, did you work on some titles for those consoles? Could you share more on that? Like how much time to finish a game, or how Nintendo allowed developers to develop for their system(since was all new, most developers didnt have a name yet, did they?)..Thats awsome info!It wasn't all that different than nowadays really, except that a lot less was done for you -- for example, there wasn't anything like an OS to speak of, in the way that an Xbox/360, Gamecube/Wii or PS2/3 have an OS. What the old consoles had, if anything at all, resembled more of a BIOS than anything else.
You were on the bare metal, as they say, instead of calling a library function to draw a sprite, you'd write to a special area of memory that the GPU would look in to find out about each sprite it was supposed to draw. Basically each piece of hardware had its own area of memory, and in that memory was a table describing how the hardware was to act or what data is was to act upon -- so you'd manipulate those tables to get the desired graphics or sound effect. This is exactly the way that, really, all processors/computers work -- its just that the operating system hides all that from us today, and takes care of these low-level details for us. If you work in small, embedded systems, you still work in the old ways -- if you've ever played with a PIC or AVR microcontroller (or indeed, any other microcontroller) then you've already done this style of programming. The NES and SNES were pretty strictly an ASM-affair (macro assemblers were about as good as it got). The genesis could be programmed in C since there were enough registers to go around, but anything speed-critical had to be written in assembler, and it was most common to just write the whole thing in assembler since you needed basically all the juice you could get anyhow.
As to engines -- not typically formally, and certainly not anything resembling the middle-ware engines we have today. Each studio might have its own loose collection of functionality scraped together, parhaps this code was shared amongst other studios with the publisher, but you certainly couldn't go out an purchase a turn-key solution.
Sprites and backgrounds were made in the art tools of the day. A package called DeluxePaint was popular back then (a modern successor is Cosmigo's ProMotion). Artists had to understand the hardware limitations and couldn't just paint freely with any color because each sprite might only get 16 or even 4 colors, with one of those colors reserved for transparency. If you absolutely needed more color, sprites could be layered, or large sprites could be composed out of pieces with different palettes, but that would eat into your sprite budget because the old systems had hard limits on the number of sprites that could be rendered -- perhaps 64 8x8 sprites on-screen at once, with no more than 10 on a single scan-line (IIRC, those are the numbers for the NES). You could do clever tricks like palette animation, or changing the palette between scan-lines to get more colors or other graphics effects.
One of these days, I'm going to get around to writing my "virtual console" -- basically it is a library for retro games which can be programmed in C or C++, but which has an interface and hard limitations like an old console, so you would have to employ all the same techniques and clever tricks that NES and SNES programmers did. I think it would be really interesting to see what people would come up with -- basically most of the fun of homebrew (less being able to play on real hardware) without the headache of setting up cross-compilers and bintools, and with full, accurate, official documentation.
#4 Members - Reputation: 100
Posted 07 June 2011 - 08:55 AM
As Ravyne said, back in those days C compilers were immature if they existed for the platform (not a given), and hardware restrictions made anything but assembler an unacceptable overhead.How did people develop games for tthe Super Nintendo and Sega Genesis? were there Game Engines? Did they have to straight up program? Most of all were there Sprite editors to make the sprites and backgrouds???
If you are interested to see what the source code to a real SNES game looks like, search for "B.O.B. source code" - its source somehow made its way to the internet.
Yeah, that's a cool idea. Alternatively systems like the Chip16 and Chip8 are available, the latter being the best-known.One of these days, I'm going to get around to writing my "virtual console" -- basically it is a library for retro games which can be programmed in C or C++, but which has an interface and hard limitations like an old console, so you would have to employ all the same techniques and clever tricks that NES and SNES programmers did. I think it would be really interesting to see what people would come up with -- basically most of the fun of homebrew (less being able to play on real hardware) without the headache of setting up cross-compilers and bintools, and with full, accurate, official documentation.
Cheers,
