Rick's b.log - entry 2020/05/16

Eurovision

Or, at least, that's how it was supposed to be.

Instead, it will be a show "honouring" the entrants from each country.

Personally, I don't agree with this. Everybody wrote songs, tweaked their performances, and many competed in national competitions in order to represent their country on a global stage. And, of course, everybody looking for the next new angle. The thing that will set them apart from the rest. They can't do rocking monsters, it's been done. Clever interaction with the video wall has been done. A dozen Euphoria clones have come and gone. Baking grannies? Swinging around on a big pole? A giant hamster wheel? Yodelling in front of a cannon? Badly dancing guys in futuristic-grunge outfits looking like rejects from the casting of Freejack? Throwing away convention and singing in an entirely made up language? Rocking out with a sax...twice? Middle aged women dressed like tweens? Or like Xena Warrior Princess? It's all been done. So what's new? What will wow audiences and garner votes? That's the question.
That's what we were supposed to see this week. The semi-finals on Tuesday and Thursday, with the big glitzy performance tonight.

That's why I disagree with having the contest in any form tonight. It should have been cancelled, like, well, like everything else. 2020 is the year that much of human civilisation reached for the Pause button. Sporting events? Cancelled. Olympics? Cancelled. Going to the beach? Cancelled. Having a beer at a local bar? Cancelled. For a vast number of people - going to work? Cancelled.
And, so, should Eurovision. Cancel, just do it in 2021 (assuming we have this virus under control by then).

