Jump to content

  • Log In with Google      Sign In   
  • Create Account

Nypyren

Member Since 19 Aug 2002
Online Last Active Today, 12:03 AM

Posts I've Made

In Topic: C# - Detect If Pre-Existing .DDS Contains Alpha Channel?

Yesterday, 10:28 AM

I'm not familiar with the internal workings of DXT5, but I found this table when I searched:
https://en.wikipedia.org/wiki/S3_Texture_Compression#S3TC_Format_Comparison

It seems like DXT5 is always capable of alpha, but doesn't use *premultiplied* alpha. The -pmalpha argument to texconv means "convert to premultiplied alpha". DXT1, 2, and 4 use premultiplied alpha according to that wikipedia page. But just because a format is capable of alpha doesn't mean it USES alpha. Every pixel might be fully opaque. If you need to actually check to see if alpha is actually used or not, you'll probably have to actually load the entire file and check every pixel somehow.


I'm curious: What happens in your tool if you pass -pmalpha for a texture that doesn't have alpha? Does Fallout 4 fail to load the texture? Does it look strange in game? Does the tool report an error?

In Topic: C# - Detect If Pre-Existing .DDS Contains Alpha Channel?

26 August 2016 - 07:23 PM

The GetAlphaMode function signature implies that it is figuring things out using the DDS_HEADER alone. If we can figure out what it's looking at, we can go back to your original approach of reading the DDS_HEADER directly from the file in pure C#. Perhaps it's looking at several other fields, not just the dwFlags field.

In Topic: C# - Detect If Pre-Existing .DDS Contains Alpha Channel?

26 August 2016 - 07:14 PM

Sorry my initial suggestions didn't help earlier on. I can provide more assistance with what you're trying now.

The signature for LoadTextureDataFromFile looks like it will store the results in the four other arguments. In order to call that using DllImport from C#, your C# DllImport line of code would need to have a compatible function signature that .Net can determine is related to the actual function in C++. However, DllImport only works with C functions as far as I know. Besides, that is one *hell* of a complicated function signature to try to get DllImport to accept; I'm not sure what to do about the std::unique_ptr from C#'s point of view even if they did add C++ support to DllImport.

If it were up to me, at this point I would build a "C++/CLI" DLL. C++/CLI is a way of writing code in C++ which can link to normal C and C++ libraries, which you can then call directly from other .Net languages like C# without using the DllImport approach. You would still need to write code that bridges between "unmanaged" code (code that calls the DirectX functions) and "managed" code ('ref classes' which can be passed directly to C#), but at least in C++/CLI you have access to both "C++/CLI" and "plain old C++" simultaneously.

It's potentially simple, but if you're uncomfortable using C++ directly it probably won't be very fun. Then again, you already have a C++ DLL building already, so it's not much of a leap to make a C++/CLI DLL. Another plus is that you probably won't need to write very MUCH C++ code yourself so I wager you could get it working.

In Visual Studio 2015, the project type you want is: Visual C++ -> CLR -> Class Library. The "CLR" part is akin to the "CLI" in C++/CLI.

After you make the C++/CLI DLL, you add it as a reference in the C# project just like you would with other .Net DLLs.

In Topic: State machine for beginner - how to shoot state AND jump state

26 August 2016 - 06:21 PM

Generally you only want to use a state machine when it contains mutually exclusive states. If you ever have two or more things that you can combine at the same time (like shooting and any movement state), either split them in two different state machines, or use something else instead of a state machine.

Sometimes you don't need a state machine at all and can do everything in a single Update function that gets called once a frame.

such as:
 
If health is <= 0 and dying animation not playing, play it and return.
If dying animation is done, do game over and return.

Check arrow keys, update velocity.
Check whether the player is touching the ground, if so reset the jumping flag.
If jumping flag is false and jump key is pressed, set jump flag and add lots of upward velocity.
If jumping flag is set and jump key is released quickly, subtract a bit of upward velocity to let the player perform a smaller jump.  Potentially add another flag to prevent the user from repeating this multiple times in the same jump.
If player is capable of flight, holding the jump key while jumping adds a little bit of upward velocity.

If fire key is down, and firing is possible now, then fire.

Apply velocity to position.

If in air, use jumping/flying animation.
Else If on ground and speed > large threshold, use running animation.
Else If on ground and speed > small threshold, use walking animation.
Else if on ground use idle animation.

In Topic: Does anyone have any advice for my unique situation?

26 August 2016 - 03:29 PM

Well... I've been doing this for at least a decade longer than most of you.  I was among the very first group of modern game designers that invented the process by which you make games.  I have already been involved with MANY published games, one of the second only to D&D in it's stature in the history of games.


Experience just means you're experienced. It doesn't mean your opinions matter more. Opinions are governed by respect, and respect is something you have to build from scratch every time you meet someone new. You don't build respect by quoting your experience. You build respect by suppressing your ego, and talk WITH people instead of TO them.

PARTNERS