The Lords of Midnight : Landscaping

[Tosk]

The Lords of Midnight was a popular and epic graphic adventure game by Mike Singleton for the ZX Spectrum (and other platforms - but not for the Beeb) originally released in 1984.

Here's a few screenshots of what it looked like:-





I never completed the game but did remember these landmark graphics. The technique that the author Mike Singleton used was "Landscaping" - using scaled graphics shown as a first person perspective view. It was unique at the time - definitely moving computer graphics forward several notches.

The challenge I've set for myself is can this be done on the Beeb with Basic? I'm only interested in getting as far as having a grid of locations, the player being able to move in one of the 8 compass directions and having a simple landscape view implemented.

The code I have developed so far is in a link at the bottom of this post which includes:-

1) The player grid set up, currently 16 x 16. Each location has a number representing a tree or mountain or just an empty space. The player grid is displayed at the moment for diagnostic purposes, showing the position of the player, with a note at the top of the screen showing which direction the player is facing.
2) The player being able to look in one of the 8 compass directions (using numbers 1-8) and move with the key "m".
3) Some procedures to draw scaled mountains and trees. (adapted from graphics code with thanks to Dominic Pajak) . The current code just shows a demo of these scaled graphics being used, showing random mountains and trees each time you look in a different direction or move.

This is an example of scaled graphics I have developed so far. The tower from the code below has been removed for now to save memory.



I have a Graphics Extension ROM (GXR) - so am using some of this extended command set in my code.

The big challenge is being able to represent the "landscaping" technique. I suspect this will be quite challenging squeezing it into memory, but I want to give it a go.

Luckily this technique is outlined in detail on this web page (see below), where Christopher John Wild has put a lot of work into understanding the game and breaking it down.

https://www.icemark.com/tower/landscaping.htm

I think it's an interesting challenge, since to my knowledge the Lord of Midnight or it's landscaping technique was never ported to the Beeb or other Acorn machines.

https://bbcmic.ro/#%7B%22v%22%3A1%2C%22 ... %5Cn%22%7D

[SteveF]

I'm having trouble understanding the calculation and adjustment tables and how they relate to the diagrams at the top of the page showing a top down view of the player looking across the tiled map.

This is really interesting! (Seeing the screenshots also reminded me of reading about the game on The Digital Antiquarian a while back.) I've had a quick look at the code and it isn't immediately clear to me how it works, so unless I have a brainwave I look forward to someone else's insights.

I think it's an interesting challenge, since to my knowledge the Lord of Midnight or it's landscaping technique was never ported to the Beeb or other Acorn machines.

I don't say it's exactly the same technique, but the (much later) Holed Out golf game may have used something similar - the player can move relatively freely around a 2D plane and see a pseudo-3D view of a consistent landscape. I do wonder if this is done using "brute force" trigonometry instead of lookup tables though. Maybe even binary space partitioning or something exotic like that?!

[Tosk]

This is really interesting! (Seeing the screenshots also reminded me of reading about the game on The Digital Antiquarian a while back.) I've had a quick look at the code and it isn't immediately clear to me how it works, so unless I have a brainwave I look forward to someone else's insights.

I don't say it's exactly the same techn ... ]Holed Out golf game may have used something similar - the player can move relatively freely around a 2D plane and see a pseudo-3D view of a consistent landscape. I do wonder if this is done using "brute force" trigonometry instead of lookup tables though. Maybe even binary space partitioning or something exotic like that?![/url]

Thanks Steve.

I'm now at the point where my code is attempting to "read" the landscape elements depending on which direction the player is facing.
I'll take a look at "Holed out" as well - that looks interesting.

The code include a variable "perspective depth'" (pd%) which sets how many lines (or how far back) of the grid the player can see.

The variable cp$ = "3579" (cardinal points row widths) defines the width of those lines, so in this case, the furthest row away shows a width of 9 cells, a closer row shows 7 cells, then 5 cells across and the closest row is showing 3 cells across. So in this case it is defining a triangular shape (a similar example shown below - which is more of a cone shape) of what the player can see. The cone graphic below is more detailed than mine at the moment where cp$ would be set to "5,7,11,11,9,5"

I've only dealt with N and S and need to test for E and W at this point. The intercardinal directions (NE,SE,SW,NW) might be harder!

