Messages

1

OpenXcom Extended / Re: [Suggestion] sqr formula for throwing range

« on: May 10, 2019, 08:55:59 pm »

Some thing like this could be done by scripts, this is simple calculation task, that scripts can handle fine.
It could do even more, each armor could have different throw ranges (or per item).

[ps]

After fast looking on code, I see that logic is bit more complicated: https://github.com/OpenXcom/OpenXcom/blob/master/src/Battlescape/ProjectileFlyBState.cpp#L693

Nowhere in code we have `2.5 × Strength / Weight` it only have `dz -= (double)(50 * weight / strength)/100;` in loop.

2

Resources / Re: Graphic Gallery

« on: May 09, 2019, 01:13:28 am »

That way supporting HD-graphics would be a matter of adding support to blitting routine.

No, if you really want you could today load 2x bigger sprites to game and it would not crash, but problem lay in other place, offset.
Game is full of magic numbers that fit current graphic size and completely do not work with any other size. And adding arbitrary sizes will be hell of a work to do.

3

OpenXcom Extended / Re: OXCE (OpenXcom Extended) main thread

« on: May 08, 2019, 11:23:30 pm »

Excuse me, but this seems like a pretty important change as far as animation behaviour is concerned, in a mod that prides itself on keeping/preserving vanilla consistency. Going by this you could also do away with the shooting animation entirely and just show the results instead.

This is priority of OXC not OXCE. When I start OXCE, my main goal was modding capacity of engine even when sacrificing original behavior.
See: https://openxcom.org/forum/index.php/topic,6459.0.html
If new behavior have similar (not same!) end effect and give more options for modder then I throw through the window original behavior.

And here we have exactly this case, changing order is very visible but end result is same. As it give lot of potential for new mod capabilities and code refactor that will simplify and allow future changes and new functionalities. And only thing left is personal taste and familiarity with old behavior.

For single hit animation current version look even better IMHO.

As far as i am concerned the tiles are 'precognitive', since the only inidication that any damage has been delat is when the hit animation plays - which is does after the terrain tile is already destroyed. Damage calculation in-game isn't transparent to the player. I'd ask you to reconsider and at least give us an option to enable vanilla behaviour (for animations).

People evaporate in nuclear strike before shock wave reach them.

Options to toggle it is out out question, because whole point of this change was to simplify game logic not add new cases and versions. Whole point is that I could really on this that calculation was done before all animations.

Only thing that could be done (as I said previous post) to alter how tiles are handled after damage calculations. That could allow delay update of tiles to some frames after hit, but this need more work and right now I have other priorities.

Right now you are only one I know who is very against this change, if there was more demand for changing it, from more people, then I could consider to alter current behavior. Other wise I leave this as is.

4

OpenXcom Extended / Re: OXCE (OpenXcom Extended) main thread

« on: May 08, 2019, 08:26:55 pm »

Doesn't this break vanilla behaviour/animation cycles?

As Nord has pointed out this looks extremely odd atm, since the terrain breaks before the projectile hit animation plays out.

Might i suggest moving this change into a seperate dev-branch until this has been sorted out? I'd like to use a version of OXCE that doesn't randomly crash, but right now i'd actually prefer the game to randomly crash instead of having precognitive terrain tiles.

With what version were these changes introduced?

This is already sorted out, and tiles aren't precognitive because damage hit them at this moment. Overall gameplay behavior is exactly same as previously, only moment when animation is play was changed.

This change is important in long run, because damage calculation is done first now then it can affect how explosion will play out, that is impossible in old version.
Example could be that explosion animation is played in random places even if damage do not reach that place, in new version I could add that animations is show only where damage was done.

One thing I have in mind is do not update every tile at once during explosion. Instead do it by circualr "layer" that will simulate propagate of shock wave.

5

OpenXcom Extended / Re: OXCE (OpenXcom Extended) main thread

« on: May 06, 2019, 10:30:00 pm »

Yes, this is intended, this is change made in propose of future changes and refactors.
Terrain is change because bullet physically hit at that moment, and after bullet hit/explosion animation will play.

6

OpenXcom Extended / Re: [Suggestion] requires for pages

« on: April 30, 2019, 01:07:49 am »

Changing number of pages in article based on research will be very hard. To make it correct way I would need refactor whole article handing, and nearly rewrite it from scratch.

But looking on your example, why not separate articles for each attack? Each page have nearly nothing in common with each other and have different research requirements. Goal of multi page articles was to handle one big thing that do not fit on one screen.

7

Offtopic / Re: XCOM Inspired Fantasy Game

« on: April 30, 2019, 12:59:49 am »

Why not just flood half of the island into a swamp? I see nothing wrong with it.

Typical for Troll :>

8

XPiratez / Re: Allow melee to be reaction able.

« on: April 20, 2019, 07:56:14 pm »