Those performers deserve their chance to do their thing on the stage in front of an audience of ridiculous numbers of people (especially given how often the contest is ridiculed, you'd think nobody really bothered watching...). But instead, they will probably show the "official video" which can range from a carefully crafted CGI-laden extravaganza to a recording of the entry at the national selection programme. Which really isn't the same thing, is it?

The problem with assembler

Unfortunately, the ARM processor has seen a number of fundamental changes in its years, and unlike (32 bit) x86 chips that are still capable of running the early versions of DOS and Windows, ARMs changes might be subtle in places but they can break software.
This isn't usually an issue, your phone/tablet probably runs ARM and it has software designed for it. Apps are a Java-like package that gets build into a native executable for the platform during installation. In short, your device, its processor, its apps.

The world of RISC OS, on the other hand, is an entirely different proposition. Versions of RISC OS 5 are available for IOMD machines, that is to say the RiscPC and the A7000(+). Machines that stopped being produced with the demise of Acorn in 1998. Yes, twenty two years ago.

So not only have we devised an API that is largely 26/32 bit neutral (so the same application code should more or less run on either configuration), but we have side issues like unaligned reads and writes from memory ... on processors since the ARMv7 family, that does an actual read or write from an unaligned address; on the ARMv5 and earlier it had a weird behaviour of loading a word from an aligned address and rotating the byte positions (writing wasn't allowed); and some ARMv6 cores can choose which behaviour (logical or rotated load) to implement. RISC OS typically sets alignment exceptions to be raised, which means all unaligned accesses will be faulted. This is a good idea as no matter what sort of unaligned load a person was trying to do, about half of the possible RISC OS machines will do something entirely different.
There is the absence of SWP(B) in the more recent ARMv8 cores. And, of course, programmers are humans and humans make mistakes. I've found a number of things failed on my Pi2 (early model, ARMv7) that worked on my Beagle xM (ARMv7) simply because the later ARMv7 was more strict about valid instructions. Consider, if you will, LDMIA R13!, {R0-R7,R13,PC}. Here we are unstacking registers R0 to R7, R13, and the program counter. It is a potential, though unusual, function exit. It is unusual as it isn't normal to restore the stack like that. It is, also, quite broken. Did you notice the '!'? That means writeback. So we're loading a bunch of registers including R13 from incrementing addresses provided by R13, the last of which is to be written back to R13.
So what's R13 supposed to be? The written back address or the one that was loaded? This sort of situation used to be "implementation defined" where the exact behaviour depended upon the core. Now it's simply faulted as being "bullshit" (which it is). It's also astonishing how many times I've come across code that looks like LDR Rx, [Rx], #4 when I suspect they might have meant LDR rx, [Rx, #4]. The latter loads Rx from the address calculated as (Rx + 4). The former? Loads Rx from Rx, then adds four, and stores that in Rx. Uh-hu...

That right there is the problem with assembler. It used to be necessary to delve headlong into it because when you have an 8MHz processor and an 8MHz memory bus - that's only four times the regular clock speed of a BBC Micro - so it was fair game to use every trick to get the most out of the machine. In the early days it was pretty unusual to write a game with motion and such (arcade games) in anything other than assembler. Or, at least, a mixture of BASIC and a lot of assembler. C wasn't used much because the C development system was scary-expensive in those days. The compiler and assembler (sold separately) cost more than half as much as the computer itself.
The era made a lot of use of assembler in order to get the most out of machines. RISC OS is mostly written in assembler. So was MS-DOS.

Fast forward thirty years. A machine is slow if it only clocks 800MHz. The sorts of ARM devices we have now originated with media players (Pi's BCM family), mobile phones (Beagle's OMAP), and so on. They might not offer the raw power of a modern x86 chip, but at a fraction of the size and a fraction of the power requirements, they're no slouch. So is assembler the best option these days?

Another problem with assembler is how much you are forced to concentrate on the nuts and bolts of the operation of the processor. Every register stacked must be unstacked (or the stack pointer fiddled to compensate). Every single part of the underlying behaviour of the processor is under your total control. But, on the other hand, every single part of the underlying behaviour of the processor is your responsibility. How much time do you spend writing an algorithm to do something, versus how much time do you spend working out what registers to use and when, plus keeping track of them to ensure that the right ones are used at the right time.

On the other hand, a higher level language allows you to express things in a form that is more human-readable. Things are given names, things can be arranged in groups (structs, in C). You concentrate on telling the compiler what you want done, and it worries about the nuts and bolts. The only time you need to get into assembler then is for calling system APIs (RISC OS makes heavy use of SWIs which is something still in the assembler domain, although the plethora of libraries tend to hide this) and for reading backtraces when things go wrong. You can see an LDR faulted, you can see the address it's trying to load from is zero. Oops, pointer used before it was assigned to something!

Greg, the game's author, said on the forum when I asked, that he writes in assembler because it is what he knows and what he has always used. This is a perfectly reasonable answer, and there is nothing wrong with that. In fact we have a game playable right now because he sat down and turned out the code to make it happen. Certainly, one must throw some respect in the direction of anybody who undertakes a project in assembler. I just wonder how much time was spent dealing with the specifics of actually coding in assembler?
If it's what you know, go for it. Familiarity helps get things done (for instance I'm happy with C, never bothered with C++).
But if you have a choice, if you know something else, then use assembler sparingly.

Now that I've talked about the programming, it's only fair to talk about the game...

EAT LASER DEATH!!!!

Note that this is an early version of the game. There's some stuff to flesh out and expand upon. But in its current state it is perfectly playable.

The game opens with a wall of text. Some blurb setting up the scenario in a manner that I haven't bothered reading in the dozens of times I've started the game. Frankly it doesn't matter. It doesn't matter if it's some sob story about how their planet succumbed to a fiery death as their primary star went supernova and now they want Earth...or if they're psychotic murderers who are hell bent on wiping out every planet where coffee is a known beverage. The blah blah is irrelevant. It's them. It's you. And there's a lot of them and one of you and everybody is heavily armed. Let's party!

We open onto a very arcade-style menu, with a primary menu on the left (cursor up and down) which affects what appears on the right. You'll want to start a new game. You'll be invited to enter your name, which appears on the lower left of the play screen - a nice touch, and also for your part in the high score table, should you make it that far.

As the game proper begins, a little bit of exposition to clue you in to what you're supposed to be looking for. Note the use of a different text style than in the menu. It would have been easy to recycle the menu fonts, but it doesn't. It's little details like that which help to elevate the feel of a game.
You can also see the constants on the screen (score and pink-thingy counter at the top left, and ship status at the bottom left).

There's a whizzy hyperspace sequence as you head into the part that is known as "sector 0-1". Just about enough time to throw down the ultimatum... "This is the warship Rocinante. You're aware of our capabilities more than anyone. We're escorting a vessel of refugees away from your A.O. Any ship that opens fire on us will feel the sum total of our state of the art Martian arsenal rammed up its ass. We'll all die together. This is our only and final warning. Stay clear." Okay, it's not exactly in context but it's a damn hardcore speech and deserves another airing.

You're lulled into a false sense of security. There are "wave after wave" of generic aliens to blow up. It will usually suffice to go to the top (or bottom) of the screen, adjust your lasers to shoot up or down as applicable, and just blast 'em to bits while staying out of harm's way.
Then come these things, in pairs, that spew out balls in all directions. Deadly to you, but interestingly not to each other (ho hum). The trick with these is that they cannot fire directly ahead, so you need to go in front (out of the range of the other one) and blast until it goes boom.

Then you see the monster. It's big. And it aims directly for you. If you don't lay it down with everything, it hurries away before any real damage has been inflicted. Even collecting a bunch of power-ups and rapid fire from a three-way wide cannon at near point blank range, it's badass.
Unfortunately for you, it's as if that big thing has taught the little guys the folly of blindly firing ahead. They now aim for you. Which means, pretty soon, it's a case of:

It's hasta-la-vista-baby... for me. With a miserably pathetic score of 8482, and three aliens shooting at the place I was just in case I have some freaky reincarnation ability (I don't). Shields 100%? I don't think so! ☺

