By Jonathan Bristow.

This will be the Fourth Section of a new game called Wurlde. Designed and developed solely by Twilight (Me) at present!!??. The other sections have been settled on, but this section poses a few technical problems. This will no doubt be my most ambitious project (And Section) to date and I have reckoned on a release date of December 1999!!!.

In the eighties, when a plethora of games were developed for the Oric, their began to appear certain patterns in the game styles used. Some games were viewed side on, with scrolling as in Doggy and Zebbie or Flip screen as in Willy, Gravitor and DPTLQ. Some games went for the overhead view, since it offered a greater area of which to view the arena and gave a better representation of an area or world. Such classic games as Gubbie and Fomula1. Where as many of these games attempted to create a virtual environment, there was still a push to create a more realistic world. This brought about the 3D style games such as 3D Maze.

Unfortunately, these early machines could not achieve a realistic pace with these games and so, a new view was born, called Isometric or Forced 3D and appeared in only one game for the Oric, and that was Hexpert. Although on the Oric, the crudeness of the game warranted it little comparison to such classic Isometric C-64 games as Fair light, Knight lore, Escape from the planet of the Robot monsters (I kid you not) and Head over Heals.

This View enabled games to play almost as fast as Platform games but with the 3D realism more associated with 3D Vector Graphics. The view retained the detail of bitmap graphics whilst some included colour (C-64). The view is as if from a higher fixed point, looking down into the arena from an angle. Since the angle was not acute enough to make the image appear non-perspective whilst distant objects were close enough not to warrant resizing, the same graphic could be used anywhere on the Displayed Grid.

I mention and Detail this, since it appears that the Oric never received this style of game view (Apart from Hexpert), where it really ought to have done. The differences between the C-64 for this style of graphic demand and that of the Oric, differs little. Save maybe the Sprites. The display is fairly easy to generate although probably slow in forming.

The only big questionable area is in the generation of the sprites, since these must mix with the background and objects, masking behind and in front accordingly. The Mapping is another dilemma but has been settled on as will become clear later on in this document.

Deciphering a Sprite mask to show in front or behind objects within the area is possible since it has been achieved on the C-64, Spectrum and CPC as in games like Knight lore, Fair light and Head over heels, to name but a few and at a reasonable speed.

Obviously, since the Oric was never graced with easily controllable colours, the game would have to be monochrome, with maybe the occasional sparse colour in out of reach places.... maybe!!.

I also go back to the C-64 in many instances throughout this document since this is also a machine that uses a 1Mhtz 6502 CPU, the same as the Oric and that the general techniques used in Plotting and manipulating the view must be easily transferable without much difference in speed.

I come back to the sprites, since these would be the real objects in such a game that would be moving. The C-64 was graced with sprites, and although only 8 were available, this did allow up to 4 on a monochrome display. Why 4?, Since monochrome Sprites on a monochrome background are best displayed with a black or white outline around the sprite to isolate it from the background. This gives superior definition to a sprite.

On the Oric, we are not so fortunate to have sprites, but even so, Sprites can be developed software wise, and in so doing, one can write special routines to mask out the outline in the procedure to plot the sprite.

I plan to develop such a game style. However, I do need help, help in devising a method in which to mask the sprites so the show in front or behind objects, when they pass them, fast and efficiently.

Shown below, is an example of the display ( 6*5 Graphic Blocks) , although i still have to decide to what limits the display should show. Whether to always stick to one level?.

Since the speed of generating the image would increase but the true 3D aspect would be somewhat held back.

 Or, to fill the screen to the limits shown in the screen shot, to give two or three levels?.

The image would take that little bit longer to generate, and deciphering would be required to decide whether or not to plot blocks ( Do you plot the Room or passage way below the grave stone?, of course not, but the processor doesn't know unless it's told). The Advantage of such a display would be to show more of the true 3D aspect

.

There is also the matter of the aforementioned Mapping method. Simply using the standard mapping of every square on the metaphorical grid is too wasteful. In large halls, where the height of the room may extend to more than 3 physical levels, one would have the majority of the upper levels void of anything in them. Let me give you an example.

Take a grid of 10 by 10 locations with 3 levels to represent a Hallway. Each location (As shown below) is given a letter to define the block type.

Notice the number of wasted 'N' locations. This method has other drawbacks as well. When Passageways are required, the rest of the screen map is wasted. Also, The Computer must look at every location on the grid to plot or not. This wastes a lot of time.

This of course all leads to another method. Mapping only the blocks needed using a co-ordinate system. Each Map location does use up a couple of extra bytes for these co-ordinates but the advantages out way the previous method. Here is the previous example but using the co-ordinate system.

The mapping will therefore be accomplished using these 3 dimensional spatial co-ordinates. This system allows the full 3D representation of the arena without using any blank locations. Eg. All locations plotted will have a shape assigned to them.

Each map location will occupy 4 Bytes, Indexed by A,B,C and D with this definition...

A0-7 X - Position (0-255)
B0-7 Y - Position (0-255)
C0-3 V - Position (0-15)
C4-6 0 Flat North Facing (Flats such as Side walls
1 Flat East Facing
2 Flat South Facing
3 Flat West Facing
4 Floor (Such as a carpet or Rug, Brick or Grass)
5 Shape (Such as a Marble Column in the centre of a hall, or a stair case that extends into the centre of the room)
6 -
7 -
C7 -
D0-5 Shape/Floor/Flat Number (0-63)
D6-7 -

In addition, furniture, Items to collect and other movable and non-movable objects are all called Objects and will use a separate area and slightly different mapping to enable each to be positioned and repositioned anywhere (That means anywhere) in the arena.

To keep the position in sync (As it were) with the mapping of the background, 12 Bits will be assigned to the x and y axis. Whilst 9 bits will specify the V Axis...

A0-3 X - Position Lo (Position within each Shape (0-15))
A4-7 Y - Position Lo (Position within each Shape (0-15))
B0-7 X - Position Map
C0-7 Y - Position Map
D0-4 V - Position Lo (Position within each Shape (0-31))
D5-7 Object Number lo *
E0-3 V - Position Map
E4-7 Object Number Hi (*0-127)

Therefore, each Object consumes 5 Bytes and the position where placed or dropped will always be relative to the top left part of the object.

Any knowledge you may have or contacts you may know of who could help me with the Sprite Masking problems would be most useful to me. In addition, if you have any constructive criticism to make or ideas to put forward in any area of the game, or you wish to take on some sections of the game (Of which you will be credited for in the game), then please don't hesitate to get in touch. My name is Jonathan Bristow, my alias is Twilight and I can be contacted by E-Mail at arc@twilighte.demon.co.uk or by Snail Mail to "30 Fensome Drive, Houghton Regis, Beds, LU5 5SH, Great Britain".