Building an app for Ubuntu using Ogre3D, CEGUI, OIS which is now all compiling and running as expected. Having got the basic app running I decided to now build a custom config file which I can store both graphics settings (ie. resolution, fullscreen, etc) as well as other configurable settings I will need in the app down the track.
As a starting point I changed from calling mRoot->showConfigDialog() at each startup to :
if(!mRoot->restoreConfig())
mRoot->showConfigDialog();
this was meant to restore the config from the 'ogre.cfg' file which exists and so it did, but got to loading a skybox texture on the first scene create and just sat there doing nothing.
Since that wasn't what I wanted anyway I tried setting things up manually like :
RenderSystem *rs = mRoot->getRenderSystemByName("OpenGL Rendering Subsystem");
mRoot->setRenderSystem(rs);
rs->setConfigOption("Full Screen","No");
rs->setConfigOption("Video Mode","1024 x 768");
Those matched the settings from 'ogre.cfg' that I was using prior from the showConfigDialog() function. I got the same issue with this manual configuration however, while loading the skybox textures it just stops.
I can't work out why these changes have any bearing at all on how the app runs and since OIS grabs the input and locks the mouse to the screen I am having trouble trying to debug it with gdb.
Regarding the mouse locking, you can run gdb on another display. It can either be a display on the same computer (including options like Xephyr that create virtual displays nested in the current display, or just a second session on a different display - if you have a working .xinitrc running two or three X sessions at a time is simple), or it can be on another machine on your network (ie. via ssh -X).
Related
I am programming in C++ using Qt (on Windows), I have a GUI application that can be run on the command line so that users can schedule it to be run using Scheduled Tasks.
Everything was working fine (I think), except when a user tried to schedule the task with the "run when user is logged on or not" option is checked. In this instance the application would run fine, but not pop up the GUI.
I thought maybe my problem was similar to this: https://serverfault.com/questions/101671/scheduled-tasks-w-gui-issue
I thought I found the issue because my GetProcID call was returning a list of ProcessId's and I was only using the first one it returned, which caused some issues. That process ID was then passed to BringToForeground.
After this change it now brings up a transparent, or non-existent other than the application icon on some machines (basically every test except my 3 machines that can debug). Works exactly as required on my test machines.
The application works well if the GUI app is already running and you make the same call on the command line (it passes the call to that process to run). The app also works fine in normal UI mode, (no command line params passed)
EDIT:
Does anyone have any ideas what might cause this? I am thinking it has something to do with the app not starting on the correct Desktop, but don't have a ton of experience with those and have no idea where to even begin.
EDIT 2: Only seem to have the issue when it is run remotely, or through virtualization. (still confirming if this is truly the case)
I'm having problem making a permanent calibration in my embedded solution. I'm developing a Qt-based app for a Embedded Linux environment with touch screen. For this last part, I use tslib (configured by previous developers).
In what comes to simply calibrate the touch screen, everything is fine: ts_calibrate runs and creates the pointercal file correctly. If after calling ts_calibrate I run my Qt app (or ts_test), I can notice that the calibration is successful.
The problem is that the calibration results only works for 1 opening of my app: I calibrate with ts_calibrate, run my app, close it and if I run my app again, the screen is one again non-calibrated.
Now obviously I don't want to have to call the calibration each time my app is closed and reopened. The question is: how to make the calibration results become permanent? (that is, till another calibration is made)
Extra info:
I did some research on the web and I found this SO thread telling about a way to handle this problem using QWSServer. At first I disliked this solution since it depends on the Qt framework to do the job (I was expecting a more general, "C++ solution" (or a call to a script, whatever)). But I implemented it and it worked - but only in a specific case, namely, if I calibrate, open my software, close it and reopen it, then the calibration is maintained. But the problem nevertheless persists if I shut down the hardware completely, turn it on and run my app without a call to ts_calibrate (reloading the Linux kernel in the process); so this show to be only a partial solution and, therefore, not acceptable.
Trying to find the source of the problem, I created a copy of the pointercal file just after calibration and another copy of it after shutting down and turning up my hardware (and confirming that the calibration was over) and I noticed that the file was changed in the middle despite no call to the ts_calibrate or similar app was made:
After calibration:
55438 118 -1920736 -543 -36058 34531168 65536 800 480
After hardware shutdown:
-55040 1280 2526720 -288 35040 -34398240 -62768
The terminal log for the linux boot (tftp; bootm command) don't mention pointercal or a relevant calibration process.
Edit
I recently learned that the pointercal file located inside /etc/ is changing between sections because that entire folder is made new when the hardware is restarted. So what is essentially happening is that Tslib is going after a file that is constantly reset to default each time the hardware is restarted, and what I need to do is to configure Tslib not to look there, but to a more secure folder (in my case, the SD Card). The new question now is: how to do that? I know I have to configure the tslib.sh file making the TSLIB_CALIBFILE variable point to the new location of pointerscal, but tslib.shis itself inside /etc/, being itself temporary.
You have to change TSLIB_CALIBFILE in the image loaded via tftp.
That should do it, since you just have to change that once.
As used in DebugHitTestBounder in SampleApp; I have subclassed SkBounder and installed in my canvas (created in each draw) in order to find what is drawn under mouse clicks but the onIRect method is never called by the drawing routines. The commit method is called as expected (but I don't need it, I need one with a display-space converted rectangle parameter). I debugged the code, found out draw loops are managed in canvas.cpp in one place with macros (LOOPER_BEGIN and LOOPER_END) and found no place in the drawing calls that calls bounder's onIRect. Am I doing something wrong?
Note: I am using code from 2 months old master branch of git repo with XCode 4.6 in Mac OS 10.8.x. Project files are created via gyp.
Apparently, SkBounder only works on the raster backend, I was using the accelerated (GL) backend.
I'm going through Qt tutorials on OSX. One thing I noticed is that when I launch the executable (e.g. the push button hello world example), the app will launch as a background window and I have to switch tasks to bring it into the foreground. How can I force the Qt application window to be the foreground window upon execution?
I'd like to do this since it's how most apps behave, not to mention that manually switching tasks slows down my edit-compile-run-debug cycle).
The behavior you observe is due to interaction with the debugger when you start the application under the debugger using ⌘-Y. If you simply run it using ⌘-R, it behaves as you expect. Your application itself is fine.
Starting OS X applications by directly firing up the executable from within the app bundle from the terminal will act similarly to running them using ⌘-Y -- they all start in the background. Qt is probably mimicking whatever magic Finder does when it starts the process via ⌘-R -- said magic may reduce to simply bringing the child app to the foreground. gdb on OS X is not so "clever", and probably for a good reason.
OS X approach is to try harder not to steal focus -- a good thing IMHO.
If you merely want to run the application, not debug it, then modify your launch command to look like open -a '/Users/daj/foo/bar/baz.app', where baz.app is the app bundle folder. Do not append a trailing slash.
If you can coax your debugger to follow through to child processes, then you can of course launch open itself under gdb, and it will work as expected -- with your child application on top.
I started making a game, I have a global class that reads in a csv file, loads two direct x surfaces, and creates the background.
the surfaces are a tile sheet and the other the background created from the tiles. the background surface does no work, after instillation I check it and if null a message box appears. It always shows the message box.
I tried setting break points to see if the values are read in corectly fron the csv file but the program will not run. a box appears in the task bar, the program goes full screen but the screen goes black and does not show the message box and can only be stopped by ctrl,alt,del.
No matter were I put the break point even if it is in a different source file this happens. does anyone know why ?
p.s it is not a multi thread application.
Edit:
I am using visual studio 2005 and direct x 9.c
With directshow, it can be bothering to debug in full screen : if you really have to do it, I suggest either using a second screen (this way, you can debug on your screen 1 while your program runs in full screen on your screen2).
If this doesn't work, you'll have to use remote debugging (i.e. run the programm on a computer and debug on another).
Most probably, what happens is that your debug point is triggerred, but your screen is held by directshow and thus visual can't be displayed. Thus your programm is actually blocked by visual, it doesn't answer to anything (as the event loop is blocked by the debugger)
In order, I would:
run in windowed mode
run in dual screen with your debugger on other screen
try to setup remote debug (good luck)
maybe use the old good way to debug with printf / traces (log4cpp e.g.)
In visual studio, if your project is not configured in debug mode (and instead is configured as release) you will not be able to debug, so any breakpoints you set will be ignored. This could possibly be the problem.
forced it in windowed mode , you may modified or hook the application