Development of Blake's 7 (was OASIS development)

[Chema]

Just another video of a cutscene. In this scene, Blake and Avon try to hijack the prison ship by hacking the computer, while the rest of the group tries to find the armory (such as in the series). But something goes wrong...

A good moment to get to know more about the characters and also reproduce some dialogues from the TV series for the fandom.

Enjoy: https://youtu.be/YNHyPHmBnDg

[ibisum]

Looks amazing .. only comment I have, after watching the video, is that the characters really need to blink every now and then ..

[Dbug]

I really like the video on the screen

Maybe you should show some snow on it a bit before and after the communication.

[Symoon]

Very nice!
And I won't add any further thing to your todo list

[Chema]

Thanks guys! I can't add more animations for the characters. I am already short on memory. I may revisit this when the game is finished, or almost. Anyway I agree that the fact that they don't blink, looks a bit alien... XD

I also think some snow on the screen would make it look better. I will try to work out something.

And more screens and scenes have been added already. Currently at 34% of floppy usage.

[iss]

Everything looks amazing indeed!

Currently at 34% of floppy usage.

What is the target floppy format (sides/tracks/sectors)?

[Chema]

Hi iss. I should check in my sources, but the geometry is the default for 720K floppies, 80 tracks.

[iss]

If you use FloppyBuilder "as is" then the default format is: 2/17/42.
In last SVN version of FloppyBuilder source after line 345 sides=2 and sectors=17 are fixed.
In regard of my speed tests (which still continue with variable success ) I had to change above source
so it allows me to use 1 side and 15,16,17,18 sectors per track for real 3" one-side floppy drives.
But maybe for OASIS it will be best to limit all possible formats to 3.5" floppy disks with 2/17/80 -
the biggest reliable capacity of real hardware.

[Chema]

Yep, I used it as is. Now that you pointed out the default values, I don't understand. Why does it have 42 sectors per track, and not 80?

I get: 487 sectors used, out of 1428. (34% of the total disk size used)
But, in fact 720K in 256 byte sectors should give a total of 2880 sectors... am I right?

[Dbug]

Yep, I used it as is. Now that you pointed out the default values, I don't understand. Why does it have 42 sectors per track, and not 80?

