Most (if not all) isometric graphics are based on a 2:1 Aspect ratio.
That is to say that if you looked closely enough at one straight edge, you would notice that the pixel step in the x direction is 2 and 1 in the Y direction. Perhaps someone else can come up with a better description?

Anyway, this format originates from the Spectrum, Amstrad and C64 computers where each displayed byte is 8 pixels wide.

However on the Oric 6 pixels are displayed for every byte.
This brings forth the intriguing idea of using a 3:1 aspect ratio, where each byte can hold 2 steps right for one step down.
So again looking closely at one edge, you would notice that the pixel step in the x direction is 3 and 1 in the Y direction.

This aspect in practice produces a much less acute camera angle. Instead of the camera almost looking at 45 degrees, it looks at something more like 33 degrees.

The example below shows a 2:1 Aspect and following it is the same image as 3:1 aspect...

Apart from this aspect looking kinder on the eyes, it may have some programming benefits (And ultimately speed and memory benefits).

1) Embedded masking(Memory Benefit)
Since each displayed byte holds two steps, the upper 2 bits of the byte (Which usually hold attribute flags) may (outside HIRES) hold the mask bitmap for the lower 6 displayed bits.
Any routine would simply extract these two bits and use them to index a Mask table whilst replacing these bits with 01.
The example below shows normal bitmap masking...

The example below shows the same image with embedded masking.

yeah yeah ok, so the bitmap has been modified to look more natural with the cruder masking, but even so still quite acceptable i think?

The final example shows the same as previous but in the 3 level room.

Whilst the example has used a staircase, the better objects to use embedded masking are floors, Walls, windows and doors since these generally only require masking to prevent corruption of neighbouring objects.

2) Sprite Movement (Speed benefit)
Any sprite movement on the isometric view will move at the angle iof the aspect ratio. To this end a 3:1 layout may move the sprite in steps of 3 pixels at a time. The benefit being that the code need only shift up to once to position the sprite on the screen.

The only disadvantage of 3:1 aspect is that most isometric graphics cannot be ripped from 8 bit games and must be created from scratch.

About the different aspect ratios, I love both your 2:1 and 3:1 pictures.
It's true that the 3:1 gives a better feeling of 3D, I think it might be due to the fact that the whole 3:1 image is above the center of the screen, and thus is quite close to what would be displayed by a true 3D perspective. And this would explain why we have a different feeling with the 2:1 room, as the part of the image that is below the center of the screen seems to not comply with "standard perspective"...

Anyway, in both cases, we have a problem with the 5:4 pixel ratio of the real Oric because we are more and more using emulators that render the screen with 1:1 pixel ratio. When using mode Q with Euphoric (256x256), you can get the Oric flat aspect of pixels, but most of the time, people use mode X (320x240) on 4:3 screen and thus get a 1:1 pixel aspect.
In order to render a realistic 5:4 aspect on a 1:1 pixel aspect screen, I could enlarge each pixel in a 5x4 rectangle, but there's no good standard resolution for this (a 1200x896 Oric screen would of course fit well in a 1280x1024 resolution, but unfortunately 1280x1024 is not a 4:3 ratio, so on such a screen the image would look a bit too flat (4:3 big pixel aspect).

A funny result I have on my notebook, is that it stretches the image on its 16/10 screen (i.e an horizontal stretch of 4.5 and a vertical stretch of 3.75), finally giving a pixel ratio of 6/5, quite close to the oric 5:4.

Twilighte wrote:
btw, did another one this afternoon, i'd love to do an isometric game with Chema...

And that would be indeed cool, cause I could learn a lot from your experience. However, I think it is important to first finish WHITE+NOSIE, which is quite far away at the moment.

I don't have all the spare time I would like to dedicate to this project, in which I have worked for a very (and I mean *very*) long time, so if I you want to help me, please notice you would have to be very very patient

Let me add the possibility for a character to go up/down stairs (in a very simple way for now) and (maybe) some kind of primitive gravity system, solve some problems with doors that may open when interacting with them (using some object, for example) and correct some of the small bugs that are still hanging around.

There are many, many little things that have to be solved, and it is difficult if you want to make something general. I already introduced some limitations without noticing that I should address, but I am afraid not all of them could be addresable for the first working version (like a limitation in the levels and height you can acheive).

