The Trouble With Graphics Today...

Introduction

I`ve been wrestling with how to develop on PC for some time now. Should I use DirectX 9, 11 or 12? Should I be coding in 32-bit, 64-bit, or both, or do I mean either? Should I be using C or C#, or something else? Should I be using someone else`s engine, like Unity?

 

I thought I`d try doing some simple graphics instead. In the words of Jack Slater: "Big Mistake!"

 

The 8-Bit Days

I started as a games programmer in 1983. My first task after learning 6809 assembler was to convert Steve Turner`s 3D Space Wars from the ZX Spectrum to the Dragon 32. To this end, he already had the completed game, albeit in hexadecimal, there was no assembler source code. I had access to the original programmer/graphics artist and my target computer had the same resolution as the original, with less colours to choose from, well no colours really, I was working in black and white mode.

 

The original graphics had been drawn on large scale graph paper and the hexadecimal values worked out and written by the side. I didn`t need to do any new graphics to start with. About 5 weeks later as I completed the coding I realised that I had plenty of RAM spare as the Spectrum version was written to run in the 16K Spectrum, and the Dragon had 32K. This was when I got my own pad of graph paper!

 

I figured I would add some more space ship designs so I set to work with my trusty 2B pencil. It was just a case of colouring in the squares. Colours then become bit-settings and bits become hexadecimal bytes. I then typed the bytes into the assembler and could see whether it looks like my diagram or makes a mess, which I have to fix.

 

I did a few more spaceships, then redesigned the refuelling ship graphic to be a bit bigger than the original, and finally designed a border to go round the screen to look like it was a view-screen. Of course that`s just a trick to make the game screen a bit smaller so there`s less chance of having to plot all the objects on screen at once, and it`s easier to see if the edge clipping is working in the plot routine. I was getting pretty good at looking at eight squares and coming up with a hex value too.

 

 

 

For the second converted game I knew that I would have spare space again so I would be doing some more graphics. I set about writing a graphics editor in Dragon BASIC. This would allow me to see the graphic immediately on screen, generate the data, and eliminate any hex working out errors. Most of the screen was a big-scale graphic, just like my graph paper, and each pixel could only be on or off. It was pretty simplistic but it saved me a lot of editing time. The Dragon mercifully had a proportional joystick which made editing a bit less tiresome.

 

 

 

 

 

4 Colours!

I switched to the C64 in 1984. Firstly I converted 3D Lunattack to the C64 in order to learn 6502 assembler and the hardware; with a game I already knew. The game design was not native to the C64 and didn`t use the character modes, but I did get to use the hardware sprites.

 

 

 

I needed a new editor for the hardware sprites. The data format was somewhat different than we had used before. Fortunately we found Ultrafont and Sprite Magic on sale in the local computer shop and I got those moved onto a C64 floppy disk to save the tape from wear.

 

For my first original game I wanted to use the native C64 multi-colour modes for the graphics. For these you get 3 shared colours and one unique one per character or sprite. The pixels are double-width though, your screen resolution is 160x200 only. I`ve mentioned before that when designing your game look, the choice of shared colours is vital to get right, or you`ll struggle with being able to draw anything. I found that out in Morpheus. If you happen to get it right by accident then you don`t even realise that you could have got that choice wrong.

 

Actually there was an extra complication in Gribbly`s Day Out. I was using sprite to background collision detection for Gribbly and Seon. You just get a 1 bit notification in a hardware register for each sprite that says that one or more pixels overlapped one or more pixels in a background character... of colours 2 or 3. Thus when designing the graphics you need to use a lot of colours 2 & 3 where you want to stop the sprites, and colours 0 and 1 where you don`t. The background sky was colour zero, and I did things like make the waterfalls colour 1 so you can fly through them, and the ground and rocks and mainly colours 2 and 3. Similarly the energy barrier switches are colour 1 so you can fly over them, and the barriers are predominantly colours 2 and 3.

 

