Some experiments

[Conti-k]

I figured out I'll start topic with my weird (?) experiments. It will be related to artwork only, because I know nothing about programming.

Anyway,

I really don't like how roof tiles don't "fit" into the walls. It's not possible to break 32x40 limit thus there's no way to move tile one pixel down. But it's possible to do it with walls - there's a "space" for one pixel up. Roof is nicely centered now (see attachment). Walls at Level 1 <==> 2 are seamless as well (original ones aren't). The only problem is that you can see uncovered "back" walls (which are black).

This is only working with OpenXcom (oh well, with MapView too). And because of that, and other improvements/fixes OpenXcom is my engine of choice for UFO (but I think I already mentioned about it).

Anyway, the best option would be to cover all, top parts of walls with tiles. The workaround is to create additional two pixels tiles (when using original walls) to "cover" two pixels of "front" walls. Another workaround is to create additional, small wall pieces that are placed above roof tiles (see one of TFTD's Port Terror buildings). It's looking really great, but doing all buildings like that isn't good idea, I think. Both workarounds would cost additional pieces for each tile (or wall), and more clicking when doing the maps. So what about this?



Selection is presenting original 32x40. I'm sure that at some point OpenXcom will get support of BMPs/PNGs/whatever. Engine is written from scratch so why not to break 32x40 limit for sprites (did I say that this kind of limits are ugly)? My thought is: sprite with 34x42 size (32x40 + one pixel for each direction). Engine would simply center tile (without cutting it) around selection I've made. This is only visual effect, LoF templates wouldn't be affected by this. Sounds great, or not?

Also, I'm reworking crafts look in base, since it's no near to what you can actually see in UFOpaedia, or on maps. So, say hello to new Interceptor, and Skyranger (they need some tweaks here, or there, but effect is really nice already):



(I must figure out how to replace images in BASEBITS.PCK - PCKView isn't able to load a correct palette for that file)

I've made shadow solid. Original one with "fake" anti-aliasing is looking nice, but only when craft is placed in hangar. On equip craft screen it's looking somewhat strange...

Also, also, I'm reworking Skyranger:



Original one looks kinda out of correct "perspective" with incorrect hull's shape, "flat" wings, and weird shadows... I do hope adding new frames won't be necessary... but I think not...

[Conti-k]

All new cross section(s) of good 'n old Skyranger:





There will be a problem with "front" walls due to 32x40 limit... I have two pixels more over there... Not to mention about that part that goes under the tiles... I hope I'll figure out something...

[Volutar]

I doubt you will find any solution. Because of "pixels beyond" they made additional tiles, which works as object, but actually are walls. North-East walls for example. And because of that you are unable to walk along these tiles.

[Conti-k]

I've been testing theory of "Big Wall" flag being ignored (?) by rendering engine... I've mentioned about this already.

- I've replaced all "back" UFO "Content" walls with normal North/West walls. Result:



of course, it's not possible to re-position original frames due to 32x40 limit:



(stuff inside of selection would be lost)



- But that horizontal, "back", "Content" wall piece left... so I figured out to put it as North wall. Result:



the same thing happens in both engines, except that you must enter through hole to actually see inside of UFO in OpenXcom.



- If engine cuts it in half I figured out to put both pieces into North, and West "slot". Result:



this is how things should look from the beginning...



- To get things done correctly this frame should be cut into two parts, with two unique destroyed versions* for North, and West, and that "half" tile should be set to block movement**:



damaged wall should be done in the way that prevents seeing "hole" in the ground after missing 2nd half of "half" tile after destroying the wall - this is only needed when "half" tile is on the ground, and is placed on tile "slot", like in this case.

Alternatively "half" tile could be attached to wall (original intention?), and "empty" frame added to block movement over there. But this would require to return back to original SCANG.DAT solution.

Either way this will 100% work when walls are intact. There could be a problem with moving through destroyed walls due to "blocking" tile, I think.


I know most people don't care about it, but I do Consistent, and bugs free visuals are important as well, IMO.


*unless it's possible to "link" both pieces to act as one. This would be really nice feature - for example, when hitting two (and more) pieces objects, all parts are destroyed in the same time - in the same way as HWP.

**I've made this kind of tiles in TFTD way (when on the ground level they're placed in wall "slots"), including changes in SCANG.DAT, and that means Avenger/Lightning walls are looking correctly on minimap, without adding additional images to SCANG.DAT.

[Volutar]

While getting better (straighter) pathfinder, I was experimenting with this "bigwall" flag alternative states.
https://openxcom.org/forum/index.php/topic,295.msg2324.html#msg2324

But this idea was thrown away.

[Conti-k]

Too bad. Additional flags would solve issues I'm talking about, I think. Oh well...

Anyway, I'll continue subject from my previous post, in case development team would like to fix (in the future) those bugs (or not properly implemented features, if you prefer)  So... we shouldn't forget about weird UFO floor tiles. In TFTD they made lil' step forward, but still it was far away from being correct. This is not a problem with Avenger/Lightning "half" tiles, because they're visible all the time.

My theory is: "half" tiles could get a special flag that says: put and draw me "above" ground tile that is used during terrain generation around of UFO, if I'm placed in the ground "slot":



to avoid this nasty glitch:



(two tiles can't be placed on the same grid obviously)

Each "horizontal", and "vertical" wall could have a flag that says: if there's a "half" tile (with a special flag), in ground "slot" (on the same grid as me), block visibility of it in the same way as rest of inside of UFO:



This way all visual glitches related to non-standard walls (including SCANG.DAT stuff) would be working as intended. This can be done via coding/additional flags only, because there's no 100% working workaround for this.

[Volutar]

Take a look inhere. Diagonal walls floor are in u_bits tilepack. And why you called them weird? They are fine. The only thing that may look weird is lighting going to neighbor tile, that's all.

[Conti-k]

Take a look at their LoF template. As long as they're on the ground there's no problem. When used on other levels may cause LoF bugs, and you'll be able to move through the "holes". See Supply Ship: "holes" in floor above ground level are filled with "half" roof UFO tiles, but actually one is missing thus Flying Suit can go through it (check out Blatant LOFTemps Bugs at UFOpaedia.org). They're causing minimap issues as well (see SCANG.DAT): image of "half" tile is actually attached to the wall thus is causing incorrect colors in Avenger/Lightning walls, and tiles will appear as "discovered" while they're not. This ain't solution, but workaround that doesn't work properly like standard tiles.

[Volutar]

Flying suit passing up/down inside diagonal walls have nothing with loft. loft used only for fire tracing and unit-unit "see" computation.

[Conti-k]

You're right, of course. I meant that LoF template is "representing" a gap you need to "cover" to get them working properly on higher levels. And this is exactly done in all more-than-one level UFOs. Also, Abductor seems to have issues with those tiles. If this is true then sixth "weird" tile should be made, while four "half" tiles is enough.

[Volutar]

If you will try to implement those "half" tiles, you will need to have them as "second-ground" layer, in order to cover grass properly. That is something that wasn't done in original. And it will require rebuilding of every ufo map, not saying about adding this feature to engine.

Actually I'm concerned more about issue of 0TUs cost of these "bit" UFO tiles. I've already described how it works.

Another issue - is negative "elevation" of roof tile of Avanger, which have famous effect.

All this issues fixing requires of MCDs fixing.
But because project is intended to be using of original game data files, so they should stay intact.

I see THREE ways of keeping them while fixing all this issues:
1. Hardcoded "fixed" values which works after resource loading (and it will be very ugly).
2. Making of our own "additional" tilepacks with fixed MCDs + making our own UFO craft maps which will be using these packs.
3. To use our own tile and map format.

[kkmic]

I believe that at some point OpenXcom will be completely customizable (somewhere after 1.0), and then #3 idea could be easily implemented.

[Conti-k]

If you will try to implement those "half" tiles, you will need to have them as "second-ground" layer, in order to cover grass properly.

The workaround used in TFTD was to place them in wall "slots" to prevent conflict with the ground.

That is something that wasn't done in original.

By the way, dunno if this is a coincidence, but if you'll look at:

- left over after "half" tile in diagonal walls (what else it can be?),
- image of diagonal wall with attached tile in SCANG.DAT,
- "weird" tiles placed in U_BITS.PCK while all roof tiles, and normal floor tile are placed in U_EXT02.PCK.

you may get an impression that "half" tiles at some point were attached to diagonal UFO walls. If this is true then original devs had a problem with finding correct solution for this issue.

All this issues fixing requires of MCDs fixing.
But because project is intended to be using of original game data files, so they should stay intact.

Without modifying original game files you won't fix HWP that will stuck in one of the forest maps in OpenXcom, for example.

Making of our own "additional" tilepacks with fixed MCDs + making our own UFO craft maps which will be using these packs.

It's not a problem to compile maps patch. And you'll need this to enjoy bugs free experience in OpenXcom, because there's plenty of them in data files as well.

Here's what I did so far:

· UFO floor tiles are done from "half" tiles (Abductor looks normally now),
· UFO roof tiles are enhanced a little (although there's a lil' problem with them in Supply, and Terror Ship),
· fixed missing pixel in one of the UFO walls,
· fixed Avenger/Ligthning walls (walking through, and LoF/LoS issues),
· fixed Lightning doors (pathfinding fixing is needed to get them 100% working),
· fixed Avenger roof,
· fixed minimap issues with Avenger/Ligthning walls,
· fixed two records in FOREST.MCD pointing incorrect images in SCANG.DAT,
· added missing tiles to level 2 of FOREST11.MAP to fix pathfinding issues in OpenXcom,
· added tiles to level 2 of DESERT10.MAP.

It's based on Combo Patch that fixes other map issues (it says that Lightning is fixed, but map file is missing).

I'm enhancing some of the original Farm maps as well: adding missing death tiles (I don't like when objects just disappear after the hit), changing layout, or adding new artwork. I want to add a "basement" level, but I'm guessing it's hardcoded in original engine that level 1 is always a ground (in my case this would be under the ground).

Anyway, as I already said: "content" walls, "weird" tiles, and "half" tiles (when placed inside) are nothing more than wrongly implemented features to me. One of OpenXcom objectives is to fix all issues present in original game, so maybe fixing those at some point will be possible as well 

I believe that at some point OpenXcom will be completely customizable (somewhere after 1.0), and then #3 idea could be easily implemented.

Exactly. Adding extra, super cool features, like multi-layered level of destruction (luke83 was talking about it) won't be possible without it, I think.



BTW, I've noticed strange thing. It happens in both engines, I think.

Walking on stairs (CULTA18.MAP). First let's go to stairs on level 1. Starting point is here (TUs = 57), destination point is here. Unit is going normally, through straight path. 29 TUs remain. Now let's go to the stairs leading to roof... starting, and destination point are the same, TUs = 57. But instead of going straight line this happens. Remaining TUs = 23. Of course, there's no problem going downward in both cases. I don't get what's the difference in both stairs when going upward. Pathfinding gurus please enlight me 

[Volutar]

Pathfinding gurus please enlight me 

It's known issue, here is most unpleasant side-effect. XCOM pathfinder precalculates path in 2d, without paying attention on level, and if there's a stair on the way - unit will go other level, and will loose TUs according precalculated path on level of clicking, not actual level.

[Conti-k]

Here's a preview of enhanced forest hills. Still need to randomize stuff here, and there. For comparison I've added original frames. Under the grass there's desert stuff, that doesn't blend well with the rest of the set. Hillsides are raised via "tile y offset" thus there're ugly holes when destroying them. In my version there will be no such thingy, and under each hillside/hill there will be death tiles (originally you have green stuff all the way).