OpenXcom Forum
Contributions => Builds & Ports => Topic started by: sir_nacnud on January 23, 2011, 01:49:46 am
-
I have been working on porting OpenXcom to Android. I am happy to report that I have OpenXcom running on Android! With the except of tracking down a crash due to a bug in Surface::setPixel(), this wasn't too difficult, it was done in a couple evenings, less than a week. In the YouTube video below you will see it running on a Samsung Fascinate. It will be interesting to see how it performs on slower hardware.
This port uses a SDL port for android:
https://www.anddev.org/code-snippets-for-android-f33/sdl-port-for-android-sdk-ndk-1-6-t9218.html.
Repository is on github:
https://github.com/sirnacnud/openxcom-android
Progress of the port:
- Virtual keyboard support. The SDL port has some support for a virtual keyboard, but not for so how we want to handle this. I faked out the keyboard input in the video for naming a new base since the Fascinate doesn't have a physical keyboard.
- UI usability with touch screen. You will notice in the video I have a magnifying mouse cursor, this is provided by the SDL port. The buttons are so small it makes them very hard to use with your finger, the magnification helps out some. In the end I think a better solution would be to make the UI more finger friendly, while maintaining a look that is true to the original.
- Wide chacter support. Android doesn't support wide characters. With a recent change, openxcom now uses wide characters for Unicode. This doesn't work on Android.
Here is a video of the port in action:
https://www.youtube.com/watch?v=J073Ej_g9gM
-
Looks rather awkward to use IMHO, but well done on the port
-
A pen would probably work better, but I'm guessing the screen only works with fingers? Anyway, it looks promising.
-
It is a capacitive touch screen, so you can only use your finger. Pretty much all smart phones now days use capacitive touch screens.
I will be looking in to why touch input is working so poorly. I think some of it has to do with the UI buttons being small, but I think there is problem with the SDL port as well. It will be improved so you don't have to use the goofy magnifying mouse cursor.
Keep in mind this is a first pass/proof of concept demo, it is not in a state that I would consider releasable/playable.
-
i think you will need change UI of game to work better with big fingers :>
e.g. menu buttons should be hided and only one with "<" will show. when you click it will show menu (3x or more in size)
problem will be with battlescape because of multiple buttons in UI.
-
I also afraid that without making alternative UI, it will be very hard to play openxcom on touch screens.
I guess you could look how Pocket Ufo guys made theirs ui.
There were also version for normal PC / windows but i can't find it anymore :(
-
Hi,
You can download the PC version of Pocket UFO by following this URL:
https://pocket-ufo.en.softonic.com/pocketpc/download (https://pocket-ufo.en.softonic.com/pocketpc/download)
Please take a look ;D
-
Thanks, I will check it out.
-
The repository for my port is now up on github. See first post for details.
-
Wicked port idea, i will be buying an Android tablet, maybe the Motorola Xoom so this is one on my radar :D
-
Just got sounds and music working!
-
Just got sounds and music working!
Congratulation. Do you think the UI design of Pocket UFO is useful?
-
Just got sounds and music working!
Congratulation. Do you think the UI design of Pocket UFO is useful?
I checked it out on PC. I thought the way they did the globe was interesting. Overall, the UI seemed like it was supposed to be used with a stylus, rather than a finger. I noticed buttons were still fairly small. I will probably poke around with it some more.
Right now my plan with the android port is to try and keep the look consistent with OpenXcom, but improve the UI to be more finger friendly. This will mainly involve increasing the size of the buttons and moving UI elements around to better suit finger use. I also plan on adding dragging to certain aspects of the UI, like the globe on the Geoscape and probably the map on the Battlescape.
-
I also plan on adding dragging to certain aspects of the UI, like the globe on the Geoscape and probably the map on the Battlescape.
Some of that features probably could be merged back to pc openxcom as well. Btw, where you will be coding those? In your fork/branch on github or in another project?
Edit:
Hmm, i just found that project https://github.com/sirnacnud/openxcom-mine
Why another project? Why not fork of https://github.com/SupSuper/OpenXcom ?
-
He probably made it before OpenXcom officially moved to Git.
I also use a stylus with my smartphone so I don't have a big issue with X-Com's interface (plus phones are 320x200 so there's not a whole lot of room for improvement). However, an alternative would be to change the game's input system so, instead of checking which button is exactly under the cursor, it checks which button is *closest* to the cursor (up to a certain distance), therefore allowing a bigger margin of error which comes from "finger pressing".
-
There are styluses adapted for capacitive touchsecreens. I don't think zooming buttons 4 times for large fingers will be fair enough, considering globe tiny 3x3 pixeled objects (ufos, crafts, bases/cities, etc) and battlescape tiles aren't capable to be enlarged for fingeraiming purposes.
-
The globe already has a built-in "tolerance" anyways so you don't have to click exactly on the markers but close enough (which is why you get a popup when there's multiple markers), so this could be tweaked for mobile devices too.
-
I also plan on adding dragging to certain aspects of the UI, like the globe on the Geoscape and probably the map on the Battlescape.
Some of that features probably could be merged back to pc openxcom as well. Btw, where you will be coding those? In your fork/branch on github or in another project?
Edit:
Hmm, i just found that project https://github.com/sirnacnud/openxcom-mine
Why another project? Why not fork of https://github.com/SupSuper/OpenXcom ?
I created it before the switch to GitHub. That repository will be going away shortly, replaced by the fork I have here: https://github.com/sirnacnud/OpenXcom. There is an android branch in this repository that I will be committing my changes to.
There are styluses adapted for capacitive touchsecreens. I don't think zooming buttons 4 times for large fingers will be fair enough, considering globe tiny 3x3 pixeled objects (ufos, crafts, bases/cities, etc) and battlescape tiles aren't capable to be enlarged for fingeraiming purposes.
Almost all new smart phones use capacitive touch screens, so I will be targeting finger input. Most people don't want to use a stylus anyways. I am planning on increasing the area for things you can click on the globe.
-
sir_nacnud : did you check this out? https://github.com/PutzWorks/androidOpenXcom
Why would he not fork the project, as that seems to be easier to merge in updates, no?
PutzWorks also seems to be good at android apps, as he is selling them, maybe you two can get in touch :)
-
sir_nacnud : did you check this out? https://github.com/PutzWorks/androidOpenXcom
Why would he not fork the project, as that seems to be easier to merge in updates, no?
Probaby, because one's done in C++ where as another is in Java?
-
sir_nacnud : did you check this out? https://github.com/PutzWorks/androidOpenXcom
Why would he not fork the project, as that seems to be easier to merge in updates, no?
Probaby, because one's done in C++ where as another is in Java?
Hehe, I even did not look that far. I wonder how all the SDL and YAML stuff works with java... I wish this guy a lot of luck, because he'll need it :p
-
sir_nacnud : did you check this out? https://github.com/PutzWorks/androidOpenXcom
Why would he not fork the project, as that seems to be easier to merge in updates, no?
Probaby, because one's done in C++ where as another is in Java?
Wow why would someone convert the entire codebase to Java?! :o
Props for effort.
-
sir_nacnud : did you check this out? https://github.com/PutzWorks/androidOpenXcom
Why would he not fork the project, as that seems to be easier to merge in updates, no?
Probaby, because one's done in C++ where as another is in Java?
Hehe, I even did not look that far. I wonder how all the SDL and YAML stuff works with java... I wish this guy a lot of luck, because he'll need it :p
This is the first I have seen of this project. I do wonder how he is handling SDL and YAML. Maybe there are some Java libraries that can do palette rendering and YAML. If he is calling SDL/YAML natively in Java, through JNI, he might as well be using the native version of OpenXcom, then it would pretty much be the same as my port.
-
i find this in google: https://sourceforge.net/projects/sdljava/ and AFIK (probaby its wrong :D) YAML is only for writing XML and can be replased by any other xml lib.
and because OpenXcom dont use any advanced C++ features (again AFIK from a short look in code) is can be easy copy/pasted to Java :) (its can be even more correct because you dont need use `delete` that can be pain in a** when you made mistaken)
-
Hey.
I'm that guy... And yes luck is needed.
Aso for the SDL and YAML stuff I just changed them to native android methods and XML. (Honestly I haven't tested the XML just yet, but I'm sure I'm close even though it's my first time writing JAVA XML code. I'm not sure why I'm doing a full code conversion, maybe it's in the hope that if I ever get an interview for a software job I can have something to show.
So far I've got the geoscape and all it's parts working. I can down UFO's and go to them but once you get into the battlescape the colors get slightly interesting. That is what I am working on resolving at the moment. After I get the colors working correctly then I have to tackle the 16 meg memory limit of Android. OpenXcom takes over 40 megs when running on my computer at home.
If anyone wants the APK to test just let me know and I can get it to you and tell you how to install the xcom files properly so it will run. My brother has been running it on his Acer tablet and loves the work I have done.
Anyway, I hope I'm not stepping on your toes openXcom people, but I just wanted to do this for me. It has been a learning experience.
-
That is what I am working on resolving at the moment. After I get the colors working correctly then I have to tackle the 16 meg memory limit of Android. OpenXcom takes over 40 megs when running on my computer at home.
If anyone wants the APK to test just let me know and I can get it to you and tell you how to install the xcom files properly so it will run. My brother has been running it on his Acer tablet and loves the work I have done.
Anyway, I hope I'm not stepping on your toes openXcom people, but I just wanted to do this for me. It has been a learning experience.
It'd be interesting to see a plain java openXcom app.
(and before you ask why... No.. I don't have an android device. :P )
-
i find this in google: https://sourceforge.net/projects/sdljava/ and AFIK (probaby its wrong :D) YAML is only for writing XML and can be replased by any other xml lib.
YAML is not the same as XML, though you are right you can just serialize in whatever other format you prefer, though this will break compatibility between the different versions.
Anyway, I hope I'm not stepping on your toes openXcom people, but I just wanted to do this for me. It has been a learning experience.
It's fine by us, and the GPL allows any code modifications as long as they're also licensed by the GPL.
It sure seems like one hell of a learning experience, good luck with that. :)
-
I read in another thread about no one being able to do optimizations. I have made a LOT of optimizations because the hardware on a phone is much inferior that of a PC. I'm sure a lot of what I fixed can be retranslated into C++ and help your system out a bit. I've only focused on the globe so far since it was the real hog for resources... I'm starting on the battlescape now.
I got the globe drawing down from 250 milliseconds to 7 milliseconds (on my phone). Moving the globe works much faster as well. Let me know if I can help you guys out at all instead of just me helping me.
-
You... you... you optimized the globe?? You tamed the beast?!?!? :o :o
Please, by all means, share with us your crazy voodoo magic because the globe has grown into this horrible monster that we have settled with "just works" and nobody dares to adventure down into its lair anymore, lest we make it worse.
-
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.
-
You... you... you optimized the globe?? You tamed the beast?!?!? :o :o
Please, by all means, share with us your crazy voodoo magic because the globe has grown into this horrible monster that we have settled with "just works" and nobody dares to adventure down into its lair anymore, lest we make it worse.
Oh, I made it worse long before I made it better... And still sometimes Europe falls into the sea until the end of the day... And if you go into the basescape then back out to the geoscape your bases disappear for some reason. Completely gone.
The biggest thing I did is created a new image that contained all the land and only drew to it when the shade changed or when you rotate the globe. Then I modified your calculations for the shades of the sea and removed a LOT of creating Vectors and destroying them just to create them again... Then I stopped drawing things that are off the screen when you are zoomed in really far.
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.
-
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.
-
Standard XCOM battlescape map could have only 255 possible tiles 32x40 pixel sized. Plus unit and groundobjects. That's really a few. Caching those tiles with lighting applied (for night mission) may deal alot more memory consumption. The only way is not to cache all these things. When you have little memory size, this could be a perfomance booster.
-
Standard XCOM battlescape map could have only 255 possible tiles 32x40 pixel sized. Plus unit and groundobjects. That's really a few. Caching those tiles with lighting applied (for night mission) may deal alot more memory consumption. The only way is not to cache all these things. When you have little memory size, this could be a perfomance booster.
That is pretty much what I want going to try to do. There have to be only a set number of permutations of damage/lighting/whatever else may happen to a tile. So I was thinking of just having the 10,000 map tiles have pointers to what they currently contain based on the permutations for that map. But that is so far from the current code it will take me plenty of time to figure out how to accomplish that.
Another option is to have the tiles chached and only create the surface when the tile is visible, instead of creating them when generating a map. But that would cause a lot more object creation/destroying and give me glitchy UI because of the stupid garbage cleaner... So many pro's and con's.
Thanks for ideas. Very welcome.
-
Currently openxcom redraws whole battlescape view (not whole map) every single frame, even if nothing happening.
In original xcom full redraw happen only for map animations such as smoke/fire and alien entertainment.
Map scrolling done with direct scrolling + redraw only new fragments. While scrolling animating is turned off (to avoid glitches).
Unit walking, firing, explosions done with kind of dirty rectangles redraw (actually they used predefined short lists of tiles to redraw, this lists are for different directions of movement (small/large units) and explosion).
No caching used at all. All sprites decoded and directly drawn on mem surface. With double bufferring.
-
Not sure which version you are using, but since 0.3 there is no caching of tiles at all anymore. All thanks to our great blitNshade function ;)
-
I'm currently running the June 3rd revision. I haven't been worrying about the updates you guys make until I get a working version, then I can break it again adding in everything that you have done. I'm thinking about doing that now though seeing all the progress you all have made while I've been tinkering...
-
Oh, I made it worse long before I made it better... And still sometimes Europe falls into the sea until the end of the day... And if you go into the basescape then back out to the geoscape your bases disappear for some reason. Completely gone.
Oh don't worry, that's completely normal, everytime anyone touches the globe it just seems to get even weirder, you'd be amazed with the crazy stuff we've seen during development (and some of it is still there waiting for some brave soul to fix it). :P
The biggest thing I did is created a new image that contained all the land and only drew to it when the shade changed or when you rotate the globe. Then I modified your calculations for the shades of the sea and removed a LOT of creating Vectors and destroying them just to create them again... Then I stopped drawing things that are off the screen when you are zoomed in really far.
That's odd, it should already work like that. Though given how many people have dug into it, I don't know what's what anymore. :P
Basically the globe is split in 4 surfaces: markers (bases etc.), detail (territory names etc.), land and ocean. Each surface is only redrawn as necessary (hopefully), but most of the time everything needs to be redrawn.
This is because originally we had no light shading, so we only needed to redraw the markers every game tick and everything else just when the globe was rotated, so it performed pretty fast. But then the sun shading was added and so everything needs to be redrawn every game tick, which slowed things down. The biggest performance hog is the shaded ocean (if you comment out the Globe::drawOcean function you'll see the difference), since nobody's come up with an efficient way of drawing it and we don't have access to the original X-Com code.
Of course this is all tolerable on modern PCs, but a real drain on lower-end platforms like mobiles (and my ancient PC CPU :P). There's also lots of other aspects surrounding the globe that could improve mobile performance, like all the complex math (turning the flat map into a 3Dish globe) is done with radians stored in doubles and run-time trigonometry, while the original X-Com used degrees in integers with pre-calculated trigonometry (better for platforms without dedicated FPUs). Dirty rectangles and other techniques could probably also help.
We're more focused on functionality than efficiency at this point, so anyone that can understand and focus on optimization is always welcome. :)
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.
A note about memory usage: currently OpenXcom just loads all the original game resources into memory at the start (whether it's gonna use them soon or not) so some smarter resource management might help, from my measurements it takes up 32MB right at startup. I hate unnecessary disk I/O so I just wanted to avoid of it right from the start. :P
I'm currently running the June 3rd revision. I haven't been worrying about the updates you guys make until I get a working version, then I can break it again adding in everything that you have done. I'm thinking about doing that now though seeing all the progress you all have made while I've been tinkering...
Yes quite a lot has changed since June (even performance stuff!), believe it or not. ;)
-
A note about memory usage: currently OpenXcom just loads all the original game resources into memory at the start (whether it's gonna use them soon or not) so some smarter resource management might help, from my measurements it takes up 32MB right at startup. I hate unnecessary disk I/O so I just wanted to avoid of it right from the start. :P
Yes quite a lot has changed since June (even performance stuff!), believe it or not. ;)
Yeah, I changed it into more of a real-time loading system where if a surface is needed it is loaded real time and deleted once it is no longer being used. That seemed to help me out a lot.
And I do believe a lot has changed, you people have way more free time than I somehow. I wish I could accomplish as much.
Once I optimized the land drawing I did notice that the ocean took the longest. I tried figuring out the calculations behind the shading but gave up quite quickly because I had other fish to fry. But I will most likely look into it since it's what is slowing down my globe currently. That and the cacheing of the land when you move the globe at all. That takes up a lot of time as well. I would like the caching of the land to take much less time. It would make the UI much more fluid.
-
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 :)
-
A note about memory usage: currently OpenXcom just loads all the original game resources into memory at the start (whether it's gonna use them soon or not) so some smarter resource management might help, from my measurements it takes up 32MB right at startup. I hate unnecessary disk I/O so I just wanted to avoid of it right from the start. :P
Yes quite a lot has changed since June (even performance stuff!), believe it or not. ;)
Yeah, I changed it into more of a real-time loading system where if a surface is needed it is loaded real time and deleted once it is no longer being used. That seemed to help me out a lot.
And I do believe a lot has changed, you people have way more free time than I somehow. I wish I could accomplish as much.
Once I optimized the land drawing I did notice that the ocean took the longest. I tried figuring out the calculations behind the shading but gave up quite quickly because I had other fish to fry. But I will most likely look into it since it's what is slowing down my globe currently. That and the cacheing of the land when you move the globe at all. That takes up a lot of time as well. I would like the caching of the land to take much less time. It would make the UI much more fluid.
Well the land cache is a trade-off. It makes it faster when the globe is standing still, since no need to recalculate the land polygons when they don't move, but makes it slower to rotate because of the constant cache regeneration. Most of the time the globe isn't moved so I figured that was more important.
-
Well the land cache is a trade-off. It makes it faster when the globe is standing still, since no need to recalculate the land polygons when they don't move, but makes it slower to rotate because of the constant cache regeneration. Most of the time the globe isn't moved so I figured that was more important.
I agree. It is much faster the way it is now when you are not rotating. But I want them both to be fast danget! I have the cake sitting next to me, I want to eat it.
And for the battlescape I will be putting in the most recent version soon before I start to mess with it. It will just make my life easier to start with if there are already process improvements in place that I probably wouldn't have thought of in the first place.
-
Holy cow...
Is there an easy way to go through code and merge in updates? I've been at this for 2 hours and only done 8 files. there are over 200 files that I need to go through. At 15 minutes each this will take for bloody ever.
I am willing to hear any trick anyone may have.
-
Well i guess it is biggest downside of translating code to other language. Maybe it would be better for you to wait until 1.0 will be released and translate it once, but completely (and maybe in future, when new version will be released).
-
SupSuper, how do you cache globe graphics?
As rendered bunch of poly bitmaps? Or as transformed to screenspace visible poly coords? I really hope it's the second way :)
-
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
if(hight_a[x][y] <= hight_b[x+off_x][y+off_y] + off_z)
if this test pass increase shade value in buffer.
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
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
-
i have probably great idea of speeding up globe drawing.
...
I was thinking of something like that, but the problem I see is there is an instance where the shade lines are straight up and down (curved a little, but the idea is there). So the radius of the shading spheres would be infinite. If that could work somehow it would make things very much faster. I just didn't take the time to figure out how to calculate out the center and radius of the shade spheres as a function of centerlat, centerlon and time of day. I know that the radius of the shade shperes would have to be a tangent function.
I also looked into fish-eye distortion. Make a flat globe and just select the pixels out of that image to make it look like a sphere (less pixels from the top and bottom but all the pixels at the equator...) That might work a bit faster, but It would take a little manipulation if you are viewing the north/south poles.
Is it the calculations for the shading polygons that takes the longest or actually shading and drawing them?
-
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.
-
SupSuper, how do you cache globe graphics?
As rendered bunch of poly bitmaps? Or as transformed to screenspace visible poly coords? I really hope it's the second way :)
I only cache the converted coordinates. Caching the graphics would be kinda pointless since they change every game tick (more or less).
Is it the calculations for the shading polygons that takes the longest or actually shading and drawing them?
A little of column A, a little of column B.
See, the land is easy. It's just a bunch of fixed polygons on a 2D map, so we convert them to pseudo-3D with these scary formulas (https://en.wikipedia.org/wiki/Orthographic_projection_(cartography)), shade them, draw them, done! The drawing is simple and the recalculating is simple and only needs to be done when the globe moves.
The ocean, however, isn't. Technically it doesn't really exist, there are no pre-existing polygons or anything, the land is just placed on top of a blue circle. So to shade it like a sphere, which is a lot smoother than the land, a lot of complex expensive stuff goes on, I'm not really sure what since I didn't code it. But I presume the game basically has to generate polygons for the ocean, figure out their positions up to the circle edge, convert them, shade them, draw them, all this every game tick. It's constantly caching so it can't be cached or whatever either. It's basically a really ugly mess :P and nobody's figured out a fast way of doing it yet.
-
SupSuper how are stored rotation of globe in `Globe` class?
we have this:
double _cenLon, _cenLat, _rotLon, _rotLat;what is meaning of each of this fields?
-
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.
Ahh, I got it. You are talking actual 3d objects. I was talking 3d appearance on 2d drawings. I understand how it would work with multiple spheres intersecting and finding the intersecting surface (basically a circle around the sphere), but I have absolutely no idea how to code it...
-
The ocean, however, isn't. Technically it doesn't really exist, there are no pre-existing polygons or anything, the land is just placed on top of a blue circle. So to shade it like a sphere, which is a lot smoother than the land, a lot of complex expensive stuff goes on, I'm not really sure what since I didn't code it. But I presume the game basically has to generate polygons for the ocean, figure out their positions up to the circle edge, convert them, shade them, draw them, all this every game tick. It's constantly caching so it can't be cached or whatever either. It's basically a really ugly mess :P and nobody's figured out a fast way of doing it yet.
What if you created a fine grid of longitude strips and cached those every time you move the globe. Then every game tick you would have to find out which longitudinal strips changed shade and redraw them, nothing else. The problem I see with this method is finding where the edge of the globe is so you aren't drawing the back side of the earth.
This would definitely not help me with making globe motion smoother in my UI, but it might make the draw ever so slightly less. I'll still work on making those ugly equations simpler or at least less time consuming. Is ther biggest problem with the globe the water shading? (the "tame the beast" comment you made earlier)
-
When I had made a simple viewer to look at the map, I treated the datafile as a description of a 3d object, and then used 3d camera matrices to view it from different angles. I cheated and just drew 2d polygons (no z-value) from the rotated earth though.
For ocean, you can use the tftd data file.
-
Holy cow...
Is there an easy way to go through code and merge in updates? I've been at this for 2 hours and only done 8 files. there are over 200 files that I need to go through. At 15 minutes each this will take for bloody ever.
I am willing to hear any trick anyone may have.
Well I'm not sure how your conversion process is, if you initially just crudely converted every file to Java and took it from there or something. Since it's a completely different codebase you can't take direct advantage of the version control features of easy merge/branch/etc. If you only want an overview of what's changed you can probably diff between different revisions of the codebase (eg. from your June 3rd version to now) and take it from there. Most changes only happened in the Battlescape folder anyways (and also Engine for optimizations).
SupSuper how are stored rotation of globe in `Globe` class?
we have this:
double _cenLon, _cenLat, _rotLon, _rotLat;what is meaning of each of this fields?
_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.
The ocean, however, isn't. Technically it doesn't really exist, there are no pre-existing polygons or anything, the land is just placed on top of a blue circle. So to shade it like a sphere, which is a lot smoother than the land, a lot of complex expensive stuff goes on, I'm not really sure what since I didn't code it. But I presume the game basically has to generate polygons for the ocean, figure out their positions up to the circle edge, convert them, shade them, draw them, all this every game tick. It's constantly caching so it can't be cached or whatever either. It's basically a really ugly mess :P and nobody's figured out a fast way of doing it yet.
What if you created a fine grid of longitude strips and cached those every time you move the globe. Then every game tick you would have to find out which longitudinal strips changed shade and redraw them, nothing else. The problem I see with this method is finding where the edge of the globe is so you aren't drawing the back side of the earth.
This would definitely not help me with making globe motion smoother in my UI, but it might make the draw ever so slightly less. I'll still work on making those ugly equations simpler or at least less time consuming. Is ther biggest problem with the globe the water shading? (the "tame the beast" comment you made earlier)
Longitude strips were the original shading method, but you need to have an absurd amount of "strip polygons" with an absurd amount of points to create a smooth shading effect. Not to mention such huge polygons cause lots of annoying wrap-around end edge-crop bugs (unlike the land which is made of small manageable 3-4 point polygons).
This was later replaced with the current method, draw a circle of the most visible shade (day/night) and then calculate and draw a single huge polygon on top of it for the visible part of the opposite shade. Not a perfect solution (the flickering edges are the most obvious issue) but much nicer than before.
If that's not clear, I will explain the full history and workings of the globe later (probably in a different thread since we've basically hijacked sir_nacnud's thread :P) since it's long and it's late and you've gotten me rambling enough as is. :) But yes performance-wise, the water shading is probably the biggest offender. For laughs, roll back to the earliest versions and behold as the globe actually performs smoothly! :o
-
_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?
-
strange when i dont draw ocean i have less fps.
I run some test with my function
I put 100 shade function in loop and only 100 fps less (from 1300).
what is slowest part of globe drawing?
-
_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?
_cenLat would be -PI or PI I think.
strange when i dont draw ocean i have less fps.
I run some test with my function
I put 100 shade function in loop and only 100 fps less (from 1300).
what is slowest part of globe drawing?
I don't know what super-computers you people have :P but here are my average FPS with Release build:
- Drawing everything: 700 (600 when rotating)
- Drawing without ocean: 850 (650 when rotating)
- Drawing without land: 800 (600 when rotating) - seems to vary a lot depending on globe position
- Drawing without land and ocean: 900 (800 when rotating)
The differences are probably more noticable on low-end hardware. But if you have come up with a more efficient / nicer method for drawing the globe, feel free to share. :)
-
i tested this with original rez (aka 320x200).
-
double post :D now some progress :)
simple test show that this is slower than normal, but i use full gradient of ocean shades (not 4, but all 32) and I can use this same function to shade lands too (without any big changes)
and i can always reduce number of shades used.
-
Looks very cool, though it's not all about speed, make sure there aren't any peculiar issues with peculiar positions and the like, they always seem to pop up on the globe :P (eg. current ocean doesn't like (0,0) position among other things).
-
after some test i find out that my version have glitch too :( because i use ints cords to move spheres around, some times you can see whole shadow line jump by one pixel forward or even backward. (best to spot this is by looking on south pole and set speed to 5s)
I pushed my ocean version to my fork. SupSuper can you test this and say is this worth continuing?
-
I tried it out, it definitely looks a lot nicer. Your pixel bug doesn't seem as noticable as the current flickering edges so I wouldn't worry too much about it.
The main issues seem to be way it's way slower in Debug (but faster in Release? weird) than the current method, and the zoom doesn't work. If you can get those ironed out, I'd say it's worth pursuing. :)
-
its because inline functions, in debug build they dont get inlined, and I `call` them every pixel. this is very slow :> that why i awlays use -o3 in even in debug (untill I f*** up something and need find out that :D )
I think about solution that will allow me to zoom globe.
-
Where can i get .apk file of this port?
-
I haven't been very active with the project lately. Currently the Android port is pretty far behind the mainline of OpenXcom due to the introduction of wide characters, which native Android development now supports.
If you want to test it out, I can make an apk for you, but keep in mind the project at this point is mostly a proof of concept and not a polished application.
-
I would be thankful for apk file)
Sorry for my bad english.
-
the apk file in the wiki page is dead, can you re upload the file or, can be posted at the mod site?
-
Apk can be found here: https://4pda.ru/forum/index.php?showtopic=539828
Requires forum registration. Can't upload it somewhere myself atm.
-
Here is another mirror (tested): https://trashbox.ru/topics/50564/openxcom-0.9-beta (previous is already dead, this one does not require registration).