Code already allow reaction to melee attacks. Only for backward compatibility its not active. Scripts can alter this behavior to enable reaction.
This mean you can encode if you are kung-fu masta nobody can react to your attacks.

9

Offtopic / Re: XCOM Inspired Fantasy Game

« on: April 20, 2019, 07:47:48 pm »

One solution would be not use hex but triangles, if they are arranged in hex then you keep all hex good properties but you still can have orthogonal moment.
Trick is that 1TU allow you to move thought 2 triangles. I added small graphic that show this, All red dots are valid unit positions, black lines are allowed "half" moves. Effective this is multiple hex grids overleaped on each other.

10

Programming / Re: RNG innerworkings?

« on: April 18, 2019, 05:14:38 pm »

For comparison: https://www.youtube.com/watch?v=pq3x1Jy8pYM
Only caveat is that doom RNG have cycle length of 255 and OXCE have cycle length around millions.
From implementation perspective they are different but from mathematic perspective they are same.

11

Offtopic / Re: XCOM Inspired Fantasy Game

« on: April 17, 2019, 07:41:57 pm »

Where will you get the depth surface? 3d software generates it together with sprite? I remember there was some zombie-shooter game demo, where artists hand-drawn such z-surface onto each pixelart sprite, so dynamic light would highlight these sprite properly from any angle. A ton of work, and I havent heard
about them since then. Guess their project is dead.

Yes, you need prove it as separate surface, this need be lot of simpler than doing main graphic on its own. Flat shades that represents different depths could be enough in 99% cases. Alternative could be done using approximation form main graphic (inner parts should have more thickness that edges).

And as I said with just z-buffer you will still get wrong draw order like: https://www.youtube.com/watch?v=BJYH-UrQ2xs
That guy solved it with two zbuffers, one for draw order, another the usual depth buffer. I solved it with topologically linking objects in a tree of what occludes what, but did that locally and only for specific units. I'm not using zbuffer now (although I had it in the first version), instead just sorting by x,y,z towards frustum.

I do not think he use z-buffer in same way as I thinking how it should be used. You could consider each pixel of graphic as voxel in space 3D space. How one voxel with less z can occlude voxel with bigger z? Trick is that flat tiles shroud have ramp in z values, and tile ramps in some cases should have flat z values (this depend on angle of ramp compare to screen). You could even blit together background as one surface and reuse it in each frame.

This is important difference. You can see in this YT video that this buffer get brighter when it going to left side, this is wrong, it should be brighter when going to bottom edge of the screen.

I dig up my very old z-buffer test. Example in images. Red circle is draw as last but it overwrite all green "boxes". Second image is normalized z-buffer.

XCOM globe is an actual 3d object, so you get normal vectors for free with it.

globe is not 3d object, its drawn using 2d polygons, all 3d math is done on our side. Normals are only avaialbe because we know that globe is sphere, with this I can precalculate them for each pixel of screen and zoom level.

https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Geoscape/Globe.cpp#L914
https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Geoscape/Globe.cpp#L1988

12

Offtopic / Re: XCOM Inspired Fantasy Game

« on: April 17, 2019, 04:16:39 am »

I want 2.5D engine, not 3D engine :>
I not even try implement drawing triangles. Simply biting 2D sprites with depth (that can be implemented as two normal surfaces but one is not treated as color but as depth).

https://github.com/Yankes/OpenXcom/blob/master/src/Geoscape/Globe.cpp#L987
https://github.com/Yankes/OpenXcom/blob/master/src/Geoscape/Globe.cpp#L175
This is shading I spoke before, each pixel have predefined normal vector and based on this I calculate sun shading on globe.
And everything still 8bit.

13

Offtopic / Re: XCOM Inspired Fantasy Game

« on: April 15, 2019, 09:24:24 pm »

You missed one important aspect, EVERY pixel have depth, this mean destination and source too. If unit clip it should look like it dive into water.
And performance will not be very bad, OXC already do half of work that I image will be needed. Overall my idea how it will work is based on my work on OXC.
I already use some custom surfaces to make some special effects, like globe illumination using normal vectors. All done in software.

14

Offtopic / Re: XCOM Inspired Fantasy Game

« on: April 12, 2019, 09:34:50 pm »

I for long time think amount 2.5D graphic engine. This mean that each screen pixel have not only color but depth too. With something like this drawing order will be only secondary thing. You will check for each pixel you draw if you it behind or on front of background pixel.

With something like this you could add shadows too, special surface that have two depths, if background pixel have depth that is in this range we change shade of this pixel.

Overall each blit function will have not only `x` and `y` but `z` coordinate too.

15

OpenXcom Extended / Re: OXCE Future plans

« on: April 11, 2019, 08:16:38 pm »

Or in OXCE, this is simple state of my not finished work on this feature. When it will be done, then I will add it to OXCE.