Messages

3106

Builds & Ports / Re: Android Port

« on: September 23, 2011, 03:43:51 am »

_cenLon / _cenLat are the longitude / latitude of the point currently shown at the center of globe. These control the rotation of the globe.
_rotLon / _rotLat are the amount of "rotation speed" on longitude / latitude currently being applied to the globe. So while you hold down one of the rotation buttons, _cenLon += _rotLon and _cenLat += _rotLat.

what vales `_cenLon` and `_cenLat ` have when globe is flipped upside down?

3107

Builds & Ports / Re: Android Port

« on: September 23, 2011, 12:42:40 am »

SupSuper how are stored rotation of globe in `Globe` class?
we have this:

Code: [Select]

double _cenLon, _cenLat, _rotLon, _rotLat;what is meaning of each of this fields?

3108

Builds & Ports / Re: Android Port

« on: September 22, 2011, 10:20:46 pm »

Putz you didnt get this :>
shadow edges on earth surface are circles (looking in 3d) and intersection of 2 spheres (again 3d objects) give this too. i dont need change radius of this spheres, only relative position.

3109

Builds & Ports / Re: Android Port

« on: September 22, 2011, 07:44:15 pm »

i have probably great idea of speeding up globe drawing.

https://on init:
we need create 2 big tables that store hight of sphere (around 200x200). both spheres have different radius (smaller have size of earth in geoscape)
https://per frame
create "shade" buffer.
made some offset (in `x`, `y` and `z` axis ) between this two spheres
we test relative hight of them

Code: [Select]

if(hight_a[x][y] <= hight_b[x+off_x][y+off_y] + off_z)
if this test pass increase shade value in buffer.

Code: [Select]

    buffer[x][y] += 1;
repeat this with different offset to create darken shadows

now when we bliting ocean to surface we add shade from buffer

Code: [Select]

surface[x][y] = OCEAN_COLOR_OFFSET + buffer[x][y];
(this can be used for shading lands too)

only problem i have with this is that work only with max zoom out globe.
to this work with `zoom in` we need
a) bigger tables (probably pointless)
b) interpolate hight (around 3 + 3 multiplates per screen pixel every frame)
c) live with big square shadow when we zoom in

i did somthig similar when i have fun with "universal blit function"
https://img21.imageshack.us/img21/2985/outqm.jpg
https://img3.imageshack.us/img3/1566/outjs.jpg

every shpere is flat bitmap but I store height of every pixel, and I use it for drawing.
this image was generate in 1/60s, when we reduce number of spheres (in this pix is around 40) we can draw this even faster
 

3110

Suggestions / Re: 3 more "easy" to implement ideas

« on: September 22, 2011, 02:36:16 pm »

first point isnt easy to implements, Xcom2 use different palettes than Xcom1. i dont know that STL support palettes bigger than 255 colors (have two palettes at once ) to allow this.

3111

Builds & Ports / Re: Android Port

« on: September 22, 2011, 12:14:14 am »

you probably dont find any big improvement here. most demanding part of battlescape is bliting but this is already optimized.

From what I found it is horrible with respect to memory savings, which is very important on Android as I only have 16 megs to work with.  Each 320*200 surface takes up 256k.  The memory gets taken up very fast in bitmaps.

The battlescape uses a rectangular surface for every possible movement position on the map.  A standard game map would be 10000 possible positions.  Each surface set up for these is something like 30*40 pixels.  That alone is 48 megabytes.  I need to find a way of making that use less than 16.  I haven't started it yet so I don't know exactly how I plan on accomplishing it.  If anyone has any ideas I would be glad to hear them.

as Daiky said you should check out new version of Battlescape  (at least you should look at differences), its a lot faster than previous one. and probably use less memory.

The garbage collector in Java takes a lot of time, so creating and destroying objects is horrible for Android gaming.  I'm sure I made many many more optimizations, but I'm not near my code right now.  I'll see what I can define and share as an improvement.  I'll try to take a movie of me playing around in the geoscape on my phone to see what you guys think.

deleting/creating object in c++ is slow too, but because vast memory and speed of cpu we dont see it often. every optimization will work on both version

3112

Builds & Ports / Re: Android Port

« on: September 21, 2011, 03:42:36 am »

I'm starting on the battlescape now.

you probably dont find any big improvement here. most demanding part of battlescape is bliting but this is already optimized.

3113

Programming / Re: Research developement

« on: September 21, 2011, 01:17:13 am »

... or maybe stun rods? I think SupSuper could have connection to aliens :>

3114

Suggestions / Re: "grey" fog of war

« on: September 17, 2011, 01:10:04 am »

on https://github.com/Yankes/OpenXcom i have my current version of SurfaceShader
now with soft shadows

3115

Suggestions / Re: "grey" fog of war

« on: September 16, 2011, 04:55:26 pm »

this ISNT alpha bliting :> i simply replace "shade" part from dest pixle by shade from src pixel. color group stay same

Code: [Select]

https://this function will be used for every pixel that is bited
static inline Uint8 func(const Uint8& dest, const Uint8& src, const int& shade, int, int)
{
if(src)
{
int t1 = (dest&ColorGroup) + (((src & ColorShade)+(dest & ColorShade)+ shade + 2)>>1) ;
int t2 = (dest&ColorGroup) | 15;
return (t2> t1)? t1 : 15;
}
else
return dest;
}it have many limitations. it can be used for shadow, but probably different function could be used instead.
this is very fast function i dont see any big performance loose (i use it only for unit now).
i will soon update my fork of openXcom, if you are interested in my implementation of this

3116

Suggestions / Re: "grey" fog of war

« on: September 16, 2011, 12:21:42 pm »

i have made next step into cloning X-Com soldier (did you remember blue skinned ones? :>). now they have chameleon genes!

and about highlighting paths, its can be say done by recoloring titles.

3117

Suggestions / Re: "grey" fog of war

« on: September 14, 2011, 07:21:44 pm »

my point of creating this "corpseitem" is for storing information whose is this body. adding this to normal items will only increasing complexity of this class and amount of useless data for rest of the items.

3118

Suggestions / Re: "grey" fog of war

« on: September 14, 2011, 05:09:45 pm »

Looks neat.
Corpses are just items so there is no connection to the original soldier, you'd probably need to modify the item structure for that. Although they might need a connection in case of stunned soldiers, dunno if/how Daiky has implemented that.

or create new class `CorpseItem` that extends normal item class. his will allow me to even color corpses in inventory screen.

3119

Suggestions / Re: "grey" fog of war

« on: September 14, 2011, 02:27:25 pm »

if you want change whole suit, yes. if you want color only part, no.
it simply replace one color group by another from palette:
https://www.ufopaedia.org/images/2/2b/5_BattleScapePal.Png

3120

Suggestions / Re: "grey" fog of war

« on: September 14, 2011, 03:24:11 am »

now better version

[ps]
i have small problem with corpse item. its dont have any connection to owner of this body. if i could find it, it will be possible to colors corpse too.