It's funny you should mention those compilations, because… not only am I familiar with them, but in fact I was the person who designed the packaging for the Level 9 Compilation! (Check the small-text credits on the back of the box – I got a nice commendation from Mike Austin for producing something that looked so authentic to the Level 9 style!) However, those adventures don't use Inform files; both sets use their own proprietary formats, and Stefan Bylund produced very nice Spectrum Next versions of the interpreters needed to run them. You're right that some of those games are indeed also available for the Spectrum +3 (either exclusively or with pictures exclusive to the +3), but they still use a special interpreter and aren't available as Inform files.
In my previous comment, I was thinking primarily of those few adventures for the Spectrum +3 that are ONLY available on the +3 (not other Spectrum models) on CP/M disks, and which could presumably be extracted from those disks and run 'natively' on some other Inform interpreter, such as ZXZVM on the Spectrum Next. Presumably the same would also be true of adventures packaged up as Ozmoo disks for other platforms, though I haven't investigating extracting those yet either. I don't suppose there are lots of adventures like this, because Inform-format adventures are mostly released as separate Inform files and don't need to be extracted from a platform-specific disk… but there may well be a few like that, so it's worth bearing in mind.
Richard Hallas
Recent community posts
Thanks for adding the Spectrum to the set of supported platforms. But it's a shame it's only for Spectrum +3 (CP/M). Could you please issue the game as an Inform file (z5 or whatever) so that it can be used better/more easily on a Spectrum Next, or indeed one of the countless other platforms that supports these files? Thank you!
Seems like a nice game… BUT, why the heck is the key to move right U rather than P (i.e. QAOU Space)?! It makes it incredibly confusing and un-ergonmic to play. Surely this is a mistake? Thankfully it's possible to use the Sinclair 1 joystick keys instead (67890) if you start the game with 0 rather than Space.
Thanks. You can use audio2tape, which is one of the Fuse Utilities (an optional download, separate from the Fuse emulator). I've just used it now on the .wav that you've just uploaded, and it produced a perfect .tap file on the first attempt. I note that someone else has already offered to send you a conversion, so I won't do it myself (though I did with one of your previous games) – but if you need it, just let me know. NB You don't really need a .tzx file since only a standard loader is used; a .tap is perfectly sufficient.
Here's a download link for the Fuse Utilities for Windows: Fuse Utilities v1.4.3 – and you'll find audio2tape and its documentation in the collection.
Regarding x86 and RVM being 'no use', you're mistaken. RVM is available for Mac, Windows and Linux (and there's even a build for Raspberry Pi now). Give it a whirl. Whether it's an emulator you want to use in general is a different matter (personally I still prefer Fuse with its no-nonsense interface for general use), but RVM is certainly VERY useful for creating tapes, I find. Surely, just saving out to a distributable tape file is preferable to having to go through audio file conversion.
Here's RVM: https://www.retrovirtualmachine.org
NB There must surely be plenty of other emulators that can save tape files. (Fuse is supposed to be able to, but I've always had trouble with doing it in the Mac version.) RVM can't be your only choice. I suggest it simply because I've found it useful for doing that, and I like its interface for creating tapes. It makes it pretty easy and lifelike.
I don't understand why you always distribute .tap files of your games in this frankly AWFUL way! You alway supply .tap files that contain raw audio data, which is the worst possible way to do it. Yes, they work in Fuse, but it's very much in the minority; hardly any emulators support this format properly (if at all) – e.g. your .tap won't load in the popular Retro Virtual Machine, though it finds some of the blocks – and so you have a .tap file that could and should be pretty much universally supported, but which works in hardly any emulators. Even with Fuse, the results are highly undesirable because you can't see or access the data blocks easily, and the user interface to the tape becomes useless, in effect. It also slows down the loading in effect, because it has to simulate pulling in the data (albeit at a turbo speed).
On top of that, supplying data in this way is MASSIVELY inefficient. The .tap file of this game is nearly 2MB in size; in reality, if it were supplied as a proper .tap file, containing just the data blocks that you normally expect to find, it'd be only a few 10s of K, or perhaps a bit over 100K if it's a massive 128K Spectrum game (which I doubt). So there's really no advantage whatsoever in supplying your games in this format, yet you always seem to do it this way. Is there some good reason why?
Surely you could just save out a regular .tap file in an emulator running your AGDX software, couldn't you? How do you actually save your games once you've created them? If it's in a way involving actual audio output, then there's SURELY a better way to do it via emulation and create exactly the type of file that's needed. In my experience, Fuse is not very good at creating .tap files (certainly not on the Mac), but doing this is one of Retro Virtual Machine's strengths. So, using RVM, can't you just create a blank .tap file and then save to it from the emulator, thus producing a standard, universally supported .tap file that you can then distribute? Bonus: if you did that, you then wouldn't also have to supply a snapshot file for all the people who can't load your .tap file…!
It'd be great if you'd do this with this and your other games, too. Thanks a lot. It'd make all users a lot happier and widen your audience, too, as your method of distribution is currently a real obstacle to running your games.
Good luck with this game. It looks as promising as usual. I've just had a brief play at the first part of the English version, and here's a little bit of feedback based on that initial try. Mostly I've just found some trivial typos, but the last point is about an important apparent bug:
1. "Physical" should be spelt with a "y" in it, not an "i" (title screen).
2. "Teclado" should be "Keyboard" in the initial control choice. (And since you say "Sinclair Joystick" in this choice, I think you should also say "Kempston Joystick", not just "Kempston".)
3. If I examine the workbook and the comic, and work my way through the motorcycle race, then whenever I make a bad choice, there's a faulty character in the failure message. Where it says "I don't remember having drawn it like that", there's an unwanted character after "that", before the full-stop. It looks like it's probably an "í" (acute-accented i).
4. *** BUG1 *** After working through the motorcycle race in the comic, if I then choose the "I order a cup of coffee" option, and follow it with the "Inventory" option, I just end up with a completely blank black screen, and nothing else happens.
I'm sure there will be other little problems to find, but that's as far as I've got. Overall, the quality of the English translation seems very good so far.
I've just downloaded the new version 1.1, and it doesn't seem to work. I've tried both English and Spanish versions in four emulators (Fuse, Retro Virtual Machine, ZXSP, Clock Signal on the Mac) and in all cases it just produces a colourful crash during loading. The existing version 1.0 – which, thankfully, I kept – works fine. I can't believe I'm the only person to have experienced this problem in the month since the version 1.1 update was released, but nevertheless, that's what I find…
Hi,
I admit that I haven't yet had chance to try this out – and I certainly will. But my initial reaction to the news about the absence of keyboard controls is… Y'WHAT???! :-)
Other than a handful of games that were specifically designed for use with a light gun (and how many people had those…?), I have NEVER encountered ANY Spectrum game that lacks keyboard controls. Making a game joystick-only is an extremely Commodore thing to do, and thus a heinous crime and wholly unacceptable.
In all seriousness, though, I personally simply do not like joysticks and game pads. I never even owned a joystick in the 80s when I had my original Spectrums. On the Next, I do now have a joystick and a game pad, but I only really got them for testing purposes, and I rarely use either. I'd MUCH rather use the keyboard, every single time.
Objectively and dispassionately, it's a straightforward FACT that the keyboard is inherently more responsive than any joystick. The only instance I can think of where I can imagine that a joystick might be desirable is when you have a keyboard-destroying 'waggler' game of the Hypersports/Daley Thompson ilk, where using the keyboard can kill both your keyboard and your hands. And even that's arguable.
The point with a joystick is that the stick has to travel in the direction indicated. By contrast, on a keyboard, the only travel is in the depression of the key. Thus, on a joystick it takes time to move in a particular direction, and it's impossible to indicate more than two directions (i.e. diagonals) at once, whereas on a keyboard you could potentially press all the directions at the same time. (Not generally terribly useful, but nevertheless…) Ergo, the keyboard IS simply faster and more responsive in use than any joystick; it's a simple physical fact. With a game pad, maybe you can use it like a keyboard, maybe you can't; it depends on the pad. Either way, it's either equivalent to a keyboard or less good than a keyboard. It can only be said to be better inasmuch as you can pick it up more easily, and there are no other distracting and unnecessary keys. On the other hand, you're probably stuck with the four-key diamond layout for the direction buttons, whereas on a keyboard (if the keys are redefinable) you can choose the option of having horizontal controls under one hand and vertical controls under the other, which I for one generally much prefer. Moreover, assuming the keyboard is indeed redefinable, you can choose the layout that you find most comfortable and responsive.
In other words, I'm REALLY struggling to imagine any justification whatsoever for NOT including keyboard controls – especially on a Spectrum, where keyboard control is universal and joystick has always been an optional extra.
So I will give your game a go in its current form when time permits, but if it always requires a joystick, that will be a very substantial deterring factor against it for me. I very much hope you'll get around to implementing keyboard control before it's considered 'finished'.
PS It's similarly hard to imagine why keyboard controls "work poorly" for this game when the equivalent joystick controls presumably work fine. How can that be? How is it that up, down, left, right and fire are so hard to pull off on a keyboard, considering the evidence of 40+ years of Spectrum gaming, and hundreds upon thousands of previous Spectrum games, all of which use the keyboard and have managed to pull it off successfully over all that time? I think the end user needs to see evidence of the poor performance of the keyboard controls in this game, and be given the option of which control method to choose.
The above is of course intended in good humour, but I think my basic points are valid.
This is a great game – an excellent follow-up to Tut-Tut.
I've spotted a couple of typos, though!
1. "BARCELET" on the list of scores
2. "KNOSSOS" on the list of objectives – inconsistent with KNOSSOSS elsewhere.
To be honest, I'm not sure about the title itself, as I thought there was only one S at the end of both Minos and Knossos (so point 2 technically isn't an error), but maybe there's some cunning reason for the extra Ss in the title. Anyway, point 2 is still an inconsistency.
Trivialities, I know, but I thought I'd point them out. 'Barcelet' is definitely a typo worth correcting.
Hi, thanks for doing this. However, could you please supply the updated game as a .tap file (like the original)? Unfortunately, a snapshot is the least desirable distribution format in many ways. People can easily make their own snapshot from a .tap file if they want to, but they can't do the reverse at all easily. A .tap would be best for both widespread compatibility and archival purposes. Thanks.
Hm. There's a lot to like about this, and it's almost very good… but the whole business of the ship getting destroyed (and ending the game) really is INTENSELY irritating and unfair. The shield is often depleted and then the ship destroyed and there's just nothing you can do about it. Also, the need to position the ship sections together pretty precisely is also frustrating. The beauty of the original Jetpac is that it was so very easy to play. It could be annoying, but it didn't have these aspects of sheer frustration. Take away the possibility of the ship being destroyed and make the assembly less frustrating (i.e. make it more like the original) and this could become really fun
Sorry, but I've just noticed a bug in v1.2. Just playing the first level, the cherries appeared for the second time (I think) – I'd missed them first time round – and they seemed to stay on-screen an unexpectedly long time. But I managed to reach them, and rather than collecting them, Pac-Man passed right over them and they stayed there on the screen.
Your archive contains separate downloads for the ZX Spectrum and the ZX Spectrum 128. These are clearly not the same because the code is different between the two, yet I can find no functional difference between them. There isn't any AY-3-8912 sound in the 128K version, which would be one reason to have two versions. Also, both versions work equally well on 48K Spectrums (even the supposed 128K version – which is actually smaller than the 48K version).
Could you therefore please explain what the difference is between these two versions? Thanks!
Thanks a lot. I'm pleased to say that I've been able to convert it to a plain .tap file successfully. Where should I send it to get it to you? NB If you'd like to email me directly, my email address is my name (as shown here) with the @ instead of the space (surname is domain name) and .net on the end.
I'm not familiar with how raw audio data is encoded is .tap and .tzx files – and I don't know how you're creating them to produce this result. I suspect it's probably just a .wav file in a .tap/.tzx wrapper, but I'd have to look into the file format specs to be sure. Anyway, there are various tools that do convert .wav files into 'proper' .tap and .tzx files. I haven't a lot of experience of creating such files personally, but I've managed it successfully from time to time. audio2tape (one of the Fuse utilities) is one such tool, and there are certainly others. If you can't manage it successfully yourself, if you post a straight .wav version of your tape file(s) here, I'm sure that someone would manage to do it without much trouble. I'd be happy to try myself, or someone else might beat me to it!
The .TAP and .TZX files currently supplied are unfortunately some sort of raw audio rather than proper tape files. This means that (a) they're much less useful than they should be and (b) they're approaching 40 times larger than they need to be (1.8MB rather than around 50K). Could they please be converted into 'proper' tape files? NB Since only a standard loader is used, a .TAP file is all that's required and a .TZX isn't really necessary. Why not instead supply (a) a proper, regular .tap file for users of emulators and modern hardware with SD cards, and (b) a .wav audio version for people to play in if they want to use original hardware?
NB The same comments also apply to your other release, Ziona Quest X.
Wonderful! Thanks very much indeed! This makes all the difference! :-)
If you're wondering why I care… when using an emulator on a modern keyboard, the right-hand Shift key is perfect for 'jump'. I typically choose either Q, W, Shift (JSW-style) or Z, X, Shift. I don't like using the space bar for 'jump' as it's too big and clumsy, but a regular key like M is too small for a one-handed function. The right-hand Shift key is just perfect.