Then I would move onto some optimizations (I want to test DBug's idea of using tables instead of rotating graphics).

My first idea, as I told Fabrice, was to develop a small demo based on Space 1999, with a small plot, a small number of rooms, some interactions with objects and characters... Far from a platform style, and more as a video-adventure. This was not intended to make up a game, but to test all the possiblities and correct bugs and maybe some design mistakes.

And, finally, I need to remember to put limits somewhere, or I will find myself next year still adding features and modifiying things whithout having anything finished.

Perhaps you would like me to do some graphics for the Space99 thing?
I can provide all that you require so long as i know what size each object/wall should be, the number of objects that may exist, the size of graphic partition in the game, the type of graphics required, etc.

Or perhaps the Space99 thing was an example only and that patience is the primary thing i should concentrate on?

What you have achieved thus far is incredible. I wish i'd the stamina to keep at it for so long.
I too will try to get my engine working, but based on the 3:1 aspect and defintely not as structured as your sounds to be.

Twilighte wrote:Perhaps you would like me to do some graphics for the Space99 thing?
I can provide all that you require so long as i know what size each object/wall should be, the number of objects that may exist, the size of graphic partition in the game, the type of graphics required, etc.

That would be indeed wonderful, as it takes me quite long to do any kind of graphic for testing. Would it be a good idea to start with characters? We can discuss this in private and I will provide with all the necessary information.

For walls, etc. I still have to decide their height, as they should fit with doors, which is another problem I am trying to deal with. I have it solved, but then you came up with the multi-level thing and I might need to throw it all away

We should chosse another channel (private email, or even another thread could work?) for discussing all this, because you can be of great help with all these matters, but I don't want to disturb other people with such long and thechnical discussion.

Twilighte wrote:
Or perhaps the Space99 thing was an example only and that patience is the primary thing i should concentrate on?

ROTFL. Patience is indeed needed... My free time is so limited I can only from time to time dedicate an hour or so to Oric programming. And I am not an experienced programmer as you are!, so it takes me long to write code, debug, optimize (to a certain extent), etc.

Twilighte wrote:
What you have achieved thus far is incredible. I wish i'd the stamina to keep at it for so long.
I too will try to get my engine working, but based on the 3:1 aspect and defintely not as structured as your sounds to be.

And I have proposed myself to finish this, even if it takes me another full year

If you want to make your engine working it would be fantastic! If I can provide anything (ideas, what went wrong and what could be done better, technical details) just ask me! I will be glad to help!

Dbug wrote:I could probably add privates chanels, but do we really need that ?

The forum is not very "high traffic", and I guess it can be of interest for everybody to follow the development of the whole thing ?

I let people decide, I just wonder if it's possible to not display private chanels at all for people that don't have access (to avoid the "you are not welcome here" feeling).

No, of course I don't mind it to be public. I only wondered if it could be a bit out of topic for any of the forums here, but I will be very glad to continue the discussion here and hear everybody's oppinions

I have now opened a new forum Subject "Space99 - Development".
I would suggest Chema replies in their.
I would not suggest carrying on in this forum subject since i suspect very much that he will expect me to be using 2:1 isometric gfx.

However, as a taster of 3:1 projection, i have "generated" my first isometric screen here...

I am now heavily into trying to get my own isometric engine working.
I am using Virtual PC in conjunction with Euphoric but only Version L currently works under VPC. however version L of euphoric gives a false impression because other people have shown me that my program run on a later version is corrupt in some places.
Anyway, Symoon let me have version M which i will try soon.

My Isometric engine is using 3:1 aspect ratio and dumping walls, floor and objects against the back walls to a background buffer. This will speed up the displaying of sprites because the background will be used as the base image when performing the objects behind/infront process.
The disadvantage is memory since the background buffer is a whopping 8K however i can put this into Overlay RAM (C000) if need be.

I am also (As mentioned elsewhere) using the same method as Jon Ritman to handle objects behind/infront, which i believe is the fastest way and as also mentioned elsewhere only going to use the overlapping parts of objects instead of the quick and dirty full object method.
This is made possible because all graphics are held in their displayed format in memory. Another special area of memory will be reserved to hold shifted Objects and Mirrored objects.
These are drawn whenever a new room is displayed but will be placed into this special area of memory.
Since i am using 3:1 aspect i can say only one shift position is required (unlike 3 for 2:1 Aspect).
The big advantage of having special memory is that i have an instant reference to an object in any form (Mirrored, normal or shifted) so should prove faster still.

The method of plotting objects behind/infront is by using a link list where the order of objects is correct for each screen at the start (Each room is held as a list of objects, starting with Walls then Floors then other objects).
This integrity is kept throughout using techniques mentioned in Jon Ritmans article.

The technique is very simple. The attributes Cyan ink and Yellow Ink are repeated down column zero of the screen.

Then all subsequent graphics use a combination of normal and inverse video bytes.

This provides a total of six colours.

Cyan, Yellow and black.
Then the inverse of these which is Red, Blue and White.

Both blue and Red are limited to byte wide painting.
Blue was dark enough to get away with it being used as the water. Closer inspection reveals it only ever occupies even lines.

Red is brighter and therefore has to be used more discretely otherwise it looks a bit crap.
However i did use it in Otype for the Nissan huts which are very bright but very square. You can sometimes give the illusion of curves which don't actually exist by using shadow or other colours. For example the oil barrels in OType.

Anyway back to the screen above.
The alternate colour mix is using Green ink instead of Cyan.
This then provides the strong green more appropriate to exterior scenes but you must then use Magenta instead of Red.

I began by drawing the back wall with a combination of green and white. Then i drew the archway (i like arches) and patio.
I really wanted to do a footbridge in this picture but just getting the angle and curve right took a good few hours
Its still not perfect and the brick-work on the walls of the bridge lack any true width. But for concept art it'll do.

The rest was pretty straightforward

So unfortunately it wasn't computer generated, just given the illusion that it was.

The only unfortunate consequence of this technique are that the colours do look a bit like the old CGA graphics of old.
The colourful Isometric graphics may also remind some people of those Last Ninja games on the C64, Amstrad and BBC micro.