Future builds of VBA-M may require the VC10 runtime - Printable Version
+- VBA-M Forums (http://vba-m.com/forum)
+-- Forum: General Discussion (/Forum-general-discussion)
+--- Forum: News and Emulation Updates (/Forum-news-and-emulation-updates)
+--- Thread: Future builds of VBA-M may require the VC10 runtime (/Thread-future-builds-of-vba-m-may-require-the-vc10-runtime)
Pages: 1 2
Future builds of VBA-M may require the VC10 runtime - Squall Leonhart - 10-01-2010 02:55 PM
since some of us have moved over to using VS2010, not to mention the improved intrinsics and better code gen SSE optimisations (2008 was buggy in this regard), future builds of VBA-M for Windows may require the Visual C+ 2010 x86 runtime.
If/when this change takes place, the readme.mfc will be updated with the VC10 download links.
RE: Future builds of VBA-M may require the VC10 runtime - JRMoore - 10-10-2010 10:13 AM
Hello Squall Leonhart, about the VC++ 2010 runtime I don't think it will be necessary even building with VS2010.
Right now the project files are set to use the /MT switch which creates executables linked to the static version of the runtime (multi-threaded, the single threaded version is long dead). I've just checked the latest executable build with Dependency Walker and there's no dependency on the C runtime. The only remarkable one would be the updated DirectX runtime (you can remove zlib from the readme file too as you're linking statically against it).
I've just compiled SVN959 using the compiler provided in the Intel Parallel Studio 2011 through Visual Studio 2010 (changing some settings), the only dependency not included in Windows (7 in my case) is D3DX9_43.DLL; I've attached to this post a binary using SSE instructions. I'm using up to SSSE3 instructions for me, If you need a binary using a specific instruction set (e.g. SSE2 to allow the use of XMM registers) just tell me and I'll generate the binaries.
RE: Future builds of VBA-M may require the VC10 runtime - Squall Leonhart - 10-10-2010 09:01 PM
we build with what we have on hand, many of us have moved to vc 2010 already and have no interest using GCC.
usage of Intel compilers is not likely as applications compiled by this and used on non intel processors have dramatically lower performance.
RE: Future builds of VBA-M may require the VC10 runtime - JRMoore - 10-10-2010 10:00 PM
Yes, GCC in no option in this project and I was aware of that problem with Intel compilers (at least years ago it was crazy, I don't know how if behaves now). I only have access to the new Parallel Studio through my employers and was doing some tests.
The important bit is that the binaries are being built with the runtime within the executable of VBAM, so there's no need for end users to install the VC runtime. If you changed the runtime library to multi-threaded DLL (/MD switch) and set MFC to use the DLL too, VBAM would be depend on msvcrXX, msvcpXX and mfcXX (so the redistributable package would be needed). Although the executable would be smaller, you'd lose the portability it now has.
EDIT: The binary I posted above is not tied to any Intel processor. Optimizations and alternative paths for Intel specific processors were not selected.
RE: Future builds of VBA-M may require the VC10 runtime - Squall Leonhart - 10-10-2010 10:05 PM
That could explain the sudden balloon in size with vc10
RE: Future builds of VBA-M may require the VC10 runtime - JRMoore - 10-10-2010 10:34 PM
That may be, It was the same with VS2008 as the runtime and standard C++ library were included too (no dependency on msvcr90.dll, msvcp90.dll or mfc90.dll) but runtime and MFC in VS2010 are slightly bigger (same as the other three but 100 instead of 90).
I know some people for small programs link against the system CRT dynamically (no version number in the files) because it's already loaded and shared in memory so they get lower disk footprint, memory usage and startup. But if I recall correctly that's not possible in Visual Studio, nor desirable either for a big program. Those files are meant to be used for system components, they are not as complete/efficient as the ones provided with newer versions of VS.
RE: Future builds of VBA-M may require the VC10 runtime - Squall Leonhart - 10-11-2010 10:31 AM
Quote:Yes, GCC in no option in this project and I was aware of that problem with Intel compilers (at least years ago it was crazy, I don't know how if behaves now). I only have access to the new Parallel Studio through my employers and was doing some tests.
it still is a problem, it was recently demonstrated on a the VIA Nano
RE: Future builds of VBA-M may require the VC10 runtime - JRMoore - 10-11-2010 08:54 PM
:O Impressive... even Agner Fog is involved!!! What a difference in the VIA Nano tests...
I know there are some switches to add alternative paths or to target an specific Intel processor family. /Qax adds a processor specific auto-dispatched code path in addition to the default one (so you're already knowing the dispatcher will be in the executable if you use this one). /Qx overrides the /arch switch targeting an Intel processor family and the executable should only be used on those (e.g. /QxSSE3_ATOM generates code to be used in an Atom processor).
The Parallel Studio provides a compiler too through the Parallel Composer which is the C/C++ compiler from Intel as generally released. The the latest version includes the v12 compiler (not available as of now, the latest standalone C/C++ compiler from Intel is v11); but there's already a post by Agner where he tells they haven't changed a thing in the new compiler .
If you ever need to use the Intel compiler in page 130+ of Agner's optimizing C++ (at the time of writing, works with v12 compiler) there's a way to override the dispatcher detection .
Thank you for pointing that out!
EDIT: For completeness I made a question to Agner regarding the use of the Intel Compiler without the switches /Qx or /Qax . Basically, if only /arch was used during compilation there's no dispatcher and the code generated will run fine in non-Intel processors. Unless special libraries are used by the project like MKL, TBB, ... (not the case in VBAM).
RE: Future builds of VBA-M may require the VC10 runtime - Universal - 10-28-2010 11:53 AM
I've been working on an installer for the VBA-M. As far as I can tell, it is complete. It will install the emulator to a folder inside the user's home directory, so it won't have issues with privileges and administrators. It will make all the folders and even makes the ini file for some preconfiguration, namely the folders where things go, like the save states, battery saves, screen shots, etc.
If you wish, I can upload both the installer itself, which is a surprising 1.11 MB big as well as the NSIS code used to make it. It's easily customizable, able to be updated to reflect any new builds. It installer will install the latest SVN at the time, which is 965.
As for uninstalling, just delete the folder the emulator was installed in.
RE: Future builds of VBA-M may require the VC10 runtime - Squall Leonhart - 10-28-2010 10:08 PM
installers are stupid. vba-m is portable for good reason.
RE: Future builds of VBA-M may require the VC10 runtime - Universal - 10-29-2010 12:15 AM
My apologies. I just thought it would be easier for others to be able to run the program without having to look for it or remember where they extracted it to. But even though it's portable, the problem is that it saves it's ini file into the user's appdata folder, meaning that it isn't entirely portable.
If they were to use the program on a usb thumb stick on one computer, but then play it on another, they would lose their configurations like where they put their save states, if they are using bios files, and what not.
So, for true portability, it would require the ini file to be made inside the same folder as emulator. Plus, the installer can be remade with portability in mind. They use NSIS is the installer for PortableApps.com programs.
But all in all, I won't make an installer if you don't think it would be a good idea. Oh, and I also realized I might have posted this bit in the wrong thread, possibly even should have made my own. My apologies there as well.
RE: Future builds of VBA-M may require the VC10 runtime - Squall Leonhart - 10-29-2010 03:27 AM
the ini thing is something to be fixed, it should prompt the user on where to store configuration and rom directories at start, it was originally intended to do so, but for now it just checks where the ini is first.
RE: Future builds of VBA-M may require the VC10 runtime - AdamN - 06-23-2011 06:29 PM
I also think the optimization settings need to be tweaked a bit,
when i compiled svn1024 with the original project settings and my tweaked project settings, my settings seems to get 10% FPS improvement and 3% file size reduction
Btw, why did Checkmarking the Link Options from the Menu causes performance to drops from 100% to 41%(45% with my tweaked optimization)? it's not even connected yet -.-a the old VBALink1.8 doesn't have this behavior (until you're connected of course)
RE: Future builds of VBA-M may require the VC10 runtime - Squall Leonhart - 06-24-2011 12:24 PM
what tweaked project settings do you use?
if you're going to say PGO, i don't even bother with that crap because different systems will behave differently to PGO.
Linking isn't even functional in vbam, so why checkmark anything.
RE: Future builds of VBA-M may require the VC10 runtime - AdamN - 06-25-2011 03:48 PM
As i remember the one i changed for Release are:
Omit Frame Pointers:Yes
Netwide Assembler>Branch Offset Optimization:Optimize
And then i rebuild everything
Regarding the Link options, usually i plays using GBALink where i have Link enabled(since i play it with my brother often in LAN), so when i run vba-m at first i thought it was d3d/opengl that causing the slowdown(because d3d/opengl are slower than directdraw in vbalink so i use directdraw), but apparently it was the link that causing the slowdown XD
anyway i fixed that link slowdown, and i'm planning to get the link working later(when i had the time) based on gbatek 2.6a which has more networking info than the official gbatek 2.5
RE: Future builds of VBA-M may require the VC10 runtime - AdamN - 06-28-2011 10:38 PM
Btw, does anyone able to use breakpoint for debugging VBA-M in Visual Studio?
I've been trying to debug it for days but unable to make breakpoints to works with VisualBoyAdvance-M.exe T_T
All symbols from the other DLLs (kernel32.dll, etc) are able to be loaded successfully except VisualBoyAdvance-M.pdb eventhough the pdb were built at the same time with the exe and in the same location also, it keeps saying that the pdb is not matching with the exe when i tried to load it manually
i've tried to clean the solution and rebuild everything many times but it still saying the same thing.
So i wonder if anyone here manage to set breakpoints properly in the source code?
RE: Future builds of VBA-M may require the VC10 runtime - Squall Leonhart - 06-29-2011 02:31 PM
are you using VS2008?
RE: Future builds of VBA-M may require the VC10 runtime - AdamN - 06-29-2011 03:20 PM
i'm using vs2010, but based on what i found at Ms site many people seems to find the same problem with pdb since vs2005
When i tried to set the secondary(stripped) pdb, it seems it was able to load the pdb from the secondary one, but the main pdb still don't match with the exe, and with the secondary pdb breakpoint still don't works T_T
Edit: When i tried to change the output of the main pdb to where my secondary located and then rebuild it w/o the secondary pdb, it seems to be able to load the full symbols successfully O_o
i still don't know why when locating the pdb at the same place with the exe always considered unmatched -.-a oh well as long i can use breakpoint i can move on now.
I put the project in C:\VSProjects\VBA-M\ and my secondary pdb was located in C:\Symbols\
RE: Future builds of VBA-M may require the VC10 runtime - Squall Leonhart - 06-30-2011 11:52 AM
has Rev 1027 helped at all?
RE: Future builds of VBA-M may require the VC10 runtime - AdamN - 06-30-2011 11:25 PM
i'm still using the PreWx 1024 since i'm not using SVN to download the source (i downloaded it in a single archive from SF), i don't quite understand how to works with svn ^_^
Anyway, i think it was vs2010 bug, because changing the pdb output path in the linker to C:\blahblah\ worked properly.
Btw, when running from vs2010 in Debug mode and then exiting the VBA-M seems to shows "Memory leaks!" warning in the output tab.
I'll try the latest svn to see whether it has the same problem.