Jump to content


Photo

Regions/countries/cities On Geoscape


  • Please log in to reply
73 replies to this topic

#1 Darkside

Darkside

    Sergeant

  • Xenocide Recruit
  • 45 posts

Posted 19 June 2007 - 02:50 PM

Hi everyone, I wanted to formally introduce myself as your newest recruit and later talk about what I hope to be working on first and get some input on.

I am a 26 years old who lives in the suburbs of New York City. I am a professional programmer with primary focus in business web applications using Java. I like working for small companies where I get to get to work in all aspects of development from actual development to testing to deployment. And it's funny but after a day of coding at work I will actually enjoy coming home and working on my own personal coding projects, which mostly are in C#. I don't have any game programming experience but I am eager and willing to learn.

I've been a fan of the X-Com series ever since my friend shows me X-Com UFO Defense way back in my high school days, probably '96 or '97 (It wasn't the same year the game was released). When I think back at all the games I have played since then, X-Com invokes the fondest memories. It had such an amazing immersing effect on me.

Anyway enough of that-

As part of applying to work on this project I sent dteviot a patch which mapped a coordinate on the geoscape to coordinate on a background bitmap which defined the regions in the game. So now we can prevent the user from building a base in the middle of the ocean and we can tell what region you are in if you click on a spot on the globe. The bitmap was made by hand, I just grabbed the earth texture and went with a paintbrush to outline each region [arbitrarily marking borders for some regions like in Asia/Europe] and then fill them in. It works very well.

I was hoping to expand on this by making another bitmap to define country borders and a third to define terrains. I was thinking the one defining country borders could also be used to superimpose borders on the actual globe as well.

Then using these bitmaps I could also make functions that will produce a random coordinate in one of these regions or countries for UFO missions. I think what I have to do is scan the bitmap to find the boundaries between the colors and then make a series of polygons representing the areas. Then I think I can pick a random point within these polygons and translate them into a geoscape coordinate.

I have been using the country.xml file but I noticed there is a xml file which overlaps some of the information already, in planets.xml. It seems to have places to define countries, regions and cities. But it doesn''t seem to be used... Should I try to make use of this or add the cities data to country.xml and continue using just that?

#2 dteviot

dteviot

    Programming Department

  • [Xenocide Senior Members]
  • 1,479 posts

Posted 20 June 2007 - 10:17 PM

Hi everyone, I wanted to formally introduce myself as your newest recruit and later talk about what I hope to be working on first and get some input on.

I am a 26 years old who lives in the suburbs of New York City. I am a professional programmer with primary focus in business web applications using Java. I like working for small companies where I get to get to work in all aspects of development from actual development to testing to deployment. And it's funny but after a day of coding at work I will actually enjoy coming home and working on my own personal coding projects, which mostly are in C#. I don't have any game programming experience but I am eager and willing to learn.

I've been a fan of the X-Com series ever since my friend shows me X-Com UFO Defense way back in my high school days, probably '96 or '97 (It wasn't the same year the game was released). When I think back at all the games I have played since then, X-Com invokes the fondest memories. It had such an amazing immersing effect on me.

Anyway enough of that-

As part of applying to work on this project I sent dteviot a patch which mapped a coordinate on the geoscape to coordinate on a background bitmap which defined the regions in the game. So now we can prevent the user from building a base in the middle of the ocean and we can tell what region you are in if you click on a spot on the globe. The bitmap was made by hand, I just grabbed the earth texture and went with a paintbrush to outline each region [arbitrarily marking borders for some regions like in Asia/Europe] and then fill them in. It works very well.

I was hoping to expand on this by making another bitmap to define country borders and a third to define terrains. I was thinking the one defining country borders could also be used to superimpose borders on the actual globe as well.

Post 14 in the geodata threadalready has a bitmap showing the countries.

Then using these bitmaps I could also make functions that will produce a random coordinate in one of these regions or countries for UFO missions. I think what I have to do is scan the bitmap to find the boundaries between the colors and then make a series of polygons representing the areas. Then I think I can pick a random point within these polygons and translate them into a geoscape coordinate.

OK, first issue is I suspect UFO missions pick a region, not a country, as the target. Zombie can probably confirm this. Note, this probably doesn't apply to terror missions.
And while picking a region point in a region as a target is no different really for doing a country, I don't know how points are allocated between regions and countries.

I have been using the country.xml file but I noticed there is a xml file which overlaps some of the information already, in planets.xml. It seems to have places to define countries, regions and cities. But it doesn''t seem to be used... Should I try to make use of this or add the cities data to country.xml and continue using just that?

Ignore planets.xml. It was a previous attempt to provide the country/region information, and used a set of polygons to mark the areas.
As we're now using bitmaps to indicate regions, that's not relevant.
Also, I'm not worrying about terain types until we're well into the battlescape. And multiple missions on Mars are not going to happen until post v1.0 release.
However, feel free to add a collection of city elements to each country for terror missions.

Actually, I suggest you have a good read of the previously referred to Geodata thread
Saving the world from the scum of the universe is hard work. Especially when you have to create the scum to begin with.

#3 Darkside

Darkside

    Sergeant

  • Xenocide Recruit
  • 45 posts

Posted 20 June 2007 - 10:33 PM

Post 14 in the geodata threadalready has a bitmap showing the countries.


Oh, that's a really good country bitmap!

OK, first issue is I suspect UFO missions pick a region, not a country, as the target. Zombie can probably confirm this. Note, this probably doesn't apply to terror missions.
And while picking a region point in a region as a target is no different really for doing a country, I don't know how points are allocated between regions and countries.


I was thinking an easy way to get a random point in a region or country is to scan the relevent bitmap file and create an array of points for every pixel of a country/region's area. Then when we just choose a random index on one of these arrays to get a random point in the associated region/country. Am I missing a more obvious alternative?

Ignore planets.xml. It was a previous attempt to provide the country/region information, and used a set of polygons to mark the areas.
As we're now using bitmaps to indicate regions, that's not relevant.
Also, I'm not worrying about terain types until we're well into the battlescape. And multiple missions on Mars are not going to happen until post v1.0 release.
However, feel free to add a collection of city elements to each country for terror missions.

Actually, I suggest you have a good read of the previously referred to Geodata thread


Actually in the time the forums were down I went ahead and basically took country.xml/xsd and renamed them to planets then added whatever extra data I needed to that, since the name planets makes much more sense. I also revamped how the data was loaded in the game, instead of putting more parsing code in CountryCollection I created a PlanetParser class which handles all the xml parsing of planets.xml. It will create the various planetary objects (Planet, Country, Region) with just passing in the attributes they need instead of passing off parsing work to them. This way, those objects are much cleaner and all the xml parsing for that file is in one neat location. I think it makes alot more sense this way.

#4 dteviot

dteviot

    Programming Department

  • [Xenocide Senior Members]
  • 1,479 posts

Posted 20 June 2007 - 11:43 PM

I was thinking an easy way to get a random point in a region or country is to scan the relevent bitmap file and create an array of points for every pixel of a country/region's area. Then when we just choose a random index on one of these arrays to get a random point in the associated region/country. Am I missing a more obvious alternative?

That was pretty much my idea as well. Only issue is that it might generate rather a lot of points. So you might want to RLE compress the data (on the fly.)
http://www.prepressu...pressionrle.htm

Ignore planets.xml. It was a previous attempt to provide the country/region information, and used a set of polygons to mark the areas.
As we're now using bitmaps to indicate regions, that's not relevant.
Also, I'm not worrying about terain types until we're well into the battlescape. And multiple missions on Mars are not going to happen until post v1.0 release.
However, feel free to add a collection of city elements to each country for terror missions.

Actually, I suggest you have a good read of the previously referred to Geodata thread


Actually in the time the forums were down I went ahead and basically took country.xml/xsd and renamed them to planets then added whatever extra data I needed to that, since the name planets makes much more sense. I also revamped how the data was loaded in the game, instead of putting more parsing code in CountryCollection I created a PlanetParser class which handles all the xml parsing of planets.xml. It will create the various planetary objects (Planet, Country, Region) with just passing in the attributes they need instead of passing off parsing work to them. This way, those objects are much cleaner and all the xml parsing for that file is in one neat location. I think it makes alot more sense this way.

