mailto: blog -at- heyrick -dot- eu
Yesterday evening while waiting for dinner to cook (fish and chips, as it was Fishy Friday (see below)), I decided to spend a few idle moments looking at the odometer.
The front of the dashboard was held in place by three screws and a half dozen clips. Easy enough to separate. The speedometer/odometer was then held by three screws at the front, and two screws through rubber grommets at the rear. The rear screws were Torx screws (star shaped), which wasn't even remotely fazing.
The speedometer needle seemed to jump when I put a screwdriver in the end and turned it and nothing appears to be rubbing, however I have not tried it with a continual rotation. I note, however, that the pinon between the gearbox and the cable was replaced, because it must match the speedometer (divide by 10, divide by 11, and so on).
The odometer? It's a mechanism more or less identical to the trip counter, only obviously without a reset button. A hidden wheel is connected to a rotating gear driven by the speedometer cable (the gear also drives the trip counter). It is set up so one rotation of the hidden wheel represents one kilometre. The trip counter is the same, only you can see the 10ths wheel. As the wheel makes a rotation, it engages a little lug that pulls up the next wheel along. And so on all the way to the hundreds (trip counter) or the hundred thousands (odometer).
Looking at the back of the odometer, we can see the mechanism is both simple and accessible. Indeed, it was simply a matter of unclipping the metal bar connected to the little grey wheels and rotating the numbers. I have set my old odometer to 060992 which I think is more realistic given the time that it was not operating. Clip the metal bar back into place, job done.
It's a shame the mechanic didn't fiddle the odometer to match what it used to be. People these days...no imagination... ☺
Since people look at the kilometre count for various reasons (it is often noted on paperwork), I've added a notice to the dashboard to point out that, no, you are not looking at a 23 year old car that has only done eight thousand. You need to add 52K to get a proper reading!
Also worth noting that the orange light on the right - what is that, oil level? That's new. It never used to light up on my old dashboard. Probably a blown bulb. I don't need to worry about that, mind you, as I check oil and coolant weekly. Or after longer journeys like to Châteaubriant (not that I do that any more).
Crazy idea... if the clock runs off 12V and the mower has a 12V battery.......... ☺
(some other day, I'm a bit fed up of scrubbing oil and muck off my hands)
Some religious thing, I think. At boarding school, the only three certainties in food were:
- You could track the evolution of ingredients from one day to the next - for example leftover boiled carrots from Monday would turn up chopped in a lasagne or shepard's pie on Tuesday.
- Sandwiches on Sunday evening.
- Fishy Friday - lunchtime was always battered fish, chips, and something that was supposed to be peas.
I don't always eat fish on Friday, but it's become enough of a habit that, well, Fishy Friday... clue in the name.
I don't have peas. I'm very fussy about my peas. Young garden peas, preferably frozen, boiled for about five minutes. If they aren't crunchy they're overcooked. If they're mushy peas... oh my god, there ought to be laws against inhumane treatment of vegetables...
I hate strimming
Whenever I cut grass, I usually end up wearing it. With Some Pig, the little mower, it isn't that bad. With Big Mower it is ridiculous as the ejection is so powerful that tiny bits of grass rain down like snow. If I have to turn and go back over parts I've already cut, well, it's best done with eyes closed!
Then there is strimming. Where large soggy wet chunks of bramble and nettle are fired directly at you. Not only do they hurt on impact, quite often the part that makes them hurt normally is still attached. So, yeah, it's great fun pulling high velocity bramble thorns out of your own neck.
Still, sometimes there are things that neither mower can do...
There is, of course, an awful lot left to do, but little by little I'm making some headway into this wilderness. The hope is to get a lot of it to the state where Big Mower (I really ought to give it a name) can whip over it to keep it all in shape.
By the way, the two replacement belts I ordered were shipped out yesterday. DPD will contact me (SMS?) for delivery options. I wonder if I could tell them "it's two mower belts, just leave 'em in the letterbox"?
Speaking of delivery, I had to sort out a delivery for a friend who lives across the way in La Mayenne (dépt. 53). Her address is like mine, it's a name of a person, a name of a propery, a postcode and a town. That's it.
We are technically what is known as a "lieu dit", or a "place called". And long time readers of my blog will know that I have some disdain for the big parcel companies (UPS excepted) that usually get in touch with me, as they did with her, to say that the address is "incomplete". Because these town folk expect an address with apartment number, street, banlieu, town, nearest bar, god knows but if it doesn't run to several lines then it is faulty.
I find myself having to contact the carriers to point out that not only can the address be found on Google Maps, but that it - as given to them - is exactly what it says on my tax return. If it's good enough for the government...
So, then, let's see if DPD can manage to deliver the first time around? At least, I think I've had enough deliveries thanks to Amazon Prime and NessyCar that both Chronopost and FedEx can find this place now. Still, you'd have thought that any competent parcel service would think to try Google Maps?
Of course, maybe they are like the French government and they shun nasty foreign muck in favour of ViaMichelin, which has the spectacular distinction of managing to find my address from the house name and postal code (it offers the correct town name) and then pinpointing it about 40km south east of Lausanne in an entirely different country!
I filled out their opinion form and gave them one star and a rating of 3 out of 10. The 3 is because their "how much will this cost me" has actually heard of Aixam cars. The rest is because I don't live in Switzerland...
Something that I have been working on along the way, evenings and rainy days, is a computer game. The premise is very simple and topical - you are a white blood cell and you need to destroy the little green viruses while protecting, and maybe healing, the red blood cells.
The game is basically three levels, starting with four reds and four viri. Then six. Then nine. The game can repeat up to three times, and it will multiply the number of reds and viri by which pass this is. This means that the first of the nine possible levels looks like this:
To explain. The white circle, that's you. You can control it using the standard key combination Z, X, ', / or Q, A, O, P. You can also use the cursor keys, but this isn't mentioned as it's even harder doing it one-handed.
The little green dot? That's the virus. You need to crash into it three times to kill it.
The red circle? That's a red blood cell.
The one with the lighter border and two green dots is an infected red cell. You need to hit it twice to heal one of the viri within. Yes, this does mean that it is simpler to recover from infection than to innoculate. I'm not on of those anti-vaxxer idiots, I just didn't want to make the game too hard, as if there are three little green dots then you need to crash into the red blood cell six times to heal it (twice for each of the viri within).
How it works is this. A virus will infect the cell leading to a cell visible with one green dot. After ten seconds, if you haven't done anything about it, the cell will create a second virus (as that is essentially how they propagate). Ten seconds later, a third will appear. And you will notice the red blood cell's inner getting progressively darker as it gets sicker. If a further ten seconds pass, the cell will die, leaving behind the three newly created viruses to go and infect other cells.
But there's a little wrinkle. You see the red cell with the magenta outline? That is one that has been hit by the white blood cell. It serves as a visual confirmation of a hit, but it also means that the duration of time that the cell is highlighted (a little under a second), subsequent hits will have no effect. The viruses have a similar mechanism, but there is no visual confirmation of this.
This, of course, repeats until you get to the hardest level, which is 9 (objects) × 3 (level) which looks like this:
The images for the cells were created using !Draw. The virus is arranged as a lipid envelope (the main green circle), several proteins (the yellow circles) and an RNA chain (in blue). It's a technically accurate description of what SARS-CoV-2 is, the only real difference is that the animation does not include the spikes that the virus has in order to attach itself to the host's cells. This was partly because it was a pain to draw, and also partly because the virus had not yet been imaged when I began drawing the graphics.
Making a usable sprite from this was a monumental pain. The first thing was to go via InterGIF which would apply some nice anti-aliasing, but output a sprite in something like 20 colours (as it was using the same method as it uses when creating GIFs, only omitting the GIF stage). It seemed utterly unable to deal with masks in sprite output mode, so I then write some BASIC to plot these images to screen and take snapshots of them (translating them to 16M colours along the way), and then all of the masks were hand-added using !Paint. For the virus animations, the palette needed to be tweaked as well to make the outer border better.
Sadly, there doesn't seem to be a useful way to go directly from DrawFile to sprite in a way that doesn't look rubbish. The Draw rendering doesn't anti-alias. It does make a big difference.
I cheated when it came to the white blood cell. The original was a DrawFile with slightly different shades of white that pulse sort of from light cream to light beige. InterGIF made a mess of that, so I simply wrote a routine to draw a circle of the desired colour and take a snapshot of it. The end result shimmers gently as desired, but is noticable in its jagged edges, as the OS plot routines don't anti-alias either...
Other graphics were used. Some from pixabay.com that claimed a commercial okay no-attribute licence (though I provide links in the Help document) and others by me.
The background texture was an interesting one. The basic image used was a photo of grass from the Fukushima Texture Pack (yes, that Fukushima). It was hue-shifted into red, and darkened until it looked like a useful background. Then, to rough it up, an overlay texture (brick? I forget) was applied. As I didn't want to turn on the PC, I did the background using PhotoDesk which is reasonably powerful but doesn't strike me as being at all intuitive.
The title screen? Well, this ought to let you know what you're in for...
Yup... terrified Playmo characters crying, peeing, even pooping. Two women deciding "sod it, let's get amorous", and of course a dose of police brutality. And not one single person respecting any form of distancing. So, yeah, pretty much like real life in some places...
The screen itself was assembled using PhotoImpact5 under Windows, my editor of choice (reasonably powerful but not over-complicated). The background was from pixabay, the foreground was two images of a Playmobil crowd (you might spot the blue wooden bars of my picnic table!) pasted together. The woman's black dress was fixed (it wasn't done up so had a large visible gap that looked weird). The background of the Playmo image was a piece of white paper, so this was masked and then the mask inverted to capture the scene and omit the background. The masked scene was dropped into the burning city backdrop. Then using the airbrush, I made the dead eyes and screaming mouths. Switching to 20% black tinting, I added tears and pee on the man's legs. Yellow tinting for the white dress. Then brown tinting to take it up to eleven for the fairy girl and red dress woman. Yes, this virus kills everybody. Fear it.
All the editing done, the image was reduced from something like 2200 pixels down to 800, and then clipped to 600 the other way to fit an 800×600 screen. The resize also helped to blur any masking harshness down to a better blend with the background.
You might spot, along the way, a fireman who isn't "aaargh", the aforementioned fairy, a cheerleader, a doctor waving her stethoscope, a Buddhist monk, and an astronaut. There were about forty people in the picture, but most of them aren't visible due to the angle. Still, at least you know the crowd goes on and on. If it was a crowd with only a dozen people, well, that would be like Trump's inauguration speech, wouldn't it?
A hokey Stylistic Suck title saying "VIRUS!" bounces across the top of the screen. That's why it's mostly blank up there. It's actually drawing the title multiple times over in order to see if your machine can keep up with a decent frame rate. If it can, all is good. If it cannot, then the background will be disabled and simple screen clearing used instead. This makes the game playable on emulators on steam powered hardware, like RedSquirrel on an EeePC 901.
Additionally, the game needs to poke around the video memory in order to work out what is possible. On a modern machine, such as the Pi, it draws an 800×600 display in 16 million colours. That's a little under 2MiB per screen. Multiply that by three (for triple buffering) and it needs about 5.7MiB.
However, the RiscPC only has a maximum of 2MiB VRAM, so the game will downgrade itself to 800×600 in 256 colours (467KiB) and if you have 2MiB VRAM installed, then there is space to claim the 1.4MiB necessary for the triple buffering.
Accordingly, on older machines, there has to be at least 2MiB VRAM.
Apparently some newer versions of VirtualRiscPC support larger amounts of video memory to allow the use of more modern resolutions and colour depths with VIDC2 era emulation. Because the fact that the VIDC2 cannot cope with something like 1440×900 in 16Mcols is a hardware limitation (~5MiB per screen, and probably pixel clocking more than the VIDC2 can manage) but an emulation doesn't suffer from such limitations. Unfortunately I don't know the mechanism behind this so I don't know if the game would stay in 16Mcols or downgrade to 256.
What the game does is check the maximum possible size of Screen Memory. This is something like 32MiB on the Pi. I'm not sure if this is just what RISC OS allocates, or if it's picking up on my GPU memory setting in the configuration (which is also 32MiB). On the RiscPC, it is 2MiB max. If less than or equal to 2MiB, it will switch to 256 colours. If less than ~1.4MiB, it will refuse to run (not enough for the triple buffering).
Following this is some help text to explain the game and the keypresses. This is simply writing out a sequence of characters stored in memory which contain some markup for switching colours (to make it a little less boring).
In between levels one and two, there is some text explaining what a virus is.
In between levels two and three, there is a wall of text explaining how washing your hands actually helps destroy viruses (and why soap is better than hand sanitiser gels). There's a lot of text there that most players will probably not bother to read. Oh well, it's there if you're interested.
In the harder/even harder playthroughs, the between-level texts are not shown.
Sound design greatly added to the ambience of the game, and I'd like to take a moment to thank Tony Bertram (of AmCog Games) not only for his RDSP module, but also for suggesting envelopes to create the sort of noises that I was wanting to have with the various events. There's a "ding!" like a prayer bell. That's a good sound. Pretty much everything else (supposed to resemble coughs and sneezes) is a bad sound. There's a robotic bloop for when a red blood cells bursts and leaves viruses behind, and an absolutely comical groaning moooo for when you die. That, coupled with the picture (no, I won't spoil it for you) really helps hammer home the dark humour underlying the premise of the game.
The game itself is written in C, and runs to about 80K of code. An outline was originally created in BASIC just to get some of the ideas in a visible form before writing the game proper. It was written entirely in Zap, pretty much from scratch.
Inline assembler is used heavily and frequently in order to reduce dependance on external libraries. It requires the SWI header from DeskLib (as I built my own that has a lot more SWIs than normal), but other than that it pretty much only needs SharedCLibrary. This was important to me for two reasons. The first is the embedding assembler directly into the code makes a more readable disassembly. If you're calling OS_Byte to read the keyboard, the OS_Byte is right there in front of you. It isn't a branch to some anonymous function at the other end of the program. And also, it reduces dependance, as previously stated. I would have liked to have made some revisions and enhancements to the WebJames web server, however I cannot as I have yet to track down all of the correct libraries required to get the thing to actually build.
This is, of course, taken to extremes more or less "for the sake of it". When you look at VIRUS! you will see an executable running to around six megabytes. No, it isn't a port from Unix, it's simply that size because all of the resources (texts, sprites, etc) are embedded directly into the executable. You might notice that it doesn't even bother to set a system variable in the Obey file. There's no need - for <Obey$Dir> is enough to get the executable running, and that's all it needs to load. Itself.
So, stuck here in a lockdown as the world slowly grinds to a halt and Dr. Deborah Birx dies a little every time her ultimate boss opens his mouth, it was time to do what proper British people do in a crisis. Put the kettle on, and then sarcastically ridicule the event. So, with lots of tea and symphonic metal courtesy of PPN Radio, I put together VIRUS! over the course of a weekend, and spent a week or two refining it with the help of Tony, David, and Vince.
The result? My first "arcade style" game.
If you're interested, it's available on !Store now, and there's an article on Riscository.
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.
|Gavin Wraith, 26th April 2020, 09:02|
Being fourth declension, not second, the plural of virus is virus (with a long u). I believe that fish on Friday was a wheeze dreamed up for economic reasons, because most monasteries had carp ponds. Just like celibacy for the priesthood, as brothels were largely church-owned.
|David Pilling, 28th April 2020, 02:33|
Draw to Sprite - one thing that comes back is being able to use GDraw to alias normal Draw output (See SpecialFX), then at worst you do a screen snap. I feel people have done Draw to Sprite, but GDraw gets you the antialiasing.
(Felicity? Marte? Find out!)
List all b.log entries
Return to the site index
PS: Don't try to be clever.
It's a simple substring match.
Last read at 02:24 on 2021/01/27.
© 2020 Rick Murray
This web page is licenced for your personal, private, non-commercial use only. No automated processing by advertising systems is permitted.
RIPA notice: No consent is given for interception of page transmission.