Messages

76

Recycle Bin / Re: Tiles, Sprites and Lofts/Loftemps

« on: April 05, 2022, 11:16:16 pm »

here's the conversion codes for OxC

https://github.com/OpenXcom/OpenXcom/blob/94640aab1279ae268e0420a7b5c99cc44eb09473/src/Battlescape/Camera.cpp#L431

and similar in MapView2

https://github.com/kevL/OpenXCOM.Tools/blob/f5eccf594eb08adebcbec7db5759d20a486aa81e/MapView/Forms/MainView/MainViewPanel/MainViewOverlay.cs#L2212


ps. that level of math spooks me out ...

pps. projectile trajectory appears to be converted and traced at the start of Map::drawTerrain()

https://github.com/OpenXcom/OpenXcom/blob/94640aab1279ae268e0420a7b5c99cc44eb09473/src/Battlescape/Map.cpp#L482

( note: I seem to recall that projectiles also cast a shadow )

/anyway, there it is :|

77

Recycle Bin / Re: Tiles, Sprites and Lofts/Loftemps

« on: April 05, 2022, 11:18:22 am »

here's a northwall sprite on its 32x40 grid

and how it draws in relation to the Map tiles (cuboids)

and its LoFTs

78

Recycle Bin / Re: Do walls (west, north) have loftemp ?

« on: April 05, 2022, 10:14:05 am »

MCDEdit is a hardcore, standalone MCD/PCK-sprite editing app

https://www.ufopaedia.org/index.php/MCDEdit

McdView is part of the MapView2 editing suite (MAP,RMP,MCD,PCK,TAB files).

https://github.com/kevL/OpenXCOM.Tools
(see Releases on the right of page)

both for M$ windows.

79

Recycle Bin / Re: Tiles, Sprites and Lofts/Loftemps

« on: April 05, 2022, 10:02:44 am »

The link you posted does not describe the formula for when moving into Z direction

... elevation simply shifts the sprites up (or down, again depending on the coordinate system used).

I always need to know how openXcom defines things... voxel x,y,z goes into a certain direction.

