Page 2 of 3
Future builds of VBA-M may require the VC10 runtime
Posted: Thu Oct 28, 2010 10:15 am
by Universal
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.
Future builds of VBA-M may require the VC10 runtime
Posted: Thu Oct 28, 2010 1:27 pm
by Squall Leonhart
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.
Future builds of VBA-M may require the VC10 runtime
Posted: Thu Jun 23, 2011 4:29 am
by AdamN
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 [img]<fileStore.core_Emoticons>/emoticons/smile.png[/img]/emoticons/smile@2x.png 2x" width="20" height="20" />
Â
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)
Future builds of VBA-M may require the VC10 runtime
Posted: Thu Jun 23, 2011 10:24 pm
by Squall Leonhart
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.
Future builds of VBA-M may require the VC10 runtime
Posted: Sat Jun 25, 2011 1:48 am
by AdamN
As i remember the one i changed for Release are:
C/C++>Optimization:Maximize Speed
Omit Frame Pointers:Yes
Linker Optimization>References: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 [img]<fileStore.core_Emoticons>/emoticons/laugh.png[/img]/emoticons/laugh@2x.png 2x" width="20" height="20" />
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
Future builds of VBA-M may require the VC10 runtime
Posted: Tue Jun 28, 2011 8:38 am
by AdamN
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 [img]<fileStore.core_Emoticons>/emoticons/sad.png[/img]/emoticons/sad@2x.png 2x" width="20" height="20" />
Â
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?
Future builds of VBA-M may require the VC10 runtime
Posted: Wed Jun 29, 2011 12:31 am
by Squall Leonhart
Future builds of VBA-M may require the VC10 runtime
Posted: Wed Jun 29, 2011 1:20 am
by AdamN
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\
Future builds of VBA-M may require the VC10 runtime
Posted: Wed Jun 29, 2011 9:52 pm
by Squall Leonhart
has Rev 1027 helped at all?
Future builds of VBA-M may require the VC10 runtime
Posted: Thu Jun 30, 2011 9:25 am
by AdamN
has Rev 1027 helped at all?
Â
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 [img]<fileStore.core_Emoticons>/emoticons/happy.png[/img]/emoticons/happy@2x.png 2x" width="20" height="20" />
Â
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.
Â