Game Programming The Old-way

[xpan]

Hi,

I was wandering in which programming language all the retro games we now play[*] were written. I am referring to Z80/81 mainly (Spectrum, Commodore, Amstrad CPC).

Was it just assembly language or something else? How all those levels were drawn, and programmed? It must have been a real pain for those developers.

I only know object oriented programming (C/Java, etc). My way of thinking of a game is affected by the OO way.

Those days must have been really hard for programmers to work. These people were the heroes of programming...


[*] Thanks to all those emulators.

 

[senquack]

Object oriented programming is just a concept.

You can do it with assembly.

 

[Null]

Was it just assembly language or something else?

A few of them were programmed in BASIC, most were created using assembly language though.

 

[fishybawb]

Skool Daze for the ZX was written directly in machine code :blink:

 

[Sphinxter]

It was not that much different, there weren't all the libraries of stuff to use so you had to roll your own, nobody shared much but some of those things I still use today even. Big difference in it was a lot more time consuming, you worked about ten times longer between, 'oh!', moments and there was a lot more planning involved.

 

[Parkydr]

In some ways it was easier for the casual programmer. My BBC Micro had BASIC built in with a load of simple graphics built in, everything was single threaded, single process, single window - you just typed stuff in and ran it, no missing libraries etc. I think it's harder to start programming these days.

Of course, for most games you needed to use assembler, it is time consuming (still is) but having the whole machine to youself was easier e.g. the addresses were all physical addresses.

 

[gp32rich]

The graphics were simpler
The sound was simpler
The whole machine was yours and you could optimise as much speed as you could out of it.


Oh - Gameplay was king.



Not much point writing in assembly these days when the OS can sap more speed than you gain
Besides compilers optimising better too

 

[Squidge]

I remember changing the background colour on the Amiga at the start and end of subroutine to measure how long it took to execute - everything had to finish executing by the end of the raster frame to get the smooth graphics, otherwise it looked pants.

These days with Windows, you never have that kind of power. You can't even talk directly to the graphics card without going through several drivers first. Not that I'd want to, with how complex some graphics cards are these days, but it does annoy me that amount of flicker you can get if you don't sync on the vertical refresh and how much time you waste if you wait for it.

 

[sol_hsa]

One huge difference, if we're talking about making games for gp2x for instance - you have a much more powerful and versatile toy to build that game with - namely, the PC - instead of having to write code and compile on the device itself.

A friend of mine has done a few Atari ST demos recently, and most of the work has been to build tools that run on the PC that generate the data that the ST can use. =)

 

[A_SN]

it does annoy me that amount of flicker you can get if you don't sync on the vertical refresh and how much time you waste if you wait for it.

I don't see what's the problem, or rather, I see what the problem is, but I fail to understand what would be better than that. I mean, there's only so many frames a screen can display in a second, so you have to produce only that many. If your game loop is so fast you have to wait for v-sync, well good for you, but it'll be fast enough to do the next frame in time anyways so there's nothing to gain.

 

[Kramy]

it does annoy me that amount of flicker you can get if you don't sync on the vertical refresh and how much time you waste if you wait for it.

I don't see what's the problem, or rather, I see what the problem is, but I fail to understand what would be better than that. I mean, there's only so many frames a screen can display in a second, so you have to produce only that many. If your game loop is so fast you have to wait for v-sync, well good for you, but it'll be fast enough to do the next frame in time anyways so there's nothing to gain.

That's a tad shortsighted.

Lets say you have enough CPU power for...28 frames per sec; it takes about 35.7ms to do your gameloop and render a frame. Your game will be ~2.35ms late, and wait for the next refresh(~31ms). :angry:

Of course, proper buffering could solve that; set the frame aside, and start rendering a new one(aka Triple Buffering?) - but how often do you see buffering done like that? Usually it's just double buffering, and then your thread will wait until the next pageflip or w/e.

And tripple buffering often introduces input delay.

 

[A_SN]

Lets say you have enough CPU power for...28 frames per sec; it takes about 35.7ms to do your gameloop and render a frame. Your game will be ~2.35ms late, and wait for the next refresh(~31ms). :angry:

Of course, proper buffering could solve that; set the frame aside, and start rendering a new one(aka Triple Buffering?) - but how often do you see buffering done like that? Usually it's just double buffering, and then your thread will wait until the next pageflip or w/e.

And tripple buffering often introduces input delay.

Oh yeah I totally hadn't thought about that. Good point. Why can't LCDs just wait for you to tell them to refresh?