A Word About Music Media Formats

I started buying music in about 1970, on vinyl, of course. That's all we had. Cassette tapes had just arrived, so there was also the option of placing a microphone next to the radio or TV to try to get a decent recording, but I always ended up with a DJ yacking over the intro and ending, so it wasn't ideal, and let's not go into the legalities of such behaviour.

 

In order to atone for my misdemeanours I made it my mission, once CDs arrived, to buy everything I had listened to and liked (i.e. may have allegedly had on a C90). I believe I achieved this some years ago. It's not too many CDs actually, as my collection was politely referred to as "focussed", it's just over 1,000 albums, and growing slowly. That's less than an album a week, but later on you'll see I've been to the music shops more often than that.

 

I was very happy with CDs when they first came out in 1984: no vinyl pops and clicks, easy to pick out individual tracks, and easier to carry around. It's only later with the resurgence of vinyl lately that I do sort of miss the big covers with lyrics and cover notes you can actually read. You really knew you owned something with the big gatefold vinyl sleeves.

 

Have they fixed the vinyl pops and clicks? Well no. So why are some people buying them, now that they are more expensive than CDs when they used to be less? Unfortunately the CD format at 44.1KHz with 16-bit stereo data is barely adequate. So the vinyl carries a more accurate representation of the original music, albeit covered up by pops and clicks.

 

The thinking was that the human ear can only hear up to about 20KHz, so as long as we can do that on a digital medium then we're covered. Unfortunately those unheard higher frequencies that exist on the original analogue tapes do seem to make a difference, and the number of values that can be stored in 16-bits turned out not to be quite good enough either. To put that into perspective: digital mastering is typically done now at 96KHz and 24-bit stereo, and that's what you get from your Blu-ray discs. Mastering can go to 192KHz and you can get some music at that even higher frequency. I believe they worked out that analogue master tapes could only distinguish about 22-bits of data, so digital has finally exceeded analogue, but it took 25 years.

 

So music is starting to become available on DVD and Blu-ray formats in full fat, plus you can buy and download in high-definition too. So vinyl ought not be needed, except for the nice big cover art. Maybe there's a market for reproduction vinyl sleeves, maybe a voucher could be included in digital albums, but why are we buying vinyl again?

 

I had a CD set of the Benny Goodman Carnegie Hall gig originally recorded in 1938... on vinyl. Yes, they actually recorded it directly onto vinyl - we hadn't begun to record on tape yet. The first CD set I bought just reproduced the original recording. I now had a CD that popped and clicked, a lot. After one listen I decided that despite the music being fantastic, I would not ever want to listen to the CDs again. I had originally heard a song on Jamie Cullum's Radio 2 show, and his recording didn't pop and click. I found a remastered edition of the CDs that had been treated to remove the pops and clicks. Of course they had to be covered with something, because they obliterated the music underneath, so there must have been some digital reconstruction algorithm. Later complaints came in that the percussion and other high frequencies had suffered, but at least you could listen to the music now. I'm quite happy with the new CDs.

 

Now I'm on the CD remastering band-wagon. Every time my favourite albums get remastered I dutifully go out and upgrade them. I'm hoping that short-cutting to High Definition formats will effectively stop the need for this process. What's happening currently is that while albums are being remastered via 24-bit 96KHz digital formats we are saving the music from being lost as master tapes deteriorate, and they can be down-sampled to CD and released in that same High Definition. There is one trick still up the record companies' corporate sleeves though... surround sound.

 

I did a sound test a while ago with Deep Purple's Machine Head. We had it on vinyl, original CD, remastered CD, and DVD-audio in both stereo and 6-channel surround. We quickly agreed that the original CD was very dull and flat (and Roger Glover pretty much said the record company did a straight transfer to the original CDs whereas when he remastered them they used some engineering magic). The vinyl sounded nice, except for the pops and clicks, and the remastered CD sounded nice. The stereo DVD-audio didn't add much that we could hear, in fairness, but the 6-channel version was totally glorious. Suddenly you're surrounded by the band, sounds can move back and forth as well as from side-to-side, and sounds can be projected inside your head. Sadly DVD-audio is also a dying format, but Blu-ray can do the same job, so if you have a surround system then go find some Hi-Def surround music.