OK, please send me an updated patch.
Saving the world from the scum of the universe is hard work. Especially when you have to create the scum to begin with.

#5 dteviot

dteviot

    Programming Department

  • [Xenocide Senior Members]
  • 1,479 posts

Posted 21 June 2007 - 03:43 AM

I was thinking an easy way to get a random point in a region or country is to scan the relevent bitmap file and create an array of points for every pixel of a country/region's area. Then when we just choose a random index on one of these arrays to get a random point in the associated region/country. Am I missing a more obvious alternative?

That was pretty much my idea as well. Only issue is that it might generate rather a lot of points. So you might want to RLE compress the data (on the fly.)
http://www.prepressu...pressionrle.htm

OK, I think I need to explain my prior post in a bit more detail.

Firstly, we have the following requirements.
  • A function that given a location on the earth, tells us the country that owns the location.
  • A function that given a country, will pick a random location on the earth inside the territory of the country.
  • A function that given a location on the earth, tells us the region that owns the location.
  • A function that given a region, will pick a random location on the earth inside the region of the country.
  • A function that given a location on the earth, will tell us the terrain. (Initially just if it's land or sea.)
As you can see, items 1 & 2 are the same as 3 and 4, just replace country with region. So, let's focus on 1 and 2.

The simplest implementation of 1 is load a bitmap. Then given a location on the earth, find the pixel that represents that location, and read it out. Which is what darkside has done.

The simplest solution to 2 is as follows.
  • Count the number of pixels in the bitmap belonging to the desired country. Call this number K.
  • Now assume we have a function int Random( int n). That given an integer n, will return a randomly selected number between 1 and n, inclusive.
  • Then the following pseudo code will allow us to pick a random pixel belonging to the country.
    i = Kforeach (pixel p in bitmap){	if (p belongs to country)	{	   if (Random(i) == i)	   {			Return location of p	   }	   Else	   {		   --i;	   }	}  }
The way it works is that when we find the first pixel, there are K pixels in the country, therefore, the odds of picking that pixel are 1 to K. So we roll the dice, and see if we pick it. If we don't pick it, then we move onto the next pixel, giving us K - 1 pixels to choose from, and the odds of selecting it of 1 to (K-1). We repeat this process until we pick a pixel. Note, if we get to the last pixel, the odds of picking it are 100%


However, I want to make a couple of additional points here.
  • I'd like to use a real bitmap (e.g. a .png file) as the raw source of this data. Mostly because that's going to be the easiest form for someone to modify/update.
  • However (as Darkside has observed) a bitmap is a very memory inefficient way of holding this data. For example, the existing 2048 x 2048 x 32 countries.png occupies 16 Megs once it's loaded into memory.
  • So, we can apply several techniques to compress this data.
    • Firstly, we don't need 32 bits to store each pixel. As a first compression technique, we could build a new "bitmap", using a single byte for each pixel in our source. Idea is we already have an array of countries, with the 32 bit colour used to represent each country. So we create an array byte[2048][2048] and then for each pixel in the original .png, get the colour, look up what country it represents and then put the index to the country into the array. (Note, As we only have 16 countries we only need 4 bits to store each index, but I'm using bytes to keep things simple. As we may want more countries in the future, I'd suggest allocating 6 bits for the index, which would give us up to 64 countries. More on this shortly.)
    • The next thing we can do is RLE encode each row of the bitmap. That is, as each row of the bitmap is going to be made up of runs of the same colour, we don't need to record each pixel, we can just record the type of pixel, and the number of them.
      e.g. A row of the bitmap might look like
      0000000111110000222220003333
      Where '0' represents ocean, '1' represents Africa, '2' represents Australia and '3' represents South America
      This could be coded as 7 zeros, 5 ones, 4 zeros, etc.
      This becomes the set of touples. (0, 7)(1, 5)(0,4)(2,5)(0,3)(3,4)
      Now, if we allocated 16 bits to store each touple, we can allocate 6 bits to the type, and 10 bits to the count.
  • So, what benefit do we gain from this? Well with the original bitmap, we had 2048 pixels per row. However, with RLE compression we have about 10 touples per row. Or 20 bytes. That's a saving of 99% in terms of memory.
  • It's also going to run a lot faster when it comes to picking a random location on the globe, as we don't have to check each pixel to see if it belongs to the country we're interested in, we just need to check each touple.
  • And once we find a touple belonging to the country of interest, evaluation is faster as well. Example. Assume the touple says the next 20 pixels belong to the country of interest. Then we only need to generate one random number, and see if it's in the range 1 to 20. If it is, then that number indicates the randomly chosen pixel.
  • Of course, the function may be a little bit slower when converting a latitude and longitude into a country, but not much.
Now, I should add that I'm committing the grievous programming sin of premature optimisation, by suggesting we use this more complicated algorithm before we've a proven need.

Edited by dteviot, 21 June 2007 - 01:47 PM.
fixed minor error in calcs.

Saving the world from the scum of the universe is hard work. Especially when you have to create the scum to begin with.

#6 Darkside

Darkside

    Sergeant

  • Xenocide Recruit
  • 45 posts

Posted 21 June 2007 - 07:05 AM

I really like those ideas. It doesn't seem like it would make it too complicated and it's well worth the savings it provides to us.

I will try and implement those solutions asap.

Do you guys know of a good memory profiler I can use with this IDE? In Java I used something called JProbe

Edited by Darkside, 21 June 2007 - 07:21 AM.


#7 red knight

red knight

    Xenocide Project Leader

  • Xenocide Inactive
  • 3,310 posts

Posted 21 June 2007 - 08:17 AM

You can use Compuware Devpartner Community Edition (I think it has some memory profiling) or AQTime for .Net (it has a trial).

Welcome to Xenocide Darkside, great contribution.

Greetings
Red Knight
Sourceforge Nick: flois - Federico Andres Lois
Visit my blog at: flois.blogspot.com

Posted Image

Pookie cover me, I am going in.

#8 Darkside

Darkside

    Sergeant

  • Xenocide Recruit
  • 45 posts

Posted 21 June 2007 - 11:49 AM

Thanks, I will look into that.

One thing about the textures from the other thread, they are huge! Huge compared to the texture we are currently using on the globe... The globe is 640 x 480 while the countries bitmap is 2560 x 2048.

Also the aspect ratios do not match. There would be no reason to use a texture for the bitmaps that is bigger than the texture on the globe, and I think in order for the code getting the right pixel at globe coordinates to work the aspect ratio has to match.

or is there some texture the c++ project was using that was bigger that these are based on ?

#9 red knight

red knight

    Xenocide Project Leader

  • Xenocide Inactive
  • 3,310 posts

Posted 21 June 2007 - 12:15 PM

You dont need a 2048x2048 texture just to know where to click or not; with 256x256 using a single 8 bits channel is more than enough for the use it will have. Just make sure you do not include the coastline in it.

On the other hand using RLE trade you space for Computation, we have a lot of memory (they even dont have to be in Video Card Memory as the Geoscape one is) but the computation grows linearly unless in the tuple a relative position from the start. To me is too much complexity for something that can be more than manageable in a 256x256 16 colors texture. With that you can even discriminate countries or special zones if you want.

Greetings
Red Knight
Sourceforge Nick: flois - Federico Andres Lois
Visit my blog at: flois.blogspot.com

Posted Image

Pookie cover me, I am going in.

#10 dteviot

dteviot

    Programming Department

  • [Xenocide Senior Members]
  • 1,479 posts

Posted 21 June 2007 - 01:42 PM

You dont need a 2048x2048 texture just to know where to click or not; with 256x256 using a single 8 bits channel is more than enough for the use it will have. Just make sure you do not include the coastline in it.

On the other hand using RLE trade you space for Computation, we have a lot of memory (they even dont have to be in Video Card Memory as the Geoscape one is) but the computation grows linearly unless in the tuple a relative position from the start. To me is too much complexity for something that can be more than manageable in a 256x256 16 colors texture. With that you can even discriminate countries or special zones if you want.

Greetings
Red Knight

Actually, the RLE will be LESS computational work when it comes to choosing a random location on the globe. (Used 5 or 6 times for every UFO mission.)
As opposed to figuring out the country/region of a postion. Used when placing a base.
Saving the world from the scum of the universe is hard work. Especially when you have to create the scum to begin with.

#11 dteviot

dteviot

    Programming Department

  • [Xenocide Senior Members]
  • 1,479 posts

Posted 21 June 2007 - 01:46 PM

You dont need a 2048x2048 texture just to know where to click or not; with 256x256 using a single 8 bits channel is more than enough for the use it will have. Just make sure you do not include the coastline in it.

On the other hand using RLE trade you space for Computation, we have a lot of memory (they even dont have to be in Video Card Memory as the Geoscape one is) but the computation grows linearly unless in the tuple a relative position from the start. To me is too much complexity for something that can be more than manageable in a 256x256 16 colors texture. With that you can even discriminate countries or special zones if you want.

Greetings
Red Knight

Actually, the RLE will be LESS computational work when it comes to choosing a random location on the globe. (Used 5 or 6 times for every UFO mission.)
As opposed to figuring out the country/region of a postion. Used when placing a base.

edit. Although RK is correct, the bitmap doesn't need to be 2048 rows high. Some calcuations I did early suggested 512 is as big as we need. And the width of the rows needs to be no more than twice the height. i.e. a 1024 x 512 bit map is as big as we need. That said, if we RLE the rows, then width is largely irrelevant, as there's no reall difference between (0,10)(1,5)(0,4) and (0,20)(1,10)(0,8)

but the computation grows linearly unless in the tuple a relative position from the start.

That's easy to achieve, conceptually
class Touple { int country, int count }

class Row { Touple[] touples }

class Bitmap { Row[] rows }
So you can jump straight to the wanted row, and then process the row. (e.g. given a Latitude and Longitude, the Latitude is a simple multiply and divide to get the Row, and then you examine the 10 touples in the row.

Of course, a somewhat more efficient struture is
class Touple { int country, int count }
class Bitmap { 
	Touple[] touples 
	int[]  rowIndexes
}
where the rowIndex gives the index to the first touple in each row.
This is more efficient for the random pixel process, because we can skip one of the iterating loops. e.g.
foreach (row)
{
	foreach (touple)
	{
		if (found random pixel)
		{
			 return row, column
		}
	}
}
becomes
foreach (touple)
{
	position += touple.count;
	if (found random pixel)
	{
		 row = position / rowLength;
		 column = position % rowLength;
		 return row, column
	}
}

Edited by dteviot, 21 June 2007 - 02:37 PM.

Saving the world from the scum of the universe is hard work. Especially when you have to create the scum to begin with.

#12 dteviot

dteviot

    Programming Department

  • [Xenocide Senior Members]
  • 1,479 posts

Posted 22 June 2007 - 04:46 PM

Thanks, I will look into that.

One thing about the textures from the other thread, they are huge! Huge compared to the texture we are currently using on the globe... The globe is 640 x 480 while the countries bitmap is 2560 x 2048.

Also the aspect ratios do not match. There would be no reason to use a texture for the bitmaps that is bigger than the texture on the globe, and I think in order for the code getting the right pixel at globe coordinates to work the aspect ratio has to match.

or is there some texture the c++ project was using that was bigger that these are based on ?

Aspect ratios should not be a problem. Remember, we take the bitmap and then map it onto the globe. But the original data is from the globe.
So what happens is the globe is examined, and an image of the globe is projected onto a rectangle. (Usually Mercator projection is used.)
In the Geoscape, we take this rectangle, and project it back onto the globle. So provided the transforms are equivelent, the bitmaps being different should be no problem. That is, provided the relative position of each pixel in the bitmaps map to the same latitude and longitude on the earth, the aspect ratio of the bitmaps is irrelevant. However, if they emply different projections, then you're correct, they can't be used together.

Also, the current bitmap being used to texture the globe was something I found by searching the internet. If you can find a better one (or make a better one) with no copyright limitations, feel free to replace it.
The country and terain textures were created by Pi Masta, using a geophysical database he found. Details are in the thread.
Saving the world from the scum of the universe is hard work. Especially when you have to create the scum to begin with.

#13 Darkside

Darkside

    Sergeant

  • Xenocide Recruit
  • 45 posts

Posted 22 June 2007 - 06:11 PM

Thanks, I will look into that.

One thing about the textures from the other thread, they are huge! Huge compared to the texture we are currently using on the globe... The globe is 640 x 480 while the countries bitmap is 2560 x 2048.

Also the aspect ratios do not match. There would be no reason to use a texture for the bitmaps that is bigger than the texture on the globe, and I think in order for the code getting the right pixel at globe coordinates to work the aspect ratio has to match.

or is there some texture the c++ project was using that was bigger that these are based on ?

Aspect ratios should not be a problem. Remember, we take the bitmap and then map it onto the globe. But the original data is from the globe.
So what happens is the globe is examined, and an image of the globe is projected onto a rectangle. (Usually Mercator projection is used.)
In the Geoscape, we take this rectangle, and project it back onto the globle. So provided the transforms are equivelent, the bitmaps being different should be no problem. That is, provided the relative position of each pixel in the bitmaps map to the same latitude and longitude on the earth, the aspect ratio of the bitmaps is irrelevant. However, if they emply different projections, then you're correct, they can't be used together.

Also, the current bitmap being used to texture the globe was something I found by searching the internet. If you can find a better one (or make a better one) with no copyright limitations, feel free to replace it.
The country and terain textures were created by Pi Masta, using a geophysical database he found. Details are in the thread.


Yeah while I'm running the country picker code I can see it's not lining up too good. It's usable but sometimes you can click off the coast of a country and it will see it as being in the country, or clicking in the country and thinking you're on the water. But it's acceptable for now I guess.

I implemented random coordinate code for country and region based on the algorithms you posted. It's looking good.

Now I'm going to add some cities.

#14 dteviot

dteviot

    Programming Department

  • [Xenocide Senior Members]
  • 1,479 posts

Posted 25 June 2007 - 02:26 PM

The simplest solution to 2 is as follows.

  • Count the number of pixels in the bitmap belonging to the desired country. Call this number K.
  • Now assume we have a function int Random( int n). That given an integer n, will return a randomly selected number between 1 and n, inclusive.
  • Then the following pseudo code will allow us to pick a random pixel belonging to the country.
    i = Kforeach (pixel p in bitmap){	if (p belongs to country)	{	   if (Random(i) == i)	   {			Return location of p	   }	   Else	   {		   --i;	   }	}  }

I'm a total retard. If we know the number of pixels right at the start, we just roll a random number between 1 and the number of pixels, then just count pixels until we reach the one given by the random number generator. No need to generate a random number for every pixel.
Saving the world from the scum of the universe is hard work. Especially when you have to create the scum to begin with.

#15 Darkside

Darkside

    Sergeant

  • Xenocide Recruit
  • 45 posts

Posted 25 June 2007 - 02:32 PM

The simplest solution to 2 is as follows.

  • Count the number of pixels in the bitmap belonging to the desired country. Call this number K.
  • Now assume we have a function int Random( int n). That given an integer n, will return a randomly selected number between 1 and n, inclusive.
  • Then the following pseudo code will allow us to pick a random pixel belonging to the country.
    i = Kforeach (pixel p in bitmap){	if (p belongs to country)	{	   if (Random(i) == i)	   {			Return location of p	   }	   Else	   {		   --i;	   }	}  }

I'm a total retard. If we know the number of pixels right at the start, we just roll a random number between 1 and the number of pixels, then just count pixels until we reach the one given by the random number generator. No need to generate a random number for every pixel.


Yeah that's the way I did it. ;)

#16 Darkhomb

Darkhomb

    Captain

  • Xenocide Artwork Department
  • 628 posts

Posted 28 June 2007 - 08:15 AM

Well the file countries.png was just not the same resolution as the others.
I changed and stretched it to 640x480 to and it fits.


I like that one better it is sharper and more accurate to the original map (more pixel to pixel).

I started making the countries off of the region as well and attached that (pic 4 deff not done yet just throwing it out)

Is the first one fine now that it is stretched or do you want one exactly the same as the region (pixel to pixel)

Edit (third one is the animated).

Attached Files


Edited by Darkhomb, 28 June 2007 - 08:30 AM.


#17 red knight

red knight

    Xenocide Project Leader

  • Xenocide Inactive
  • 3,310 posts

Posted 28 June 2007 - 10:47 AM

Wow that was fast :)

I dont know what the different green colours codify but it would be great to have another one of those to select Urban, Suburban, Rural, Tundra, Desert, Rain Forest, Pine Forest, Mountains; so we can use it to select the map in the battlescape.

Greetings
Red Knight
Sourceforge Nick: flois - Federico Andres Lois
Visit my blog at: flois.blogspot.com

Posted Image

Pookie cover me, I am going in.

#18 Darkside

Darkside

    Sergeant

  • Xenocide Recruit
  • 45 posts

Posted 28 June 2007 - 11:30 AM

Wow that was fast :)

