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 - Yankes

Pages: [1] 2 3 ... 135
1
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.

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

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

4
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

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

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

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

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

9
OpenXcom Extended / Re: OXCE Future plans
« on: April 10, 2019, 09:52:17 pm »
Yankes, are you planning to enable displaying several crafts per hangar as well?
Right now I do not write any code that would do this, but overall functionality have explicit link between crafts and hangars.

Again, this is about being able to assign actual craft and hangar sizes/types, not about buildings.
Low level testing, I even do not run game once, probably over moth of coding without any tests. And I know first report: "game crash" and this will not help much.


Would this still be a problem if the sizes are exclusive? As in, only one size can be assigned per craft/hangar?

Default/vanillar hangar or non-defined size defaults to 1, number of free slots per hangar also defaults to 1 if not assigned to not break compatibility. Check the largest hangar size and max. number of total hangar slots per size, create an array with 1:[largest size] lines and 1:[max. hangar slots] columns. Write a 1 for every free slot per size. The sum of the array gives you your total slots.

Do the same for the crafts. Pad both arrays accordingly. Substract the craft array from the hangar array. The sum of the resulting array is your (total) free hangar space. Check the sums of the individual line vectors. If any of those are 0 or negative there is no free space for that type of craft.

Disclaimer: Above is (a probably overcomplicated way of) how i would implement this in matlab. I'm very bad at matlab and have no idea how this should actually be implemented.


You could always allow multiple sizes later on, but i for one would be happy to even be able to assign one type of size per craft/hangar. I think having multiple sizes per hangar while also having multiple slots per hangar might be overly complicated, at least for an initial implementation.
First of all, I paned that each hangar can store selected types of crafts, and this can overlap with other hangars. This mean one hangar can be used to store A, B or C, another can store A or B, and last hangar only B. Now depending order in with you allocate you can end up with free hangars and not allocated crafts.
e.g.  first get craft A, second B and last one cant fit C because only allow B. And now consider that you have 16 hangars and 16 crafts with different types.

Over all I write already algorithm that should solve this in some effective manner but it need lot of testing to fix all corner cases.


For any one interested WIP branch: https://github.com/Yankes/OpenXcom/commit/08bc53208f0e9dabdfccc323f5c6ac1a4c826bf9

10
OpenXcom Extended / Re: OXCE Future plans
« on: April 09, 2019, 10:11:45 pm »
This I want implement is that each hangar can accept only some types of craft. Image rocket launcher pad that allow only IBM, or garage that allows cars, not space ships.

Probably biggest problem was automatic handling of free space. You have X^Y combinations to check. Last time I worked on this it did needed lot of testing to work correctly. And testing is not thing that programmers like doing :>

11
OpenXcom Extended / Re: OXCE Future plans
« on: April 08, 2019, 11:14:41 pm »
right now on shelf, but at some time I can back to it.

12
Open Feedback / Re: OpenXcom code history
« on: April 02, 2019, 08:34:44 pm »
That is whole point, written from scratch but look and work exactly* same.

There is no original code in OXC, only thing that could be "steal" that sometimes writing of some algorithms was consulted with disassembly of original.

13
Work In Progress / Re: [OXCE] Heavy Plasma Blaster
« on: March 31, 2019, 04:33:47 pm »
btw Recently I push changes to UFOpaedia that have better support multi ammo slot weapons.

14
Area 51 / Re: Area 51 future versions and OXCE
« on: March 30, 2019, 01:10:16 am »
ϙζ (using ancient Greek numerals)
I see, our contribution to version system numbering was significant :D

15
Area 51 / Re: Area 51 future versions and OXCE
« on: March 29, 2019, 12:05:18 am »
This is not roman numeral, after 3 repetion of same symbol you need use new one. Correct should could look like:
1000: M
4000: BM
5000: B
9000: WM
10000: W
40000: EW
50000: E
90000: ZW
100000: Z


Or at least start using float number notation:
10: X^I
100 X^II
1000: X^III
10000: X^VI
100000: X^V

Pages: [1] 2 3 ... 135