..:: PCSX2 Forums ::..

(05-10-2010, 04:59 AM)rama Wrote: [ -> ]I strongly advise you to keep using VS2008.
Especially the people that distribute these builds.
The differences in compilers and our highly random bugs (IPU coroutines for example) could create bogus bug reports.

In time we will switch to VS2010, but not yet.

I agree with this statement 100%.
I still recall bugs in 2008 that caused mis-compiles. had to stick with 2003 for a little while.
If MS says something is "RTM" that just means its a passable beta... wait until at least SP1 to make the switch.

Plus the fact they aren't really paying attention to the sol so you have to add each new includes update manually hunting it down and putting it in the logical spot is not for the faint of heart.

Yeah it's just too much trouble to support 2 micrsoft IDEs that have completely different build systems. We will be switching to VS2010 eventually; just not quite yet. I still have other more pressing matters on PCSX2 before I spend the week (or more) it'll take me to make a proper VS2010 build system (it requires a complete rewrite of the build system to be done properly).

I don't doubt it bjusty by looking at how it builds now. Though I was mildly amused clicking through folders and finding things stored in different places throughout the two builds so I was like this is missing wait not it's over here.

My error on compiling

directx sdk directories ok
glew directories ok
nvidia sdk ok

show 110 erros and 9 Warnings

Basically a bunch of missing files that should be included in the solution that aren't is at least 75% of the errors I see there. However I'm not quite sure which file has destroy yet I need to look at the svn history to find it.

if you are using vs 2010, change line 6 of heapallocator.h to

std::_Destroy( _Ptr );

try again and tell me how it went...

(06-02-2010, 11:23 PM)mArgAAle Wrote: [ -> ]if you are using vs 2010, change line 6 of heapallocator.h to

std::_Destroy( _Ptr );

try again and tell me how it went...

worked for me, thanks.

Hi, I´m having trouble compling pcsx2 in visual studio 2010. If i include the file GameDatabasePanel.cpp i get this error message:

Is there any pragma, define or something that i'm missing?

Thanks

Edit:

That is the code that seems to be causing the problem. I guess that the compiler cannot distinguish between that operator and the default one.

(06-07-2010, 11:40 PM)mArgAAle Wrote: [ -> ]Hi, I´m having trouble compling pcsx2 in visual studio 2010. If i include the file GameDatabasePanel.cpp i get this error message:

Code:

Error 1    error C2666: 'operator |' : 2 overloads have similar conversions C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\istream    1042 1 pcsx2"

Is there any pragma, define or something that i'm missing?

Thanks

Edit:

Code:

template< typename WinType >
pxWindowAndFlags<WinType> operator | ( WinType* _win, const wxSizerFlags& _flgs )
{
    pxWindowAndFlags<WinType> result = { _win, _flgs };
    return result;
}

template< typename WinType >
pxWindowAndFlags<WinType> operator | ( WinType& _win, const wxSizerFlags& _flgs )
{
    pxWindowAndFlags<WinType> result = { &_win, _flgs };
    return result;
}

That is the code that seems to be causing the problem. I guess that the compiler cannot distinguish between that operator and the default one.

I got this code to compile with a bit of a kludge of a solution. Basically you have to define a more specific version of the templated operator| so that the compiler will use the built-in version rather than trying to guess and being unable to choose between two very generic operator|s. I added the following code to pcsx2\File_Reader.h before the line 'class File_Reader {':
This will make the compiler choose the built-in operator rather than the pxWindowAndFlags version (int is a dummy type, so this kludge is rather fragile and will likely break anything that uses GameDatabasePanel.cpp as well as File_Reader.h) but it does compile correctly and as far as I can tell, runs games properly and is able to search the Game Database, so at the very least, it's a good enough workaround until someone comes up with something better.