Recent Posts

Pages: 1 [2] 3 4 ... 10
11
Graphics Update / Re: Production & Commercial
« Last post by Hooman on October 17, 2018, 06:44:13 PM »
Hmm, interesting concerning the colors. Seems like a simple an effective way of keeping track of things. And those colors look very much like Google. They've built their logo into their data centers. :P
12
Outpost 2 Update / Re: Compiling NetHelper with MSVC toolset 1.40 (2015)
« Last post by Hooman on October 17, 2018, 06:37:52 PM »
Thank you two very much for working on this!

Previously, I was seeing error messages about:
Quote
C:\windows\system32\msvcr100.dll
C:\windows\system32\msvcp100.dll

With the replacement DLL, there are no longer any error message popups.

Both before and after tests were run on Linux with Wine, under OllyDbg.



I checked the multiplayer Internet TCP/IP menu, though I saw an internal IP address there. I'm in a cafe though, so that might not mean much.
13
You're right about truncating the constants, though I also believe you'll need to adjust the number of constants based on the bit size. From the Wikipedia article you linked on Hamming Weight:
Quote
For processors lacking those features, the best solutions known are based on adding counts in a tree pattern.

The height of that tree depends on the number of bits at the bottom.

If you were to look at the first algorithm listed:
Code: cpp [Select]

//types and constants used in the functions below
//uint64_t is an unsigned 64-bit integer variable type (defined in C99 version of C language)
const uint64_t m1  = 0x5555555555555555; //binary: 0101...
const uint64_t m2  = 0x3333333333333333; //binary: 00110011..
const uint64_t m4  = 0x0f0f0f0f0f0f0f0f; //binary:  4 zeros,  4 ones ...
const uint64_t m8  = 0x00ff00ff00ff00ff; //binary:  8 zeros,  8 ones ...
const uint64_t m16 = 0x0000ffff0000ffff; //binary: 16 zeros, 16 ones ...
const uint64_t m32 = 0x00000000ffffffff; //binary: 32 zeros, 32 ones
const uint64_t h01 = 0x0101010101010101; //the sum of 256 to the power of 0,1,2,3...

//This is a naive implementation, shown for comparison,
//and to help in understanding the better functions.
//This algorithm uses 24 arithmetic operations (shift, add, and).
int popcount64a(uint64_t x)
{
    x = (x & m1 ) + ((x >>  1) & m1 ); //put count of each  2 bits into those  2 bits
    x = (x & m2 ) + ((x >>  2) & m2 ); //put count of each  4 bits into those  4 bits
    x = (x & m4 ) + ((x >>  4) & m4 ); //put count of each  8 bits into those  8 bits
    x = (x & m8 ) + ((x >>  8) & m8 ); //put count of each 16 bits into those 16 bits
    x = (x & m16) + ((x >> 16) & m16); //put count of each 32 bits into those 32 bits
    x = (x & m32) + ((x >> 32) & m32); //put count of each 64 bits into those 64 bits
    return x;
}


The constant m32 would by useless as a bitmask on 32-bit operations, as would the x >> 32 operation. Accounting for the halving/truncating of the constants, and removal of dead operations, the 32-bit equivalent should be:
Code: cpp [Select]

const uint32_t m1  = 0x55555555; //binary: 0101...
const uint32_t m2  = 0x33333333; //binary: 00110011..
const uint32_t m4  = 0x0f0f0f0f; //binary:  4 zeros,  4 ones ...
const uint32_t m8  = 0x00ff00ff; //binary:  8 zeros,  8 ones ...
const uint32_t m16 = 0x0000ffff; //binary: 16 zeros, 16 ones ...

int popcount32a(uint32_t x)
{
    x = (x & m1 ) + ((x >>  1) & m1 ); //put count of each  2 bits into those  2 bits
    x = (x & m2 ) + ((x >>  2) & m2 ); //put count of each  4 bits into those  4 bits
    x = (x & m4 ) + ((x >>  4) & m4 ); //put count of each  8 bits into those  8 bits
    x = (x & m8 ) + ((x >>  8) & m8 ); //put count of each 16 bits into those 16 bits
    x = (x & m16) + ((x >> 16) & m16); //put count of each 32 bits into those 32 bits
    return x;
}


That is, one less tree operation for half the number of bits. Or one extra tree operation if you double the number of bits.


Well, I think I got wildly off topic on this thread :P
14
Graphics Update / Re: Production & Commercial
« Last post by leeor_net on October 17, 2018, 06:02:36 PM »
Goof! You live!

I like the idea of color coding feeder/return lines like that. It makes a lot of sense. I think the only potential issue is that this sort of color coding would be done on the interior of the structure. Externally is a hostile environment -- they probably wouldn't care what the color is, it would use a corrosion/thermal resistant coating. One of the research topics I proposed was plasma spray technique to improve environmental resistance and reduce maintenance upkeep (a little in-depth me thinks for this topic but it's effectively related).