I'll also need to optimise the code - but at the moment I'm just trying to get the basic landscaping method to work.



https://bbcmic.ro/#%7B%22v%22%3A1%2C%22 ... %5Cn%22%7D

[Tosk]

I now have the code able to "read" the landscape by looking either N, E, S or W.

The last column in this development output is showing the landscape elements ahead of the player (in the direction that they are facing).

I will deal with inter-cardinal points next.

But in the meantime, my idea is to check when the player is looking beyond the edge of the map as they move towards the edge. I will be placing a line of landscape elements of "1" (representing a mountain) to show an impenetrable barrier around the map.

I thought that would be easy enough, but I'm getting a subscript error on either line 710 or 720

IF ex% > ms% OR ex% < 1 OR SGN(ex%) = -1 THEN Element$ = "1" ELSE Element$ = map$(ex%,ey%)
IF ey% > ms% OR ey% < 1 OR SGN(ey%) = - 1 THEN Element$ = "1" ELSE Element$ = map$(ex%,ey%)

I added the check OR SGN(ex%) = -1 out of curiosity, because I would have thought ex%<1 or ey%<1 would have done the job.

So my question "Is it the case that the interpreter still calculates the ELSE part of the statement (causing a negative number to be used in an array) even though it shouldn't be executing it?"

...or maybe I've overlooked something really simple here.

https://bbcmic.ro/#%7B%22v%22%3A1%2C%22 ... PROC%22%7D

[tom_seddon]

In either case, the unchecked one of ex% or ey% could still be invalid.

--Tom

[Tosk]

In either case, the unchecked one of ex% or ey% could still be invalid.

--Tom

Thanks Tom. I was getting a bit blind staring at my own code.

[Tosk]

I happy to report a proper working version of this first person perspective landscaping exercise in BBC Basic. Really pleased to have got this far!

A reminder on the meaning of the display. A 16 x 16 grid is displayed showing the player initially in the centre of the land, represented by the "@" symbol. A digit "1" represents a mountain, a "2" represents a tree. Digit "3" will represent something a little more rare (eg a tower) if there's enough memory to play with - but this hasn't been implemented yet.

A reminder on the controls. Keys 1-8 allow you to look in the points of the compass N, NE, E, SE, S, SW, W, NW. Key "M" will move you one space in the direction you are looking.

An array of first person perspective points are now worked out, with mountains and trees drawn to a scale depending on the perspective distance.

There are a few bugs still:-

1) NW and SE read the landscape elements right to left rather than left to right, so I need to sort this.
2) I get a subscript error at line 800 when travelling east, getting to cell 12. The detection of checking if we have reached limit of the map array (defined by ms% = map size) fails. Again this is probably something simple when I revisit this, but if you spot the problem beforehand - let me know!

In the meantime happy exploring of the map!

https://bbcmic.ro/#%7B%22v%22%3A1%2C%22 ... Cn%22%7D

[Tosk]

Now I've squeezed in a procedure to draw towers in the landscape!
Edge detection of the map is sorted.
Bug : Inter cardinal directions need work
Cardinal directions (such as west) need to cross check that landscape elements are being read properly from left to right.



https://bbcmic.ro/#%7B%22v%22%3A1%2C%22 ... PROC%22%7D

[Tosk]

There was a bug in placing the scaled landscape elements correctly from left to right when looking South or West, where it was placing them backwards. The bug is fixed, though because extra lines of code were needed to fix it, I hit max memory. So the inter-cardinal views (NE,SE,SW,NW) have been removed.

This means that the revised keys to use are :
1- look N
2- look E
3- look S
4 -look W
M - Move one space in the direction you are looking

A little bit of memory may now be free to provide a game task for this program, so my plan is to place a hidden element in the map that you need to find in the least moves.

https://bbcmic.ro/#%7B%22v%22%3A1%2C%22 ... PROC%22%7D

[fizgog]

Just to say I’m enjoying reading your progress on this, keep up the good work

[jms2]

Same here. I was totally unaware of this game, but I was always a bit dissatisfied with traditional adventure games (graphical or otherwise) and had this sort of vague aspiration to come up with some way of either plotting or describing a predefined landscape from any given direction. Of course I never figured out how to do this - but it looks very much like LoM does what I was looking for!