I dont know what the different green colours codify but it would be great to have another one of those to select Urban, Suburban, Rural, Tundra, Desert, Rain Forest, Pine Forest, Mountains; so we can use it to select the map in the battlescape.

Greetings
Red Knight


Well, the way it is written it allows us to easily add more bitmaps, like one for terrain.

All we would need to do, is create a terrain.png to color in the various terrains on the map, then devise an xml section under planets.xml to define all the terrains and give them a unique color on the bitmap, maybe something like:

(under <planet> .... )

<terrains>
<terrain name="Mountain">
<colorKey R="128" G="255" B="64" />
</terrain>
<terrain name="Desert">
<colorKey R="255" G="255" B="0" />
</terrain>
etc...
</terrains>

then the only code changes we need to add would be one line to create a new GeoBitmap object for terrain and then add a function called something like GetTerrainAtPosition (GeoPosition) which simply refers to the GeoBitmap's GetMemberAtPosition function. Would also make the Terrain object to hold it's unique properties. All the hard work is handled universally by GeoBitMap.

So if someone would like to make a terrain bitmap based on these other maps I can go ahead and incorporate it soon after

Edited by Darkside, 28 June 2007 - 11:31 AM.


#19 dteviot

dteviot

    Programming Department

  • [Xenocide Senior Members]
  • 1,479 posts