My biggest concern is related to visuals -- basically providing a good aesthetic look as well as reasonably good contrast to have details 'pop' while also preventing 'muddling' of colors where everything sort of starts to look samey.

White Claw and I talked about it a bit on IRC in terms of exterior lighting colors and having different related 'industries' have similar exterior color coding. E.g., health is blue, research is white, energy is red, etc. I think the idea was to have industrial/production be green. Perhaps a lighter green would alleviate some of this? Brighter color with less saturation perhaps?
15
Graphics Update / Re: Production & Commercial
« Last post by Goof on October 17, 2018, 02:56:19 PM »
Great work on these amazing structures.

For the colors, as a factory they need some pipes to get hot/cold water, pressurized air, Coolant, electricity, ...
A good way to know what is in each "pipeline", is to sort them by color.
Like in some actual data-centers

(a Google one for air conditioning)


(A Online one near Paris for electric purpose)
Color is used externally and internally to indicate witch generator line is connected to the equipments inside.
16
Graphics Update / Re: Production & Commercial
« Last post by JetMech1999 on October 16, 2018, 07:03:13 PM »
White Claw, in UG factory 01A, the intensity of the green with the brown is where I get the "weed" impression.  I noticed on your next versions, the coloration is toned down and looks really good.  Both lighting types look good to me.  It's possible the whiter color might seem stark in comparison with the yellow lighting effects.  And in regard to my comments about clean-sheet designs, I'm just voicing my irrational need to see everything new.  I think what you're putting out is great.  The surface factory is fantastic as are the redesigns of the existing buildings.  The Park is amazing, too.

Leeor, I get what you're saying about the dome structures.  Supports have to meet somewhere, right?  I have to remember that there is also a certain design type when you start looking at extra-terrestrial constructs.  Low atmospheric pressures, increased ionizing radiation, and other hazards kind of dictate how things will look.  Makes sense to make the structures address some of those items.
17
Graphics Update / Re: Science Structures
« Last post by JetMech1999 on October 16, 2018, 06:40:34 PM »
I like that idea.  I hadn't considered entirely new structures with purposes not previously-used.  Hooman,  I also agree about the blue.  Something about the green I like, but Leeor makes a point, especially for those with color-blindness.
18
Outpost 2 Update / Re: Compiling NetHelper with MSVC toolset 1.40 (2015)
« Last post by Vagabond on October 16, 2018, 05:46:31 PM »
Good news. Thanks to Arklon's suggestion of adding the two defines directly to the codebase, I got NetHelper to compile. I ran it with Outpost 2 using a DEBUG build and was able to see NetHelper's DLL be stepped into for initialization and destruction.

When I click on Internet TCP/IP for multiplayer, Outpost 2 appears to be showing me my external IP address. In the past I remember seeing the internal IP address. Still need to actually test a scenario with someone else.

Also, NetHelper destruction is averaging about 7 seconds for me now, way improved over earlier results. Although it would probably be better to see that number reduced further.

Can someone please post the name of the DLL that is reported as missing when Outpost 2 is started with the current distributed version of Outpost 2? (It is probably already on the forum somewhere but I missed it)

The new build of NetHelper is attached with the .pdb file bundled. It is a release build, so the symbols will jump around a bit when step debugging. Could someone who is getting the missing DLL message download it and try it and make sure I actually fixed that problem?

Thanks,
Brett
19
Outpost 2 Update / Re: Compiling NetHelper with MSVC toolset 1.40 (2015)
« Last post by Arklon on October 15, 2018, 07:04:27 PM »
Sounds like miniupnp/libnatpmp headers are using __declspec(dllimport) (i.e. for dynamic linking) because you don't have the #defines for static link mode set: MINIUPNP_STATICLIB in miniupnpc_declspec.h, and NATPMP_STATICLIB in declspec.h.

Also, I'd recommend VC 2017 now, since 15.7 it's gotten past the first year of being unstable and they've fixed the code gen bugs now, and better yet it has full C++17 support. The IDE itself still seems a bit less stable than 2015 though, but the compiler is fine. Regardless of what toolset you use, you should statically link the CRT (which also requires configuring the miniupnp/libnatpmp builds to do so as well), even though it creates a bigger DLL it's worth it to avoid VC runtime version dependency hell.
20
Outpost 2 Update / Compiling NetHelper with MSVC toolset 1.40 (2015)
« Last post by Vagabond on October 15, 2018, 05:20:03 PM »
I took a stab at updating NetHelper to compile against the 2015 C++ toolset (ver 1.40). This included the two project dependencies: libnatpmp and miniupnpc.

I have both dependencies compiling on their own.

I've setup the project to compile statically into a dll.

When compiling NetHelper itself in win32 debug or win32 release, I get 14 errors. 13 LNK2019 and the corresponding LNK1120.