I don't have sound connected (the speakers are hooked to my netradio), but I'd imagine the audio is the expected assortment of explosion noises and laser-firing sounds. Commenting on the video, somebody else thought there should be music. I disagree. There should perhaps be an intentionally naff 8 bit chiptune during the menu, but in the game itself? For the love of god why do people feel the need to have music non-stop during a game? Unless it is intelligently able to respond to what is happening on-screen, it's a distraction. An annoyance.
For example, if I was to playlist my game we'd start out with some cheesy power rock (like Freedom Call). Very quickly we'd be into metal, something like Epica. When the big thing turns up? By that point it's the sort of metal that's nothing but a lot of growling and screaming (not my genre so I can't name any). Once it has passed, we're on to the unsettling atmosphere of drone metal. Yeah, that's a thing. Look on YouTube for "Sunn O Live At The Mayan" and prepare to have your mind melted (how far do you get before giving up?).
And, finally, as the "GAME OVER" appears, a song by Evanescence of mourning and loss like everybody ever has just died, which is pretty much any of their songs.

Game play is fluid, movement (of ships and lasers) is responsive and rapid. And, of course, everything wants to kill you. There are powerups along the way but it's hard. This completely lives up to the sort of arcade game that it is trying to be. A great job!

Phone line woes

I started an e-Chat with Orange and described the situation. They say an engineer will visit on the 19th (Tuesday) at 6pm. It had better not be naff weather between now and then, I have no Netflix to turn to!
Well, actually, just noticed that I have 26.52GiB remaining until the 22nd of May. Only, I'll need to download things as I don't have reception in the house. I guess I'd better fire up the PC and dump some stuff on harddisc, eh? ☺

Your comments:

Please note that while I check this page every so often, I am not able to control what users write; therefore I disclaim all liability for unpleasant and/or infringing and/or defamatory material. Undesired content will be removed as soon as it is noticed. By leaving a comment, you agree not to post material that is illegal or in bad taste, and you should be aware that the time and your IP address are both recorded, should it be necessary to find out who you are. Oh, and don't bother trying to inline HTML. I'm not that stupid! ☺ ADDING COMMENTS DOES NOT WORK IF READING TRANSLATED VERSIONS.
 
You can now follow comment additions with the comment RSS feed. This is distinct from the b.log RSS feed, so you can subscribe to one or both as you wish.

Greg, 16th May 2020, 19:01

A good read. I would imagine the problem with assembler part would be quite informative to someone undecided. Its a good argument Rick. Thank you for the fair but decent review of my game. A thumbs up from me, cheers. Hope you get your connection back soon, mobile just isn't the same.

Rick, 16th May 2020, 23:11

Eurovision... It's a shame that they only played snippets of each song, I still feel like this year's artists deserved better.  However, this show was not only better than I was expecting but was also genuinely moving. There is power in music, the shared cultural experience that transcends stupidity like race, gender, sexuality, and culture to unite us as, simply, people.    The UK should also hold it's head up high. For all of the years and all of the songs, the last winner (Love Shine A Light) was not only the theme but was performed twice, by a (quarantined) orchestra, and then by all of the contestants. Britain might have had a long time of mediocrity, but when it wins, it wins hard.  Here's hoping for 2021, and maybe in the intervening year, time to take a step back and notice how this time it was about the songs and not the fancy staging? Portugal won recently with exactly that. Practically no staging whatsoever, just a gentle song strong enough to blow everything else away.    Speaking of strong, my favourite part of the broadcast - Molitva. So totally unexpected, I really like that song. And all the footage of empty cities. So strange. So very strange.

John, 17th May 2020, 12:59

Is the multimetre the metric version of a multimeter?  Just askin'

Rick, 17th May 2020, 13:35

No, John, it's the FRENCH version! :-p

Jeff Doggett, 18th May 2020, 12:36

The thing with Assembler nowadays is that the compiler can often produce "better" code than manual coding.    Let's look at a simple example.    unsigned int a = 4;  unsigned int b = 5;    unsigned int function (unsigned int c, unsigned int d)  {  a = b;  return (c + d);  }    Now if we were to code this directly in assembler we might do something like:    LDR R2,VariableB  STR R2,VariableA  ADD R0,R1,R1      However the compiler might do something like this:    LDR R2,VariableB  ADD R0,R1,R1  STR R2,VariableA    This is because memory access is very slow compared to internal cpu operations. Some CPU's can move the memory access into the background and execute the next intruction if it doesn't need to use the register to be loaded. So the ADD in the example above will run concurrently to the memory access, and will therefore produce faster code.  The Norcroft compiler will do this.

Jeff Doggett, 18th May 2020, 12:37

I'll let you work out where the typos are in the above!

Rick, 18th May 2020, 14:09

I took it as pseudo code to make the point, so the square brackets and stuff were "omitted for clarity" (as was the fact that you don't need to load something in order to assign it). ;-)

Add a comment (v0.11) [help?] . . . try the comment feed!
		Your name
		Your email	(optional)
		Validation	Are you real? Please type 79539 backwards.
		Your comment