Dungeon Master Forum

GG, how do the POSITIONS of wall bitmaps work?

I've finally got around to creating my new wall sets, and I'm using the numbers from your walls.txt sample file. It works fine if you keep everything the same.

However, I was trying some clever things with overlappings/'bandage' parts and have come to the conclusion that the POSITION values are utterly bonkers. They seem to bear no relationship to the actual positions of the walls on screen. I can't work out where the POSITION value count from: The top left of the dungeon view? Bottom left? Middle? Same but of the whole screen? What does (-1,-1) mean? It's completely illogical!

For example, in v0.34, the front middle wall is 320x222. The walls.txt file specifies its position as (160,110). Now if that coordinate is based on top left of the image being offset from the top left of the dungeon view, then it clearly doesn't work -- in this case, the coordinates should be (64 along,18 down).

If on the other hand the position is based on the centre of the image being placed at the position specified, it also doesn't work.

I've tried to get my head around this, and when I got to a point where I thought I knew what was going on, I looked at some other walls and they seemed to work differently! Clearly you are using different approaches for different elements. The position (0,0) for floor AND ceiling proves this. Would't it be simpler to have one point of origin, one axis and for all elements to work from this point?

Can you please explicitly tell us exactly how to use these coordinate systems for placing walls?

Thanks in advance.

It's been a long time since I delved into this, but if I remember correctly (which could be very wrong lol) the co-ordinates were for the top-left hand corner of the image? When I think about it, when I was creating my custom dungeon gate and such for before you enter... the positioning took me a while to grasp but I think the co-ordinate represented the point in which the top-left corner of the image was.

Of course, this could be complete waffle and of no help at all, in which case ignore it entirely .

Aah, I think that would make sense if the origin is the centre of the dungeon view... still doesn't explain (-1,-1) though, or the roof and ceiling images....

It wouldn't be the old edges of the dungeon view (where the original graphics would have started?) But you can draw then anywhere in the window, so you can put a floor tile at -1, -1 say, which would be one up and one to the left of the original top left corner of the DM floor picture?

-1, -1 is certainly ringing a bell in my head, as I do remember seeing it when I was playing around with similar things... just can't remember what it all meant or if I even knew in the first place!

And now I'm just as curious .

*Awaits GG*

Well, I just took another look at this and stand by my original assertion: it's bonkers!

<I'm out working in the US this week, hence the odd posting style and frequency>

The bitmap position for walls isn't actually the position of the wall bitmap, but the position on the bitmap where other bitmaps should be placed. I.e. where the mirror / keyhole etc hangs relative to the wall.

The -1,-1 value just means that no bitmaps are shown on that wall.

I agree, it's odd and more importantly doesn't allow you to do cunning things with overlap. I'll be changing this for V0.35 to do what you think it should do...

I'll be changing this for V0.35 to do what you think it should do...

why ? now that we understand the mechanics it's very easy to make a tool that gives you the correct position of a wall dec !

Um, that's not the point, and how do we now understand the mechanics? GG has basically just admitted the positions of walls are hardcoded and need to be opened up to the designer. No wonder I couldn't do anything useful!

It's currently a massive inconsistency to have POSITION mean one thing for walls and something else for all other items. That needs to be fixed in my opinion, so I say go ahead GG.

The issue of positioning wall items is something different again, yet I think everything should use the same origin. It doesn't really make a lot of sense otherwise, though I guess the reasoning for making a relationship between wallitems and their wall is purely for getting the scaling right...?

What's a good solution that makes both things usable and intuitive?

so what do you think of POSITION for walls and OFFSET for items ?
- every wall/floor/ceiling bitmap POSITION is defined from the top-left corner of the dungeon view.
- every item OFFSET is relative to the center of the wall/floor/ceiling bitmaps.. and a flying item OFFSET is relative to the center of the dungeon view.

Back in blighty again :)

All fixed up for V0.35

Welcome back!

But you're not getting away with a simple message on this one! How exactly is it changed?

The position is now the position on the screen relative to the top left hand corner where the bitmap will be put.

Does this mean for *everything* or are wallitems still requiring some kind of origin on the wall they are tied to?

