using tmxparser (and failing)

Recommended Posts

Hi everyone!

I've managed to build zlib, tinyxml2 and tmxparser with cmake-gui & visual studio 2017, but when I try building the example program for tmxparser (https://github.com/sainteos/tmxparser/tree/master/test) I'm getting numerous unresolved externals for errors, and in the warnings they all state the library machine type 'x64' conflicts with target machine type 'x86'. (some of the unresolved symbols include __imp__UnhandledExceptionFilter@4, __imp__getCurrentProcess@0, __imp__HeapAlloc@12 and the file referenced in the error log is MSVCRTD.lib along with varying object files)

Thing is, when I go back to the cmake configuration listings for all 3 of those libraries, i can't find anything to suggest i've explicitly configured anything as a 64bit build, and when I open the solutions cmake generated for each of the libraries, all of them (including the test project) have x86 as the current target.. what gives?

Thanks in advance!

Share this post

Link to post
Share on other sites

Maybe its your compiler setting is x64 instead of x86, or you've include a x64 lib file by mistake. Can you post an error message related to/saying:

On 9/19/2017 at 11:56 PM, Poprocks said:

type 'x64' conflicts with target machine type 'x86'.




Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Partner Spotlight

  • Forum Statistics

    • Total Topics
    • Total Posts
  • Similar Content

    • By Finalspace
      I am playing around with ImGui, adding a UI to my level editor, but i am having trouble with mouse clicks in ImGui triggers a click in my actual editor (Because it uses the same input states).
      Right know i have just a main menu bar and the editor rendering is behind that. When i click on a menuitem for example, and select another sub item and click, i place a block in my editor - just because the input events are the same for both ImGui and my editor.
      So i have a few questions:
      1.) Is there a way to detect when ImGui has taken any action/hover in the previous frame, so i can skip the input handling for my editor? (This way i can prevent the issue i have right now)
      2.) Can i add a imgui window which fully fits the rest of the entire screen - after a main bar has been added? (Do i manually need to calculate the size?)
      3.) Should i make the entire editor with ImGUI only - so i wont get any input fuzziness problems?
    • By irreversible
      I'm writing some code for automatic function argument type deduction using a tuple. I'm then iterating over it to narrow down and check each argument separately. I spent a cozy evening tinkering with getting by-value, const value and const references to work, until I discovered that some functions need to return more than one result. This is where I need to identify non-const lvalue references, which a tuple has difficulty in handling.
      As far as I can tell most problems out and about on the web focus on creating fairly simple stand-alone tuples that only contain lvalue references using std::tie. In particular, this stackexchange thread outlines how that can be accomplished. 
      Problem is, I have a packed array of types, which may or may not contain one or more lvalue references interleaved with other types. forward_as_tuple is suggested here and there, but I'm unsure how to use it. 
      Here's there relevant code:
      // split the return type from the argument list template<typename R, typename... Args> struct signature<R(Args...)> { using return_type = R; using argument_type = std::tuple<Args...>; // 1 }; template<typename FUNCSIG> editor::nodetype_t& CreateNodeType( IN const char* category) { // instantiate the argument list tuple. No need to post any further code as this // is where things fail to compile signature<FUNCSIG>::argument_type arglist; // 2 } // the below snippet outlines how CreateNodeType() is called: #define DEFINE_MTL_NODE(function, category, ...) \ auto& nodeType = CreateNodeType<decltype(function)>(category); // a sample function for completeness. I'm intentionally not using the return value here. void Lerp( IN const math::vec3& ColorIn1, IN const math::vec3& ColorIn2, IN float Alpha, OUT math::vec3& ColorOut) { .. } void main() { DEFINE_MTL_NODE(Lerp, "Color"); } Either the line marked with 1 or 2 needs to be something else, but apparently my C++ level is not high enough to figure out what. PS - to further complicate things, I'm stuck on C++11 for now.
    • By noodleBowl
      I got a quick question about buffers when it comes to DirectX 11. If I bind a buffer using a command like:
      IASetVertexBuffers IASetIndexBuffer VSSetConstantBuffers PSSetConstantBuffers  and then later on I update that bound buffer's data using commands like Map/Unmap or any of the other update commands.
      Do I need to rebind the buffer again in order for my update to take effect? If I dont rebind is that really bad as in I get a performance hit? My thought process behind this is that if the buffer is already bound why do I need to rebind it? I'm using that same buffer it is just different data
    • By noodleBowl
      When it comes to the copy, move, and assignment operators of a child class how is it supposed to look?
      If this is the implementation of my parent class
      //Default constructor Buffer::Buffer() { buffer = nullptr; } //Copy constructor Buffer::Buffer(const Buffer& other) { buffer = other.buffer; buffer->AddRef(); } //Move constructor Buffer::Buffer(Buffer&& other) { buffer = other.buffer; buffer->AddRef(); other.release(); //Free the buffer resource of the other instance } //Destructor Buffer::~Buffer() { release(); } //Copy assignment Buffer& Buffer::operator=(const Buffer& other) { if (&other != this) { release(); //Free the buffer of this instance buffer = other.buffer; buffer->AddRef(); } return *this; } //Move assignment Buffer& Buffer::operator=(Buffer&& other) { if (&other != this) { release(); //Free the buffer of this instance buffer = other.buffer; buffer->AddRef(); other.release(); //Free the buffer of the other instance } return *this; } And this is the implementation of my child class. Is this correct?
      I'm really just wondering about the at the copy, move, and I'm not too sure about the assignment operators
      //Default constructor VertexBuffer::VertexBuffer() : Buffer() { } //Copt constructor VertexBuffer::VertexBuffer(const VertexBuffer& other) : Buffer(other) { } //Move constructor VertexBuffer::VertexBuffer(VertexBuffer&& other) : Buffer(other) { } //Destructor VertexBuffer::~VertexBuffer() { } //Not sure how to handle the copy/move operators. //Do I treat them as there own operators and copy the Buffer assignment operators code? VertexBuffer& VertexBuffer::operator=(const VertexBuffer& other) { } VertexBuffer& VertexBuffer::operator=(VertexBuffer&& other) { }  
    • By SeraphLance
      After seeing this talk (and combined with similar experiences in other languages), I got to thinking just how many times I pointlessly copy variables around.  I'm sure it's a lot, and I'm sure more experienced C++ programmers are better at catching these things (especially given how off-handed he remarks these -- like they're "duh" to everyone in the room), but it feels like I'm a bit lost as to how to actually find these sorts of mistakes.  Right now it sort of feels like an "experience through code review" thing, and that's a bit disconcerting.  Are there tools or techniques to track this sort of thing, so that I can find whether I'm spuriously making copies where I didn't intend to?
      In context, the very first example he gives is the sort of thing I'd do if I thought I was being clever.
  • Popular Now