Messages

1

Coding / Re: Trying to speed up code for Routing

« on: March 29, 2020, 02:18:38 pm »

Somehow missed this topic earlier.

A quick answer:

1) Intent of this code is stated just a few lines above: "/* put the crosspoint DIST_EPSILON pixels on the near side */". The same comment is present in the original Quake2 source code, which also uses the same signs; in fact, UFO:AI code is 100% identical here.

2) First Quake uses a different approach, with a single fraction, like  Namerutan proposes. So calculating two fraction for the split is the intentional by the engeine developers.

3) Quake3 collision detection code is seriously refactored, but this calculation is identical to the Quake2 and the UFO:AI. So this math is likely to be intentional rather than bug.

4) CPU consumption by calculating fractions separately is marginal; main cost lies in the AABB vs arbitrary polytope collision detection.

So, unless someone sits with paper & pencil to redo the math, I'd recommend to keep it as it is.

PS: Routing code can (and, likely, should) be optimized, that is true. But not here.

2

Linux / Re: Fedora29 Compile problem

« on: May 21, 2019, 02:21:53 am »

picomodel library should be located in the UFO:AI source tree under src/libs/picomodel -- please make sure you've checked out and compiling all the workspace. Same goes for the mxml library.

3

Discussion / Re: Thermobaric ammo

« on: January 10, 2019, 04:43:28 am »

Doable. Engine got everything needed, except for the gas cloud simulation (smoke grenade is pretty much a hack). Tile-based approach should do. After all, this is a game, not a physics simulator. You can always rearrange graphics a bit to hide the tiling.

4

Discussion / Re: Why do things look derpy.

« on: January 10, 2019, 04:38:48 am »

Because we don't have a 3D artist right now. Want to be one?

5

Feature Requests / Re: Variable Smoke Persistence

« on: February 15, 2018, 06:41:28 am »

The problem is, UFO:AI is not the tile-based game, it just pretends to be one. Underlying engine, the idtech2, is freestyle 3d, so there are no "smoke tiles", but the smoke volume.
Therefore changes you propose will require major modifications of true visibility system. Of course, there could be some simpler way, like shrinking the smoke cloud each halfturn by some randomized value.

6

Bugs in development version (2.6-dev) / Re: Some settings are not used after restart

« on: November 29, 2017, 03:54:22 pm »

Texture resolution:
i have choices up to 8192, but if i set it to 2048 or higher, after reload it drops to 1024 without reason, with only this feedback in log:

Intel graphics chipset, no doubt. Game got some forced limitations for those, since there are some Intel drivers that report more than hardware could handle -- and crash when program actually tries to beleive thoise claims.

You shouldn't worry much anyway -- the only thing you probably lose is the high-res Earth, if you have installed the texture pack. There are no other textures bigger than 1024x1024 IIRC.

7

Artwork / Re: A question about MDX files

« on: July 24, 2017, 10:31:09 pm »

Thanks Sandro for correcting me. As you know I'm not much into the Renderer or graphics in general and yeah, I guessed what it exactly does from the function name. Could you maybe update the code to better reflect what it does? Maybe adding some in-line documentation?

While I'd like to, I haven't got a working environment, just a copy of source right now (of 2.5 release). So only things right now I can do is to make suggestions and perhaps provide some code snippets, if I'll be able to compile them.

Going back to the R_ModCalcUniqueNormalsAndTangents() function, it really calculates normals, but only to use them as intermediate data; they are discarded at the function returns.

After some thoughts, it looks to me that it will be better to call this function R_ModBuildIndexedMesh(), because it is what it actually does.

8

Artwork / Re: A question about MDX files

« on: July 24, 2017, 06:09:35 pm »

Our mdx files are generated by the ufomodel tool. It pre-calcuates normals and tangents to speed up model loading a bit. You can safely remove and recreate the mdx with the ufomodel tool.

It doesn't. Our talk over the IRC led me to investigate it again (forgot the previous results), and no, it does not store any normals. It is a bidirectional vertex<->index map for indexed representation of models, with duplicate vertices removed. And that's pretty much all. See the R_ModLoadMDX() for yourself -- it only processes the indices.

