Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - kevL

Pages: [1] 2 3 ... 28
1
Help / Re: Problem with converting spritesheet to PCK
« on: May 08, 2022, 11:50:15 pm »
regardless, here's a better list of spite editors

https://openxcom.org/forum/index.php/topic,2676.0.html

2
Help / Re: Problem with converting spritesheet to PCK
« on: May 08, 2022, 10:46:46 pm »
For some reason, when i'm opening spritesheet (attachement 1) with PckView, some random pixels turning into blue (attachment 2).
I used InfranView convert all colours to battlescape palette, which comes with openxcom.
What may cause this problem?

i think you need a better sprite editor
https://openxcom.org/forum/index.php/topic,7781.0.html

It looks like irfanview 'optimized' the palette (hint: don't use an editor that figures it knows what it's doing with the palette ... it doesn't, this is XCOM, we use our own palettes here. )

2nd, the spritesheet didn't preserve transparency for palette id #0 -- and we like our 0 ids to be transparent :)

4
Tools / Re: MAPVIEW upgrade
« on: May 02, 2022, 12:25:15 am »
woohoo! no auto-rewrite routine (yet?) but better error messages

(not committed to repo atm)

yeh i was getting fed up with the other cr*p i was working on ...

5
Tools / Re: MAPVIEW upgrade
« on: April 29, 2022, 08:45:41 pm »
the highlighted data in first screenshot is the 7th sprite in the PCK file, the 8th sprite begins at offset 0x0c0b ... but the second screen shot shows the offset of the 8th sprite in the TAB file as 0x0c06

0c06 != 0c0b

All of the remaining offsets are borked also ...

I have a small routine that rewrites TAB files, but it's not robust enough for general use. At some point i might put in an option to rewrite the TAB file if my time and health permit,

6
Tools / Re: MAPVIEW upgrade
« on: April 29, 2022, 05:03:21 pm »
Tks, will have a look

[edit]
corrupt TAB file, try this one


I tried opening one of the PCK files using PckView and got an error: "File data overflow a sprite's length."

This is a valid PCK file and is used in one of the mods without a problem. But PckView and consequently MapView2 give me an error if I try opening a map/terrain that uses such a PCK file.

perhaps because OxC/e doesn't use the TAB files (idk). They're redundant but MapView2 / PckView will continue to use TAB files.

7
Tools / Re: MAPVIEW upgrade
« on: April 29, 2022, 03:42:45 pm »
does it have a .TAB file? If so pls link it also

PckView doesn't open .PCK files unless they have a .TAB file ...

8
here for example is the code that changes to a different MCD record if a part gets destroyed by an explosion

bool TileEngine::detonate(Tile* tile)
https://github.com/OpenXcom/OpenXcom/blob/94640aab1279ae268e0420a7b5c99cc44eb09473/src/Battlescape/TileEngine.cpp#L1560

bool Tile::destroy(TilePart part, SpecialTileType type)
https://github.com/OpenXcom/OpenXcom/blob/94640aab1279ae268e0420a7b5c99cc44eb09473/src/Savegame/Tile.cpp#L466

9
there is only one loftset per MCD record.

for a part to change its loftset, the part in the tileslot must be changed.

1. it's a door
2. it got destroyed
3. ???

The 8 sprites for each part cycle constantly on the battlefield. But this doesn't change the loftset of the tilepart.

note: Sliding/UFO doors are tricky ... (they don't cycle until activated, then do only 4 animations before changing to their alternate part, iirc)

10
Programming / 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 :|

11
Programming / 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

12
Programming / 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.

13
Programming / 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).

Quote
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()

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

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

Quote
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 ...

Quote
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

14
Programming / 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 ...

15
Programming / 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

Pages: [1] 2 3 ... 28