sorry I haven't looked at OxC code for a long time and wouldn't be comfortable stating those specifics. I imagine an increase in x shifts to the right, an increase in y shifts downward, and a (literal) increase in z also shifts downward ... for example, each tilepart has an MCD entry for "elevation" or similar -- it's usually a negative value that shifts a part's corresponding sprite upward on the screen. And elevation by Map level(s) should shift a sprite by multiples of <blargh> pixels per level (the exact value, before scaling for screen resolution, should be in or near Battlescape/Map::drawTerrain()

I assume tile and voxel coordinates go into the same direction.

i think that's a safe assumption ... /test

I think bottom right corner might be 50, 50... so y might be right side, x left side... hmm

uh, 0,0 (2d screenspace) is likely to be the top left corner. And 0,0,0 (3d tilespace) is likely to be close to there ...

But which is X and Y in the diamond ?

the x-axis goes upperleft to lowerright (west to east), the y-axis goes upperright to lowerleft (north to south) ... thats my best guess atm

80

Recycle Bin / Re: Tiles, Sprites and Lofts/Loftemps

« on: April 05, 2022, 09:25:27 am »

this is the best page i've found describing isometric math (conversion between cartesian and isometric views)

https://clintbellanger.net/articles/isometric_math/

and here's a pic showing how sprites overlay other sprites. The black pixels are the borders of 32x40 sprites (but think of black as transparent).


ps. the coordinate system is arbitrary, decided by the programmer. Some use the top of the diamond as 0,0 while others use the top left corner of the draw surface as 0,0 ... elevation simply shifts the sprites up (or down, again depending on the coordinate system used).

the tricky part, as anyone who's worked on it can attest, is the sequence to draw things ...

81

Recycle Bin / Re: Do walls (west, north) have loftemp ?

« on: April 05, 2022, 09:01:44 am »

every tilepart has voxel data (12 double-layered loftemps, defined in an MCD file) unless, uh it doesn't (blank loftemps)

I don't believe there is any loft-data implicit in the engine ...

loft-data for walls, etc might not be what you'd expect; you should use MCDEdit or McdView to see the lofts used for a given tilepart

82

Recycle Bin / Re: What is size of tile ?

« on: April 01, 2022, 08:09:04 am »

my bad, carry on overthinking it

/shrug

83

Tools / Re: MAPVIEW upgrade

« on: March 26, 2022, 08:59:15 pm »

McdView 4.1.1.0
- bugfix: clear selected id when a terrain loads, before its parts are
  instantiated not after. Else the tilepanel could try to scroll to a part past
  a terrain's total parts id.

https://github.com/kevL/OpenXCOM.Tools/releases/tag/220326

84

Help / Re: TFTD fire and the ocean floor. (Fire stops burning after 1 turn)

« on: March 26, 2022, 05:30:31 am »

i can't find an MCD file called "seabed" ... I see SAND.MCD

(and i don't believe there should be a colon after "  - type: BARN"

eg.

Code: [Select]

MCDPatches:
  - type: SAND
    data:
    - MCDIndex: 13    # record 13 in SAND.MCD
      fuel: 255       # will burn for 255 turns (id 57)
      flammability: 0 # highly likely to ignite (id 45)
#etc

or backup your MCD file(s) and use either MCDEdit or McdView to edit the values directly.

85

Recycle Bin / Re: What is size of tile ?

« on: March 25, 2022, 05:48:03 pm »

I can confirm that the width and height are 16 by 16... and the depth are 24 for tile dimension. At least that is what I currently believe.

it's a safe bet

The depth goes into the sky. The ground level is at 0 in tile space

in MapView (not sure about the XCOM engines) 0 is the highest level, counts down to ground level.

and then can go up to 4 or 5...  terror map is 50x50 width and height.

i don't think there's a strict limit to any of the dimensions ... (other than Max.int) ... there are Maps that are 10 tiles high etc.

I now believe the correct max voxel x,y,z calculation is:

sry I haven't twiddled with the trajectory routines for years, but i dig what yer doin'

I'd think (guess) that endvoxel (0-based) could be

_save->getMapSizeX() *16 - 1

( *24 vertical ofc )

since parameters labeled "size" are usually a 1-based count. Then the 'id' of the last voxel subtracts 1 to go 0-based.


ps. which is the same as

int vMapVoxelBoundaryMaxX = (((_save->getMapSizeX()-1)*16)+16)-1;

/don't overthink it

86

Tools / Re: MAPVIEW upgrade

« on: March 16, 2022, 08:52:07 am »

MapView 4.3.0.0
- x2 scale button for RouteView

https://github.com/kevL/OpenXCOM.Tools/releases/tag/220315

87

Recycle Bin / Re: What is size of tile ?

« on: March 14, 2022, 12:47:03 am »

yes

and a soldier/unit is just several circular LoFTs stacked into a cylinder (fits in one tile, although when on stairs or a haybale etc its top can stick up into the tile above). Quad units are more complicated, but are basically just large cylinders over 4 tiles.

(see desc of LoFTs in pic)

[edit] iirc,
x is measured on the east-west axis
y is on the north-south axis
and z is the vertical axis

eg: width, depth, height /shrug ...

88

Tools / Re: MAPVIEW upgrade

« on: January 23, 2022, 01:55:34 am »

yep that's the latest. Did you fix it simply by creating .RMP file(s) ?

am going to try to reproduce it here, i don't like the app thowing that error ...

[edit]
dang can't repro... Map loads fine here without any RMP file.

89

Tools / Re: MAPVIEW upgrade

« on: January 21, 2022, 09:26:28 am »

hey Luke, good to hear from ya,

Are you using the latest build? (i addressed very similar errors over the past few months)

a missing RMP file shouldn't matter; iirc. It's highly unlikely to be related to the error ... MainView doesn't care about routes.

if the newest release (i changed the download to github itself, btw) is borking, will need a link to your mapfile etc ...



from the stacktrace i notice this is a pseudo-known .net issue ... MainViewOverlay.DrawTile() should be calling a function MainViewOverlay.DrawSprite() before the Graphics.DrawImage() call ...

while i've seen it before, no one seems to have a good explanation of it,


anyway, try the latest and/or perhaps get in touch by PM so we can poke this.

90

Tools / Re: MAPVIEW upgrade

« on: January 18, 2022, 09:33:39 am »

2022 jan 18

https://github.com/kevL/OpenXCOM.Tools/releases/tag/220118

- mainly address the issue of .net's ToolStrip control ignoring a mouseclick when its parent window is inactive.
- TopView had the same issue except for different reasons.

The fix has not been extensively tested (nor tested when built against Mono at all) and although i don't expect probs, lemme know if anything glitches out,