Back to the graphics though. I managed to come up with some pretty hallucinogenic colour schemes for Gribbly`s without really trying. Generally you need 2 colours that go together, one lighter, one darker,  contrasting background colour and another different colour that shows up. I wasn`t scrolling the colour attributes, they were all set to the same colour. That kept things fairly simple. There aren`t any shadows being cast, but we do need to create form, which was just a one colour plus a highlight sort of job. I could just about use the third colour for darker low-lights.

 

 

 

I started Paradroid in multi-colour too, but I was trying to get a blue-print type look. The colour choices are a bit too vivid, there are only 16 colours available and having pixels twice as wide was not giving me the level of detail I wanted. I therefore took the decision to go for a 2-colour presentation. In order to get more on-screen colours I upped the scale of what I was doing so that structures such as walls used more than one character, and by scrolling the attribute map (or, more accurately, re-creating it every game frame), I could create light and shade. I couldn`t use sprite to background collision, but I stuck with sprite to sprite collision.

 

Ultrafont was able to let me create all the graphics quite quickly in multi-colour or "hi-res" mode. Organising the background characters was straightforward as the only distinction I needed was whether the character blocked movement or not. If you put all the blocked characters at one end of the character set then the test is simply a cut-off point.

 

The colour choices for the decks were quite straightforward too: the deck needed to be a mid colour so that the walls could have a highlight and a shadow colour. The floor patterns then needed to be a contrasting colour and I could use individual attributes for the alert status. I reserved white for the player, and black for the other robots. They always showed up on any background. 

 

 

 

Uridium provided me with a new specification, since I wanted metallic-looking graphics and fast scrolling, so I couldn`t afford to set the attribute colours every frame, though I did get the Uridimine ports to glow. Uridium being metallic, I started with a set of greys. The C64 has 3 grey shades, plus black and white, so there's some wiggle-room. Space is black, obviously, and on top of that we need a base colour, a darker shadow colour and a lighter highlight colour, usually white, for that harsh light look. I did run some different colour space, if memory serves, just to spice things up.

 

The sprites for Uridium then can use a similar approach of a base colour and a lighter and darker version. With the grey backgrounds we can get some bright colours onto the sprites so they show up nicely, except for the Manta, which is predominantly white so that it too stands out, but in a different way.

 

 

 

Alleykat`s graphics were influenced by my playing of Pastfinder on the Atari XL. The viewpoint was from 45 degrees behind rather than top-down or side-on, though the game was able to behave as if it were top-down. We had harsh lighting again, but no black background this time, though I`m thinking that since it was set in space then some see-through bits of inaccessible track would have been interesting. 

 

The graphics viewpoint really defined the colours. I needed a top colour, a back colour, a ground colour and a shadow ground colour. Drawing the graphics was as straightforward as building with Lego. I deluded myself that I was getting the hang of this graphics thing.

 

 

 

I got to Morpheus and came up with a different stark metallic look using all 3 greys plus black and white as the colour attribute in multi-colour mode. This gave me the font and the main ship graphics, also done in characters. I just had to get the sprites right. Whatever shared colours I chose, and I don`t even want to remember what they were, I got them rather wrong. I was struggling to come up with any graphics. I had some single-colour sprites for muzzle flashes, so I just needed a fleet of meanies that could attack the player in space.

 

Each sprite gets one unique colour, plus, if it`s in multi-colour mode, it shares two other colours between all of the multi-colour sprites. If you choose those two shared colours incorrectly from the palette of 16 then whatever third colour you put on them doesn`t go. This was the dilemma I had.

 