Of course one's loudspeakers are analogue, and until we get an HDMI socket fitted to the backs of our necks at birth we'll always be listening to analogue sound waves. Your loudspeakers would convert your digital data to analogue even if your DACs hadn't already had to do that for the power amplifiers. The granularity of the digital data has already been smoothed out, twice, before your ears get to do it again. I have also read a detailed article that I was tweeted that explains that it's all hogwash and the "improvements" we're hearing are usually down to better mastering and nothing to do with the extra bits. I've got 3 HD albums in stereo mastered from same source as the CDs I have, and whilst you can't tell on your ear-buds or the car stereo, I still believe the bass especially is smoother and you can pick out more detail. That's what I want to believe, anyway!

 

I then set to wondering how many copies of some albums I bought over the years. Rush's A Farewell to Kings comes to mind. I know I bought the vinyl 3 times, because I'd worn the first 2 out. Just taking a vinyl record out of the cover can cause damage, playing it can cause damage, speaking about it can cause damage! Then I bought the musicassette version to play in the car. I bought the CD when it came out, I bought the remastered CD when it came out, then I bought the box-set re-remastered set when that came out, and that has a CD and a surround DVD copy. So that's 8 copies, and the DVD probably isn't the full 24-bit 96KHz monty. Same sort of thing happened with Moving Pictures, though I have that on Blu-ray, so shouldn't be needing that any more. The only way it could be better is if Rush set up in my living room and play it live.

 

  So when bands say they have sold 10 million copies of an album, they haven't necessarily got 10 million fans, they might only have 1.25 million nuts like me that keep buying the same album over and over trying to get the most out of it.

Read More

On to the PC

I'm starting again on the PC because that's what I have at home. I've tried 5 generations of NVIDIA graphics cards and my development PC now has a GTX 970. I figure that's about the top speed anyone would expect. Previously I had a GTX 760 and before that a 550ti. The latter is about the minimum I'd expect anyone to be using now for gaming, being 4 years old. I'd also expect maybe at least a 2 core CPU. From what I've been reading so far, DirectX 11 has graphics hardware expectations that maybe go back a bit further. Not sure currently how far back the on-board graphics capabilities go. I don't want to have to code different ways of doing things for older machines. Direct X appears to support that in its own layers so I can leave that be.

 

My computer is called Azumi, and I built her myself from components selected to last a while, but not be too expensive. There's an i7 in there, 16GB of RAM, and with the GTX 970 has been brought more up to date. I put 2 DVD drives in, which came in handy when I converted all my music CDs to FLAC files to put onto the NAS drive for the hi-fi, and for my Windows phone. The latter has been a tale of mixed success. The phone plays lossless CD music to the earphones by wire and car stereo via Bluetooth. I'd like a word with the person that coded the condescending message to tell me to turn the Bluetooth volume down, which it also handily does itself, so as not to deafen myself with headphones - about 20 minutes into my journey, thus ensuring that I can't hear the rest of what I was listening to. Since it knows its linked to a car stereo, it might reasonably think I have a separate volume control. I would be much more likely to deafen myself by turning the volume up on said stereo to hear the Bluetooth properly at the default volume, then switch to the radio and deafen myself that way. Was this the same person that also resets the Bluetooth volume to 20 out of 30 every time the phone reboots, which is far too often, by the way, so I have to keep adjusting it back up to full, which you can only do if the Bluetooth is connected, which it isn't usually. Normally I'd be 100 metres down the road before the two devices link and I realise the volume is too low and I'm not allowed to press buttons on the phone. Sort it out, people. Stop adjusting my chosen Bluetooth volume. Rant over. 

 

Well do I remember the hassle I had to go through to stop the MSI drivers from being over-ridden by the on-board graphics drivers before I switched the on-board graphics off in the BIOS. The PC would boot up using the MSI card, then when Windows 7 started up it would switch to the on-board, which had no monitor plugged in. You'd think the default would be the additional shiny graphics card, but no. 

 

I'd like my software to detect the graphics capabilities and never lose a frame, but maybe have a manual over-ride if the CPU and graphics card are a bit out of step. A chain is only as strong as its weakest link. One of the many things I have to investigate is how many nasty API calls I have to make to find out what resources I am using and what I have left. Been a long time since all we had to do was set the border colour at different points in the game cycle and measure the bars with a ruler. No border at all on the PC.

 

The PC graphics architecture pretty much expects the screen, or at least my window, to be completely refreshed every frame. That eliminates any attempts at cleverness to preserve some of what was on the screen from the previous frame. The whole concept of smooth scrolling and character maps, and palettes has all but gone. Of course you can program that back in - we more or less had to do that on the Sega Saturn for Rainbow Islands. I'm thinking that probably the Shaders would be only too pleased to do palettes and colour look-ups. They'd still be better used for reflections and lighting, i.e. the sort of things that I'd rather not have to think about.  

 