Posted 28 June 2007 - 01:58 PM

Well the file countries.png was just not the same resolution as the others.
I changed and stretched it to 640x480 to and it fits.


I like that one better it is sharper and more accurate to the original map (more pixel to pixel).

I started making the countries off of the region as well and attached that (pic 4 deff not done yet just throwing it out)

Is the first one fine now that it is stretched or do you want one exactly the same as the region (pixel to pixel)

Edit (third one is the animated).

OK, let me try and explain.
What we're trying to do is when someone clicks on the geoscape, we know the region, country (and eventually terain) of that position.
So, from a Player's perspective, HPC-earth-map.png is "ground truth", and the other two (three) bitmaps must match it.
Note, the bitmaps don't need to have the same scale or aspect ratio, but they do need to correspond.
By that I mean that if you work in relative co-ordiantes (that is, X has a value of 0.0 to 1.0, where 0.0 is the leftmost column and 1.0 is the right most column) then the pixel at X,Y (e.g. 0.35, 0.28) in country.png corresponds to the same pixel at (0.35, 0.28) in HPC-earth-map.png.

I hope that's clear.
Saving the world from the scum of the universe is hard work. Especially when you have to create the scum to begin with.

#20 Darkhomb

Darkhomb

    Captain

  • Xenocide Artwork Department
  • 628 posts

Posted 28 June 2007 - 02:23 PM

I know what you mean, and after i scaled the graphic it matched the earthmap perfectly, see the animated pic i attached.

Edit : The region.png kind of rounded the edges a little. Which is also why I asked if you like the 4th pic better because it matches the region 1/1. Now if you would like the region.png to match the new countries.png I can do that as well

Edited by Darkhomb, 28 June 2007 - 02:28 PM.


#21 dteviot

dteviot

    Programming Department

  • [Xenocide Senior Members]
  • 1,479 posts

Posted 28 June 2007 - 02:44 PM

I know what you mean, and after i scaled the graphic it matched the earthmap perfectly, see the animated pic i attached.

Edit : The region.png kind of rounded the edges a little. Which is also why I asked if you like the 4th pic better because it matches the region 1/1. Now if you would like the region.png to match the new countries.png I can do that as well

Ah, my bad. Thanks for doing that.
And yes, if you'd redo region.png, that would be helpful.
Saving the world from the scum of the universe is hard work. Especially when you have to create the scum to begin with.

#22 Darkhomb

Darkhomb

    Captain

  • Xenocide Artwork Department
  • 628 posts

Posted 28 June 2007 - 04:02 PM

I think this shall do, I removed the overhead from the origional as it really was just clouds




edit: - outdated images

Edited by Darkhomb, 17 August 2007 - 04:18 PM.


#23 dteviot

dteviot

    Programming Department

  • [Xenocide Senior Members]
  • 1,479 posts

Posted 28 June 2007 - 04:05 PM

I think this shall do

Thanks for that.

I is basiclly pixel to pixel of countries though im going to edit the great lakes into countries as well, will attach in here as well

go ahead.


While I remember, best wishes for your surgery.
Saving the world from the scum of the universe is hard work. Especially when you have to create the scum to begin with.

#24 Darkhomb

Darkhomb

    Captain

  • Xenocide Artwork Department
  • 628 posts

Posted 28 June 2007 - 04:12 PM

Done, and thank you

#25 dteviot

dteviot

    Programming Department

  • [Xenocide Senior Members]
  • 1,479 posts

Posted 13 August 2007 - 02:26 PM

