So I am trying to read sensor data from an IMU and update angles accordingly. I open the sensor data file, read line by line, convert quaternion to rotations and then update my model. The problem is that when calling the glutPostRedisplay() from the while loop the loop continues while glutPostRedisplay() operates in paralell. This makes it appear that everything happens instantly. What I want to do is to force the program to halt until the display is updated.
I can't think of another way to do this because I don't want to constantly open and close a file or keep track of where in the file I currently am. It would be easier if I could just read the line, process it, then force OpenGL to render, then read the next line etc.
Does anyone have any suggestions?
Note: Currently the while loop fully executes by the time I am able to render. I have tried using glutSwapBuffers() directly after the glutPostRedisplay()
GLUT doesn't work that way. You will have to stop your loop and return from whatever function you want in order for GLUT to issue a rendering command. Generally you put this kind of stuff in an idle func.
Or you could use GLFW, which allows you to have ownership of the rendering loop. Or you could use FreeGLUT's glutMainLoopEvent, which allows you to have ownership of the rendering loop (though you need a bit of code rewriting to make this work).
Instead of using a while loop, you can register a function to be called when GLUT isn't busy with glutIdleFunc. Read from the IMU in this idle function and call glutPostRedisplay when you need to force a redisplay.
Related
I have run into a problem that I am rather stumped on because every solution I can think of has an issue that makes it not work fully. I am working on a game on the MSP430FF529 that when first powered up has two images drawn to the screen infinitely using a loop and cycle delays. I would like to have it so that when the user presses the start button (a simple high-edge trigger on a port) that the program immediately stops drawing those screens, no matter what part of the process its in, and starts executing the rest of the code that runs the game.
I could put the function that puts the images on screen in a do while loop but then it wouldn't be asynchronous as the current image being drawn would have to finish before it moved on.
I'd use the break command but I don't think that works in ISRs and only when its directly in the loop.
I could put the entire rest of the program in the ISR I use for the start button press so that the screen drawing is essentially never returned to but thats really messes, poor coding, and would cause a lot of problems later.
Essentially, I want to make it so that when the button is pressed the program will immediately jump to the part of the program that is the actual game and forget about drawing those images on the screen. Is it possible to somehow have an ISR that doesn't return to what was currently happening after the code in the routine is executed? Basically, once the program starts moving forward (the start button is pressed) I don't want to come back to the function that draws the images unless I explicitly call it again.
The only thing I can think of is the goto command, which I feel in this particular instance would not actually be too bad, though I want to avoid using it for fear of it becoming a habit due to it being a poor solution in most cases. However, that might not even work because I have a feeling that using goto in a ISR would really mess up the stack.
Any ideas? Any suggestions are appreciated.
What you want is basically a "context switch". You should modify the program counter pointer and stack pointer which will be restored when you return from the ISR, and then do the normal ISR return so the interrupt mask is cleared, stack is restored, etc. As noted in the comments to your question, this likely requires some manual assembly code.
I'm not familiar with the MSP430, but on other architectures this is in a structure of saved registers on the kernel stack or interrupt-context stack (or maybe just "the stack" on some microcontrollers), or it might be in some special registers, and it's saved automatically by the CPU when it jumps to your ISR. So you have to change these register pointers where they are.
If you relax your requirement from "immediately" to "so fast that the user doesn't notice", you can put the if (button_pressed) into some loop in the image drawing routine.
If you really want to abort the image drawing immediately, you can do so by resetting the MCU (for example, by writing a wrong password to the WDT). In the application initialization code, check if one of the causes of the reset was your own software:
bool start_button = false;
for (;;) {
int cause = SYSRSTIV;
if (cause == SYSRSTIV_WDTKEY)
start_button = true;
if (cause == SYSRSTIV_NONE)
break;
// you might handle debugging of other reset causes here ...
}
if (!start_button)
draw_images();
else
actual_game();
(This assumes that your code never accidentally writes a wrong WDT password, but even if that happens, you're only skipping the intro images.)
I have a GTK window with an image inside of it. I want this image to change. Let's say I have two images, "sun.png" and "moon.png". Once every second, I want to receieve the output of "date -f%l" to get the current hour. If the hour is between 7-19 (7 AM to 7 PM), I want to display sun.png. Else, I want to display moon.png.
Is it possible to have a seperate thread with a while loop in it, that changes the image as the program's running? How would I go about doing this?
I'm writing in C, by the way.
This isn't going to be a complete answer, but it's too long for a comment and it's important.
You definitely do not implement something like this by going into a loop sleeping for one second at a time and calling the external date command and parsing its output to determine what to do next. Not only is this a lot more work than is necessary; more importantly, it will eat your users' batteries for dinner.
Instead, you call gettimeofday or clock_gettime to determine the current time, then compute the next time in the future that the sun/moon image will need to be changed. Then, you sleep the whole interval until that time, i.e. up to 12 hours in a single sleep. If your thread wakes up early (perhaps from signals, etc.) then you just determine, on calling gettimeofday again, that it's not yet time to change, and compute a new duration of time to go back to sleep. This way, the CPU remains completely idle (and can go into powersaving mode) except when there's actually work to be done.
As for whether you can do this with a thread at all in GTK+, I'm pretty sure you can, but I'm not familiar with the GTK+ API.
I need to be able to access the X Event Loop to add clipboard support for a game API. The problem is the game API does not know which API it will use for display (It could use SDL or other). As a result, I do not have direct access to the X event loop. Is there a function in XLib to get a pointer to my display so that I can process messages and add clipboard support?
Thanks
If it runs on X11, there has to be a Display pointer in the graphics object somewhere. You can allocate a new one with XOpenDisplay(NULL); but that's not likely to achieve what you want. You'd still have to find the Windows and other info which is tricky enough when a program does it once.
You really need to dig through the existing code to find the X11 module. There's likely to be a single function that performs on iteration of the "Event Loop" as a subroutine of the real "main Processing Loop". If you can't simply add your new code there, you can at least see how the program already accesses this information.
If you're using OpenGL for graphics, you can exploit that. At some point in the program where you know, the OpenGL context is made current call glXGetCurrentDisplay. However you should be carefull not to interfere with the programs main event loop.
I've been trying to make a game using ncurses.
However, I am stumped with how to make the timing part of my main loop work.
Would someone be able to add some insight into how I could add framerate code to my main loop, while keeping portability and not compromising speed.
Thanks in advance!
The normal way to handle this type of problem I believe is to pass in the duration since the last loop (often called delta) as a parameter to the system. This allows you to update the progress of entities in the game based on the amount of real world time that has passed. For example:
new_position = old_position + delta*speed
This allows entities in your game to move at a constant speed independent of the frame rate of your program.
Assuming you have functionality to update your gamestate after a small period of time, next you need to be able to poll the user for input. If you do not specify otherwise, ncurses will block when you ask for input. To prevent this, look up the init functions here. In particular, the halfdelay() function may be of use of you (it implements a sort of framerate).
Just remember to check for ERR on the return value of getch() when using this mode.
I want to write a C program that will sample something every second (an extension to screen). I can't do it in a loop since screen waits for the program to terminate every time, and I have to access the previous sample in every execution. Is saving the value in a file really my best bet?
You could use a named pipe (if available), which might allow the data to remain "in flight", i.e. not actually hit disk. Still, the code isn't any simpler, and hitting disk twice a second won't break the bank.
You could also use a named shared memory region (again, if available). That might result in simpler code.
You're losing some portability either way.
Is saving the value in a file really my best bet?
Unless you want to write some complicated client/server model communicating with another instance of the program just for the heck of it. Reading and writing a file is the preferred method.