Jump to content


Photo

Xna Pr 0.1.x Bugs


  • Please log in to reply
36 replies to this topic

#1 dteviot

dteviot

    Programming Department

  • [Xenocide Senior Members]
  • 1479 posts

Posted 05 September 2007 - 02:34 PM

Yes, I know we have a bug tracker, but I thought I'd set up this thread to record bugs initially.

I get an error in XNet when I click on an certain entries..
For instance Alien Navigation Systems, Plasma Principles -

edit wrong pic

Ditto (that is, exactly the same problem here).

Fixed.


There are some other "bugs" that I've found (you probably know them, but I don't know if you do :P):
1) The buttons can be pressed even in the xeno-window is out of focus and behind another active window

A few more details please, exactly which windows & buttons are you referring to?

I think this isn't a bug, it's because XNA uses direct input, so it's always aware of the mouse, even when Xenocide doesn't have the focus.

2) Time runs while you're reading the X-Net (I forgot to check if this also happens in baseview, although my guess is that it does)

OK, I'll look into that. (Not sure how that happened.)

Fixed.

3) Your fighters can attacked a crashed UFO! A new firing circle begins until the first hit, where the ufo either crashes (an already crashed ship crashes, kewl xD) or gets destroyed. You can redo this procedure until you completely destroy it

That's not a bug. That's an additional feature I added.
More specifically, fighters being able to attack a crashed UFO is not a bug, that's a feature I added.
The fact that a crashed UFO crashes again (before it takes off) probably does count as a bug. If you attack a crashed UFO, combat should continue until UFO or aircraft is destroyed or runs out of ammo.
Note, if you don't attack a crashed UFO, it will eventually fly off. But I'd assumed that it repairs would be jury rigged, so if you attacked it again, it wouldn't take much to make it crash.

4) Fighters can attack terror sites and salvage artefacts :S

Lockout needs to be implemented. However, it's contingent on some refactoring I also want to do

fixed.

Btw, something strange happened 2 mins ago while I was taking screenshots: I moved around the globe, and all of a sudden the whole globe render (all the left part of the xeno window) turned blue!!! I couldn't do anything else, I entered the X-Net and returned but it was still the same. I abandoned the game and started a new one, same render. I tried to put a new base, and an error poped up (3rd image) and of course crashed. Restarted the game and everything worked well. It MAY be due to running it from within a .rar archive, but it happened as I was happily moving the globe around, don't know...


Fixed.

edit: Updated some of the bugs.

Edited by dteviot, 17 September 2007 - 01:32 PM.

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

#2 kafros

kafros

    Creative Text Department

  • Xenocide Creative-Text Departmen
  • 1800 posts

Posted 06 September 2007 - 09:00 AM

May I add another "irritating" bug?

At the save dialog, if you try to save a game but you haven't written a name, the game crashes!

I call it "irritating", because I tried to save a game after spending ~10 mins in order to research everything (I was checking something) and the aforementioned situation occured <_< ^_^


In addition, could you make the enter key close any "OK-Dialog" just like you did with the "Add your first base" one? That would be useful!!

Edited by kafros, 06 September 2007 - 01:21 PM.


#3 dteviot

dteviot

    Programming Department

  • [Xenocide Senior Members]
  • 1479 posts

Posted 06 September 2007 - 01:59 PM

May I add another "irritating" bug?

At the save dialog, if you try to save a game but you haven't written a name, the game crashes!

I call it "irritating", because I tried to save a game after spending ~10 mins in order to research everything (I was checking something) and the aforementioned situation occured <_< ^_^

Fixed.

In addition, could you make the enter key close any "OK-Dialog" just like you did with the "Add your first base" one? That would be useful!!

SaintD is (was?) looking into this.

Edited by dteviot, 10 September 2007 - 02:15 PM.
Update bug status

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

#4 SaintD

SaintD

    Captain

  • Xenocide Recruit
  • 195 posts

Posted 06 September 2007 - 03:13 PM

