Apparently, my Java teacher at school doesn't know that the mouseMooved and mouseDragged events activate every few milliseconds. I had to find that myself while exercising events.
I am trying to make an applet in which you can draw stuff. Currently I can draw with a small filled circle. When I move the mouse too fast, big dots appear get drawn, instead of lines. That's because the mouseDragged event gets called every few milliseconds. I want to make the two events to get called EVERY time when the coordinates of the mouse change, no matter the speed.
I have no idea how to do that. Nor I know if the proper solution is by decreasing the interval between every capture, after overriding a certain method.
How can I capture the coordinates of the mouse's location absolutely every time they change?
EDIT:
Apparently I can't make the applet capture the coordinates every time they change. Can I decrease the time between the captures (can I increase the speed of capturing) somehow?
Related
I am currently working on a project that moves a circle from a space to space when button is pressed. I designed as following: When the button is pressed, it increments the coordinates of circle, in a for loop from 0 to 10.
The problem is, the motion I wanted with for loop doesn't show up on the screen but it only shows the object on the first and the last coordinates, so it doesn't move one by one.
Any suggestion would be appreciated,
Kutay Demireren
You need to set a frame draw length that the human eye can see in order for motion to work properly. The can be achieved in many ways, but the easiest is with a thread.sleep at the end of each for loop iteration for however long you want the different pictures to be visible for.
I've build a simple click and drag background for a program I've written which is all good and working. It adds on the distance moved by the mouse while held down. However thinking ahead I'd have to do this for all objects every time I moved the image as I was going to give the objects positions relative to the image and this might cause a few issues with processing power.
What I would like to do is have the background in a set position within the program and move the users view over the image without having to change the position of every object every tick, the problem I'm having is where to start and how to build something like this.
Thanks in advance
Well you need to tell your program where the objects are supposed to be drawn somehow.
It sounds like you are currently thinking to draw your frame by looping through your objects and drawing them at their location, and when you move the background, updating the object location.
If that method isn't sitting well with you, you could create a sort of 'map' (2-d array of pixels/locations) that you fill sections in on when you create new objects. Then when you go to draw your frame, you could scan through some range of positions in your 'map' and draw the objects that you find. When the background is moved, you could then keep the offset in a single location and use that when determining what range of map values to scan through.
i'm not positive how the processing implications of these two methods compare, i'm sure it depends on the size of your frame, level of detail, and number of objects that you have offscreen at any time.
How do I get the mouse position. I have tried:
int mouseX = MouseInfo.getPointerInfo().getLocation().x;
int mouseY = MouseInfo.getPointerInfo().getLocation().y;
But that does it for the whole screen. Anyway to do it relative to the JPanel/JFrame
If I'm only using Graphics JFrame and JPanel that is being repainted every millisecond, should I have buffers? Or will it be fine?
How do I add a mouseAcionEvent only to the frame so it gets X() and Y() of mouse but only in frame?
Use a MouseListener instead of MouseInfo. MouseListener will trigger events which are contextual to the component which raised them, which means you won't need to translate the events into the component space as the event will already be converted to within the component context.
See How to write a mouse listener for more details
How should I update my game rePaint() every millisecond or another way?
Use a javax.swing.Timer...
See How to use Swing Timers for more details...
Should I use buffers?
That will depend. Swing components are already double buffered, but if you use a more complex timing mechanism (AKA game loop), you might find it useful, even to roll your own.
I, personally, would start simple
How can I improve the way I thought out my code in the first place? Is it right having 10 loops or only all in 1 to reduce lag ect.
There are probably lots of things, but start with broader idea...
Breakdown entities to their own responsibilities, for example, the player should know where it is and how it should be painted. It could even know how it's suppose to move based on the current state of the game. This way you could create any number of entities, all with there own set of rules which are isolated and easily updated.
Devise a controller mechanism which is responsible for taking in keyboard and mouse events and simply updating the current state of the game model. That is, rather than going "the user pressed the 'left' key, move player to the left", it would simply raise a flag in the game model that the "left" state has been triggered (or untriggered) and the engine would, on the next update loop, ensure that each entity knew about the change
Don't use magic or hard coded numbers, instead provide some kind of ability to scale the scene. For example, you could decide what is shown on the screen based on the size of the window...
I am currently in the process of making a tile based 2D platformer using lwjgl. I have a character that is able to run and jump all around the map. I have run into a strange problem when moving the window. When I move the window the game will freeze which isn't a big deal because when you let go it unfreezes, but after it unfreezes my character will end up moving down a number of tiles based on how long you hold the window or move the window for. Is there anything i should know about the library and the display, or do you need to see the code for the window initialization or the physics and collision detection? I have no idea why the movement of the window would have anything to do with the players position!
Solution:
After quite a lot of thought and attempts to fix the problem, I had realized that i am using a delta in my update methods, because delta is calculated by the time between each update, because the game freezes when the window is "moved" or "grabbed" the delta value becomes very large in a short period of time causing the player or object to be moved a very large amount at once. To fix this i simply put a limit on the delta value that gets passed into my update methods so that the player would not be able to move 10+ tiles at a time.
I am currently programming a gui with JavaFX 2.0, which is resizable. When the user resizes the window, a big rectangle resizes with it. Now I need to push the new boundaries of this rectangle on to an image which floats inside the rectangle and may not cross its borders.
I thought of updating the boundaries via a ChangeListener, but I don't want it to update the boundaries that often. The perfect solution would be a "ChangeIsOverListener" which updates the boundaries once at the end of a change.
Can anybody help me out?
Thanks in advance! :)
You may be able to trap mouse-down and mouse-up events on either side of the window resizing - but whether you see those events will depend on the AWT system and may depend on the O/S too.
Otherwise you will have to use a timer within the window sizing event to trip a separate event some number of ms after the last window sizing event, such that you consider the size to be "done" if it hasn't be changed in the last, say, 1/2 a second. The amount of time will be a compromise between the user's perceived lag and the number of resizes you want to process.
Maybe you could compare the size of the window every x milliseconds, and when it doesn't change in this time interval, you know that the change is over.