(I am using Codeblocks on Debian Linux with the GNU GCC Compiler)
I created a game with sfml and everything works really well unless i implement the usual
while (window->pollEvent(event)){
//optional code
}
loop.
I have tried the same code on Windows with MS Visual Studio and it worked perfectly fine. The game still laggs a lot even when I only execute the
window->pollEvent(event);
line only once, even if there is no event at all. Why does that line of code take so much time? (It takes as much time as about 10 frames would take without it).
Try doing window.pollEvent(event) instead of window->pollEvent, I have never seen this form of using pollEvent until now..
Related
I am currently testing the GTK Application that I built on windows using the MSYS2 64bit shell.
For the program to be able to run outside of the shell, I packed all the required DLLs with it as well as the following:
FOLDER\lib\gdk-pixbuf-2.0\2.10.0\loaders\\*
FOLDER\lib\gdk-pixbuf-2.0\2.10.0\loaders.cache
FOLDER\share\glib-2.0\schemas\gschemas.compiled
FOLDER\share\icons\Adwaita\\*
FOLDER\share\icons\hicolor\\*
The good news is: It works :) And it also works flawlessly on another PC that doesnt have GTK/Msys2/whatever installed.
The bad news is: On yet another PC (I have tested it on 2 other Systems other than my developing System so far, one one of them it works flawlessly), the program itself works, but the GUI is not rendered sharply (texts are blurry).
Do you guys have any idea on what could be the reason for that? I'm guessing it could be one of the following:
The affected system could have some general display problems that have nothing to do with my app.
The gschemas.compiled file does not suit the affected system. In that case I would probably have to create that file dynamically, but I have no idea how to do this.
I am missing some file from GTK or Glib that would solve the problem.
I am thankful for any help :) Compiling/Deploying a GTK App for Windows has proven to be a pain in the ***, but since (almost) everything works now, I feel like its not much that I am missing unless I have overseen something critical.
Regards,
tagelicht
Given the way you created your package, my bet is that you are missing some components, making the drawing code use some fallback routines, hence the "sharp" drawing.
Try to run the application in command line on the machine where your have the problem, to see if there are some unusual warnings you don't have when running it on your machine.
See also my answer on how to distribute a GTK+ application on Windows.
Why does making a C/C++ app take very long compared to other apps (Java for example).
I am trying to build Ubuntu Unity, and it takes about 4 minutes on my local machine.
I think the process of Generating object files is the one that take most time.
Any advice?
If you want to speed up code generation you can use ccache. Also you can take a look at gcc version as older versions are known to lag behind. Clang also supersede them a lot.
I'm not touching compilation speed bacause this is a HUGE topic. Starting from that C/C++ is a fully compilable languages, while in Java you never compile to the machine codes, you just generate a bytecode leaving everything else to the VM.
The reasons I want to move are:
Compile speed. About a minute with gcc, 15 minutes with MSVC. Admittedly, the code I'm compiling is a ball of spaghetti, but it is the code I have to work with on a daily basis. Sure, I don't expect gcc would magically take my compile times down to a minute, but I do expect it to compile files a lot faster.
Slow debugging: Its been close to a year now, using VS2010 trying to debug on Windows is a nightmare - it is so slow, it is unusable. Yes, I've tried deleting my .suo, closing the autos window, unplugging myself from the network and dancing around a fire three times under the full moon, to no avail.
So my question is: How do I get my code, which makes heavy use of the Windows APIs and MFCs to build on GCC? Rather, what would be the simplest route?
Another developer at work told me it wouldn't work for some reason specific to Visual Basic 6 applications.
But I think it should work as long as you include the correct DLLs and runtime files, isn't VB6 compiled to machine code?
EDIT: I just mean in general should it be possible. I'm going to actually test this out in a few days as long as nobody gives me a theoretical reason it won't work.
EDIT 2: I think the developer was referring to P-code, which vb6 can optionally compile to instead of binary which runs under a virtual machine similar to (or the precursor of) the .Net framework.
I've tested a large VB6 app in Wine under Ubuntu. Event the msi installer worked fine. Had some troubles with low-level implementation details (e.g. in NM_CUSTOMDRAW on CDRF_NOTIFYITEMDRAW phase the hDC text is not transparent by default as in Windows common controls). So yes, even heavily subclassed stuff works. I just had to iron those minor glitches.
Here is a function that checks if app is running under wine
Property Get IsWine() As Boolean
IsWine = (GetProcAddress(GetModuleHandle("kernel32"), "wine_get_unix_file_name") <> 0)
End Property
Take a look at this http://appdb.winehq.org/objectManager.php?sClass=application&iId=7361
It looks like you can get most VB6 programs to work.
I'm having a problem getting OpenMP and OpenCV to play nicely with a new project in Xcode. The project in its current state does nothing but grab frames from the default camera and put them into a window. This functionality works. However, I would like to grab the frames in a separate thread, and I was hoping I could get some experience with OpenMP.
Merely checking the checkbox to enable OpenMP in Xcode wreaks havoc. The program, while it will compile, load and run just fine, will not respond to any events -- period. It just sits there, drawing grabbed frames. (I do get the OS X beachball, too, even though it's running fine.) I eventually have to force quit the app or kill it from Xcode. Keep in mind I get this behavior even without any OpenMP #pragmas -- I have only to enable the option in Xcode.
Any ideas on how to solve this?
I'm just guessing here. You might need to make sure that all OpenGL drawing commands are called from one thread.