OK, I ran into an issue yesterday.
Specifically, I managed to shoot down a UFO over lake superior. No big deal, except that the points I got for shooting it down were not allocated to any region or country. And that's because the lakes are not allocated to any region or country.
So: a quick overveiw. We have 3 bitmaps describing the globe (4 if you include the texture, but that's not used for anything but making the globe look pretty.)
The three bitmaps are:
1. Terrain type (land vs. water)
2. Regions
3. Countries.

The primary purpose of the regions bitmap is to divide the earth into regions, so that alien activity can be assigned to areas in the stats. So X-Corp knows where to go looking for UFOs when radar coverage is incomplete. The upshot of this is that that:
1. Every area of this bitmap must be assigned to a region. There can be no areas that do not belong to a region.
2. It should not distinguish between land and water. e.g. it doesn't show islands in the pacific.
3. The regions bitmap needs to be updated to reflect this. Sorry guys.

Countries is similar to regions, it allows us to map alien activity to countries that fund X-Corp. However, as not everywhere belongs to countries, it's allowable for there to be unassigned areas. That said, lakes SHOULD be marked as part of a country. That is, the bitmap doesn't distinguish between land and water areas belonging to a country.
the countries bitmap needs to be updated to reflect this. Again, my apologies.

Now, one of the problems I've had was using the region map for 2 incompatible roles. One was to figure out the region that owned a position on the globe (correct use.) Other use was to pick a target for a UFO mission. This was wrong (partly) because I wanted a land target, which resulted in the bitmap having water areas masked off, which made it fail the primary function.
So, proposed change. UFO missions will pick a location at random in a Region (which might be a water position.) They will then wander at random, and only land if the position is marked as "land" on the terrain bitmap.

Final point. Current structure of planets.xml assigns cities to countries. However, as cities are only used as randomly chosen terror sites, there is no need for this relationship. Points for cities can be assigned to region and country via location. So I plan on changing this. It will also allow us to add our own favorite cities to Xenocide without needing to assign them to wrong countries.

I hope this is all clear. Please tell me if it isn't
Saving the world from the scum of the universe is hard work. Especially when you have to create the scum to begin with.

#26 SaintD

SaintD

    Captain

  • Xenocide Recruit
  • 195 posts

Posted 14 August 2007 - 01:52 PM

OK, I ran into an issue yesterday.
Specifically, I managed to shoot down a UFO over lake superior. No big deal, except that the points I got for shooting it down were not allocated to any region or country. And that's because the lakes are not allocated to any region or country.
So: a quick overveiw. We have 3 bitmaps describing the globe (4 if you include the texture, but that's not used for anything but making the globe look pretty.)
The three bitmaps are:
1. Terrain type (land vs. water)
2. Regions
3. Countries.

The primary purpose of the regions bitmap is to divide the earth into regions, so that alien activity can be assigned to areas in the stats. So X-Corp knows where to go looking for UFOs when radar coverage is incomplete. The upshot of this is that that:
1. Every area of this bitmap must be assigned to a region. There can be no areas that do not belong to a region.
2. It should not distinguish between land and water. e.g. it doesn't show islands in the pacific.
3. The regions bitmap needs to be updated to reflect this. Sorry guys.

Countries is similar to regions, it allows us to map alien activity to countries that fund X-Corp. However, as not everywhere belongs to countries, it's allowable for there to be unassigned areas. That said, lakes SHOULD be marked as part of a country. That is, the bitmap doesn't distinguish between land and water areas belonging to a country.
the countries bitmap needs to be updated to reflect this. Again, my apologies.

Now, one of the problems I've had was using the region map for 2 incompatible roles. One was to figure out the region that owned a position on the globe (correct use.) Other use was to pick a target for a UFO mission. This was wrong (partly) because I wanted a land target, which resulted in the bitmap having water areas masked off, which made it fail the primary function.
So, proposed change. UFO missions will pick a location at random in a Region (which might be a water position.) They will then wander at random, and only land if the position is marked as "land" on the terrain bitmap.

Final point. Current structure of planets.xml assigns cities to countries. However, as cities are only used as randomly chosen terror sites, there is no need for this relationship. Points for cities can be assigned to region and country via location. So I plan on changing this. It will also allow us to add our own favorite cities to Xenocide without needing to assign them to wrong countries.

I hope this is all clear. Please tell me if it isn't


Sounds great. Questions:
  • Since we are seperating regions from water should regions extend off-shore? I mean, if I shoot down UFOs over the English Channel I would expect to get points in Europe, etc.
  • I don't understand from above post if it's possible to add Hawaii to the North America region. Do the regions have to be contigious? I know in UFO you and the aliens can make bases there.
  • Can we get a higher resolution of the globe skinning photo? The one we have looks crappy when you zoom in.
  • Can we alpha blend a light map into the night side of our earth? http://veimages.gsfc...arth_lights.gif
When we move the cities out of the countries and/or regions we should also make the change from map-coordinates to lat-long. Maybe someone can look up the lat/long for all the cities we want and compile a table for the programmers.

Work is super busy for the next couple weeks, so I can't do much if any coding until we pass this milestone. (yes, it's a lot like passing kidney stones).

-D

edit: missing words, concepts, rambling, etc.

Edited by SaintD, 14 August 2007 - 01:55 PM.


#27 dteviot

dteviot

    Programming Department

  • [Xenocide Senior Members]
  • 1,479 posts

Posted 14 August 2007 - 02:44 PM

Sounds great. Questions:

  • Since we are seperating regions from water should regions extend off-shore? I mean, if I shoot down UFOs over the English Channel I would expect to get points in Europe, etc.

Yes, it makes sense for some regions to include water. Figuring out the boundries may be a bit of a challenge. But we don't need to be perfect.

  • I don't understand from above post if it's possible to add Hawaii to the North America region. Do the regions have to be contigious? I know in UFO you and the aliens can make bases there.

  • I'd count Hawaii as Pacific for region, USA for country. And neither regions or countries need to be contigious.

  • Can we get a higher resolution of the globe skinning photo? The one we have looks crappy when you zoom in.

  • If you can find one, by all means. However, please note that this would probably require the other bitmaps to be redone.

  • Can we alpha blend a light map into the night side of our earth?
    http://veimages.gsfc...arth_lights.gif

  • If you want to, by all means.
    However, if you're going to alpha blend additional data onto the Geoscape, I'd start with more useful information.
    e.g. A colour coded overlay for UFO activity by region, or the radar coverage from your bases.

    When we move the cities out of the countries and/or regions we should also make the change from map-coordinates to lat-long. Maybe someone can look up the lat/long for all the cities we want and compile a table for the programmers.

    I've already changed co-ordinates to lat-long.
    Saving the world from the scum of the universe is hard work. Especially when you have to create the scum to begin with.

    #28 SaintD

    SaintD

      Captain

    • Xenocide Recruit
    • 195 posts

    Posted 14 August 2007 - 07:54 PM

    Patch attached...


    [*]Can we get a higher resolution of the globe skinning photo? The one we have looks crappy when you zoom in.

    If you can find one, by all means. However, please note that this would probably require the other bitmaps to be redone.


    I think I found one that Comes from the same projection. I tested some random shorelines and it seems to line up. We could probably scrap the lowest zoom level and this map will look just fine.


    [/list]When we move the cities out of the countries and/or regions we should also make the change from map-coordinates to lat-long. Maybe someone can look up the lat/long for all the cities we want and compile a table for the programmers.

    I've already changed co-ordinates to lat-long.

    Oh, very cool. I didn't see that update.

    Since I can't program effectively right now I wrote some unit tests.
    I think we have some bugs in the position stuff.

    testRegionRoundTrip(); // gets random regions then checks to see if that pos is in the region. Fails.
    testCountryRoundTrip(); // same thing with countries. Fails
    testLatLongBoundaries(); //What ARE the lat-long upper/lower boundaries? Brasilia co-ordinates crashes when checking if it's under water. The GeoPosition class should enforce the boundaries.
    testMapCoordinates(); //Crawls the map and checks spots for water, regions and countries. We have co-ordinates with no regions. (try putting a base on hawaii to see what I mean) Right now only checks positives numbers, since all negative ones seem to crash.

    I think line 84 of GeoBitMap.cs is faulty. But I can't follow the purpose of the math. Even for some positive Lat/Long combinations it's throwing errors.

    Edit: Removed out of date patch.

    Edited by SaintD, 16 August 2007 - 01:16 PM.


    #29 Darkhomb

    Darkhomb

      Captain

    • Xenocide Artwork Department
    • 628 posts

    Posted 15 August 2007 - 08:01 AM

    Can you attach the map you found? I would like to see it, especially if we have to redo the regions/countries.png

    Also can we only use a 640x480 bitmap, It would look a lot nicer with something bigger I'd think at least 800x600 it isn't that big of a difference in memory usage is it?

    I lost how we were going to be using a 2048x2048 for geoscape detail and then 512x512 for the regions and countries as stated in the beginning of this thread.

    #30 SaintD

    SaintD

      Captain

    • Xenocide Recruit
    • 195 posts

    Posted 15 August 2007 - 02:05 PM

    Can you attach the map you found? I would like to see it, especially if we have to redo the regions/countries.png
    Also can we only use a 640x480 bitmap, It would look a lot nicer with something bigger I'd think at least 800x600 it isn't that big of a difference in memory usage is it?


    The image is in the patch I think. I have also attached a copy of image I am using. I got it off the Nasa "blue marble" page and reduced it to as close as 2048 (the max the program would load) wide as I could get it with MSPAINT. Which is why the slightly strange size.

    I lost how we were going to be using a 2048x2048 for geoscape detail and then 512x512 for the regions and countries as stated in the beginning of this thread.


    The program automatically scales the images. So when you click on the middle of the texture at 2048x2048 it scales it by 1/2 and arrives at the middle of the 512x512 color map. I think this scaling may be responsible for some of the bugs I see with the above tests.

    You can ask the game for a place in Europe, then take that location and ask the game what region it's in. Sometimes it will say "Russia" or another adjacent area.

    Attached Files


    Edited by SaintD, 15 August 2007 - 02:10 PM.


    #31 dteviot

    dteviot

      Programming Department

    • [Xenocide Senior Members]
    • 1,479 posts

    Posted 15 August 2007 - 02:37 PM

    Also can we only use a 640x480 bitmap, It would look a lot nicer with something bigger I'd think at least 800x600 it isn't that big of a difference in memory usage is it?

    I lost how we were going to be using a 2048x2048 for geoscape detail and then 512x512 for the regions and countries as stated in the beginning of this thread.

    No, we are not restricted to 640x480 bitmaps.
    Second point, a 2048 x 2048 bitmap is more detailed than we need. Note that distance around the equator is twice the distance from pole to pole, so bitmap's height only needs to be half the width.

    Since I can't program effectively right now I wrote some unit tests.
    I think we have some bugs in the position stuff.

    testRegionRoundTrip(); // gets random regions then checks to see if that pos is in the region. Fails.
    testCountryRoundTrip(); // same thing with countries. Fails

    hmm. I'll look into these tonight

    testLatLongBoundaries(); //What ARE the lat-long upper/lower boundaries? Brasilia co-ordinates crashes when checking if it's under water. The GeoPosition class should enforce the boundaries.

    The geoposition stores co-ordinates internally in radians. Valid ranges for longitude are plus and minus half pi. Valid ranges for latitude are plus and minus pi.
    And you're quite correct, Geoposition should validate the co-ordinates are always in range.

    testMapCoordinates(); //Crawls the map and checks spots for water, regions and countries. We have co-ordinates with no regions. (try putting a base on hawaii to see what I mean) Right now only checks positives numbers, since all negative ones seem to crash.

    Yes I'm aware there are undefined regions on the regions bitmap. And yes, this needs to be fixed.

    I think line 84 of GeoBitMap.cs is faulty. But I can't follow the purpose of the math. Even for some positive Lat/Long combinations it's throwing errors.

    Well, this part:
    (int)(th + th / (Math.PI / 2) * location.Latitude * -1)
    converts the latitude into the bitmap's Y co-ordinate for that latitude. e.g. +pi/2 is the north pole (Y == 0) and -pi/2 into the (Y == bitmap height)
    The rowindexes[] takes us to first tupple in the array that holds data for that bitmap row.

    I'll look into your patch in more detail tonight.

    Also, I've just realized we've got some more issues.
    • USA/Hawaii is a problem. It was originally assumed that every country would belong to a single region, and the XML schema (and internal representation of countries and regions) reflects this. The minimum work solution is to adjust the bitmap so that Hawaii is no longer a part of the country USA. However, as we intend to allow users to update the bitmaps themselves, there is no way to enforce the constraint. Therefore, only choice I can see is decouple countries from regions, just as cities will be. However, this does raise an interesting point that if Aliens DO build a base on Hawaii, there will be large alien activity counts for the USA, but nothing (or very little) in the North America region. Is this likely to be a problem?
    • Second problem, region bitmap doesn't distinguish between land and water. This becomes a problem when/if we wish to select a random land location in a region. Although the only time we might REALLY need to do this is for alien base building missions. So, possible solutions:
    • Ignore issue. For time being, we will allow Alien bases to be built on water. (We assume they're on a island to small to appear on the map.)
    • Add an additional bitmap, a landed region bitmap. (This will require extra work from ART department.)
    • Generate the landed region bitmap programatically from the regions and terrain bitmaps.) This could either be a stand alone tool, or integrated into mainline code.
    • Programatically generating the landed region bitmap would be simplifed if we combine the existing region and terrain bitmaps into a single bitmap, with region being encoded into color and terrain encoded into the alpha channel. We then provide a mask to say the bits we're interested in.
    In interests of KISS, I recommend option 1 for the time being.

    Saving the world from the scum of the universe is hard work. Especially when you have to create the scum to begin with.

    #32 dteviot

    dteviot

      Programming Department

    • [Xenocide Senior Members]
    • 1,479 posts

    Posted 15 August 2007 - 02:46 PM

    The image is in the patch I think. I have also attached a copy of image I am using. I got it off the Nasa "blue marble" page and reduced it to as close as 2048 (the max the program would load) wide as I could get it with MSPAINT. Which is why the slightly strange size.

    Stupid questions time. Can you please check if we have any copyright issues using this bitmap?

    I lost how we were going to be using a 2048x2048 for geoscape detail and then 512x512 for the regions and countries as stated in the beginning of this thread.


    The program automatically scales the images. So when you click on the middle of the texture at 2048x2048 it scales it by 1/2 and arrives at the middle of the 512x512 color map. I think this scaling may be responsible for some of the bugs I see with the above tests.

    You can ask the game for a place in Europe, then take that location and ask the game what region it's in. Sometimes it will say "Russia" or another adjacent area.

    OK, that should be easy enough to verify, if it returns the a different region, try probing a few pixels to the north, south, east and west, see if the region that is expected turns up.
    Edit: Alternate solution. Texture the globe with the regions bitmap. Then after running the test, put geomarker on globe where results don't match. Are the geomarkers at region boundries?

    Edited by dteviot, 15 August 2007 - 02:48 PM.
    correction.

    Saving the world from the scum of the universe is hard work. Especially when you have to create the scum to begin with.

    #33 SaintD

    SaintD

      Captain

    • Xenocide Recruit
    • 195 posts

    Posted 15 August 2007 - 04:03 PM

    The image is in the patch I think. I have also attached a copy of image I am using. I got it off the Nasa "blue marble" page and reduced it to as close as 2048 (the max the program would load) wide as I could get it with MSPAINT. Which is why the slightly strange size.

    Stupid questions time. Can you please check if we have any copyright issues using this bitmap?

    Not a stupid question by any means. As far as I can tell these images are copyright free.

    from http://earthobservatory.nasa.gov: "The low cost of Landsat 7 data, as well as the elimination of data copyright, has fostered an environment in which users are free to experiment with novel applications, and use large quantities of data for existing applications." (Emphasis mine.)

    Valid ranges for latitude are plus and minus pi.

    Valid ranges on Earth.
    Latitude is -90.0 to +90.0.
    Longitude -180.0 to +180.0

    EDIT: I see where you convert to radians. ToRadians converts degrees to radians, but this seems incorrect since neither Lat nor Long is expressed in degrees.

    public GeoPosition(XPathNavigator node)
    {
    this.longitude = MathHelper.ToRadians(Util.GetFloatAttribute(node, "longitude"));
    this.latitude = MathHelper.ToRadians(Util.GetFloatAttribute(node, "latitude"));
    }


    You have set (for example) Brasilia as <geoposition latitude="-15.87" longitude="-47.92"/>, however according to what you just said pi (-3.141) is the smallest possible latitude. EDIT: Which works, because when you convert to radians you actually get 0.276983751975.
    Since you use earth lat-long in the XML file, the min-max for Lat-long should match Earth coordinates, right? EDIT: I see I am wrong since these lat-long in the class are clearly meant to be radians.
    However, I think we have a faulty conversion from earth lat-long to radian lat-long.

    Edited by SaintD, 15 August 2007 - 04:37 PM.


    #34 SaintD

    SaintD

      Captain

    • Xenocide Recruit
    • 195 posts

    Posted 15 August 2007 - 08:07 PM

    New patch.
    • Streamlined unit tests to report number of failures instead of stopping on each one.
    • Fixed errors in unit tests so they use radian lat long instead of earth based.
    • created GeoPosition constructor that converts from earth coordinates to radian to coordinates.
    • Added a class to contain earth based lat-long coordinates (as opposed to radian lat long) as a helper to GeoPosition
    • added boundary checking code to GeoPosition constructors.
    I am not convinced I have the coordinate system right. I may be testing invalid things from some of the tests.
    Round trips are failing a lot. Either the "get random spot in region/country" is broken (my bet) or "get region/country at position" is.
    The position -Pi,-Pi causes an index out of range exeception when checking terrain type. This should be a valid location.

    A lot of positions between -pi,-pi and pi,pi fail when the terrain type is queried.

    (int)(th + th / (Math.PI / 2) * location.Latitude * -1)
    As far as I can tell this will only give valid results for a range of 0 to about -1.56. (since it's an array with 480 entries).

    Edit: Removed patch since it's out of date.

    Edited by SaintD, 16 August 2007 - 01:15 PM.


    #35 dteviot

    dteviot

      Programming Department

    • [Xenocide Senior Members]
    • 1,479 posts

    Posted 15 August 2007 - 09:41 PM

    A lot of positions between -pi,-pi and pi,pi fail when the terrain type is queried.

    That would be because the valid range for latitude is pi/2 to -pi/2
    it's longitude that is valid from pi to -pi

    (int)(th + th / (Math.PI / 2) * location.Latitude * -1)
    As far as I can tell this will only give valid results for a range of 0 to about -1.56. (since it's an array with 480 entries).

    th is half the bitmap's hight.
    Saving the world from the scum of the universe is hard work. Especially when you have to create the scum to begin with.

    #36 dteviot

    dteviot

      Programming Department

    • [Xenocide Senior Members]
    • 1,479 posts

    Posted 16 August 2007 - 06:47 AM

    I've believe I've figured out why the RoundTrip() unit tests fail.
    It's because this code in GeoBitmap for converting from X, Y bitmap co-ords to a latitude and longitude

    float longitude = (float)(Math.PI * 2 / width * (position%width) - Math.PI);
    float latitude = (float)((Math.PI / height * (position / width) - Math.PI/2) * -1);

    and this code for converting from latitude and longitude to X,Y bitmap co-ords.
    long x		= (int)(tw + tw / Math.PI * location.Longitude);
    int  index	= rowIndexes[(int)(th + th / (Math.PI / 2) * location.Latitude * -1)];
    are not quite exact complements of each other.
    I think the X,Y to longitude is in error, it needs to give the latitude and longitude of the CENTER of the pixel, not the corner of the pixel.
    Saving the world from the scum of the universe is hard work. Especially when you have to create the scum to begin with.

    #37 SaintD

    SaintD

      Captain

    • Xenocide Recruit
    • 195 posts

    Posted 16 August 2007 - 12:52 PM

    Another new patch. Ignore the old ones in this thread.

    A lot of positions between -pi,-pi and pi,pi fail when the terrain type is queried.

    That would be because the valid range for latitude is pi/2 to -pi/2
    it's longitude that is valid from pi to -pi

    Ah, my mistake. That makes sense. I just need to change my conversion for latitude then.


    (int)(th + th / (Math.PI / 2) * location.Latitude * -1)
    As far as I can tell this will only give valid results for a range of 0 to about -1.56. (since it's an array with 480 entries).

    th is half the bitmap's hight.

    I see it now. I was having problems with the order of operations in my head and I translated it wrong. I see how (and that) it works now. My problem with it was that I wasn't converting latitude (mostly) correctly.

    I think I have everything working correctly in the tests and the conversion from earth Lat-long now. Aside from round trip bugs, I found some boundary bugs around the edge of the map.

    I create a GeoPostion(0, (float) Math.Pi /2 * -1) and then check if it's over water. This throws an IndexOutOfRangeException. A latitude of exactly -1.57079637 (negative half pi) causes the index to read 480, which is off by 1 in the 0 based array that has 480 elements. It should be 479.

    -1.57079637 latitude also converts to 180.3901 in the GoePostition.ToString() function. It should round trip to 180.0f

    Attached Files



    #38 dteviot

    dteviot

      Programming Department

    • [Xenocide Senior Members]
    • 1,479 posts

    Posted 16 August 2007 - 01:43 PM

    Another new patch. Ignore the old ones in this thread.

    A lot of positions between -pi,-pi and pi,pi fail when the terrain type is queried.

    That would be because the valid range for latitude is pi/2 to -pi/2
    it's longitude that is valid from pi to -pi

    Ah, my mistake. That makes sense. I just need to change my conversion for latitude then.


    (int)(th + th / (Math.PI / 2) * location.Latitude * -1)
    As far as I can tell this will only give valid results for a range of 0 to about -1.56. (since it's an array with 480 entries).

    th is half the bitmap's hight.

    I see it now. I was having problems with the order of operations in my head and I translated it wrong. I see how (and that) it works now. My problem with it was that I wasn't converting latitude (mostly) correctly.

    I think I have everything working correctly in the tests and the conversion from earth Lat-long now. Aside from round trip bugs, I found some boundary bugs around the edge of the map.

    I fixed that up when I checked in your patch last night.


    I create a GeoPostion(0, (float) Math.Pi /2 * -1) and then check if it's over water. This throws an IndexOutOfRangeException. A latitude of exactly -1.57079637 (negative half pi) causes the index to read 480, which is off by 1 in the 0 based array that has 480 elements. It should be 479.

    Yes, I saw that in your unit tests, and fixed that also.
    So thanks for that test.

    -1.57079637 latitude also converts to 180.3901 in the GoePostition.ToString() function. It should round trip to 180.0f

    Nope. pi/2 is 1.57079632679 not -.57079637
    Saving the world from the scum of the universe is hard work. Especially when you have to create the scum to begin with.

    #39 SaintD

    SaintD

      Captain

    • Xenocide Recruit
    • 195 posts

    Posted 16 August 2007 - 01:43 PM

    I've believe I've figured out why the RoundTrip() unit tests fail.
    It's because this code in GeoBitmap for converting from X, Y bitmap co-ords to a latitude and longitude

    float longitude = (float)(Math.PI * 2 / width * (position%width) - Math.PI);
    float latitude = (float)((Math.PI / height * (position / width) - Math.PI/2) * -1);

    and this code for converting from latitude and longitude to X,Y bitmap co-ords.
    long x		= (int)(tw + tw / Math.PI * location.Longitude);
    int  index	= rowIndexes[(int)(th + th / (Math.PI / 2) * location.Latitude * -1)];
    are not quite exact complements of each other.
    I think the X,Y to longitude is in error, it needs to give the latitude and longitude of the CENTER of the pixel, not the corner of the pixel.


    Some slop is OK. It's probably not really a bug if a few scattered pixels at the edges don't quite work out, but in my tests I am seeing about 70% of region round trips fail and 70% of country round trips. So it's more than just a little off.

    #40 SaintD

    SaintD

      Captain

    • Xenocide Recruit
    • 195 posts

    Posted 16 August 2007 - 02:43 PM

    Nope. pi/2 is 1.57079632679 not -.57079637



    (float) (Math.PI /2) = 1.57079637
    (double) (Math.Pi /2) = 1.5707963267948966


    the constructor is

    public GeoPosition(float longitude, float latitude)

    thus my rounding error.

    So I think we need to work in doubles or, account for this rounding error.

    -D

    #41 dteviot

    dteviot

      Programming Department

    • [Xenocide Senior Members]
    • 1,479 posts

    Posted 16 August 2007 - 05:08 PM

    I've believe I've figured out why the RoundTrip() unit tests fail.
    It's because this code in GeoBitmap for converting from X, Y bitmap co-ords to a latitude and longitude

    float longitude = (float)(Math.PI * 2 / width * (position%width) - Math.PI);
    float latitude = (float)((Math.PI / height * (position / width) - Math.PI/2) * -1);

    and this code for converting from latitude and longitude to X,Y bitmap co-ords.
    long x		= (int)(tw + tw / Math.PI * location.Longitude);
    int  index	= rowIndexes[(int)(th + th / (Math.PI / 2) * location.Latitude * -1)];
    are not quite exact complements of each other.
    I think the X,Y to longitude is in error, it needs to give the latitude and longitude of the CENTER of the pixel, not the corner of the pixel.


    Some slop is OK. It's probably not really a bug if a few scattered pixels at the edges don't quite work out, but in my tests I am seeing about 70% of region round trips fail and 70% of country round trips. So it's more than just a little off.

    I'll be looking into this tonight, I'm pretty sure I can fix it.
    Saving the world from the scum of the universe is hard work. Especially when you have to create the scum to begin with.

    #42 Darkhomb

    Darkhomb

      Captain

    • Xenocide Artwork Department
    • 628 posts

    Posted 16 August 2007 - 05:25 PM

    Don't know which you like better but this is Blue marble (2nd Generation) (June edition) (More detail), I decreased it to 2700x1350, images are compressed to 300k jpegs for download, I will upload png's if you like them.

    2ndly would it be possible to use a bump map (very little bumping) to give the planet elevation? I attached an elevation map that fits, I think it would look cool.

    Attached Files


    Edited by Darkhomb, 16 August 2007 - 05:28 PM.


    #43 dteviot

    dteviot

      Programming Department

    • [Xenocide Senior Members]
    • 1,479 posts

    Posted 16 August 2007 - 11:55 PM

    Don't know which you like better but this is Blue marble (2nd Generation) (June edition) (More detail), I decreased it to 2700x1350, images are compressed to 300k jpegs for download, I will upload png's if you like them.

    .jpg give best compressions for photographic textures.
    You need to use .png for the country, region and terrain bitmaps however, because .jpg may alter the colors as part of the compression.
    At moment, changing the texture we use for the globe isn't a big problem. If you've got C# express installed, just drop the bitmap into the content\textures directory and build. IIRC, XNA then converts it into a .xnb file. And you should be able to just drop that over whatever existing .xnb file you have.

    So, Mad, would you make up .xnb files from the various bitmaps, and post them up so people can try them out and see which look nicest?

    2ndly would it be possible to use a bump map (very little bumping) to give the planet elevation? I attached an elevation map that fits, I think it would look cool.

    It's almost certainly possible to add a bump map to the sphere. I'm pretty sure I saw a section in one of my XNA books on how to do it, but I've been so busy writing the basic engine, I haven't had time to read them to find out how to do advanced XNA graphics.
    However, at the moment, my focus is on getting the features into the game, rather than polishing the graphics.
    ToDo list:
    1. Fix problems found by SaintD.
    2. Terror, Base, Supply, Retatiation UFO missions.
    3. Buy/Sell Enginers & Scientists.
    4. Transfer supplies between bases.
    5. Research & Manufacturing.
    6. Christmas.

    However, if anyone else wants to add bumpmapping, feel free.

    1.57079637 latitude also converts to 180.3901 in the GoePostition.ToString() function

    Something funny here.
    180.3901 = 1.5742 radians

    edit: minor correctoin

    Edited by dteviot, 16 August 2007 - 11:57 PM.

    Saving the world from the scum of the universe is hard work. Especially when you have to create the scum to begin with.

    #44 dteviot

    dteviot

      Programming Department

    • [Xenocide Senior Members]
    • 1,479 posts

    Posted 17 August 2007 - 05:52 AM

    Problem reported by SaintD (Round Trips not working) was because GetRandomCoord() was returning the latitiude and longitude of the top right corner of the selected pixel. These co-ordinates are shared with 3 other pixels. And when GeoBitmap.GetPropertyIndexOfLocation() resolves the lat and long, it assumed they were for the bottom left corner of the pixel. Thus, when the random selection picked a pixel on the top or left border of an area, the round trip would fail.

    Fix has been checked into SVN.
    Saving the world from the scum of the universe is hard work. Especially when you have to create the scum to begin with.

    #45 Mad

    Mad

      Creative Text Department

    • [Xenocide Senior Members]
    • 1,958 posts

    Posted 17 August 2007 - 06:27 AM

    So, Mad, would you make up .xnb files from the various bitmaps, and post them up so people can try them out and see which look nicest?

    I'm not 100% positive I'll succeed, but I'll surely give it a try and post the result in here. :)
    Keep smiling while dying

    Of course I have gone mad with power! It would be completely ridiculous to go mad without power!
    And no, this is not a quote from the Simpson's movie, I want it on paper, that I actually wrote that quite some time before the movie came out.

    Posted Image

    #46 Darkhomb

    Darkhomb

      Captain

    • Xenocide Artwork Department
    • 628 posts

    Posted 17 August 2007 - 07:08 AM

    Ok, I am almost done with the terrain. Does everyone like that Geo I posted?

    How does the compression work with graphics memory, is a 2700x1350 jpg using the same video memory as a 2700x1350 png? (I know its compressed on disk, I don't know how it is in memory)If it is do you like that resolution 2700x1350, since it is only 300k I could put a 5400x2700 for more detail.

    2 - so what res for the terrain region and countries would be good enough? The smallest whole resolution is 1350x675, is this too big? Next smallest is 675x337.5 can I just make it 675x338 if you want it smaller? Don't know is that makes a diffrence

    I should have the terrain.png done tonight and next will be regions which should not take too long once terrain is done. Countries will take the longest.





    So by the time we are done should have

    GeoScape.jpg (2700x1350) 300k or if you want (5400x2700) Should be Around 600k compressed
    Terrain.png (1350x675) (675x338)
    Region.png (1350x675) (675x338)
    Countries.png (1350x675) (675x338)
    Elevation.png [Bump Map] (2700x1350) or (1350x675)? Don't know how detailed bump needs to be
    Nightlights.png [Spec Map] (2700x1350) or (1350x675)? Don't know how detailed spec needs to be



    ----
    Edit my job got easier, turns out the old regions and countries were actually resized and stretched to 640x480, they fit this map pretty good. I will finish them later but these are good enough to be put into the release as they are (With the new geo posted above), they will line up much better then they were and I'll modify them to what you wanted as stated earlier but just for now here they are.

    1350x675 (First is animated with all textures so you can see how they line up)

    edit pngs removed as they are updated in newer posts

    Attached Files

    • Attached File  All.gif   296.25K   15 downloads

    Edited by Darkhomb, 17 August 2007 - 04:16 PM.


    #47 Darkhomb

    Darkhomb

      Captain

    • Xenocide Artwork Department
    • 628 posts

    Posted 17 August 2007 - 08:36 AM

    Now by going off what you said about regions, I am hoping I understood correctly. basicly coastlines and water are still part of that region, islands do not count, and I can basiclly round everything off?

    Kind of like this?

    Attached Files



    #48 Mad

    Mad

      Creative Text Department

    • [Xenocide Senior Members]
    • 1,958 posts

    Posted 17 August 2007 - 10:17 AM

    Ok, This depends on the memory usage predictions and requirements of PRG, but I would enjoy a higher (5400x2700) resolution!

    Anyway, here is the 2700x1350 Geoscape .xnb, but it doesn't pass all the unit tests.

    Edited by Mad, 17 August 2007 - 10:35 AM.

    Keep smiling while dying

    Of course I have gone mad with power! It would be completely ridiculous to go mad without power!
    And no, this is not a quote from the Simpson's movie, I want it on paper, that I actually wrote that quite some time before the movie came out.

    Posted Image

    #49 red knight

    red knight

      Xenocide Project Leader

    • Xenocide Inactive
    • 3,310 posts

    Posted 17 August 2007 - 10:34 AM

    Ok, I am almost done with the terrain. Does everyone like that Geo I posted?

    How does the compression work with graphics memory, is a 2700x1350 jpg using the same video memory as a 2700x1350 png? (I know its compressed on disk, I don't know how it is in memory)If it is do you like that resolution 2700x1350, since it is only 300k I could put a 5400x2700 for more detail.

    2 - so what res for the terrain region and countries would be good enough? The smallest whole resolution is 1350x675, is this too big? Next smallest is 675x337.5 can I just make it 675x338 if you want it smaller? Don't know is that makes a diffrence

    I should have the terrain.png done tonight and next will be regions which should not take too long once terrain is done. Countries will take the longest.

    So by the time we are done should have

    GeoScape.jpg (2700x1350) 300k or if you want (5400x2700) Should be Around 600k compressed
    Terrain.png (1350x675) (675x338)
    Region.png (1350x675) (675x338)
    Countries.png (1350x675) (675x338)
    Elevation.png [Bump Map] (2700x1350) or (1350x675)? Don't know how detailed bump needs to be
    Nightlights.png [Spec Map] (2700x1350) or (1350x675)? Don't know how detailed spec needs to be


    5400x2700 at 3 bytes per pixel (RGB) = 47 Mb of video memory (quite too much), there are Wavelets techniques to do it in such a way that you have as much detail as you need and do not kill the video card in the process when you have all the globe visible. However it doesnt need to be done in that way at least someone have an streaming wavelet library that does that on the fly (theorically posible, hard to implement).

    For assets use PGN instead of JPG because in the end you will get the same memory usage but PNG is a loseless compression method, while JPG isnt. So you are only trading hard disk space in that way (HD is "free" today).

    Greetings
    Red Knight
    Sourceforge Nick: flois - Federico Andres Lois
    Visit my blog at: flois.blogspot.com

    Posted Image

    Pookie cover me, I am going in.

    #50 SaintD

    SaintD

      Captain

    • Xenocide Recruit
    • 195 posts

    Posted 17 August 2007 - 01:42 PM

    5400x2700 at 3 bytes per pixel (RGB) = 47 Mb of video memory (quite too much)


    When running the application with the new files (exception terrain.png, see next comment) the program has a footprint of about 46,000K. Similar to MS-Word, Outlook, and other fairly heavy applications. I don't think this is out of line for a game with a 3D interface.

    I am seeing ~60FPS on a moderately powerful machine. 3.0Mhz dual proc with a RADEON 9600 graphics card. This while running Word, powerpoint, Outlook, Visual Studio and some other programs.



    Terrain.png (1350x675) (675x338)


    Terrain.png has some wrong pixels. The green is not consitently the color defined in the XML. Xenoicide detects this on load.

    <terrain name="land">
    <colorKey R="32" G="192" B="0" />
    </terrain>


    I also think regions still has some invalid pixels as well. Xenocide should probably set the flag to error on invalid colors when loading this file as well.