News: 11 March 2016 - Forum Rules, Mobile Version
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia

Author Topic: How were early 8 and 16-bit games programmed?  (Read 1640 times)

pianohombre

  • Full Member
  • ***
  • Posts: 194
    • View Profile
    • My personal website of short stories and comics
How were early 8 and 16-bit games programmed?
« on: November 02, 2017, 05:32:58 pm »
Most guides say they were written in Assembly, but C++ has been around since the '70s, and they also had Pascal. There are engines today, such as Unreal Engine, that are used to reduce time to create a game. I really find it hard to believe every game in the 80's and 90's was created by scratch, in ASM, especially since many Nintendo and Capcom games look very similar. Seems like you could upload 100-500kb of graphics and some program would store it all correctly, and the programmer would just need to write things like which direction the graphic fired, or what graphics to display when he died, upgraded armor.

I don't really think it happened that in the early planning stages they said ok let's spend 100 hours compressing graphics and then getting them to display properly when the character changes X or Y position. Of course disassembling graphics is 10x harder than working with the same software, but game companies won't release the actual code, because it's copyrighted, not even if the games get put in the public domain in 10-20 years! (I don't expect them to).

However, I got in this stuff late. I never even studied game programming in college either. I was on a different track (you know working with databases, how to use PHP to create an online social media site or store). It seems like maybe some of the folks on this site may have actually worked on games that were popular in the 80's and 90's, and were familiar with the software used to make some of the games. Please drop a few names (of popular software programs)?? Thanks.
One small step for man,
one giant leap for mankind. -Neil Armstrong

FAST6191

  • Hero Member
  • *****
  • Posts: 2172
    • View Profile
Re: How were early 8 and 16-bit games programmed?
« Reply #1 on: November 02, 2017, 07:26:03 pm »
Basic was available for quite a few systems, though not so much for the 16 bit and older mainstream consoles like Americans think of them (to ignore "minicomputers" in the UK/Europe/Australia when talking of stuff of that era is not the done thing at all).

Equally C compilers were not exactly the things producing the sort of results you see today. Actually that might be a good exercise -- get a C compiler for the console in question (a few now exist, or exist for similar processors) and try to do something like you would see on a top tier game then. If it even runs, never mind at a playable speed, and does not eat all the memory then you are doing extremely well and that is with a modern compiler that will not push every register (assuming that is a meaningful concept, for the NES it is not) to do a simple few line piece of arithmetic and check just because that is how function calls work. Minor aside, I know I said modern compiler but a lot of the homebrew ones available are hardly that modern and closer to a proof of concept.

Likewise if you are thinking more the assembly we use in hacking then don't underestimate the niceties of labels, comments and more being there from a start, probably with a design doc or working goal for it. It is not copy-paste a routine like we do for... everything else but it is not so far off. Even if you can't do that then crack paralax scrolling on one game, something which could take a few hundred hours of experimentation, and you will know the sorts of numbers that make each layer work, approaches and more for the next one.

"look very similar"
Ignoring the stuff above and also the next step there of pipelines I should say that there are only so many ways a limited palette (especially if you are going to be lazy and use a stock one), a copy of corel draw, a limited sprite count (top half, bottom half swap out works well for many purposes), limited tile size*, a limited pool of artists, limited animation/manipulation abilities, a limited pool of source material (all those capcom games looking similar are often all disney games too) and so on and so on play out.

*general theory of art also applies here -- a proportional human(oid) or a cartoon giant head are where it goes to if you have a limited pixel count and are still traumatised by the Atari and thus need some detail in your life.

"compressing graphics and then getting them to display properly"
That is probably a backwards way of how it was done. More likely the devs would be given a size to work to, or thrust upon them later in the day, and have to make it fit, if compression was used at all. It might still be assembly but you can still do a routine, and being assembly you probably knew your routine compared to today where many a programmer sort of fumbles and may not have a clue about all the assumed commands that are being passed to the routine.

" but game companies won't release the actual code, because it's copyrighted,"
Do a search for lost code. It is not that people won't release code. In many cases, including for massive games by massive companies, the code may well not exist. Or if you prefer it is not just that Sega is nice that they tap fans game makers, emulator authors and ROM hackers for their Sonic stuff.

Of course this is not to say you don't get interesting cases like
http://www.pagetable.com/?p=28
« Last Edit: November 02, 2017, 09:38:39 pm by FAST6191 »

Psyklax

  • Sr. Member
  • ****
  • Posts: 412
    • View Profile
    • Psyklax Translations
Re: How were early 8 and 16-bit games programmed?
« Reply #2 on: November 02, 2017, 07:37:22 pm »
Of course they were written in assembly, why wouldn't they be?

Take the ZX Spectrum as a good example: people were making new games all the time in their bedrooms, and if you browse old Speccy magazines, you'll see countless adverts for them, most of which say "fully written in machine code" as a selling point - since the only alternative was BASIC, which is very slow and primitive.

Perhaps parts were done in another language. My dad was telling me about his programming days (not games but business software) and said they usually didn't write directly in assembly, instead using C or something like that, but they still had to get into the assembly to tweak it. After all, 8-bit computers and consoles are primitive by today's standards, and you need to get every instruction working right for two reasons: speed and storage capacity.

Look at the NES: without memory management controllers (which didn't appear until around 3 years after the Famicom debuted) you get 8KB for graphics and 32KB for everything else. If you're writing the whole thing in a high level language, it may be doing instructions that are totally redundant and wasting space in your valuable storage. Not only that, but these instructions take time. If you want a fast-moving action game, you really need to fine tune the code.

Also, having worked on a good few NES games myself for hacking purposes, I can say that although you may think games look similar, under the hood it's a different story. Sure, if you take, say, Mahjong and Gomoku Narabe Renju, which immediately look very similar because they were clearly made at the same time by the same team, you can see similarities. But SMB3 and Mega Man 2? I doubt that they look similar in the code. There's a reason people talk about 'game engines': you spend time crafting an engine and then you can make several games with it, rather than reinventing the wheel every time, like you said (hey, they made six Mega Man games on the NES: that's a great example of having a good engine and just rehashing it to death).

But having delved into 6502 assembly, I don't see it as impossible to code a game that way: it's a really simple language. I could never get started on high level languages, while 6502 assembly now seems very accessible to me. It doesn't take 100 hours to compress graphics: that's what computers are for! :D

As FAST6191 says, assembly is a bit easier to work with than pure bytes because you can use definitions of things that you need, usually addresses. So instead of making a branch instruction and having to literally count the bytes until the next instruction (which will change if you change your code) you just write to branch to the PlayerShootingHisWeapon routine or whatever and the compiler takes care of it. In fact, take a browse through the reverse-engineered SMB disassembly to see what I mean.

https://gist.github.com/1wErt3r/4048722

KingMike

  • Forum Moderator
  • Hero Member
  • *****
  • Posts: 6177
  • *sigh* A changed avatar. Big deal.
    • View Profile
Re: How were early 8 and 16-bit games programmed?
« Reply #3 on: November 02, 2017, 10:37:19 pm »
A lot of game development was farmed to other studios.

Nobody heard of TOSE before the DS era but if I remember reading they and Micronics had written a supply large number of Famicom games uncredited. I want to say maybe even 10%.
gdri.smspower.org is a site dedicated to tracking down such unknown developers (actual mentions or looking for telltale code similarities, etc.)

I've thought TOSE might've had the manpower to write 100 games at once or whatever. Like an entire farm of programmers sitting at computers. :D
Quote
Sir Howard Stringer, chief executive of Sony, on Christmas sales of the PS3:
"It's a little fortuitous that the Wii is running out of hardware."

pianohombre

  • Full Member
  • ***
  • Posts: 194
    • View Profile
    • My personal website of short stories and comics
Re: How were early 8 and 16-bit games programmed?
« Reply #4 on: November 03, 2017, 12:31:15 am »
@FAST6191,
Yes, if they were using assembly, such as in your example of the Link's Awakening game. That would make more sense. An organized directory of 10-20 asm files. Rather than what we see in hexadecimal programs, lines of confusing op codes and memory addresses. With comments and notes I suppose it's a lot more feasible, even if it's assembly. I can understand an easy game made in assembly like Mario 1 for NES (less than 50Kb), but for these more complex games, that use so much RAM, and have hundreds of things going on in the screen, and dealing with loops, memory banks, switching palettes, only the top programmer who had been studying computer science for 20 years, would be able to code these beasts, it seems.
One small step for man,
one giant leap for mankind. -Neil Armstrong

FAST6191

  • Hero Member
  • *****
  • Posts: 2172
    • View Profile
Re: How were early 8 and 16-bit games programmed?
« Reply #5 on: November 03, 2017, 01:36:04 am »
One of the parts of learning assembly for people is when they realise they can go from small snippets to actually useful operations (I had a nice one once that ran through a CRC check or something, most likely somewhere in either https://stuff.pypt.lt/ggt80x86a/asm1.htm#toc or http://www.plantation-productions.com/Webster/ ).

"hundreds of things going on in the screen"
Assuming that is the case (you would have to get to a very small level of delineation for that to count to me) then while the NES was hardly a multi core monster you do still have the option to get something done with serial processing. I doubt any programmer had a full mental model of what was going on on the screen at any one time -- it was likely all a bunch of smaller screen handling routines, layers and sprite priorities. They may have been able to drill down into any one aspect but being able to do a complete in head emulation was likely not skill seen so very often in that world.
Similarly many of those routines are simple and may only have apparent complexity (the Castlevania fleas, and possibly medusa heads, moving randomly was a somewhat notable thing) if your bog standard human tries to do it all at once, in their head without any great understanding of programming graphics. I was contemplating a new round of "things you have seen as a hacker", similar to how it is hard to impress a chef with food, make a comedian cringe or wow a cinematographer with your film... maybe I will do it later.

Similarly with RAM then is it all data going off at once, possibly some self modifying code, maybe some obfuscation or the assembly equivalent of an esoteric language (or just something like return oriented programming a couple of decades before it was invented)? No. Still got your core loops (likely dictated somewhat by vblank lengths), probably not a lot in the way of bounds checking, and maybe a stats bigger table to play with. You can still build up the program from basic concepts and then file off the rough edges, optimise sections to whatever ends and drop features to get under your instruction/memory/storage budget. Likewise is your complex game a single game or a series of games? I like Earthworm Jim on the megadrive, most consider it a platformer but in reality it (and especially the sequel) are a bunch of different games stapled together. People occasionally joke how Final Fantasy the story takes place in a separate reality (even got a nice screen effect to signify the switch) from the battle... guess where my comments would be going next if it was not a bit late right now and I wanted to type them out. Banks are storage, often no more troublesome than "insert disc 2 to continue" or "look at book 3 for information on this" to handle*. The makers of the consoles also wanted people to make games for them, and make them themselves, so they tended to have features there which helped people achieve this goal.

*ROM hacking occasionally finds it a pain first of all for the memory addressing being a bit abstract in many cases but more as the kinds of changes that might want to get made can conflict with the core of the program. Going back to the book example you can reference book three in the text if you like, however anybody just changing numbers and the contents pages is going to come unstuck. The original author presumably noted the cases of such references (or might remember them), and maybe made efforts to reduce and minimise use of such constructs and thus might be able to handle them better. The ROM hacker lacking such notes then has to either hope there are none or hunt through for them, and hope there is no bk 3, book 3, book III, bkIII, book three, third book, 3rd book and definitely no second and third books contain them respectively.

There were no doubt some amazing people working in that world then (there still are) -- pick some of the interviews with Yuzo Koshiro (streets of rage music composer/programmer) and he did some crazy stuff, and I could carry on listing people like that for a while.
At the same time your bog standard php/java programmer may well struggle with many of the concepts, and that would in turn mean the idea of the programmer lost some of its cache over the decades. Similar thing was once said for reading.

You may be doing something similar to the new people that consider using a hex editor is as some kind of magical skill, however rather than editing a text section or something you are doing it for assembly.

KingMike

  • Forum Moderator
  • Hero Member
  • *****
  • Posts: 6177
  • *sigh* A changed avatar. Big deal.
    • View Profile
Re: How were early 8 and 16-bit games programmed?
« Reply #6 on: November 03, 2017, 02:32:53 am »
I can understand an easy game made in assembly like Mario 1 for NES (less than 50Kb),
Are you saying you can easily understand a game with small code?
Because writing a game (especially a game like Super Mario Bros. which was probably relatively complex in its day) with such a small amount of memory was probably not easy.

I read that to be able to do anything decent on 2600, you have to not only micromanage assembly for code space but also execution time as well (something you wouldn't be able to do in higher-level languages).
Quote
Sir Howard Stringer, chief executive of Sony, on Christmas sales of the PS3:
"It's a little fortuitous that the Wii is running out of hardware."

FAST6191

  • Hero Member
  • *****
  • Posts: 2172
    • View Profile
Re: How were early 8 and 16-bit games programmed?
« Reply #7 on: November 03, 2017, 09:55:48 am »
Is that such a bad thing on older RISC processors? I will give some of the things I have seen have been more timing accurate than interrupt driven (one of course would not even dream of wasting cycles on a check) like we saw on the systems after that.

Equally cycles stuck around for a while. Here it is on an introduction to GBA graphics http://www.coranac.com/tonc/text/video.htm and another https://www.cs.rit.edu/~tjh8300/CowBite/CowBiteSpec.htm#Graphics%20Hardware%20Overview
It is also not absent from things I see in programming courses when they teach assembly to C and such programmers, though some of the focus has gone to the branch prediction and cache miss family.

Also because I did not link it before and it seems appropriate now
http://www.catb.org/jargon/html/story-of-mel.html

Jorpho

  • Hero Member
  • *****
  • Posts: 3650
  • The cat screams with the voice of a man.
    • View Profile
Re: How were early 8 and 16-bit games programmed?
« Reply #8 on: November 03, 2017, 11:33:50 pm »
There was all sorts of news recently about how Sakurai programmed the first Kirby's Dream Land (or at least a prototype thereof) using just a trackball.
https://arstechnica.com/gaming/2017/04/the-first-kirby-game-was-programmed-without-a-keyboard/
This depresses me. I feel like a goldfish right now...

FAST6191

  • Hero Member
  • *****
  • Posts: 2172
    • View Profile
Re: How were early 8 and 16-bit games programmed?
« Reply #9 on: November 04, 2017, 07:06:25 am »
Forgot to link up
https://www.youtube.com/watch?v=Kalmryn9_sE
Guy is making stuff for the megaCD but using many of the same tools and covers a lot of good stuff along the way.

jonk

  • Sr. Member
  • ****
  • Posts: 252
    • View Profile
Re: How were early 8 and 16-bit games programmed?
« Reply #10 on: November 04, 2017, 07:09:44 pm »
I'm going to reduce your question to 8-bit games since those were the "early ones" (unless you are talking about games on the PDP-11.. but that's a different animal, entirely.) Your topic is also pretty much bait, in a way. But fun bait just the same.

Most guides say they were written in Assembly, but C++ has been around since the '70s, and they also had Pascal.
Pascal had been around since Dr. Wirth first invented it (my recollection says "late 1960's" and perhaps to the "early 1970's" when I first heard about it. However, it was very very difficult to get ahold of -- unless you were a student at an elite college and an up-to-date teaching crew. Which means most of us hoi-polloi couldn't get our hands on it, even through we tried (I certainly tried.) When UCSD Pascal came out, things became a bit easier (roughly 1980?) and books arrived in the late 1970's discussing the P-machine, which really did help people in porting Pascal on their own. Wirth also wrote a book (black hard bound cover, as I recall) called "Algorithms and Data Structures" in 1976 (which I bought) and near the end of that book Wirth develops a PL/0 interpreter which also went a long ways in helping people just "get started" writing their own interpreters.

This is around the time that "The C Programming Language" book came out (1978) and when I was first working on the Unix v6 kernel code (written in C and in PDP-11 assembly code.) It was my own first experience with C.

C++ was NOT here yet! Not in the late 1970's. It was being used by Bell Lab's as part of some research on their telephone switching systems, circa 1980 or so. But it was NOT in any way or form available to the public at this time. I think the first announcement I saw about C++ would have been around 1985. It was still "C with classes" at least until 1983 and probably later. When I first saw it, circa 1985, it was a pre-processor called CFRONT (last version was 4.0) And I was writing compilers, so I was kind of around these people and exposed as much as anyone to it, I think.

So no C++ in the 1970's. Sorry, not so.

For most of us doing coding on the Altair 8800, IMSAI 8080, Apple II, and IBM PC (and I was a cofounder of a company selling Apple II and IBM PC software nationally), it was assembly code. Memory was quite tight. I don't think most people today have any clue at all about that. It was very tight. By the time the IBM PC first came out in August of 1981, the standard memory system was 64k byte! And I considered that to be "HUGE." I'd developed a complete interpreter to fit in just 5k byte leaving room for user programs in the remaining 3k byte of an 8k byte system!! So for me, 64k byte was incredible. But still, commercial applications needed RAM and even the few C compilers available at the time were not particularly efficient in their code generation. There really was little choice in the matter. You wrote in assembly. You also wrote in C, perhaps. And sometimes you used BASIC as a "harness" of sorts and used it to invoke your assembly code.

I don't think I started writing applications "mostly in C" until about 1985, or so. Even then, there was still a requirement for assembly coding -- for commercial applications, anyway. Windows 1.0 through 1.04 also came out (none of them worked worth crap.) It wasn't until Windows 286 and Windows 386 arrived (windows 2.10) that anything was worth a darn. Here, you coded in C and assembly, routinely.

For games, it all depended. For games which targeted "game machines" that had very little RAM available and relatively slow processors, you were pretty much stuck writing assembly code -- perhaps in a mixture with C, if lucky. There was NO POSSIBLE WAY you could do this without the use of assembly code. If for no other reason, then because C itself doesn't have the semantics and syntax to permit the required hardware mapping (C uses a very strict and rather simple model of the world, which pretty much fits zero game machines of the time.)

There are engines today, such as Unreal Engine, that are used to reduce time to create a game.
Well, 30 years and more have passed. There were no packaged software back then. If you were a business and wanted to use an Altair 8800 for business work, you hired a custom programmer. Because there were NO PACKAGES. Didn't exist. Not at first, anyway.

Today, you have veritable oceans of RAM and multi-core CPUs and at least a factor of 10 if not a factor of 100 more programmers out there developing tools for you.

I really find it hard to believe every game in the 80's and 90's was created by scratch, in ASM, especially since many Nintendo and Capcom games look very similar. Seems like you could upload 100-500kb of graphics and some program would store it all correctly, and the programmer would just need to write things like which direction the graphic fired, or what graphics to display when he died, upgraded armor.

Well, you are bandying years around a lot. The 1990's were nothing like the 1980's which were nothing like the 1970's which were nothing like the 1960's, to be honest. Have you ever worked with a mercury delay line memory? I have. These are tubes of mercury with little vibrations in them. The ones I worked with could store 2000 bits in them as a "circulating memory." You'd rack up 42 of these to make up a single 42-bit wide memory system with 2k to work with. Ever work with a drum memory (8k byte the size of a washing machine and costing more than a car and slow as molasses?) I did. Ever work with core memory (little donuts with three wires threaded through each of them and looking like a kind of "weaving loom" of sorts?) I did.

The 1990's saw the demise of the RISC vs CISC wars of the mid to late 1980's, the advent of the reflection wave PCI bus and the movement towards the new Windows NT/2000 kernel. Memory systems were measured in 100's and then 1000's of megabytes, processor speeds near and then exceeding 1 GHz in that decade. The 1980's were basically going from the 8080 to 8086 transition at the beginning of the decade and memory sizes typically in the 8 kb to 64 kb area, to the 80486 and fast floating point and memory sizes that were 1000 times larger. 1985 was the first year that Intel made more money selling processors than memory! The 1970's started out with no microcomputers at all and the cheapest minicomputers costing $100k (back when $100k actually meant something) for a PDP-8, to the development of C as a language and the PDP-11 16-bit minicomputer (costing in some cases nearly one million dollars) to the development of the first affordable kit computer, the Altair 8800 in the last 1974 to early 1975 period. Calculators were horribly expensive, but at least they were no longer the mechanical monsters of the 1960's! Glass terminals were in their infancy and didn't become more common until the TV typewriter or the ADM-3A (I built one from a kit) or the Altair 8800 memory-based displays. Graphics was almost unheard of and we were using periods and asterisks on line printer paper to print pictures, for gosh sake. Pong was the game of this decade. The 1960's? Multi-million dollar computers on raised, air-conditioned floors built in special buildings and owned by just a few of the wealthiest companies in the world.

When I wired up my first computer, it was using 7400 parts. I designed it. And it worked. Had the news folks at my doorstep because "some kid made a computer in 1974." When I next built an Altair 8800 from a kit, it came with 256 bytes of memory. I could not even afford to buy the added 768 bytes of memory I wanted, which could have fit into the three remaining empty sockets on the board. 256 bytes of memory cost me almost as much as the entire computer did!! I couldn't afford it. So it wasn't until a year later that I could afford to buy two 4k dynamic ram cards (which I had to make, of course.) Around this time, all I did was write in assembly code (or machine code directly, toggling in the bits with my fingers.)

Darned yes, people wrote entire commercial applications in assembly. You are talking to one who did. I also later got to work on the Intel chipsets you use, working at Intel in the 1990's.

Language choice depends a great deal on circumstances. Until at least 1986 or so and probably until after 1990 in many case, game machines were just too cost-conscious and strapped for resources to make extensive use of higher level languages and still have their game products be very competitive. Those that delivered well and survived well were almost certainly heavy in assembly code, I believe.
« Last Edit: November 05, 2017, 01:08:32 am by jonk »
An equal right to an opinion isn't a right to an equal opinion. -- 1995, me
Saying religion is the source of morality is like saying a squirrel is the source of acorns.  -- 2002, me

KingMike

  • Forum Moderator
  • Hero Member
  • *****
  • Posts: 6177
  • *sigh* A changed avatar. Big deal.
    • View Profile
Re: How were early 8 and 16-bit games programmed?
« Reply #11 on: November 04, 2017, 11:16:02 pm »
Let's not forget ZSNES was originally written in assembly entirely (probably part of what eventually killed it. Too much work updating it to C once the speed advantage of being written ASM no longer mattered and they were left with unmaintainable code).
Probably why I was able to even play SNES games on my original 486 PC... by turning off sound and maximizing frameskipping, and it worked great... until games crashed due to the completely absent sound emulation. (since SNES9x ran much slower but didn't freeze my guess was partly that it was still emulating the sound but not outputting it)
Quote
Sir Howard Stringer, chief executive of Sony, on Christmas sales of the PS3:
"It's a little fortuitous that the Wii is running out of hardware."

Psyklax

  • Sr. Member
  • ****
  • Posts: 412
    • View Profile
    • Psyklax Translations
Re: How were early 8 and 16-bit games programmed?
« Reply #12 on: November 05, 2017, 06:00:39 am »
Nice to see someone who knows what they're talking about in this thread. :)

Memory was quite tight. I don't think most people today have any clue at all about that. It was very tight.

I have to quote a well-known song here:
https://youtube.com/watch?v=Ts96J7HhO28
"Hey hey 16k, what does that get you today? You need more than that for a letter". So you tell me why nobody coded games in C, when every single byte mattered.

And what about the Atari 2600? In some games you can see black lines on the side of the screen: that's actual game code, appearing on the screen because there's not enough room for it to fit in regular memory. Now THAT'S tight.

Programming today is so easy: look at all the Steam Greenlight/Early Access games which use existing engines, existing assets, almost everything has already been done for them - and there's no point in optimising because everyone has gigabytes of RAM and hard drive space, with 3GHz processors.

Anyway, I think the OP has got a definitive answer to his initial query by now. :D

FAST6191

  • Hero Member
  • *****
  • Posts: 2172
    • View Profile
Re: How were early 8 and 16-bit games programmed?
« Reply #13 on: November 05, 2017, 10:09:14 am »
If we are pushing the scope of the thread that much then
https://history.nasa.gov/computers/Ch6-2.html

or indeed the lot
https://history.nasa.gov/computers/contents.html

jonk

  • Sr. Member
  • ****
  • Posts: 252
    • View Profile
Re: How were early 8 and 16-bit games programmed?
« Reply #14 on: November 05, 2017, 02:28:28 pm »
If we are pushing the scope of the thread that much then
https://history.nasa.gov/computers/Ch6-2.html

or indeed the lot
https://history.nasa.gov/computers/contents.html

Thanks! That almost reaches as far back as my own personal experiences.  ;) I still remember plug-board computers, too. I'll peruse that site and see what it brings back. (I started circa the transition between vacuum tubes and the first symmetric constructed BJTs, where the collector and emitter were fully exchangeable and gain was rather terrible and germanium was quite common [these days they are planar, silicon, and quite different and better performing, of course.])
An equal right to an opinion isn't a right to an equal opinion. -- 1995, me
Saying religion is the source of morality is like saying a squirrel is the source of acorns.  -- 2002, me

pianohombre

  • Full Member
  • ***
  • Posts: 194
    • View Profile
    • My personal website of short stories and comics
Re: How were early 8 and 16-bit games programmed?
« Reply #15 on: November 09, 2017, 02:35:58 pm »
Hi Jonk, thanks for the informative reply. No, most of that computer stuff I've only read about in textbooks or seen on websites, like the NASA one. By the time I studied computers even the Apple II was ancient history, and most were rigged with some version of Windows operating system, although we have used Ubuntu Linux to write a few programs in assembly and C. Yes, I had meant C in the '70s. Today C and C++ seem so similar, usually the only way I can differentiate is by which include files they are using.

It's hard to imagine today, people grinding things out in hard ASM to make a game for Sega or Nintendo, but I guess it makes more sense, seeing as most probably went to top universities back in the day, and they had a whole team for development of these games, which were anywhere from six months to a few years for some of them (or for a few of the crappy ones were made by one person in the span of a month or two). Game Maker has sure simplified a lot of things.
One small step for man,
one giant leap for mankind. -Neil Armstrong

jonk

  • Sr. Member
  • ****
  • Posts: 252
    • View Profile
Re: How were early 8 and 16-bit games programmed?
« Reply #16 on: November 09, 2017, 06:27:11 pm »
Hi Jonk, thanks for the informative reply. No, most of that computer stuff I've only read about in textbooks or seen on websites, like the NASA one. By the time I studied computers even the Apple II was ancient history, and most were rigged with some version of Windows operating system, although we have used Ubuntu Linux to write a few programs in assembly and C. Yes, I had meant C in the '70s. Today C and C++ seem so similar, usually the only way I can differentiate is by which include files they are using.
I think of them as quite distinct. You can write a C compiler fairly quickly (I can, anyway.) It's not hard. On the other hand, C++ despite its similarities, has some very very significant changes which greatly complicate the compiler. And I cannot think of the two as being the same, or even similar, despite the fact that you can write "nearly C" code and use a "C++ compiler" on it. For example in C++, because it must support exception handling, you might call a function called "X()", then create an object (like a string, perhaps), and then call the same function "X()" again, right afterwards. In C (if you could do this), both calls would look exactly the same at the assembly level. But in C++, it's not. The reason is that before the string was created there were no objects that needed to be destroyed if an exception took place in X(). But after the string is created, it must be properly destroyed if an exception occurs in X(), and then propagated upwards. Even if there is no try-block in the function and even if the function otherwise does nothing at all with exceptions. Just the fact that an exception MIGHT happen means the compiler does different things in different circumstances. I consider C++ to be a "programmer's programming language." One that should ONLY BE USED by those who are the best of the best programmers. Because only those people are prepared to understand things like "partial template specialization" in C++ and why one might care, or not care, about it. Etc. C++ is not a language for the faint of heart. Of course, in reality, all of the computer courses at universities cannot teach C anymore. Not because it's wrong, but because customers (their students) will find another university to go to if they cover C instead of C++. So it is a matter of "marketplace" that forces something I think is wrong to teach so early, is all.

It's hard to imagine today, people grinding things out in hard ASM to make a game for Sega or Nintendo, but I guess it makes more sense, seeing as most probably went to top universities back in the day, and they had a whole team for development of these games, which were anywhere from six months to a few years for some of them (or for a few of the crappy ones were made by one person in the span of a month or two). Game Maker has sure simplified a lot of things.
I developed most of a nationally sold application for the Apple II in assembly, by myself. We quickly hired on some added programmers and we then moved towards a combination of BASIC and assembly for the Apple II (because I had to train these people) and similarly for the IBM PC version. Keep in mind that the early games didn't do 3D graphics and the art was "rather childish" for the most part (I mean that in a nice way.) I did my own graphics, too. And I'm NOT an artist, nor even close to a good one. By around 1990, though, a lot of gaming was starting to move towards larger teams where you had artists and musicians working together with story writers and programmers. For example, the Borland "Living Books" series is a very good example of this level of teamwork. The bar had risen by around this time and, yes, it took teams to do the work. But around this time, also, more memory was available and so were faster computers. So the need for assembly coding was a lot less, too, and I rather doubt that "Living Books" was largely written in assembly -- almost certainly not, in fact.
An equal right to an opinion isn't a right to an equal opinion. -- 1995, me
Saying religion is the source of morality is like saying a squirrel is the source of acorns.  -- 2002, me

Psyklax

  • Sr. Member
  • ****
  • Posts: 412
    • View Profile
    • Psyklax Translations
Re: How were early 8 and 16-bit games programmed?
« Reply #17 on: November 10, 2017, 03:09:09 am »
It's hard to imagine today, people grinding things out in hard ASM to make a game for Sega or Nintendo, but I guess it makes more sense, seeing as most probably went to top universities back in the day

It's really not as difficult as you make it sound. Look again at the ZX Spectrum: the Oliver Twins were making top selling games while they were still at school. I think Matthew Smith made Manic Miner and Jet Set Willy when he was around 16. Most programmers for the 8-bit computers were young, and did their own graphics and sound, too. Look at homebrew games. Sure, a lot of them are simple, but you don't need to be a university grad to do it.

Bregalad

  • Hero Member
  • *****
  • Posts: 2489
    • View Profile
Re: How were early 8 and 16-bit games programmed?
« Reply #18 on: November 11, 2017, 03:41:32 am »
Quote
Today, you have veritable oceans of RAM and multi-core CPUs and at least a factor of 10 if not a factor of 100 more programmers out there developing tools for you.
As a result, the salaries dropped by a significant factor and difficulty to be hired increased by a significant factor. The days when "being able to program a computer" made you a very special person are long over :(

Quote
If for no other reason, then because C itself doesn't have the semantics and syntax to permit the required hardware mapping (C uses a very strict and rather simple model of the world, which pretty much fits zero game machines of the time.)
I wonder what exactly do you mean here ? Are you refering to memory-mapped IO ?

FAST6191

  • Hero Member
  • *****
  • Posts: 2172
    • View Profile
Re: How were early 8 and 16-bit games programmed?
« Reply #19 on: November 11, 2017, 05:16:32 am »
Quote
Today, you have veritable oceans of RAM and multi-core CPUs and at least a factor of 10 if not a factor of 100 more programmers out there developing tools for you.
As a result, the salaries dropped by a significant factor and difficulty to be hired increased by a significant factor. The days when "being able to program a computer" made you a very special person are long over :(

Whenever I read such things I tend to mentally substitute the words such that is refers instead to basic literacy and the printing press and what have you.