project-navigation
Personal tools

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - Jon_dArc

Pages: [1]
1
Mac / HEAD (2.5) build failure on OSX 10.8/Clang and fix
« on: June 05, 2013, 06:20:15 pm »
Building complains about two function calls in src/shared/images.cpp on account of no matching functions in jpeglib.h and no known conversion from bool to boolean; the offending argument is "true", and nearby similar functions use "TRUE" in the same position. Changing the two offending calls to "TRUE" satisfies the compiler; it looks like this might have been a typo (or brain-o) that might be concealed by an implicit conversion in other build environments. The relevant patch is included below:

Code: [Select]
diff --git a/src/shared/images.cpp b/src/shared/images.cpp
index d11e250..b8f9868 100644
--- a/src/shared/images.cpp
+++ b/src/shared/images.cpp
@@ -247,7 +247,7 @@ void R_WriteJPG (qFILE *f, byte *buffer, int width, int heig
 
        jpeg_set_defaults(&cinfo);
        jpeg_set_quality(&cinfo, quality, TRUE);
-       jpeg_start_compress(&cinfo, true);      /* start compression */
+       jpeg_start_compress(&cinfo, TRUE);      /* start compression */
        jpeg_write_marker(&cinfo, JPEG_COM, (const byte *) "UFOAI", (uint32_t) 5
 
        /* Feed scanline data */
@@ -397,7 +397,7 @@ static SDL_Surface* Img_LoadJPG(char const* const name)
                jpeg_mem_src(&cinfo, buf, len);
 #endif
 
-               jpeg_read_header(&cinfo, true);
+               jpeg_read_header(&cinfo, TRUE);
 
                cinfo.out_color_space = JCS_RGB;

~J

2
So darwin.mk from HEAD (and as far back as I can remember offhand) has a nice, convenient little section where it checks to see if /opt/local or /sw exist and, if so, add the first one to exist to CFLAGS/LDFLAGS. This caused some troubles for me back in the day because instead of having my extra libs/headers in either of those locations, I had them in /usr/local (shocking, I know).

Once I figured out what was going on it was a quick fix. Over time, though, UFO:AI has picked up a few more dependencies, some of which have installed themselves in other places—the most recent being, in fact, in /opt/local.

Is there in fact a realistic fear of people getting stale libraries/headers from the wrong source if, instead of selecting precisely one source for headers/libs, darwin.mk instead tested for existence of common places to stick such things and then simply added each one it found (plus /usr/local and /Library/Frameworks) to CFLAGS/LDFLAGS appropriately? It would require a few more tests to tease out exactly where SDL_* is living, but not much more, and it seems like it would dramatically reduce the likelihood that someone will need to edit darwin.mk (or, I guess, probably pass the right options to configure) to have a successful build.

~J

3
Bugs in stable version (2.5) / Clang static analysis of HEAD
« on: June 08, 2012, 04:35:05 pm »
So in an attempt to further investigate this issue, I ended up sticking the 2.5-dev HEAD under the Clang static analyzer. Unfortunately nothing that showed up seems relevant to that bug, but as long as I have the report I figure I may as well toss it up here. I'll see if I can't look into some of these to possibly weed out obvious false positives.

~J

4
I'll start off by recognizing that I don't think anyone's ever said that Clang is supported as a build environment, but what I've found investigating the bug so far suggests that it isn't a pure compiler-compatibility issue, so here goes. Also, though I consider myself pretty competent with C, the issue looks to be solidly in C++-land, so there's some risk of me starting to talk out of my ass at some point.

Symptoms: attempting to run built ufo executable results in segfault. Attempting to run ufomodel exits with message "Error: Mem_Alloc: Error - no pool given [newline] alloc: src/common/mem.cpp:#656".

Last known good commit: b7ffc466749335dc45024fbc10bf014f7ea2227e (henceforth "Good")
First known bad commit: 8adf00afba41a139f7ff8c8a9a26ecc659084a21 (henceforth "Bad")

The issue, based on what I've been able to find with the debugger, is that as of Bad a custom definition of new in mem.cpp makes reference to com_genericPool, which is initialized in Mem_Init, which breakpointing has confirmed is never called in Bad.

Based on the stack trace, it looks to me like the issue is that the redefinition of new goes into effect immediately (at least relative to what we're doing), but the calls to Mem_Init (inside Qcommon_Init) occur inside the UFO:AI main, which looks to be getting inlined into CustomApplicationMain in SDL, which in turn generates a call to new before getting around to running the UFO:AI main where initialization happens.

Tracking down this issue was complicated by the fact that the main ufo executable detects the uninitialized pool and tries to upload a crash report (which, incidentally, is something I don't remember having been disclosed, nor do I remember having been offered a chance to opt out…), but because none of the initialization has happened yet net_ipv4 is still null when we try to access a member in NET_GetAddrinfoForNode, which is where the segfault comes from.

The next question, I guess, is why everyone else hasn't noticed the same problem. If anyone is building and running 2.5-dev on Darwin and isn't seeing this issue, please let me know immediately (and, in particular, if you're using GCC). Otherwise, I'm going to start looking into the platform-specific entry points to see what the difference could be.

~J

5
Discussion / Weapons and damage in 2.5 (HEAD)
« on: May 11, 2012, 06:18:16 pm »
Understanding that with 2.4 having just been released 2.5 is very much in a kind of "gameplay alpha" status with lots of fluctuations in values likely, I'd like to bring up for discussion a few things that caught my attention with the weapons and damage weights as they currently stand. For organizational reasons I'm going to put each new subtopic in a separate reply. First up: laser weapons.

Laser weapons appear to have been nerfed into uselessness. Accuracy has been drastically reduced (and the non-pistol weapons have picked up an inexplicable penalty to accuracy for burst-fire modes), laser pistol damage has been substantially reduced, and though the Heavy Laser got a slight damage bump it also got more TU-expensive. Worse yet, nothing is vulnerable to it—the Shevaar have no resistances, but the other three species resist at least a third of the expected damage before armor (Ortnoks are guaranteed to take 1 damage per laser pistol hit, and resist ~73% and ~50% respectively for the laser rifle and heavy laser). Armor also has substantial impact.

In 2.4, at least, the implied bargain was "high accuracy, reasonably fast, low damage, stay away from Ortnoks". IMO at least it failed at this by being too effective overall, so a nerfing was needed. Unfortunately, by striking at both accuracy and damage the pendulum has swung much too far in the other direction—I'm honestly not sure that the weapons would be viable even with 2.4 accuracy, given 2.5 damage and TU use, but as it stands they're a clearly bad bargain.

I'm inclined to say that their accuracy characteristics should be restored to their 2.4 levels, the Heavy Laser should be restored to its 2.4 TU use, and the Laser Pistol and to a lesser extent Laser Rifle should get a damage bump—maybe to 30±5? Or 25±5 and a drop in Ortnok resistance? Actually, dropping all base resistances by 10 could work. Well, actually, let's try a more principled approach by comparing it to some other weapons.

Laser pistols have Spread 1.5, Crouch 1, Range 60, 28 ammo, 10 TU reload cost, are 2x3, and have 2x1 ammo. They deal 20±5 laser_light at a TU/shot of 4/1 or 8/3.

7.62mm (???) pistols have Crouch 1, Range 40, 12 ammo, 6 TU reload cost, are 2x2, and have 1x1 ammo. They deal 30±5 normal_light at 4 TU for Spread 2 and 8 TU for Spread 1.5.

Plasma Pistols have Crouch 1, Range 40, 8 ammo, 15 TU reload cost, are 2x3, and have 1x1 ammo. They deal 50±10 plasma_light at 6 TU for Spread 2.2, 10 TU for Spread 2, and 10 TU for 3 shots at Spread 2.8.

Laser pistols have a 50% range edge, but I'd argue that their inaccuracy makes it largely irrelevant—you can't seriously engage targets in the 41-60 range category with any actual hope of hitting. Therefore, I'm going to focus on their other characteristics.

Per-round damage by alien/armor; damage whose range is constrained by minimum damage has its range given in parentheses:

Taman:
7.62mm: 30/15/(1)±5
Laser: 10/5/(1-5)±5
Plasma: 45/15/(1-5)±10

Ortnok:
7.62mm: 10/(1)/(1)±5
Laser: (1)/(1)/(1)±5
Plasma: 50/20/(1-10)±10

Shevaar:
7.62mm: (1-5)/(1)/(1)±5
Laser: 20/15/10±5
Plasma: 60/30/10±10

Bloodspider:
7.62mm: 10±5
Laser: 10±5
Plasma: 50±10

So in terms of damage it's almost strictly dominated by plasma. In principle it would make up that deficit through superior accuracy and volume of fire (fewer TUs/shot, plus a larger magazine and less expensive reloads), but look at how many more shots need to hit:

(Best case-worst case ranges to kill an uninjured alien with no/light/medium armor; probabilities will weight towards the better end, as the worst case requires larger numbers of extreme results)

Taman:
Laser: 7-26/10-130/20-130
Plasma: 2-3/4-26/20-130

Ortnok:
Laser: 150-190 (all)
Plasma: 3-4/5-19/15-190

Shevaar:
Laser: 5-12/6-16/8-32
Plasma: 2-4/3-8/6-160

Bloodspider:
Laser: 10-30
Plasma: 3-4

So with the notable exception of a Shevaar using Medium Alien Armor, you consistently need at least twice as many hits for a kill, wiping out the speed advantage (though reloading speed recovers a little of this) and magnifying the effects of the reduced accuracy. Although 2.4's 36±6 damage for the laser pistol was excessive, 30±5 or maybe 25±5 with a reduction in Ortnok laser resistance (it'd be nice for it to be possible to deal more than 1 damage to an Ortnok, even if it remains a miserable option) seems reasonable.

An alternative to a straight damage boost could be to make Shevaar more vulnerable to lasers and less to plasma, but given that a laser pistol takes up the entire holster I don't think making it a dedicated anti-Shevaar weapon is reasonable, especially given how much time there is between being able to research laser pistols and when Shevaar make their first appearance.

(Another question this raises is whether 7.62mm pistols are intended to have any role in the game—I understand they're intended to become obsolete, but they do that almost instantly, as soon as the player either researches laser pistols+DF cartridges or obtains and researches plasma pistols, plus maybe a bit to build up a comfortable reserve of plasma pistol ammo. Even just making them 3-square L-shaped in the inventory like the machine pistol would go a long way to making them not quite as much a complete joke.)

~J

Pages: [1]