Error   LNK2019   unresolved external symbol __imp__UPNP_GetValidIGD referenced in function "public: bool __thiscall PortForwarder::Initialize(bool,bool)" (?Initialize@PortForwarder@@QAE_N_N0@Z)   NetHelper   \NetHelper\src\PortForward.obj   1

Error   LNK2019   unresolved external symbol __imp__closenatpmp referenced in function "public: __thiscall PortForwarder::~PortForwarder(void)" (??1PortForwarder@@QAE@XZ)   NetHelper   \NetHelper\src\PortForward.obj   1

Error   LNK2019   unresolved external symbol __imp__freeUPNPDevlist referenced in function "public: bool __thiscall PortForwarder::Initialize(bool,bool)" (?Initialize@PortForwarder@@QAE_N_N0@Z)   NetHelper   \NetHelper\src\PortForward.obj   1

Error   LNK2019   unresolved external symbol __imp__FreeUPNPUrls referenced in function "public: __thiscall PortForwarder::~PortForwarder(void)" (??1PortForwarder@@QAE@XZ)   NetHelper   \NetHelper\src\PortForward.obj   1

Error   LNK2019   unresolved external symbol __imp__getnatpmprequesttimeout referenced in function "int __cdecl ListenForPmpResponse(struct natpmp_t &,struct natpmpresp_t *,int)" (?ListenForPmpResponse@@YAHAAUnatpmp_t@@PAUnatpmpresp_t@@H@Z)   NetHelper   \NetHelper\src\PortForward.obj   1

Error   LNK2019   unresolved external symbol __imp__initnatpmp referenced in function "public: bool __thiscall PortForwarder::Initialize(bool,bool)" (?Initialize@PortForwarder@@QAE_N_N0@Z)   NetHelper   \NetHelper\src\PortForward.obj   1

Error   LNK2019   unresolved external symbol __imp__readnatpmpresponseorretry referenced in function "int __cdecl ListenForPmpResponse(struct natpmp_t &,struct natpmpresp_t *,int)" (?ListenForPmpResponse@@YAHAAUnatpmp_t@@PAUnatpmpresp_t@@H@Z)   NetHelper   \NetHelper\src\PortForward.obj   1

Error   LNK2019   unresolved external symbol __imp__sendnewportmappingrequest referenced in function "public: bool __thiscall PortForwarder::Forward(bool,int,int,char *,char *,int)" (?Forward@PortForwarder@@QAE_N_NHHPAD1H@Z)   NetHelper   \NetHelper\src\PortForward.obj   1

Error   LNK2019   unresolved external symbol __imp__sendpublicaddressrequest referenced in function "public: bool __thiscall PortForwarder::Initialize(bool,bool)" (?Initialize@PortForwarder@@QAE_N_N0@Z)   NetHelper   \NetHelper\src\PortForward.obj   1

Error   LNK2019   unresolved external symbol __imp__upnpDiscover referenced in function "public: bool __thiscall PortForwarder::Initialize(bool,bool)" (?Initialize@PortForwarder@@QAE_N_N0@Z)   NetHelper   C:\Users\Brett\Documents\OutpostUniverseGitHub\NetHelper\src\PortForward.obj   1   
Error   LNK2019   unresolved external symbol __imp__UPNP_AddPortMapping referenced in function "public: bool __thiscall PortForwarder::Forward(bool,int,int,char *,char *,int)" (?Forward@PortForwarder@@QAE_N_NHHPAD1H@Z)   NetHelper   \NetHelper\src\PortForward.obj   1

Error   LNK2019   unresolved external symbol __imp__UPNP_DeletePortMapping referenced in function "public: bool __thiscall PortForwarder::Forward(bool,int,int,char *,char *,int)" (?Forward@PortForwarder@@QAE_N_NHHPAD1H@Z)   NetHelper   \NetHelper\src\PortForward.obj   1

Error   LNK2019   unresolved external symbol __imp__UPNP_GetExternalIPAddress referenced in function "public: bool __thiscall PortForwarder::Initialize(bool,bool)" (?Initialize@PortForwarder@@QAE_N_N0@Z)   NetHelper   \NetHelper\src\PortForward.obj   1


It appears all the errors come from PortForward.obj. All the unresolved external symbols start with __imp__. I think this stands for import. I suspect part of the code base is set to export the functions for access across different DLLs while part of the code base is set to link against the functions as if they are part of the same module.

Inside Visual Studio, When I click 'goto definition' on the PortForwarder class calls to the functions in question, Visual Studio is smart enough to pull up the function definitions.

It may have something to do with __declspec(dllimport) or __declspec(dllexport) calls.

There is a flag inside both dependent projects to mark them as static builds. Both flags seem to be set.

Not sure how to troubleshoot this. Maybe someone wants to review the project files? I could email or post them if interested.

Thanks,
Brett
Pages: 1 [2] 3 4 ... 10