In addition, could you make the enter key close any "OK-Dialog" just like you did with the "Add your first base" one? That would be useful!!
SaintD is (was?) looking into this.


I spent a few days on this actually. The Add First base is easy because the text dialog has focus, so I can trap the keystrokes and scan for enter. The other dialogs don't have focus when they pop up. The main windows still has the focus. I tried various ways of changing focus and/or capturing the input, but unless I clicked the dialog with the mouse first, I was unsucessful.

I am sure it's possible, but it doesn't work at all like windows.forms does and that's what I am used to. I may look into again in the future. It might be possible to hook deeper in the object graph and capture those inputs.

Also, work got really busy so I haven't had as much time to spend on Xenocide. :P

-D

#5 Darkhomb

Darkhomb

    Captain

  • Xenocide Artwork Department
  • 628 posts

Posted 15 September 2007 - 11:07 AM

I wouldn't call this a bug but my laptop didn't have the driver for audio installed and I wanted to try xenocide on it. It crashes because it can't init the audio driver. Don't know if we want it to ignore this so game is still usable with out a soundcard.

#6 kafros

kafros

    Creative Text Department

  • Xenocide Creative-Text Departmen
  • 1800 posts

Posted 15 September 2007 - 05:20 PM

I wouldn't call this a bug but my laptop didn't have the driver for audio installed and I wanted to try xenocide on it. It crashes because it can't init the audio driver. Don't know if we want it to ignore this so game is still usable with out a soundcard.

I guess they use a "NullAudio" device for that purpose, tricking the software into thinking that it communicates with a real sound card

#7 taz0k

taz0k

    Sergeant

  • Xenocide Recruit
  • 17 posts

Posted 16 September 2007 - 02:28 AM

I've found the source of blue screen bug, but I haven't tried to find a solution yet as I don't exactly understand the code in the particular function (GeoPosition.GetAzimuth) in which the source of the bug resides. Someone with more knowledge please check it out.


The problem is that Math.Sin(d) inside the outer else statement in GeoPosition.GetAzimuth(GeoPosition position) can become ZERO,
which causes "maker" some lines later to become NaN in the statement:

float maker = (float)((Math.Sin(position.latitude) - Math.Sin(latitude) * Math.Cos(d)) / (Math.Sin(d) * Math.Cos(latitude)));


d is calculated as:

float d = (float)(2.0f*Math.Asin(Math.Sqrt(
(Math.Sin((latitude-position.latitude)/2.0f))*(Math.Sin((latitude-position.latitude)/2.0f)) +
Math.Cos(latitude)*Math.Cos(position.latitude)
*(Math.Sin((longitude-position.longitude)/2))*(Math.Sin((longitude-position.longitude)/2))
)));

Yes, this assignment is the part that I don't understand, so I am not the best candidate to actually solve the bug.

#8 taz0k

taz0k

    Sergeant

  • Xenocide Recruit
  • 17 posts

Posted 16 September 2007 - 11:15 AM

Problem solved. Darkhomb tipped me to set the divisor to a low number, so I set it to 0.0000001f.

After that modification I managed to trigger the same "situation" again (the situation that triggered blue screen before) and I didn't notice any oddities, so it seems to be working.

Patch posted under patch topic.

#9 dteviot

dteviot

    Programming Department

  • [Xenocide Senior Members]
  • 1479 posts

Posted 16 September 2007 - 10:42 PM

I've found the source of blue screen bug, but I haven't tried to find a solution yet as I don't exactly understand the code in the particular function (GeoPosition.GetAzimuth) in which the source of the bug resides. Someone with more knowledge please check it out.


The problem is that Math.Sin(d) inside the outer else statement in GeoPosition.GetAzimuth(GeoPosition position) can become ZERO,
which causes "maker" some lines later to become NaN in the statement:

float maker = (float)((Math.Sin(position.latitude) - Math.Sin(latitude) * Math.Cos(d)) / (Math.Sin(d) * Math.Cos(latitude)));