So right now I am working through the easier of the two DirectX books that I bought in order to get a foot-hold. The trickier of the two books starting talking advanced mathematics by page 12, which I thought was out of order - pun intended. The easier book discusses topics in terms I understand and has to do things in the right order because we're constructing a demo program or 2, and I don't even know what they're going to do yet. Hopefully by the end of the first book I'll be ready to try the second book again.

 

I wish I had thought of adding a mass figure to in-game objects to affect collisions: taking mass into account. The PhysX library is something I will have to avail myself of. I think I could also have a bit of fun playing with that in cartoon style.

 

  

 

 

 

 

Read More

Uridium 2 Amiga Graphics

We were excited to move to the Amiga since it meant we had a CPU that was 8 times faster than the C64, had more registers and better instructions, but... there was no character mode to use. The bitmap screen was 16K big in 16 colour mode, 16 times bigger than the C64 character screen.

 

We had used 8x8 pixel blocks on Rainbow Islands in order to emulate the arcade machine. We stuck with that for Paradroid 90 as we had built a custom editor to build the backgrounds, and a custom lossless compression routine. After that, and a few discussions with the Factor 5 lads, we decided that 16x16 pixel blocks was going to be more space efficient and easier to restore the background behind the plotted objects. Despite the faster and better CPU, we couldn't rebuild the entire background every frame, something the C64 did as a matter of course. When an object passed over an area of the background we flagged up which characters needed patching up afterwards (I believe, it's getting tricky to remember).

 

The 16-bit machines had just a bitmap for the screen. The Amiga had a number of tricks up its sleeve over the Atari ST though, Firstly you could start the screen on any 16 bit boundary, so as well as setting smooth scroll registers to scroll up to 15 pixels, you could slide the whole screen to the right, or left, by 16 whole pixels, retaining most of the information on screen and not having to rebuild it. Then you could have 32 colours rather than 16, at a cost, or 64 colours on the A1200 and CD32. We also had 4 bits of red green and blue in the palettes rather than 3. The STE went up to 4, and the A1200 stayed ahead by going up to 8 for some really smooth fading effects.

 

Actually the Amiga also could handle 2 playfields, as used in such games as Shadow of the Beast. We did try that in an early version, with a 4 colour back playfield and a 7 colour foreground, scrolling in parallax. This gave us some nice extra depth, but the graphics artists weren't happy working in only 7 colours. The objects moving around over the background had to share those colours too, though we did later use the hardware sprites as well as software sprites. Foreground objects were also difficult to see because with only 7 colours, everything used them all.

 

Having abandoned dual playfield mode, we went for 32 colour mode, arranging the colours in pairs, light and darker, so that we could skim shadows under the ships by only clearing one bit-plane of data, making plotting a lot faster. It also made sense to put black as colour zero and white as colour 31 so that we could flash a sprite white by setting all the bit-planes to the mask bits of 1 where there is data and 0 where transparent. You could also then set a sprite to all black by clearing the mask bits on all bit planes.

 

In order to use the blitter most efficiently for plotting objects on screen in one 'blit', we had to supply mask data for each bit plane, which would necessarily be identical to the other bit plane masks. Otherwise you have to reset the data pointers to the one supplied mask for each of the 5 bit planes, so you had to do 5 consecutive blits. That was inefficient because you had to wait for the blitter to finish each bit plane before starting the next, whereas if you blit all 5 bit planes in one go then you can be preparing the next object's plotting data while the blitter does its job. So it was the old fight of space versus time.

 

You can use more memory to save processing time. Often that might mean working out some outcomes in advance in a table. An example would be calling the random number routine before the level starts say 256 times and putting the results in a table, and then just lifting out the numbers as the level plays, which is faster than calling the random number routine during play. You can still afford to maybe combine two different numbers from the table and have the pointers stepping through the data in different directions to give lots more combinations, and you can write the new results back into the table to really mix things up.

 

So, back to Uridium 2. I wanted all of the effects that the C64 had, plus any more we could think of. The shadows could be done with just plotting to a single bit plane, so nice and quick. Stars are easier to do on a bitmap screen because you only have to plot a single pixel for a star where the screen had space-colour. We had tried this out on Rainbow Islands. on Monster Island. Once you have collected the big gem on that island, the stars come out next game, if memory serves.

 

I took all the parameters of the control mode from the C64 version, plus allowed the Manta to fly upside-down. What that would have done to the pilot in reality is anyone's guess!

 