[NickLuvsRetro]

I'm a massive fan of Mike Singleton. It was his later games (Midwinter series) that got me hooked into computing. Particularly the concept of procedural generation, his obsession with generating massive worlds in such limited hardware. Likewise I'm really enjoying your progress on here!

[Tosk]

Thanks all for checking in on my progress on this. I've really enjoyed the challenge of trying to emulate this landscaping technique!

Perhaps I can challenge everyone to add in replacement procedures to provide alternate (and better) graphics into the code so far. Because of limited space I don't think we will get beyond more than 3 or 4 elements. Remember you'll need to include X,Y (position of graphic) and a scaling parameter (S). Just use the existing procedures as templates.

One approach may be using the same procedure to include a toggle parameter to produce graphical elements that are similar and may only need a few extra lines of code to make the difference. The toggle would act as a switch between one graphical element or another. So for example I am beginning to experiment with trying to produce an "icy waste" graphic or a mountain with the same procedure. I was also trying to switch between a tower and a keep, which have similar elements but just need different dimensions or proportions applied.

Here's some examples still in development and are unfinished but this includes a procedure to draw a simple citadel, a procedure to switch between a mountain or icy waste element and WIP procedure for switching between a Tower and a Keep.



https://bbcmic.ro/#%7B%22v%22%3A1%2C%22 ... ROC%22%7D

[Cybershark]

May be worth considering switching to the (monochrome) MODE 4 if you're that tight on memory.

[shadow]

The Lords of Midnight is my all time favourite game from my childhood (I played it on the zx spectrum), so I love the idea of this project.
I think you have the right idea about finding commonalities with the graphics elements.
So instead of calling separate functions for each graphical element, I thought why not just have one "Drawing" procedure, that we call for every graphical element. The procedure can do 5 things, Move/Draw/Plot(Triangle)/Plot(Rectangle)/Change Color, and we build each graphic with those.

I've never coded in this language before, so you can probably do a lot better. I borrowed your magic print statement that made the colours blue. I have no idea how that works. (And the way you make the trees is genius)

Here's an example of 5 objects (wastes/citadel/keep/mountains/tower) and how to draw them (I kept the graphics simple):
https://bbcmic.ro/#%7B%22v%22%3A1%2C%22 ... %5Cn%22%7D

I tried to integrate this with one of your earlier code versions, but there's memory issues with Mode 1. I reckon switching to Mode 5 (still 4 colours, but a little blockier) would give you more room for actual game code. Here's a rough and ready example of what mode 5 would look like mashing your code together with what I did today:
https://bbcmic.ro/#%7B%22v%22%3A1%2C%22 ... PROC%22%7D

I think that mode change would give you close to an extra 10k to code with, but as I said, this is my first day with this. The graphics would need to be remade slightly for the new mode. Anyway, do keep going with this. I'm fascinated by what's possible.

[Tosk]

I think that mode change would give you close to an extra 10k to code with, but as I said, this is my first day with this. The graphics would need to be remade slightly for the new mode. Anyway, do keep going with this. I'm fascinated by what's possible.

Thanks shadow - this is a fantastic development, squeezing the graphics in by this method! Great idea - I'm really pleased how you've progressed this.

The other graphic element I tried to play with, but it requires more of a sprite approach perhaps, was based on the original LOM dragon character, in order to use this as the "special" graphic and "hide" this in the grid. As the player gets nearer the dragon you'll get a "warmer" kind of text hint appearing. This is the game element I want to add. I'm busy with work commitments at the moment, so may not find time to add this for a short while. If there's enough memory - it would be fun to move the dragon around to make it even harder to find.

The other element I felt like introducing was the kind of descriptions that the original LOM locations had, which were built with a token dictionary (see this web page by Christopher John Wild): https://www.icemark.com/dataformats/mid ... drawformat. My aim would be just to have a small list of description tokens (10-20?) and add coding to each cell of the grid, or more practically zones of the grid to add more of an atmosphere to the game.

This is the original LOM dragon I was trying to go for:-



It might be possible to build this merely with triangle, move, draw. Perhaps worth an experiment for anyone that's interested.