d is calculated as:

float d = (float)(2.0f*Math.Asin(Math.Sqrt(
(Math.Sin((latitude-position.latitude)/2.0f))*(Math.Sin((latitude-position.latitude)/2.0f)) +
Math.Cos(latitude)*Math.Cos(position.latitude)
*(Math.Sin((longitude-position.longitude)/2))*(Math.Sin((longitude-position.longitude)/2))
)));

Yes, this assignment is the part that I don't understand, so I am not the best candidate to actually solve the bug.

Well, d is the distance between the two positions.
And the purpose of GetAzimuth() is to give the heading between to points.
That is, what compass direction do you need take to get from this to the position that was provided.
Now, thinking a bit more, sin(d) = 0 under two conditions.
d = 0, and d = 180 degrees
Obviously, when d = 0, there is no unique solution, because your start and end position are the same. So any direction will do.
And when d = 180, then the two points are at opposite ends of the earth, e.g. North and South poles. So again, any direction will do.

So, correct solution is: if sin(d) is very close to 0, return 0. (Any bearing will do.)
Should be possible to confirm this is the error, by setting up a unit test with a GeoPosition calling GetAzimuth on itself. When point is NOT at the north or south poles, as they're already special cases, with their own handling.
Saving the world from the scum of the universe is hard work. Especially when you have to create the scum to begin with.

#10 dteviot

dteviot

    Programming Department

  • [Xenocide Senior Members]
  • 1479 posts

Posted 17 September 2007 - 01:39 PM

3) Your fighters can attacked a crashed UFO! A new firing circle begins until the first hit, where the ufo either crashes (an already crashed ship crashes, kewl xD) or gets destroyed. You can redo this procedure until you completely destroy it

That's not a bug. That's an additional feature I added.

More specifically, fighters being able to attack a crashed UFO is not a bug, that's a feature I added.
The fact that a crashed UFO crashes again (before it takes off) probably does count as a bug. If you attack a crashed UFO, combat should continue until UFO or aircraft is destroyed or runs out of ammo.
Note, if you don't attack a crashed UFO, it will eventually fly off. But I'd assumed that it repairs would be jury rigged, so if you attacked it again, it wouldn't take much to make it crash.

I wouldn't call this a bug but my laptop didn't have the driver for audio installed and I wanted to try xenocide on it. It crashes because it can't init the audio driver. Don't know if we want it to ignore this so game is still usable with out a soundcard.

Yes, that's a bug. However, I think it's going to be a very rare one, and I can't see any solution that is small and non-complicated and efficient (Pick any two.) So I'm going to put this on the list of "bugs I'm not going to fix". That said, if people feel it's going to be common I'll revise the decision. And of course, if anyone wants to try and find an elegant solution, as always, they're free to try.
Saving the world from the scum of the universe is hard work. Especially when you have to create the scum to begin with.

#11 red knight

red knight

    Xenocide Project Leader

  • Xenocide Inactive
  • 3310 posts

Posted 17 September 2007 - 01:49 PM

The solution for that is adding that into the MSI installer to make sure it doesnt install at all... for now that should be kept in the "Known Issues" category. What should be done is throw a SoundEngineException when the Sound Engine cannot initialize.

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.

#12 dteviot

dteviot

    Programming Department

  • [Xenocide Senior Members]
  • 1479 posts

Posted 17 September 2007 - 02:14 PM

The solution for that is adding that into the MSI installer to make sure it doesnt install at all... for now that should be kept in the "Known Issues" category. What should be done is throw a SoundEngineException when the Sound Engine cannot initialize.

Greetings
Red Knight

Actually, I think it does throw an error if it can't initialize. However, the exception isn't caught, and the game exits. (Which does look like a crash to the average user.)
Saving the world from the scum of the universe is hard work. Especially when you have to create the scum to begin with.

#13 red knight