The game works without mdx-es fine.

It just recalculates it on every load by the O(n^2) algo with quite a big multiplier. See the  R_ModCalcUniqueNormalsAndTangents(), which does NOT exactly do what its name suggests. Normals get recalculated every frame anyway.

P.S.: Proper name should be something along the lines of R_ModFindSharedVerticesForReuse(), or something like it.

9

Discussion / Re: setting up a target, green or red

« on: June 04, 2017, 02:13:10 pm »

But we do have:

Code: [Select]

g_combat.cpp:38:#define MAX_WALL_THICKNESS_FOR_SHOOTING_THROUGH 8Which is used at g_combat.cpp:1061 when a shot goes through an obstacle, so the game does care about thickness, just in a buggy way apparently.

It doesn't, since G_Trace() does not work as expected by the author of this code.
At the end, it indirectly calls SV_Trace(), which got a hack to avoid player and other moving objects being caught in solids -- and also disables solidity check for firing from INSIDE the solids.
That effectively disables the wall thickness checking code.

10

Discussion / Re: setting up a target, green or red

« on: June 02, 2017, 03:53:09 pm »

Game does not care for the thickness of obstacle, only the count of them along the projectile's path. Could be considered a bug.

11

Feature Requests / Re: Smooth encumbrance system

« on: April 16, 2017, 12:49:51 am »

Skyblue is obviously way off the color ramp chosen. Is it meant to be an eye-catching indicator that your soldier just begins to slow down under the load?

12

Feature Requests / Re: "Red" encumbrance level over 80% weight

« on: March 06, 2017, 07:26:51 pm »

IMHO, the best version could be a smooth encumbrance increase instead of increasing in steps.

13

Newbie Coding / Re: Idea for visibility, black blocks

« on: November 05, 2016, 05:25:56 pm »

What are the main roadblock for implementing a graphic visibility system?  Is it within the game engine itself that limits a visibility system, or is it difficult to implement in a Quake game?  I've seen Quake games where weapon fire illuminates the surroundings, but come to think of it I've never seen a Quake game where you can shine a flashlight around (unless its the modern engine).

That case is complicated. And flashlight and visibility system are two different things. For example, flashlight was implemented in a Half-Life, but it used a hack (virtual spot light). Doom III uses a true flashlight, and it is still based on the similar engine architecture.
Visibilty is the other thing, engine already does it for many things, but rendering of it is not supported by the current engine, and WILL requre a somewhat different rendering approach. To be exact, a some sort of "visibility shadow" should be calculated, and the engine (currently) does not have any provisions for that. Alas

14

Windows / Re: Text graphics problem in 2.5(?)

« on: November 05, 2016, 04:56:28 pm »

Actually, the problem was that upon porting to SDL2 alpha blending was mistakenly applied when rendering text (the problem existed only in the SDL2 version), I have since fixed the issue (and adjusted font hinting while I was there) and IMHO the text looks way better now — at least here, and I also have an NVIDIA card — but we haven't made any release since then, and, looking at how things have been here lately, I doubt that we will any time soon, you could always try to compile the latest version from git on your own (if you want to try see the indtructios here: http://ufoai.org/wiki/Coding)

It depends on how you define "mistakenly". Alpha blending sometimes helps with a font rendering, sometimes not. Since game uses prerendered (cached) glyphs, alpha blending looks like a somewhat better blending option IMHO. Obviously, the alpha masking gives a sharper version, but jagged edges are not fun either.

OFC, distance field font rendering solves all the problems, but who will do it? Sorry, I cannot do it right now. No time to do it. For more than a two years

15

Artwork / Re: Dropship/Fighter Contribution

« on: April 14, 2015, 01:19:09 am »

Here is an image showing the versions, current version on the left, 700k poly version on the right and low poly with new maps in the middle.


Niiice!!!
But, for  realism, it could be better to increase the stab area to keep the 1:5 rule.