[Cybershark]

Here's an example of 5 objects (wastes/citadel/keep/mountains/tower) and how to draw them (I kept the graphics simple):
https://bbcmic.ro/#%7B%22v%22%3A1%2C%22 ... %5Cn%22%7D

I tried to integrate this with one of your earlier code versions, but there's memory issues with Mode 1. I reckon switching to Mode 5 (still 4 colours, but a little blockier) would give you more room for actual game code. Here's a rough and ready example of what mode 5 would look like mashing your code together with what I did today:
https://bbcmic.ro/#%7B%22v%22%3A1%2C%22 ... PROC%22%7D

I think that mode change would give you close to an extra 10k to code with, but as I said, this is my first day with this. The graphics would need to be remade slightly for the new mode. Anyway, do keep going with this. I'm fascinated by what's possible.

These both work very well and that's quite the efficient all-in-one plot routine. MODE 5 doesn't look like a bad option there either
A big space saver (for your examples) would be offloading the plot data elsewhere. Creating an initialisation program to save it away in memory means you then have a clean slate with the actual display/game program, without your RAM being clogged up by all the BASIC DATA statements. The data could then be directly addressed by memory location or loaded into an array in that program.

[TobyLobster]

This is the original LOM dragon I was trying to go for:-



It might be possible to build this merely with triangle, move, draw. Perhaps worth an experiment for anyone that's interested.

I made a general purpose polygon fill routine, but it may be too slow.
https://bbcmic.ro/#%7B%22v%22%3A1%2C%22 ... %5Cn%22%7D

I invite others to optimise it.

[TobyLobster]

I optimised it a bit here here

EDIT: ...and a little more here

EDIT: ...and a little more here

EDIT: ...and a little more here

EDIT: ...and further tidied up a bit here

EDIT: ...and further scrunched here

[Tosk]

@TobyLobster - this is a great development to see!

I was thinking of only displaying the dragon when the player actually landed on the grid square it was in, with text messages at the top of the screen indicating how close or how far away the player is from the dragon before the player got to that final square.

So with that thought in mind another optimisation would be leave out any calculation of scaling (leave at 1), which will make the procedure a little faster.

[TobyLobster]

Removing the scale doesn't make a big difference. But this is much faster, at the expense of a bit more data.

EDIT: If you only plot the dragon at one size you could use *SPOOL to record the VDU output of the dragon being drawn into a file. Then when you need to display it you just *EXEC the file, and the dragon takes up no memory.

[fuzzel]

Wow, that is quick. I wonder just how much faster an assembly language version would be

[shadow]

I worked a little on a lot of graphical elements this weekend.
Mountains/Wastes/Citadel/Tower/Keep/Lith/Lake/Downs/Caverns/Ruins/Forest/Henge/Village/Snow Hall
Made them a bit more consistent with regards to centering/scaling, but there's still work to be done. Mountains and Citadel could use more detail. Some objects scale clumsily.
I took the code for a tree, and altered it to give a cluster of 5, which looks a bit closer to the game aesthetic


I'll link to a program that shows them all on screen at the same time.

https://bbcmic.ro/#%7B%22v%22%3A1%2C%22 ... PROC%22%7D

Feel free to take/use anything you want.
Caverns and Liths both need a Downs to be printed at their location first. (basically just a reused asset)
Cybershark, you said we could save space by offloading the plot data elsewhere, but is that possible using the bbcmic.ro site? I am not good with anything beyond the simplest code.

[TobyLobster]

Fastest

[Cybershark]

Cybershark, you said we could save space by offloading the plot data elsewhere, but is that possible using the bbcmic.ro site? I am not good with anything beyond the simplest code.

Haven't used the editor before but I see it tells me that PAGE - the BASIC program start address - is set at &1C00. The standard value for a disk filing system is &1900, so changing it to that already gives you an extra 1k. and, realistically, you can usually set it all the way down to &1100, so that would free up another 2k.

I think that you'll have to shift over from Owlet to an emulator (or real hardware) if you need to start juggling multiple files but, in terms of code, it's a very simple thing to do. Simply create a "data maker" program containing the following - along with all the plot data statements:

Code: Select all

FILE%=OPENOUT"PLOTDAT"