yep, i wonder how you can position the alternate bitmaps if not...

The position of wallitems are (and have always been) relative to the center of the walls.

Cool, OK, all I need to know! Thanks!

Ermm... flooritems are different don't they ? I thought they were relative to "FLOOR" bitmap ! I cannot generate anything correct in RTCWM

The position of flooritems are relative to the center of the tile they're on (not relative to the whole floor bitmap).

i.e. if you had a 1x1 bitmap with an offset of 0x0, then it would appear in the centre of each tile regardless of which tile it was.

i see, so i need center tiles exact coordinates to make a correct conversion.

These are the values RTC use (all relative to the TLC of the dungeon view)

224,272
-86,228

224,208
-30,208

224,166
48,166

224,136
102,136

Looking at them again, especially the first lot, they don't seem quite right though - I'll check to see if they're inconsistent or not! If your 3D model comes out with better values, let me know.

thanks, this will help me a lot !
about the 3D scene, you're right : i managed to reproduce -approximately- CSB view. this means i had to change some of the walls coordinates you gave me, and this means also warnings when i test an RTCWM generated wallset in RTC.

Given that RTC neither uses the DM graphics nor the CSB ones for walls (it uses the DM graphics squished into the CSB perspective), then if they're only a few pixels off, then it might be a good plan to use the "proper" 3D wall sizes in RTC.

It would certainly make auto-generation of new graphics alot easier...

George Gilbert wrote: 224,272
-86,228

i think you made a typo : 228 must be 272

George Gilbert wrote: Looking at them again, especially the first lot, they don't seem quite right though - I'll check to see if they're inconsistent or not! If your 3D model comes out with better values, let me know.

yep, but for the last lot in fact (136 => 145) , others seem fine.

I've just used WHACK to create a quick wallset -- works great!

However, I've noticed that there is a signifacnt problem with RTCs new wall sizes/perspective for the furthest wall. See this lightened pic for details:

http://homepage.ntlworld.com/matt_hill/ ... arwall.jpg

You can see that the door frame is too far away from the wall.

I think that this furthest wall needs to be made longer to fill up the space and also to extend further back to the shaded part of the floor.

Hi, me again
I discovered a very weird thing with Y position value for FRONT_SIDE0 flooritems. It's *again* not logical. A better way to explain the problem is an example :
On the front 0 tile, FLOORITEM_PIT_FRONT0 is a 344x24 bitmap, positioned at 0x24. Woot ! that's normal.
On the side 0 tile (means same Y than front 0), FLOORITEM_PIT_SIDE0 is a 68x24 bitmap, positioned at (-86) x (-20) !

I can't see why you did this George !!!
(of course Y are logical in other tiles)

oh i just found my answer.. the 228 typo in your previous post wasn't a typo...

but i still don't know why !

I'm reporting this as a bug: the new perspective simply doesn't work for the furthest side wall (as noted three posts above).

Check the size of the wall -- it simply isn't long enough. You've somehow squished a long wall into a small space. For this wall to have the correct perspective and work with the door frame (which incidentally should really be a bit lower), it should stretch much further.

Amiga CSB is the only one that gets this right -- it's furthest walls are much longer and built differently:



And it also displays wall items on that wall which you sneakily managed to get rid of with the new (incorrect) perspective. Is there anyway you can revisit this as I really do think it's very wrong...?

See this image for where the wall should really end -- you can see that in your perspective, the walls fall much too far short of the end of the floor graphic:

http://homepage.ntlworld.com/matt_hill/ ... rwallc.jpg

Hmm - my understanding from Linflas is that the current wall perspective, and therefore bitmap sizes, are correct because the 3D model maps on to them exactly.

I am however, more than willing to believe that the door frame is wrong! The door frame bitmaps are taken from the ST DM perspective and are now being used with the CSB perspective and so could easily be the wrong size and / or in the wrong place (in fact I've often thought that the furthest images have looked wrong even in the original games).

Linflas, can you let me know exactly where the walls *should* be for the 3D model to work; assuming that they don't need changing (significantly) the fix will be to sort out the door frame...