[Fixed for V0.50] Bitmap offsets inconsistent

[Gambit37]

I've put a new fullscreen (640x480) bitmap as my backgrounds on all parts of the interface.

I adjust the position to 0,-40 and this places them all correctly and fully visible if your config is set to 640x480.

However, the utilities section (Credits, Make New, etc.) now has shifted all it's contents up by 40 pixels to compensate for the negative offset.

I think this is wrong and that it should work the same as the others, in that the negative offset should not be taken into account.

[Gambit37]

Let me explain this in more detail for those who might find my bug report confusing:

RTC has a usable "canvas" of 640x400 pixels which looks like this:



But RTC never runs in that resolution unless you tell it to, it actually runs in the very common, standard PC resolution of 640x480. So RTC compensates by placing it's canvas 40 pixels down the screen at 0,40, a bit like wide-screen:



This means that the origin for RTC coordinates is at 0,40 on a 640x480 display, but internally RTC treats this as 0,0.

It's possible to put a big bitmap in the background that extends BEYOND the 640x400 RTC canvas and to use the extra 80 pixels of wasted space in a 640x480 display.



You do this by setting the origin point of any 640x480 bitmap to start at 0,-40. So we're saying to RTC "Place this image 40 pixels further up the screen from where your normal 0,0 point is". This means our images appear at the TRUE 0,0 point on a 640x480 display.

If you use this method to place a larger 640x480 image on screens like the Main Menu or Plot Screens, you usually also have the option to place other images over the top -- buttons, etc.

Images overlayed in this way take their x,y coordinates from RTCs internal canvas, NOT the background image. So when you position overlayed buttons, if you put one at 0,0 it would actually appear at 0,40 on a 640x480 display. You have to remember to add 40 to all your Y axis values when doing this kind of overlay work.

But the Utility screen is different. You can place your 640x480 background image where you like and all the other overlaid items use the top left corner of this image as their 0,0 origin point.

This is completely inconsistent with what the other screens do, but in fact is much more logical.




(Sorry for the long explanation, I just wanted to get this all down for anyone who might not understand what's going on.)

So, questions:

1) Why is RTC doing this in different ways?

2) Can you make it consistent?

3) Better still, can't you just overhaul all of this so everything starts at true 0,0 on a 640x480 display?


As an aside, I'm kinda confused why you chose the default resolution of RTC to be 640x400.

I can see that it's double the original NTSC Atari ST resolution of 320x200, but weren't you an Amiga baby living in England?

PAL Amigas ran at 320x256... The closest PC equivalent would be 320x240 so would it not have made more sense to simply double up to 640x480 right from the start, surely? Why did you choose the NTSC resolution?

Sorry to sound critical -- I'm just rather bemused by these design decisions which don't really seem to make a lot of sense and make editing RTC much harder than it should be

[linflas]

I can see that it's double the original NTSC Amiga resolution of 320x200, but weren't you an Amiga baby living in England? PAL Amigas ran at 320x256... The closest PC equivalent would be 320x240 so would it not have made more sense to simply double up to 640x480 right from the start, surely? Why did you choose the NTSC resolution?

DM was originally designed for Atari ST : 320x200 (no overscan!).
I agree with the idea of using the PC resolutions and be able to interact with the above and below areas for custom stuff but i would keep the negative values you mentioned. I won't use them for FoD because i prefer a wide-ish interface. Btw, most of screens sold nowadays are wide

[Gambit37]

DM was originally designed for Atari ST : 320x200 (no overscan!).

Yes, but as GG was an Amiga kid, It seems odd to have chosen to base RTC on the original ST version...

[George Gilbert]

DM was originally designed for Atari ST : 320x200 (no overscan!).

Yes, but as GG was an Amiga kid, It seems odd to have chosen to base RTC on the original ST version...

Heresy!

[Gambit37]

I thought you were!

Any insight to be had here about the thread subject?

[George Gilbert]

Any insight to be had here about the thread subject?

As Linflas has already pointed out, the reason for the default being 640x400 is because that's (double) the size used by the original game.

As for the offsets themselves, they are all the offsets relative to the thing they appear ontop of. For example:

- The offset of a background is the offset relative to the 640x400 screen.

- The offset of a utility button is the offset relative to the utility background.

The reason for doing it that way is because it means less change if you change the background. For example, if you move the position of the background, then because all the buttons are defined relative to it, you don't have to change all of them as well.

[Gambit37]

But that's inconsistent. Why?

[George Gilbert]

But that's inconsistent. Why?

"because if you move the position of the background, then because all the buttons are defined relative to it, you don't have to change all of them as well."

!

[Gambit37]

I mean, why does the utility use offsets relative to its background when nothing else does? This is just a confounding design choice.

If I move the background for the GAME INTERFACE or an INFO SCREEN, the behaviour of things appearing above it does not match what happens in the utility screen. It just doesn't make any sense to treat these differently, surely?

[George Gilbert]

I mean, why does the utility use offsets relative to its background when nothing else does?

That's not true.

For example, the position of the sleep /save / sound / quit etc icons in the inventory screen are all defined relative to the inventory screen - not relative to the whole screen.

As I said before, the offsets of a bitmap is relative to the thing that the bitmap appears on (and if there are any that aren't, then they're the ones that are bugged).

[Gambit37]

As for the offsets themselves, they are all the offsets relative to the thing they appear ontop of. For example:

- The offset of a background is the offset relative to the 640x400 screen.

Info screens or Title screen OVERLAY images are not relative to their background, they are relative to the canvas. I have to add 40 to all these overlay buttons to get them in the right place, if I use a 640x480 background that's positioned at 0,-40.

I mean, why does the utility use offsets relative to its background when nothing else does?

That's not true.

Sorry, by "nothing else" I meant "no other large screen background images".

[George Gilbert]

As for the offsets themselves, they are all the offsets relative to the thing they appear ontop of. For example:

- The offset of a background is the offset relative to the 640x400 screen.

Info screens or Title screen OVERLAY images are not relative to their background, they are relative to the canvas. I have to add 40 to all these overlay buttons to get them in the right place, if I use a 640x480 background that's positioned at 0,-40.

Info screens have no background (they're displayed straight onto the canvas), therefore nothing to be relative to other than the canvas. The info screen buttons should be relative to the background - checking though they're not - this is a bug and I'll fix it.

Entrance overlays clearly have a background (i.e. the entrance background) and should be offset relative to it - checking them, they're not as well - again, I'll fix this.

[Gambit37]

Glad we got there in the end!

[George Gilbert]

OK...info screen buttons and entrance graphics now fixed!