red knight

    Xenocide Project Leader

  • Xenocide Inactive
  • 3310 posts

Posted 18 September 2007 - 05:54 AM

Then we are done :)

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.

#14 SupSuper

SupSuper

    Programming Department

  • Xenocide Programming Department
  • 2418 posts

Posted 29 September 2007 - 04:32 PM

Figured I'd post this here: There's a bug with craft handling.

For once, in the Sell screen, the game seems to count every CraftType to show the quantity of any one Craft. (eg. having 2 Gryphon-1 and 2 Gryphon-2)

For second, even after selling one Gryphon, you can't dismantle any of the landing pads. Sell 2, and you can dismantle one. Sell all the craft, and you can dismantle all the landing pads.

too bad, now you will never know the ancient secrets of supsupers long gone avatar ;)

Posted Image

Posted Image

#15 dteviot

dteviot

    Programming Department

  • [Xenocide Senior Members]
  • 1479 posts

Posted 29 September 2007 - 11:55 PM

Figured I'd post this here: There's a bug with craft handling.

For once, in the Sell screen, the game seems to count every CraftType to show the quantity of any one Craft. (eg. having 2 Gryphon-1 and 2 Gryphon-2)

That's not a bug. You've got 2 items of type "Gryphon"
It's a bit more useful when it comes to soldiers and the like, when it's not so easy to know how many you have.

For second, even after selling one Gryphon, you can't dismantle any of the landing pads. Sell 2, and you can dismantle one. Sell all the craft, and you can dismantle all the landing pads.

That sounds like a bug.
Saving the world from the scum of the universe is hard work. Especially when you have to create the scum to begin with.

#16 dteviot

dteviot

    Programming Department

  • [Xenocide Senior Members]
  • 1479 posts

Posted 30 September 2007 - 10:12 PM

Figured I'd post this here: There's a bug with craft handling.
For second, even after selling one Gryphon, you can't dismantle any of the landing pads. Sell 2, and you can dismantle one. Sell all the craft, and you can dismantle all the landing pads.

That sounds like a bug.

That was a bug. It's now fixed.
Saving the world from the scum of the universe is hard work. Especially when you have to create the scum to begin with.

#17 Darkhomb

Darkhomb

    Captain

  • Xenocide Artwork Department
  • 628 posts

Posted 02 January 2008 - 04:42 PM

Rare equip soldier blue screen bug that seems to happen to me only. I have narrowed it down to the changes in rev 1765. No problems closing in 1764.

Further inspection, I updated to 1765 and reverted EquipSoldierScreen back to 1764, again works fine.

The only code difference is this.
/// Removes the frame from the display
		/// </summary>
		protected override void Dispose(bool disposing)
		{
			if (disposing)
			{
				if (scene != null)
				{
					scene.Dispose();
					scene = null;
				}
			}
			base.Dispose(disposing);
		}

		/// <summary>

And just to test, I updated to latest version (1781) and took out that code. Works fine. Curious why it works for everyone else.

Edited by Darkhomb, 02 January 2008 - 04:44 PM.


#18 red knight

red knight

    Xenocide Project Leader

  • Xenocide Inactive
  • 3310 posts

Posted 02 January 2008 - 04:48 PM

Rare equip soldier blue screen bug that seems to happen to me only. I have narrowed it down to the changes in rev 1765. No problems closing in 1764.

Further inspection, I updated to 1765 and reverted EquipSoldierScreen back to 1764, again works fine.

The only code difference is this.

/// Removes the frame from the display
		/// </summary>
		protected override void Dispose(bool disposing)
		{
			if (disposing)
			{
				if (scene != null)
				{
					scene.Dispose();
					scene = null;
				}
			}
			base.Dispose(disposing);
		}

		/// <summary>

And just to test, I updated to latest version (1781) and took out that code. Works fine. Curious why it works for everyone else.


Make sure that the dispose methods isnt been called multiple times; with that you will narrow its scope. And see what happens if you take out the scene=null or scene.Dispose and combinations of those 2.

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.