42 tracks per side is the maximum size that fits on a 3" floppy - they have 360kb in total, not per side, so effectively have the capacity of 720k DD floppies.
(On a DD 3.5" we could use up to 82 tracks.)

[Chema]

So that means I am at 34% of a double side 3-inch disk?

So I can put:

Code: Select all

DefineDisk 2 80 17 3

and so I get:

Code: Select all

// 487 sectors used, out of 2720. (17% of the total disk size used)

Which means a lot more space than I thought!

Yeah, I am a bit stupid... I read the interleave thing, configured everything and forgot to change the number of tracks!

Another question, then. IIRC most of the 3-inch drives did not have 2 heads, so you had to flip the disk. Is that true? Does it happen in the Oric Microdisc drive? Is there any drive which could read the two sides? If I understood correctly, each 3-inch disk side is 160K, both sides being 320K in total.

If the game ends up fitting in a 360K disk I may try to get a 3-inch version, but if that means asking the user to flip the disk when needed, it might be a bit more than just a recompile. Just wanted to know...

[ThomH]

Possibly a tangent but if what we're talking about is a read-only format and total storage is an issue, why not dispense with sectors after the first track? Though you'd probably then need to avoid use of byte values above F4 if you want to be able to write the thing on Oric hardware and/or store reliably* as an emulator disk image.

But, supposing you conservatively allow 6000 bytes per track and expand F5 and up to two bytes then for a completely random byte stream that's 6000/(10/256*2+246/256)= 5774 bytes per track times 41 tracks = 231kb per side. Or so. Which is around a 28% improvement.

Probably not worth it for the tooling issues though?

[Dbug]

Regarding the 3" floppy drive: I've no idea how many drives were single sided, myself I ended up with one of each type, and I'm pretty sure all the Telestrats had double sided models.
It's probably possible to detect by software if the second side can be read, and if not ask the user to insert the second floppy/swap the disk.

Regarding the "large track without sectors", yes it's doable, and we even had some demos on the Atari ST that did that, but the end result is that it was a bitch to copy around, so these demos ended-up having their built-in copier with disk checker embeded.

If Chema was planning to release commercial versions of his game, duplicating the floppies himself, that would definitely be the way to go. On the other hand, if all he wants is to make it easier for people to play the game on as many machines as possible, and make sure it can be easily copied, no you definitely don't want to do that

[ThomH]

If Chema was planning to release commercial versions of his game, duplicating the floppies himself, that would definitely be the way to go. On the other hand, if all he wants is to make it easier for people to play the game on as many machines as possible, and make sure it can be easily copied, no you definitely don't want to do that

Yeah, tooling issues then.

One other observation though: if the thing is going to be read-only but you still want sectors, you can dispense with all but one byte of gaps and the track header*. Which by my count makes a 256-byte sector that occupies 16 + 6 + 1 + 16 + 256 + 2 + 1 = 298 bytes of track space. That puts you at 20 sectors = 5kb per track, with quite a lot of empty space at the end.

So 210kb per side for 420kb total. For a ~17% improvement, again while remaining compatible with the established emulator disk format and, probably, the established emulators. And real hardware, naturally.

... and there's no escaping on the individual bytes and the copying routine is trivial to write so you can put it directly in the game itself. It's just: find 5kb**, read 20 sectors to it, ask for new disk, perform a write track with tiny gaps, perform a sector-by-sector write of the data just read, repeat.

* assumption being: the same drive with the same disk will rotate at close enough to the same speed for the few rotations necessary to write that most of the gap is unnecessary; however I retained the 00 PLL synchronisations and a single byte of gap in case the given drive tends to splice when writing.

** temporarily use the screen area if you have to, as you almost certainly don't have anything stored there that you can't reproduce.

[Chema]

Hi guys!

First thanks for your ideas. I love these crazy tricks a lot! I'll, however, stick to the usual output from FloppyBuilder. It is already closed and incompatible enough as to prevent me for using easy tricks (such as copying a saved game from a disk by hand for use on another different build, etc.). It seems that the compression is more than enough to keep a rather large game with no issues (I hope).

I'd be very grateful if someone comes up with a solution for the interleave/speed thing. I am already too busy developing the game itself.

And I have some good advances. Unfortunately nothing that can be shown on a screenshot without spoiling the plot too much. But I'd say that Episode II is 60% programmed and 90% designed. I need to draw some more rooms for the final part on the planet Cygnus Alpha and then move onto designing the plot for Episode III.

Already 26 different rooms in, with some new (and I hope interesting) puzzles and events. This part is much more guided by cutscenes and automatic dialogues, because of the interaction between characters. So expect to read a lot and to watch characters doing things. Solving puzzles just push the story through. Nevertheless, I think you'll find the result nice, fun and interesting.

In addition the first part of this episode contains puzzles which are of slightly different nature than the previous one; less go and find these objects to give them to this character and room-walking and more one (or a just a few) different rooms, a few objects and dialogues to trigger events and use your brains to find out a way to solve the puzzle.

As I am getting used to the power of the script language, I am able to do some advanced things. Imagine that you need to perform an action in a precise moment so something else occurs. If you fail, you receive some kind of (harmless) damage. I could leave that as such, but the adventure player may find this frustrating if he tries 5 times in a row with no success, so after some failed attempts I added a "Hey!, Are you trying to kill me? - Let me do it by myself" message and our hero does the task automatically. In the end you knew that had to be done and this is not a platform or shoot-em-up game.

I am quite sure you'll enjoy this part.

On another matter, I hit the memory limit barrier several times, which drove me crazy for some days. There is one particular scene with a lot of characters involved and a lot of text which is very memory hungry. I will have to start thinking about optimizing things and saving memory because I have just over 500 bytes in normal memory left (if I want to give this scene memory enough to run as it is) and even less in overlay ram before I overwrite the loader code.

This is a bit frustrating because, even if the engine is almost finished, I have not put in the code needed for redefining keys, handle joysticks, etc. And the needed memory grows with the number of things stored in disk, so I am a bit worried about this.

As I already said, this is by far the most complex project I have ever worked at. And it is going quite well for now