FOR Q%=1 TO 957
READ DAT%
PRINT #FILE%,DAT%
NEXT

CLOSE #FILE%

That creates a data file called PLOTDAT which can be very simply read back in by the main program with the following:

Code: Select all

DIM IN%(957)
FILE%=OPENIN"PLOTDAT"

FOR Q%=1 TO 957
INPUT #F%,IN%(Q%)
NEXT

CLOSE #FILE%

And, ta-da, you've now lost all the memory overhead of having those data statements in your main program.

Do note, however, that PAGE has to be set to (at least) &1300, as some workspace is required for file handling - see here.

[TobyLobster]

Cybershark, you said we could save space by offloading the plot data elsewhere, but is that possible using the bbcmic.ro site? I am not good with anything beyond the simplest code.

Haven't used the editor before but I see it tells me that PAGE - the BASIC program start address - is set at &1C00. The standard value for a disk filing system is &1900, so changing it to that already gives you an extra 1k. and, realistically, you can usually set it all the way down to &1100, so that would free up another 2k.

I think that you'll have to shift over from Owlet to an emulator (or real hardware) if you need to start juggling multiple files but, in terms of code, it's a very simple thing to do. Simply create a "data maker" program containing the following - along with all the plot data statements:

Code: Select all

FILE%=OPENOUT"PLOTDAT"

FOR Q%=1 TO 957
READ DAT%
PRINT #FILE%,DAT%
NEXT

CLOSE #FILE%

That creates a data file called PLOTDAT which can be very simply read back in by the main program with the following:

Code: Select all

DIM IN%(957)
FILE%=OPENIN"PLOTDAT"

FOR Q%=1 TO 957
INPUT #F%,IN%(Q%)
NEXT

CLOSE #FILE%

And, ta-da, you've now lost all the memory overhead of having those data statements in your main program.

Do note, however, that PAGE has to be set to (at least) &1300, as some workspace is required for file handling - see here.

The Owlet editor includes the Graphics Extension ROM (GXR), which is why PAGE is higher than normal.

[Cybershark]

The Owlet editor includes the Graphics Extension ROM (GXR), which is why PAGE is higher than normal.

Ah, cheers. Had no experience of the GXR, so did not know that. Having just acquired a copy of the ROM and "plugged it into" BeebEm, I note that in Master128 emulation mode, PAGE is only bumped up (from &E00) to &1100, so targeting a Master does give a bit more wiggle room for that precious memory

[TobyLobster]

The Owlet editor includes the Graphics Extension ROM (GXR), which is why PAGE is higher than normal.

Ah, cheers. Had no experience of the GXR, so did not know that. Having just acquired a copy of the ROM and "plugged it into" BeebEm, I note that in Master128 emulation mode, PAGE is only bumped up (from &E00) to &1100, so targeting a Master does give a bit more wiggle room for that precious memory

Even better: All the drawing features of the GXR were added to the standard Master OS ROM, so there's no need for a separate GXR ROM on the Master.

[Cybershark]

Even better: All the drawing features of the GXR were added to the standard Master OS ROM, so there's no need for a separate GXR ROM on the Master.

Wow, I never realised that was already under the hood! Even better, as you say

[dr_d_gee]

Like Shadow, LOM was my favourite game too — in my case on an Amstrad CPC464. It's easy to see why there was never a BBC Micro version — the only 6502-based computer that had a version was the Commodore 64 AFAIK.

I've tried running these on a "modern" RISC OS machine (Pinebook Pro). The first thing to know is that the magic PRINT command doesn't work, or rather, it just prints the characters as shown! I wonder if it actually saves any memory over the equivalent GCOL commands?

When I tried running your program directly under RISC OS (5.28) the colours were wrong — modern systems don't support the old numbered modes correctly. However, I was able to run it using David Ruck's !GraphTask which emulates the numbered modes and displays them in a window — and the results were the same as shown above.

I've not managed to get the program running correctly without !GraphTask. The Pinebook Pro only really supports modes with 32-bit colour; these use the command

Code: Select all

GCOL OF r,g,b ON  r,g,b

where r,g,b are the proportions of red, green and blue (integers 0-255). This almost works but for some reason the items are only half filled with white — usually the lower right triangle. I'm not sure why.