I shared my problem with John Cumming, as he was working on Zynaps and coming up with graphics quite happily. He suggested I change the shared colours. We ended up sharing white and a dark grey, which allowed me to put any other colour in that I wanted, which would usually be something more colourful. I could also use hi-res animated sprites to produce other metallic effects. I had a sprite multi-plexor implemented for this game for the first time. I might have even used two sprites overlaid to get an extra colour onto some objects. Since I didn`t show any player bullets with sprites, only muzzle flashes and the character-based Defender-inspired toothpaste guns, there were plenty of sprites available.

 

 

 

I went back to the Uridium-style presentation with Intensity, though I could set the colour attributes for each individual character since I wasn't scrolling the screen. The sprite multi-plexor was altered to do shadows for most of the sprites. The shadow graphics were single-colour, generated at initialisation time, and had to match the background character shadow colour.

 

 

 

16-Bit

I had an Amiga A1000 at home, with Deluxe Paint. I bought each new edition as they came out. The idea of being able to pick up any part of your picture as a brush was genius. You might only pick up a couple of pixels, but then being able to draw a line with them saved so much time. You could draw a whole grid of guidelines to arrange your graphic images neatly. The other genius feature I used a lot was the stencil mode, so that you could pick up graphics without the guidelines, or cut out your font and insert some new colours in so easily.

 

I did sit down and do some space ship graphics using the 32-colour mode. I set up a nice array of grey shades and that allowed me to smooth out the graphics. It wasn`t really improving my artistic abilities any, as games tended to need more different colours. I was beginning to feel my graphical limitations.

 

 

 

The graphics artists at Graftgold were artists who used computers, whereas I am a computer user who tries to do art, or maybe more correctly, graphics design. I like messing about with fonts but don`t have the artistic talent to do big graphics. I drew all the fonts that were in my games, From Gribbly`s Day Out right the way through to Uridium 2. I didn`t design all the fonts, but implementing them was all me. I used multiple 8x8 characters to do the Gribbly`s Day Out and Paradroid fonts, including partial variable widths since the lowercase m and w were wider, and the uppercase I was narrower.

 

 

 

I did draw some Paradroid `90 background graphics, but again that was graphics design, not art. The real fiddly bits and the big pictures were done by the proper artists. Working with a whole screen of graphics must have been tricky for them. I was programming while they were creating those.

 

 

 

64-bit

So now I sit here behind the most powerful computers I`ve ever worked on and I can`t find a way to work with pixels. I`ve got my flashy new 3D Paint and I thought I`d start with a fixed width font and overpaint it. I can`t see a way of getting a DPaint-style grid up to enable me to work free-hand. So I typed in all the ASCII letters from Hex 20 to 7E in a decent size courier new font. Since it`s lovingly rendered the letters with some anti-aliasing it`s difficult for me to even modify the letters in the same style. It`s actually being way too clever for my own good.

 

I downloaded half a dozen recommended free graphics packages. I sat on the Tokyo to Kyoto Shinkansen with my laptop and set about colouring in a font. I didn`t even get one alphabet done because there are actually too many colours to work with. The packages seem to think we have to do everything freehand. I spent more time undoing the mess I was making. How do graphics artists work like this? It`s like painting a jumbo jet with a number 3 brush and a billion pots of Humbrol enamel paint.

 

One package I downloaded stumped me completely, I never managed to set a single pixel colour on the drawing grid. It was like trying to enter a program on the Unix Vi editor: it can do everything in one keystroke except type! 

 

Just what tools are people actually using? 

 

Conclusion

Clearly someone doesn`t want me, or anyone else, to be working with individual pixels any more. We appear to have to algorithmically generate everything. I appreciate that we can`t necessarily control how the graphics are rendered since we may not control the screen resolution, but I`m old school, and if I want to render some retro graphics  then I want what I want, I don`t want to have to cook up some code recipe for getting roughly what I want in realistic glory.

 

I still haven`t found any art package that allows me to do what I could do 30 years ago with DPaint II. I did find my PC DPaint, but that`s a 16-bit application, and isn`t playing ball, nor would its output files be of much use to me.

 

Should I be running an Amiga emulator on a PC with DPaint II? I doubt it because the end PC isn`t going to handle the output LBM files anyway. I believe I should be using PNG files.

 

More likely I should give up on pixels and be building all of my graphics out of 3D models and endless textures. I was reading up on the World of Tanks team's graphics techniques and that was just frightening. The game looks fantastic, but how many hundreds of people have they got capturing textures, making the models and working out the maths for that lot?

 

In 1998 we had an end-to-end development path to capture graphics, work some artistic magic, then format the graphics into game-friendly formats and incorporate them into our game. 20 years later and it`s all changed and gone. I thought progress was supposed to make thing easier. It hasn't. We live in a photo-realistic world, and I don`t like it!