New Adventures?

[Dethmunk]

Is anyone doing new Text or Text/Graphic adventures on the Beeb/Elk? I'm thinking of doing a new game, just starting to form the map and puzzles now. I'm an artist (by trade) so it's definitely going to have graphics pulled off disc. Here's a taste...



A supernatural tale of world ending terror. You have been drawn to Raven Wood. Why? What is special about you? Lord Raven Wood has some dark and menacing mission afoot. A plan that could plunge the world into everlasting darkness! The villagers cower in the Tavern and outside the surrounding area is being stalked by the stuff of nightmares!

[hoglet]

Yes please!

[Dethmunk]

I shall endeavor to finish it then....

[CMcDougall]

sounds wicked already!
and nice 'n' dark screen loader

[Dethmunk]

Let the Darkness creep in....

[Dethmunk]

Here's a mock-up of the very first starting location screen. Obviously the font style is not right, but you get the idea.

[sweh]

*hear* noise

[Dethmunk]

Ha ha true....its only a mock up and its late....

[Lardo Boffin]

That looks awesome! It puts me in mind of the Lucas Arts games on much more powerful machines.

Lardo

[Dethmunk]

Thanks Lardo.
Yeah that's the kind of art style I was going for. Hand drawn style. Now you mention it, yeah a bit of a Secret of Monkey Island vibe. Just without the jokes.

[Dethmunk]

A quick question. Does anyone know what the screen address is for the halfway point of a Mode 5 display? I really should work out how to calculate these things

[davidb]

The top is &5800, 16 lines is half way down, each line is &140 bytes long: &5800 + (16 * &140) = &6C00

[Dethmunk]

The top is &5800, 16 lines is half way down, each line is &140 bytes long: &5800 + (16 * &140) = &6C00

Awesome!!! Thanks Davidb.

[Lardo Boffin]

[leenew]

Looks awesome!
The most important part of an adventure (to me) is the plot and the puzzles... so I hope you have enough energy to pull off these amazing graphics PLUS an enjoyable adventure
My fave genres for adventures are classic cave crawls with magical elements, and spooky horror stories, so I am really looking forward to this being finished
If you only have energy for the visuals, how about a collaborative effort with the plotting?

Lee.

[Dethmunk]

Here's the title-screen and final version of the first location for The Darkness of Raven Wood. I've tracked down some interesting code to help with text compression and font compression too. Hopefully these will work nicely with the game to give a rich text and graphic adventure.



There's going to be a fair bit of graphics work. We'll see how many screens I can physically get done and how many will fit on a typical disk. Ideally I'd love to draw every location as bespoke visuals, but I might have to cheat, with repeated graphics for multiple locations like tracks or woods etc.

First part of the adventure (mapped so far) has 22 locations, would need 18 bespoke location graphics and 2 'other' graphics. So there's a bit of repeating for certain locations already.

@Leenew - Totally agree. Well I'm going for hopefully a supernatural horror vibe. I'm hoping to instigate some nice little touches like for instance, in a ruined burnt out church yard, you see a lumbering creature of the dead (zombie) amidst the gravestones. But your given a few goes to enter commands, as its a zombie is very slow moving after all. But with each command entered it gets ever closer. Hang around too long and .....well you know, you've seen The Walking Dead... LOL The point is its not just 'a zombie' it has a backstory and once you learn it you then know it has a important element for the entire adventure.... I'll say no more.

[hoglet]

There's going to be a fair bit of graphics work. We'll see how many screens I can physically get done and how many will fit on a typical disk. Ideally I'd love to draw every location as bespoke visuals, but I might have to cheat, with repeated graphics for multiple locations like tracks or woods etc.

If this is half a Mode 5 screen, that would be &1400 bytes, which is 5KB.

A standard single density 80 track Beeb disk is 200MB, so about 40 images.

And you could use both sides.

Dave

[Dethmunk]

There's going to be a fair bit of graphics work. We'll see how many screens I can physically get done and how many will fit on a typical disk. Ideally I'd love to draw every location as bespoke visuals, but I might have to cheat, with repeated graphics for multiple locations like tracks or woods etc.

If this is half a Mode 5 screen, that would be &1400 bytes, which is 5KB.

A standard single density 80 track Beeb disk is 200MB, so about 40 images.

And you could use both sides.

Dave

Still got to leave room for the Program too. lol. Thats through DFS though right? Does the BBC use ADFS too like the Electron did. That could manage 80 track 640k maximum I think? May be I should review how many locations will feature graphics. It's obvious to me I can't do every location. Need to be sensible about it. Just realized you mention the DFS can have 2 sides, so thats around 80 images, which should be more than enough. How does that look in a digital file, doesn't it treat each side as a separate drive?! So I read.

[hoglet]

Just realized you mention the DFS can have 2 sides, so thats around 80 images, which should be more than enough. How does that look in a digital file, doesn't it treat each side as a separate drive?! So I read.

Yes, each side is a separate drive, with a separate catalog.

The other limiting factor with DFS is the catalog only has room for 31 files.

Dave

[Dethmunk]

Just been noodling around. Used BBCExplorer to create a blank disk image. A .dsd file. Which has Side 1 and Side 0. Question. I get I can drop files onto either side that's simple. Does BBCExplorer create the 80 track 200k a side version of this file type as standard? and when I'm coding do I have to refer to the appropriate side somehow when loading a file or will the BBC automatically search for the file on either side of said disk?

As you can tell, I had no interaction with disk drives back in the 80's, only now am I trying to understand the BBC system.

[Dethmunk]

Just realized you mention the DFS can have 2 sides, so thats around 80 images, which should be more than enough. How does that look in a digital file, doesn't it treat each side as a separate drive?! So I read.

