DogfightState development

[d2uriel]

No, it doesn't. Can you try to fork my code to a seperate repo instead of pulling it to yours? Maybe there's a different issue here.

There are other bugs found but it does work for me pretty well.

Edit: Have a look: https://www.youtube.com/watch?v=-rI6VkDLzo8&feature=youtu.be

[pmprog]

I downloaded your Git, compiled it, and it did exactly the same as what it did from my repo!? I have no idea why it works different for you than me.

I'm compiling with VS2008 BTW, not that that should make any difference...

[d2uriel]

I'm using 2010 but it shouldn't make any difference IMO. So it does happen every time you start a new game and launch two interceptions?

I know radius75 also tried it - you haven't had this kind of issues, right? You had others, though .

What the heck? Every time I try it - it works without any problems. Umm... weird.

Edit: can you set a breakpoint at line 385 in GeoscapeState.cpp file and run the game again in debug mode? Ooh... are you running debug or release version?

[radius75]

Still having problems, thought it'd be easier to record what I'm doing...

https://youtu.be/IRYHufVLsPE
https://youtu.be/asjyNwlzjcE

Confirm this, on vc2010. tested on commit [ec7e92412e13959f84287bab702b7ccc626cc45d]

[pmprog]

Yes, does it every time

Release. The game won't start if I run the Debug mode (not figured out why).

Anyhoo... I found this little gem:

_dogfights[0]._x = 80
_dogfights[0]._y = 304

_dogfights[1]._x = 80
_dogfights[1]._y = 0

Edit:
Could this be a scaling issue?

Edit 2:
Call me n00b, but where the frigg does _y get set? there's a _y(0) suffixed on the constructor, but I don't understand where it gets set?!

[d2uriel]

Yes, does it every time

Release. The game won't start if I run the Debug mode (not figured out why).

Anyhoo... I found this little gem:

_dogfights[0]._x = 80
_dogfights[0]._y = 304

_dogfights[1]._x = 80
_dogfights[1]._y = 0

Edit:
Could this be a scaling issue?

Edit 2:
Call me n00b, but where the frigg does _y get set? there's a _y(0) suffixed on the constructor, but I don't understand where it gets set?!

Aah, I know what's wrong! Thanks for this piece of information. Try the newest build.

AFAIR, when I used screen resolution for calculating window positions it wasn't working. I guess we still work with 320 x 200 and then the image is up-scaled to whatever resolution you have chosen in the settings, right?

[pmprog]

Yep, works fine now! Good job!

[d2uriel]

Not really fine, but it works ;-).

I'll update the first post with bugs that are still present. Check it please before posting a bug you find ;-).

[radius75]

Does someone have save with four interceptors in Base? He necessary is to tests 

Edit
OK, I already have him

https://www.speedshare.org/download.php?id=4086F13A1

[d2uriel]

I'm experiencing a different issue now. Creating a new DogfightState object takes about 200ms in debug mode (a little less in release). Because of that you can see a small slowdown when a dogfight is about to be started (just before the zoom in effect).

Does someone have save with four interceptors in Base? He necessary is to tests 

Edit
OK, I already have him

https://www.speedshare.org/download.php?id=4086F13A1

Haha, good one ;-). Fixed.

Edit: Don't use that saved game for testing now though. It has the wrong values saved. Well, you can do it but you need to return all crafts to the base and make them intercept again.

Edit2: New build available. Cosmetic changes to code... which may break stuff ;-).

Edit3: Regarding the creation time issue - I'm wondering if the dogfight handling shouldn't be a bit different. Maybe I should create 4 instances of DogfightState class when the game starts and then just use them when necessary without deleting them? That would make this issue disappear. What do you think? Is the slowdown really frustrating?

[radius75]

Geoscape buttons are enable if the dogfight window  is open
[661cec6f3e395601...]

[d2uriel]

Geoscape buttons are enable if the dogfight window  is open
[661cec6f3e395601...]

Fixed.

The other one with changing interceptors target while it's interception window is minimized is also fixed.

[radius75]

Save 5vs1 for testing;)
https://www.speedshare.org/download.php?id=F7B0EA6F1

[SupSuper]

Aah, I know what's wrong! Thanks for this piece of information. Try the newest build.

AFAIR, when I used screen resolution for calculating window positions it wasn't working. I guess we still work with 320 x 200 and then the image is up-scaled to whatever resolution you have chosen in the settings, right?

Yes, internally the game is all 320x200 and scaled in post, makes it a lot easier to manage. The only time you need to account for the real screen resolution is when doing advanced stuff like handling the mouse cursor position.

[d2uriel]

Yes, internally the game is all 320x200 and scaled in post, makes it a lot easier to manage. The only time you need to account for the real screen resolution is when doing advanced stuff like handling the mouse cursor position.

That explains a lot. Well, next time I'm not gonna make the same mistake again (hopefully) .

Anyway... how's the testing going?