We added vertical scrolling in on later levels, just because. We also added a second Manta and some additional 1 and 2 player modes. Glowing colours were achieved by reserving two consecutive palette colours and changing them every couple of frames. Glowing colours can be useful for Uridimine ports, engines or lights. I also added the radar display later on, but with a twist that there could be radar jammers on the ships. Go near one and you lose some of the radar capabilities but can still just see through the static. Go near 2 or more jammers and the radar is useless. By destroying the jammers you get the radar back.

 

Choosing your limited palette can be agonising. Going back to Rainbow Islands, we had 16 colours per level, and some colours had to be consistent across levels, particularly the main player graphics, the rainbows and the gems. We tried to allow a couple of floating colours so that an island could have a bit of uniqueness. The arcade machine had less limitations because the sprites and the background each had their own palettes of 16 colours, plus they could have 2 or more palettes per level.  We were always chasing the arcade hardware. John Cumming agonised for some time over getting the colours right, but it was worth it in the end.

 

Since the Uridium Manta was predominantly white, we reserved a small block of colours for the Manta and its weapons. I then let the graphics artists choose the rest, only stipulating that the bits of background you can crash into had to be easy to see. I can't say that it was easy to get graphics we thought were suitable. We had 4 or 5 graphics artists who gave it a go. Some of the schemes they came up with were really pretty and organic, but difficult to navigate at speed. We also found that the ships we thought would be the first few levels were too difficult for some people to play at first, so we had to do some even easier ones.

 

We also tasked the graphics artists with providing sprites for the levels. Some would be ships, others vehicles on the surface. Some created hatches that opened and closed, or laser turrets. Depending on how difficult the levels are to play, we would have to rearrange the levels. Whist some of the tuning, like Uridimine numbers and frequency was based solely on the level number, objects solely available on a set of 4 levels had their own tuning. We had an end sequence for Uridium 2 rather than sending you back to the first level with the difficulty racked up on the C64 version. End sequences can be expensive on graphics that are only used once. Arcade games didn't usually have them early on for the same reason and because they just wanted to see how far you could get on 10p against ever increasing difficulty.  

 

The Amiga hardware sprites were a bit of a let-down, being only 16 pixels wide and once combined into 15 colour mode you had 4 per raster line, but they did show that by being the full height of the screen that you could switch them on and off, and that's pretty much what our sprite multi-plexors on the C64 were doing, just moving a sprite that has finished displaying high up the screen further down so it gets displayed again, at a small cost. You couldn't do any bit plane "tricks" with them to get shadows and they would display over the top of any software plotted sprites, so maybe good for bullets, things that move fast and don't linger. Quick to plot though, and no background clean-up needed afterwards.

 

We tried to add some additional weapons too, for the Manta. We found though that they tipped the balance of the game too much in the player's favour, so we had to rig them to run out fairly quickly. I did like the homing missile algorithm. Initially, because the homing missiles had a slow rate of turn they could miss a target, turn to have another go but not be quick enough, and end up orbiting the target. This was clearly not satisfactory, and you might now occasionally spot this starting to happen, but the missiles are now improved to recognise the looping situation and they go a bit further away before looping back successfully for the kill. Problem solved!

 

 

 

Read More

Computer Development in 30 years

Uridium C64 Graphics

Way back in the early days of Uridium; I was keen to get a full 50 frames per second high-speed scrolling game. On the one hand, the C64 graphics chip was pre-programmed to decode a 1,000 character map via the 2K of character graphics onto the display screen every 50th of a second, for free, well almost. On the other hand, aside from setting the scroll offset in hardware by 0 to 7 pixels for smooth scrolling, just leaving the data as-is, you can only make it move by 8 pixels. In order to slide sideways by a whole character, you have to rebuild all 1,000 characters on the screen. Therefore you'd have the whole level unpacked in a larger map and copy the 1,000 characters that you needed. Every processor cycle counted big-time, so if you want to copy 40 characters per line you might repeat the same copy instructions 40 times rather than implement a loop with a count. It's the same count every time; why not just put that number of instructions in? You could unravel the Y loop as well, but then the code would take about 1.5K of space, which was about a 40th of your available RAM space. We didn't do that.

 