#19 Darkhomb

Darkhomb

    Captain

  • Xenocide Artwork Department
  • 628 posts

Posted 02 January 2008 - 04:50 PM

Bluescreen is I take out scene = null;

works if I take out scene.Dispose();



#20 red knight

red knight

    Xenocide Project Leader

  • Xenocide Inactive
  • 3310 posts

Posted 02 January 2008 - 04:52 PM

Sounds like the dispose is unregistering the screen while it is still in use... mhhh interesting. Post a Call Stack when it gets called :) ... you can get it putting a breakpoint and copying the Call Stack window into notepad :)

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.

#21 dteviot

dteviot

    Programming Department

  • [Xenocide Senior Members]
  • 1479 posts

Posted 02 January 2008 - 05:49 PM

Sounds like the dispose is unregistering the screen while it is still in use... mhhh interesting. Post a Call Stack when it gets called :) ... you can get it putting a breakpoint and copying the Call Stack window into notepad :)

Greetings
Red Knight

What it tells me is that the problem is in EquipSoldierScene.Dispose()
looking at the code,
/// <summary>
		/// Implement IDisposable
		/// </summary>
		/// <param name="disposing">false when called from a finalizer</param>
		protected virtual void Dispose(bool disposing)
		{
			if (disposing)
			{
				if (spriteBatch != null)
				{
					spriteBatch.Dispose();
					spriteBatch = null;
				}
				if (content != null)
				{
					content.Dispose();
					content = null;
				}
			}
		}
I'll bet 2 hours of sleep tonight the culprit is this bit:
if (content != null)
				{
					content.Dispose();
					content = null;
				}
Darkhomb, if you can confirm that removing these lines makes the bluescreen go away, I believe I know how to properly fix the problem.
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 02 January 2008 - 06:04 PM

didnt work, i have to go thought will try tomorrow.

#23 dteviot

dteviot

    Programming Department

  • [Xenocide Senior Members]
  • 1479 posts

Posted 02 January 2008 - 09:20 PM

didnt work, i have to go thought will try tomorrow.

Scratches head.
Well, see if removing
if (spriteBatch != null)
				{
					spriteBatch.Dispose();
					spriteBatch = null;
				}