Yes, each side is a separate drive, with a separate catalog.

The other limiting factor with DFS is the catalog only has room for 31 files.

Dave

Ah so only 31 files per side. Hmmm. Definitely need to look at cutting down the locations with graphics then. Or make it a multi-disk extravaganza!!!

[poink]

Still got to leave room for the Program too. lol. Thats through DFS though right? Does the BBC use ADFS too like the Electron did. That could manage 80 track 640k maximum I think?

The greater capacity on ADFS disks is because of the use of MFM encoding, which requires a 1770-style floppy controller. As the 1770 was much cheaper, 3rd-party ones usually are, as is the one in the B+ and Master lines. The exception is the official Acorn floppy upgrade for the Model B (and A), which uses an 8271, which only supports FM encoding. (The only reason Acorn used the 8271 seems to be that they already had the circuit design from earlier machines.)

The maximum Acorn did on a Beeb was 800K like the Archimedes (however, it was for DOSplus on the Master 512). You can almost certainly get more by using a custom format (albeit, at the expense of compatibility with emulators etc.,)

You can use a DFS format with MFM encoding - 3rd party upgrades were often supplied with 'double density DFS'. You can also claim more space by using larger sectors (this reduces the amount of space used in in intersector gaps). In order to get this to boot on a standard Acorn DFS, you can format the first track as a standard BBC DFS first track, and use it to store your loader (BTW, you can put some of your loader code in the unused entries of the DFS catalogue...).

Once you're having to write your own loader, there's little reason not to use a custom format, with as few sectors per track as possible - you should be able to get fairly close to 1MB per disc. Getting an emulator to understand such a format might be interesting though!

and when I'm coding do I have to refer to the appropriate side somehow when loading a file or will the BBC automatically search for the file on either side of said disk?

It won't look: it sees it as a separate floppy drive - DFS assumes that you're using a single sided floppy drive, it does however, have a bit of a hack to provide some support for double sided drives; side 0 of the first physical drive is drive 0, side 1 on the first physical drive is drive 2, side 0 of the second drive is drive 1, side 1 of the second physical drive is drive 3.

It wasn't until ADFS that Acorn provided something that could seamlessly use both sides.

Ah so only 31 files per side. Hmmm. Definitely need to look at cutting down the locations with graphics then. Or make it a multi-disk extravaganza!!!

Alternatively, you can store multiple images per on-disc file.

[oss003]

There are several options to reduce the data format of screens:

- Use tile-based graphics (4*8), the size of a picture is reduced to 40x17=680 bytes + the tile data.
- Use a set of drawing commands to draw a screen, I know Quill for the Spectrum used a set of drawing/filling commands to draw a picture.
- Another option is to load sprites (eg. tree, house, moon, etc) to build a screen, this way you can use the same sprite in multiple screens.
- Use a compression algorithm like

• RLE, http://codebase64.org/doku.php?id=base:rle_pack_unpack or
  LZW , http://codebase64.org/doku.php?id=base: ... _crunching

Greetings
Kees

[oss003]

Hi guys,

I did a quick test with my Atom to compress a detailed picture with RLE compression.
The RLE pack/unpack code is only #120 bytes long.

The picture is 256x192 pixels = 6 KB.
This picture size was reduced from $1800 to $1403 bytes, about 17% shorter.

Greetings
Kees

[dp11]

Ah so only 31 files per side. Hmmm. Definitely need to look at cutting down the locations with graphics then. Or make it a multi-disk extravaganza!!!

Another option , say you limit yourself to 255 locations.

Take the top 5 bits of location to give you a filename e.g. 0 to 31. the lower 3 bits enable you to index into the file. you might have a little header at the beginning of the file if the images start at different locations. You might also have the text in the file too for the location.

You might also consider if you have spare SRAM or a TUBE to cache the next location the player might goto while they are reading the text/ typing in the command.

[davidb]

It might also be worth trying tricky's compressor.

[Dethmunk]

Wow all great suggestions. I have no physical disc drives attached to my BBC B. I do have multiple DFS's and a Retroclinic HD installed. I'm coding on BeebEm at the moment and then testing on the BBC when I get to that point.
I don't want to draw the screens via vectors etc. ala Twin Kingdom Valley or The Lost Crystals I really want the hand drawn versions. Or construct them out of Sprites.
I mean its all dependent on the size of the adventure. Double sided disc 60 location graphics max (maybe less) might be fine. Not all locations have to have graphics or can use repeated ones. So I can probably have a rather large adventure without going over budget actually. I mean something like The Hobbit only had 26 location graphics I think. Yet it was a much larger adventure.

I think I might be ok, once you know the limitations you're working to, its easier to scope the project. I was being a bit too ambitious really, on the plus side it means less work for me, graphics wise. LOL

Thanks again for all the advice guys, very interesting stuff.

[Dethmunk]

Plus I'm guessing most people would be playing this either through Emulator or via USB/virtual drives such as Retroclinic HD for instance. I was just wondering if its finished, someone might want to play it via an actual disk, at least it would be a viable option for them.

[Pernod]

I wouldn't be concerned about restricting yourself to 62 files on double sided DFS, why not make it Master only and take advantage of ADFS and the sideways RAM.

If you were developing this back in the 80's then being standard BBC compatible would be essential for sales, but today with emulation why not take advantage of the extra capacity and RAM.

[tricky]

There was a survey a couple of years back on here and over half had sideways RAM + all the emulators that I can think of
Compression would speed up loading from a real floppy and the overhead of around 100 bytes total should be affordable.
Sorry, as usual got carried away with techie bits, just be assured that there are many ways to make it fit on disk and retro fitting them should be fairly easy. Even the which side is it on should be a show stopper, try one if not there, try the other