Since the Uridium manta ship can move at 1 character (8 pixels) every 50th of a second, I rebuilt the screen every frame. Might as well take the hit because you can't guarantee that you won't have to do that anyway. That also means that any alterations made to the background map get actioned on screen immediately. This copy process might typically take almost half the frame to do (it was a split screen, so only 21 x 40 being scrolled). Whilst we could have implemented double-buffering, we didn't to save space, and relied on copying the new screen data over at a time when the display raster would not catch up with the copy, avoiding screen tearing. Actually, I was updating some of the colour map too, and you only get one of those, so it can't be double-buffered. I had to note where I had updated last time, clear those, then spot the new positions with the next animating colour for the Uridimine ports.

 

The background stars, as someone figured out, are an animated character counter-scrolling so that they appear in the same position on screen regardless of the scroll position. The star character only replaces the blank space character on screen, not a solid one. It's quite usual to have the easily identifiable first character as the blank space. I also had to ensure that there were no stars in the area where the Manta shadow could be cast, because the colours were all back-to-front and the shadow would have cast on the stars - yeuck!

 

The C64 allows sprites to selectively go behind 2 colours and in from of the other 2. The shadow colour was the same as the darker background colour, and was told to go behind the blackness of space, and behind the background shadow colour, which are the same anyway. This allows the shadow to cast onto the mid background colour and the highlight colour. Previously, shadows had typically been simulated by alternating black and not displaying, which effectively only runs at 25 frames per second and strobes rather. Flying Shark does this. Conveniently also, the Uridimine port was cycling foreground colours for a glow effect, and the shadow went behind that too, as casting a shadow onto a light emitter would look wrong.

 

The last character trick I used was to reserve some background characters for the Manta bullets. By working out what the background character was behind a bullet, I copied that graphic to one of my reserved characters, then overlaid a bullet graphic in, and plotted that reserved character onto the screen. That also meant that I could quickly get the enemy ships to detect a bullet character under them because all the bullet characters were in a preset range, and they'd blow up. Bullets were always character-aligned and moved at 2 characters a move. Enemy ships had to check three adjacent characters under them to make sure they didn't miss. Bullets fired on button down and button up, so there were plenty around. That was an important feature to get lots of movement on screen. Hated the Space Invaders and Galaxian limitation that only allowed one player bullet at a time.

 

I didn't have a sprite multi-plexor at the time, and probably wouldn't have been able to afford the processor time anyway. I decided that the enemy ships would be flying higher and not cast a shadow (convenient!). They don't therefore ever collide with the player; I don't especially approve of kamikaze enemies. The Alleykat racers would stupidly collide with the player, but at least you had energy and could potentially sustain such collisions.

 

So... that's what you can do with a graphics chip helping out with characters and sprites.

 

Next time: the Amiga equivalent.

Read More

Part 1 of Many

Welcome

Hi everyone. I've created this blog to accompany my @UridiumAuthor  twitter account. This will allow me to talk in more depth about issues, and also my escapades while learning to use DirectX 11 to write some new games on my PC. These games may well be in a Retro style because that is what I am: Retro.

I may also head off into a rant about something or other every now and again, because other people's software can really irritate me at times. The less of it I have to use; the better. If you're one of the people writing the software I have to use: apologies... and buckle up!

I may, from time to time, talk about such items as Japan, gardening, guitars, bass guitars, drums, Lewis Hamilton, telescopes, and certainly Babymetal (Su-Metal, YuiMetal and MoaMetal).

I've also been inspired to write this alongside Steve Turner's blog at http://graftgold.blogspot.co.uk/ about his first game for a while: Deepest Blue.

It Starts Here

Right now I have 2 DirectX 11 books to read, to get to grips with building a display system. I have the basis of a game engine to drive objects independently, what I used to call my AMP system. That stands for Alien Manoeuvre Programs. This handles movement, animation, collisions, plotting, everything that goes on in the game really. It allows me to write each game element as if it is the only one there, so I can write the code linearly rather than 'inverted'. This avoids the need to save out what a game element is doing from frame to frame in one or more mode variables.

  The AMP system I have can log one or more game elements for information and/or errors in real time so I can see if something goes wrong. We never had that on the Amiga. Thing is that in the 16-bit and 8-bit days we were writing in assembler, and that is very unforgiving. It would crash if we made the slightest mistake. Having been working with C for the last 20 years things have become more ordered, and we code with some degree of contingency in mind nowadays to enable bugs to be identified and fixed without crashing the computer.

Currently I've been writing in 32-bit mode. I see no way that I can spill out of a 2GB working space. All the maths is done with 32-bit floats. Should it become necessary to go to 64-bit to comply with the OS then I'm trying to use as few data types as possible, and all the same size, so that everything fits together nicely, and can be expanded if need be.

Read More