At the very beginning of time, when I was writing on the Dragon 32 and Steve Turner was working on the Spectrum you could draw your graphics on graph paper with a pencil. Each pixel was either on or off, there were only 2 colours. We did also have to create a "mask" which told the plot routine which pixels were plotted and which were transparent. Some really early games didn't even do that, you can see squares around the graphics.
The data we used to define sprites was mostly raw pixel data, we just had a couple of bytes at the beginning to say how wide the graphic was, plus an offset for adjustment of X positioning, then one or more columns of 8-pixels of data, again with an offset adjustment for Y positioning. We would draw the graphic, work out the hex value, and type in the data into the assembler as data to be loaded.
Moving to the Commodore 64 we had a hardware chip that imposed rules on where you put the data to be displayed, nd the format. You had to designate 1 quarter of the RAM space to contain all the displayable graphics at any one time. Likely you could alter that during the frame with a raster split, but we didn't bother. Each 64 bytes in the 1 quarter of the RAM space could represent 1 hardware sprite. The first 63 bytes were interpreted as 21 rows of 3 bytes in either multi-colour mode or single colour. The final byte was a spare. For Lunattack I again keyed in the data and stuck mostly, if not completely, to single colour sprites, e.g. the gunsights and HUD displays.
Multi-colour data requires you get your colouring pencils out on the graph paper. Working out the hex values is harder, so I didn't waste any time getting to the local computer shop and buying SpriteMagic, which was paired with CharFont, I think it was called, which did for character sets what SM did for sprites. Sprites being a fixed size and position, there is no header data with offsets, so the data format is simple, it's just the raw display data with a spare byte at the end. You just load and save your raw, or binary, data, and again you can tell the Assembler to include the same edited raw data file at a fixed location in memory.
When we moved onto the 16-bit machines, even though we only had 16-colours on screen, aside from raster-splitting tricks, I had to hand over graphics drawing duties to other artists. As I have alluded to before, choosing what those 16 colours are going to be is very important. Get that wrong and you'll have all sorts of trouble drawing what you want. With no hardware on the Atari ST for sprites, we had to all the graphics plotting with software. We took a step back and designed a format with 16 and 32 pixel wide graphical vertical stripes that could be bolted together for bigger images. There were Y offsets for each vertical stripes to strip off and blank data, no point in wasting time plotting no pixels. A mask was included again to be able to distinguish a transparent colour.
We couldn't afford 15 different coloured pencils, but fortunately we had Deluxe Paint on the Amiga. At this point you are constrained by the save and load formats of the art package. The graphics were saved on sheets of LBM files, with animations stored usually on 32 pixel or 64 pixel boundaries. We didn't load those sheets directly into the programs though, we still wanted raw data, so we wrote a sprite picker that loaded in a sheet of graphics and then extracted the graphics from given co-ordinates on the sheets, and output the raw data, optimised to remove top and bottom blank lines, and containing the vertical slice sizes. We could then concatenate all the graphics together in one file. We also produced a header file of offsets into the raw data for each graphic image, and name the images so we could work with frame numbers still, like we did on the C64.
When you animate a game object then through, say 4 graphics, you know that the graphics are consecutive, and you just define an animation list that says which graphic you want and for how many display frames to hold it. By working with offsets from the "Base" frame, i.e. the first, you can reuse lists for different objects wanting the same animation sequences. We also introduced a second modifier for Paradroid 90 that was defined by the facing direction, so that when you draw a 4-graphic animation sequence pointing in 8 different directions then you have 32 graphics. Drove the artists mad drawing the same thing 8 times and lighting it differently.
Now we move to the PC, and we find that the middle-ware, DirectX wants to define the graphics formats to drive the hardware. That's not set in stone, there are options, but it is set in quicksand. Since we are no longer writing the actual plot routines, and the screen is out of reach on the graphics card, we have to rely on DirectX. Additionally, the formats required by DirectX, although many and varied, contain much more colour data, plus arbitrary alpha channel data which might be used for transparency, or bump-maps, or other data. The files required to be loaded by DirectX also have mysterious headers. The manuals we got with the Amiga explained the few data formats quite well. Even now you might find jpegs with different formats that some of your software can't deal with, but others can. With the compression algorithms built into jpegs they're unsuitable for game graphics anyway, but it illustrates that there are multiple data formats even for the same filetype, and they can be shrouded in mystery.
Right now I'm looking at graphics in dds format in some demos. I have found the DX tool to display the data in there, and can look in there with my hexadecimal display program, but I haven't found any useful documentation on the format yet. I have read the data into GIMP 2.8 (not my name, but it's a freeware drawing package), but that's got a really complex interface that is trying to be all clever things to all clever people. Again, no training manual. I haven't managed to choose a single colour or plot a single pixel where I want it yet. I'm thinking then that I need to write a simplistic graphics editor of my own that I can add to as I go along, but I need to crack the .dds file format or DirectX won't load it. The problem then with black boxes that just magically do what they want is that you can't see what they're doing. As a control freak I find this rather rattling.
I expect we'll have all the same trouble when we get to sounds! I wrote the Graftgold sound engine for the tank game we were writing at the end, and incorporated direction and Doppler-shifting plus a bit of optional variance on the playback sample rates so that the exact same sound wouldn't come out all the time. I expect that's all old-hat these days and it's all different and we have to use Dolby Atmos 11.2 sounds created in a studio. That's tomorrow's problem.
For now I'd like a simple editor that I can create some simplistic graphics and textures. You know what? I might go get the Amiga A1200 and Deluxe Paint from the loft. Except it reads 3.5" discs and my PC doesn't. USB stick? Not on an Amiga. No wonder I fear change.
Now where did I put that graph paper?
0 nhận xét:
Đăng nhận xét