I am creating a game in GMS2. I am using "show_message_async()" in my code. I know that when it is run, a message pops up on the screen and the game still runs in the background. However, I want the game to freeze in the background while the message pops up. Is it possible to do this? And if so how.
You should try looking up instance_deactivate_all(notme) and instance_activatie_all(notme)
https://docs.yoyogames.com/source/dadiospice/002_reference/objects%20and%20instances/instances/deactivating%20instances/index.html
This will disable all objects in a room except the object that's calling it (which should be the menu object that shows the message)
The only tricky part of it, it that it also disables drawing the objects. resulting in an empty screen. For this, you could either use a black screen, or draw a screenshot of the scene before they're disabled.
I agree with Steven's answer. To add on his answer about taking the screenshot of the game, you probably need to make a new surface, then use surface_copy from application_surface before deactivating the object.
Related
So far I've created an object called obj_mouse. And my plan is whenever the player left clicks, it spawns a bullet from him toward where ever the mouse is pointing. I've got the concept down, but I'm struggling getting it to work.
Extra bits of code I'm messing around with to try to get it to work:
bullet=instance_create(x,y,obj_bullet)
with (bullet) {
move_towards_point(mouse_x,mouse_y,5)
image_angle=direction
}
point_direction(obj_mouse,obj_mouse,obj_mouse,obj_mouse)
image_angle=direction
(In the above code, I have not attempted to specify to the program that I want the bullet to go in the direction of obj_mouse, or rather, just the mouse. The above code works, and bullets do shoot, however the player must have the mouse on the players sprite for it to work.)
Thank you in advance for any advice given.
The fix was applying the piece of code to a global mouse click event, so that it does not call the code from the object being left clicked rather it calls the code when left click is clicked.
Something seems to have changed in Qt 5: you can't get a drop or move event if you don't move at least one pixel from the start point where you were when QDrag::exec() was called. Try putting a breakpoint in the dropEvent of the Draggable Icons Sample, then click a boat and release it without moving the mouse. That generates an "ignore" without any drop signal.
(This is on Kubuntu 13.10 with Qt 5.1.)
When teaching how to start a drag operation, the documentation suggests you might use manhattanDistance() to determine if the mouse has moved enough to really qualify as "the user intending to start a drag". But you don't have to use that; you can start up a QDrag on the click itself.
Anyone know of a workaround to have that same kind of choice on the drop side, or is that choice gone completely? :-/
Why I care: I've long had frustrations trying to get a tight control on mouse behavior in GUI apps—Qt included. There seems to be no trustworthy state transition diagram you can draw of the invariants. It's a house of cards you can disprove very easily with simple tests like:
virtual void enterEvent(QEvent * event) {
Q_ASSERT(!_entered);
_entered = true;
}
virtual void leaveEvent(QEvent * event) {
Q_ASSERT(_entered);
_entered = false;
}
This breaks all kinds of ways, and how it breaks depends on the platform. (For the moment I'll talk about Kubuntu 13.10 with Qt 5.1.) If you press the mouse button and drag out of the widget, you'll receive a leaveEvent when you cross the boundary...and then another leaveEvent when the button is released. If you leave the window and activate another app in a window on screen and then click inside the widget to reactivate the Qt app, you'll get two consecutive enterEvents.
Repeat this pattern for every mouse event, and try and get a solid hold on the invariants...good luck! Nailing these down into a bulletproof app that "knows" it's state and doesn't fall apart (especially in the face of wild clicking and alt-Tabbing) is a bit of a lost cause.
This isn't good if your program does allocations and has heavy processing, and doesn't want to do a lot of sweeping under the rug (e.g. "Oh, I was doing some processing in response to being entered... but I just got entered again without a leave. Hm, I guess that happens! Throw the current calculations away and start again...")
In the past what I've done is to handle all my mouse operations (even simple clicking) with drag & drop. Getting the OS drag & drop facility involved in the operation tended to produce a more robust experience. I can only presume this is because the testers actually had to consider things like task switching with alt-Tab, etc. and not cause multiple drop operations or just forget that an operation had been started.
But the "baked in at a level deeper than the framework" aspect actually makes this one-pixel-move requirement impossible to change. I tried to hack around it by setting a timer event, then faking a QMouseEvent to bump the cursor to a new position once the drag was in effect. However, I surmise that the drag and drop is hooked in at the platform level, and doesn't consult the ordinary Qt event queue: src/plugins/platforms/xcb/qxcbdrag.cpp
The issue has--as of 1-May-2014--been acknowledged as a bug by the Qt team:
https://bugreports.qt-project.org/browse/QTBUG-34331
It seems that me bountying it here finally brought it to their attention, though it did not generate any SO answers I could accept to finalize the issue. So I'm writing and accepting my own. Good work, me. (?) Sorry for not having a better answer. :-/
There is another unfortunate side effect of the Qt5 change, pointed out by a "Dmitry Mordvinov":
Same problem here. Additionally app events are not handled till the first mouse event after drag started and this is really nasty bug. For example all app animations are suspended during that moment or application hangs up when you try to drag with touch monitor.
#dvvrd had to work around it, but felt the workaround was too ugly to share. So it seems that if you're affected by the problem, the right thing to do is go weigh in...and add your voice to the issue tracker to perhaps raise the priority of a solution.
(Or even better: patch it and submit the patch. 'tis open source, after all...)
I'm trying to fiddle a bit with a Qt example regarding 2D Graphics.
Basically it is a small diagram editor. In the example, the author explains that the tracknodes() function is used to update the line's endpoints, when the user drags a connected node into a different position.
This actually does not happen. After looking at the code, I have the feeling it's because there is no event being called after moving the node QGraphicItem, in order to update the link's rendering.
I figured I have to find out where and how the QGraphicItem's movement is handled in order to send a wasDropped signal (or something like that) to a slot that re-renders the link. Does this make sense?
I'm pretty new to Qt/C++ in general, so I don't have a very clear idea on how to achieve this, does anyone have any pointers he/she could share?
He seems to be using the QGraphicsItem::itemChange virtual function to call the tracknodes() function which draws the lines. ItemChange should be called every time a node is moved. It's called in other cases as well but he only uses it for tracking the movement of the QGraphicsItem.
I'm using a progress bar to let a user know how much more live streaming video data is to be buffered before it starts playing. Have that much working fine.
Problem is, if the buffer gets used up, and I need to rebuffer, I can't seem to get the progress bar reset and visible again. Seems once it hits 100% on app start up it can't be reused. What am I missing here?
I'm catching the proper NetStream.netStatus events. The hook for the empty buffer is there and is executing. I'm just not seeing how I might redisplay and start a fresh bar there?
I've tried bar.visible = true and nothing appears. Also tried making a new one and setting visible each time the buffer is empty but no dice. Seems to just be ignored.
you can force the progress bar to reset "pBar.setProgress(0,100);", that will set it back to 0. just manually do that when you know that you have to rebuffer.
No, destroying the old one and making a new one with the same id.
That seems to be kind of working, but I'm not really sure what the best practice is here. Should I be making new ones each time I need to display one? Isn't there a way to simply recall the old one to the screen and reset it's progress to zero?
Is there a way to force a JavaFX app to repaint itself before proceeding? Similar to a Swing Panel's paint(Graphic g) method (I might be getting the keywords wrong there).
Consider the following example: you write a TicTacToe app along with the AI required for a computer player. You would like the ability to show two computer players duke it out. Maybe you put in a two second pause between computer turns to give it a life-like affect. When you hit your "Go" button, there's a large pause of unresponsiveness (the time it takes for the 9 turns to go by with faked pauses for the computer to 'decide') and then suddenly the app's visual is updated in with the completed game's state.
It seems like JavaFX repaints once processing in the app's thread is finished? I'm not completely sure here.
Thanks!
You are right. JavaFX is event-driven and single-threaded. This means that repaint and event response can not be done simultaneously. Long-running task should be executed on separate thread so they do not block the rendering of the UI, When the task is finished it can sync back to the FX thread by calling FX.deferAction() which will simply execute the code on the main thread.
This won't be the most helpful answer as I have toyed around with JavaFX for all of half a day, but wouldn't you use Timelines, Keyframes, and binding to accomplish your repaints instead of calling them explicitly like you have described?
See this tutorial for an example.
JavaFX's model is to separate you from the painting of the "stuff" on the screen. This is very powerful but is a change from how you might be familiar with.
whaley is correct that the appropriate way of doing this in JavaFX is to make a timeline where the move is done every X seconds and will be drawn at that keyframe.
If you have a question about how to do this, try it and make a new question with some code.