works. (If should do, it's the only other code in the function.)
If it doesn't, then remove all code from inside the function. Just to confirm we ARE in the right place.
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 03 January 2008 - 12:45 PM

I put back the other part and removed this only, it now works.

if (spriteBatch != null)
				{
					spriteBatch.Dispose();
					spriteBatch = null;
				}


I just tried latest build on my laptop (vista x64) and it works fine. I have no clue why this is not working on mine.

Edited by Darkhomb, 03 January 2008 - 02:31 PM.


#25 dteviot

dteviot

    Programming Department

  • [Xenocide Senior Members]
  • 1479 posts

Posted 11 January 2008 - 11:33 PM

Next thing to try for Darkhomb's blue screen problem with Equip Soldier screen.
Want to find out if the dispose is killing CeGui, or the entire graphics system.
Not easy to tell, because closing Equip Soldier Screen returns to the Soldier List screen, which is purely CeGUI.
So, solution is modify EquipSoldierScreen so on close button, it disposes of things, then creates a new EquipSoldierScreen.
change line in Xenocide\Source\UI\Screens\EquipSoldierScreen.cs
from:
ScreenManager.ScheduleScreen(new SoldiersListScreen(SelectedOutpostIndex()));
to
ScreenManager.ScheduleScreen(new EquipSoldierScreen(soldiers, Soldier));
When close is pressed, does the whole screen go blue, or is it just the buttons that are lost?

Another thing to check, after blue screen occurs, see if EquipSoldierScreen.Draw() is being pumped.
Probably easiest way of doing this is once blue screen occurs, put a breakpoint on first line of Draw() function, and see if execution stops at breakpoint.

Edited by dteviot, 11 January 2008 - 11:36 PM.

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

#26 Darkhomb

Darkhomb

    Captain

  • Xenocide Artwork Department
  • 628 posts

Posted 11 January 2008 - 11:59 PM

Ok when I change that, it works how it should, i see everything. I know it redraws the screen because the font problem I told you about earlier (loses a line when clicked). RK had me put some breakpoints in places I don't remember how far we got though.

#27 dteviot

dteviot

    Programming Department

  • [Xenocide Senior Members]
  • 1479 posts

Posted 12 January 2008 - 11:37 PM

Ok when I change that, it works how it should, i see everything. I know it redraws the screen because the font problem I told you about earlier (loses a line when clicked). RK had me put some breakpoints in places I don't remember how far we got though.

Scratches head. That's weird. If theory is correct, we should either loose the buttons, or the whole screen.
With latest build 1788, StatisticsScreen disposes of it's sprite batch. What happens when that screen is closed?
Saving the world from the scum of the universe is hard work. Especially when you have to create the scum to begin with.

#28 Darkhomb

Darkhomb

    Captain

  • Xenocide Artwork Department
  • 628 posts

Posted 12 January 2008 - 11:40 PM

Works fine.

#29 dteviot

dteviot

    Programming Department

  • [Xenocide Senior Members]
  • 1479 posts

Posted 13 January 2008 - 02:42 PM

Works fine.

Hmm. Could it be an interaction between disposing the sprite batch, AND what the parent screen does on return?
Test, modify the List Soldiers screen to go to the statistics screen when "equip soldier" is called, and modify the statistics screen to go to the List Soldiers screen when it's closed. (i.e. Replace the Equip Soldier screen in sequence with Statistics Screen.)
Does the blue screen still appear?
Saving the world from the scum of the universe is hard work. Especially when you have to create the scum to begin with.

#30 Darkhomb

Darkhomb

    Captain

  • Xenocide Artwork Department
  • 628 posts

Posted 13 January 2008 - 05:04 PM

can you tell me exactly which lines you would like me to replace?

#31 dteviot

dteviot

    Programming Department

  • [Xenocide Senior Members]
  • 1479 posts

Posted 13 January 2008 - 10:26 PM

can you tell me exactly which lines you would like me to replace?

In StatisticsScreen.cs, replace
private void OnGeoscapeButton(object sender, CeGui.GuiEventArgs e)
		{
			ScreenManager.ScheduleScreen(new GeoscapeScreen());
		}
with
private void OnGeoscapeButton(object sender, CeGui.GuiEventArgs e)
		{
			ScreenManager.ScheduleScreen(new SoldiersListScreen(0));
		}

In SoldiersListScreen.cs, replace
private void ShowEquipSoldiersScreen()
		{
			if (null != SelectedSoldier)
			{
				ScreenManager.ScheduleScreen(new EquipSoldierScreen(soldiers, SelectedSoldier));
			}
		}
with
private void ShowEquipSoldiersScreen()
		{
				ScreenManager.ScheduleScreen(new StatisticsScreen();
		}

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

#32 Darkhomb

Darkhomb

    Captain

  • Xenocide Artwork Department
  • 628 posts

Posted 13 January 2008 - 10:55 PM

I click stats it takes me to stats. I click geoscape it takes be to the soldier list but not the equip screen, i click equip takes me back to stats.

#33 dteviot

dteviot

    Programming Department

  • [Xenocide Senior Members]
  • 1479 posts

Posted 14 January 2008 - 12:54 PM

I click stats it takes me to stats. I click geoscape it takes be to the soldier list but not the equip screen, i click equip takes me back to stats.

That's doing what I was after, that is, replacing the EquipSoldier screen with the StatisticsScreen.
However, result isn't what I expected.
Looking into matter a bit more, problem is StatisticsScreen DOESN'T call Dispose(). StatisticsScene has a Dispose(), but the StatisticsScreen doesn't call it. A bug that I'll need to fix. Which renders the previous experiment invalid.
Could you add this code to the StatisticsScreen and try again?
/// <summary>
		/// Removes the frame from the display
		/// </summary>
		protected override void Dispose(bool disposing)
		{
			try
			{
				if (disposing)
				{
					if (scene != null)
					{
						scene.Dispose();
						scene = null;
					}
				}
			}
			finally
			{
				base.Dispose(disposing);
			}
		}

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

#34 Darkhomb

Darkhomb

    Captain

  • Xenocide Artwork Department
  • 628 posts

Posted 14 January 2008 - 04:49 PM

ok that did it. Click on geoscape button now have blue screen.

#35 dteviot

dteviot

    Programming Department

  • [Xenocide Senior Members]
  • 1479 posts

Posted 20 January 2008 - 03:13 PM

OK, to summarize the data we have, my deductions and where to go from here.
  • Initial problem reported by Darkhomb. When closing the equip soldier screen (and returning to the list soldiers screen) the list soldier screen doesn't show, it's just an empty "blue screen".
  • No one else is seeing the problem. (Darkhomb is using an 8800 GTS, no one else is.)
  • After some trial and error, it was found that if the SpriteBatch used on the equip soldier scene was not disposed, the list soldier screen would behave correctly.
  • The only other screen that uses a SpriteBatch is the StatisticsScreen. Interestingly, when closed, it returns to the GeoscapeScreen, and Darkhomb reports no problems on closing the StatisticsScreen.
  • Experiment 1: I modified the Equip Soldier screen to go to the Geoscape screen when closed. The result was the Geoscape screen appeared.
  • Experiment 2: Modified the Statistics screen to go to the list soldier screen when closed. The result was the the "blue screen" when statistics screen was closed. Commenting out the "SpriteBatch.Dispose()" made the list soldier screen appear.
  • Conclusion: It's not just Disposing the SpriteBatch that's the problem, it's an interaction between the ListSoldier screen and SpriteBatch.Dispose.
  • Hypothesis: The obvious difference between Geoscape and ListSoldier screens is that the Geoscape has a 3D scene which it draws before running any CeGui code. So, I suspect the problem is when SpriteBatch is disposed, it's changing some of the render state. When we draw the 3D scene, we reset the render states, and then CeGui manages to render. This could be tested by commenting out the 3D scene drawing code in the Geoscape and see if the blue screen appears when the StatisticsScreen is closed. e.g. these lines in PolarScreen.cs:
    public override void Draw(GameTime gameTime, GraphicsDevice device)		{			scene.Draw(gameTime, device, scenewindow.Rect);		}
  • If this confirms problem, a possible work around is add the various "initialize scene" commands to ListSolider, until we find the ones that make the blue screen go away. This would hopefully allow us to know exactly what we're looking for in SpriteBatch.Dispose().
  • Use Reflector to examine SpriteBatch.Dispose(), is there anything in there that looks suspect?
  • Alternate workaround: Have a single, global SpriteBatch, and use it with all screens. Don't dispose of it until we close game.

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]
  • 1479 posts

Posted 24 January 2008 - 01:49 PM

How to set up reference DirectX renderer. Use to check if driver is responsible for drawing artifacts.
http://www.riemers.n...ence_device.php
Saving the world from the scum of the universe is hard work. Especially when you have to create the scum to begin with.

#37 dteviot

dteviot

    Programming Department

  • [Xenocide Senior Members]
  • 1479 posts

Posted 26 March 2008 - 01:23 PM

  • The alien (and other combatant models on battlescape) need a scale so that they can be set to correct size (current code isn't good enough.)
  • Models also need to be correctly centered in cells.
  • if you go to sound options, change settings and hit ok, everything is fine, when you go back into options its back at full volume. The value is saved, but when it does a check for the checkbox after you reopen it, it sets its value to 1f.

edit: fixed a couple of the bugs.

Edited by dteviot, 28 March 2008 - 10:56 PM.

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