This site requires JavaScript, please enable it in your browser!
Greenfoot back
Twitter Twitter.hover
Transpire
Transpire wrote ...

2011/5/8

Actor Falls Through World; Cartesian Coordinates

1
2
Transpire Transpire

2011/5/8

#
In my greenfoot world, positive y coordinates run downwards. This is confusing the heck out of me; why does setLocation(int, int) behave like such? I resolved my second issue. Finally, Greenfoot is retaining state across installations. This is a fresh install, but it remembers my last opened project.... Finally, I have the following error from my last install...
# # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6d166b30, pid=4992, tid=976 # # JRE version: 6.0_24-b07 # Java VM: Java HotSpot(TM) Client VM (19.1-b02 mixed mode windows-x86 ) # Problematic frame: # C # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x0ec70800): JavaThread "AWT-Windows" daemon siginfo: ExceptionCode=0xc0000005, reading address 0x00000000 Registers: EAX=0x0f86f7f4, EBX=0x0f9f08b0, ECX=0x000003de, EDX=0x000000c0 ESP=0x0f86f7dc, EBP=0x0f86f988, ESI=0x00000000, EDI=0x000000c0 EIP=0x6d166b30, EFLAGS=0x00010216 Register to memory mapping: EAX=0x0f86f7f4 0x0f86f7f4 is pointing into the stack for thread: 0x0ec70800 "AWT-Windows" daemon prio=6 tid=0x0ec70800 nid=0x3d0 runnable java.lang.Thread.State: RUNNABLE EBX=0x0f9f08b0 0x0f9f08b0 is pointing to unknown location ECX=0x000003de 0x000003de is pointing to unknown location EDX=0x000000c0 0x000000c0 is pointing to unknown location ESP=0x0f86f7dc 0x0f86f7dc is pointing into the stack for thread: 0x0ec70800 "AWT-Windows" daemon prio=6 tid=0x0ec70800 nid=0x3d0 runnable java.lang.Thread.State: RUNNABLE EBP=0x0f86f988 0x0f86f988 is pointing into the stack for thread: 0x0ec70800 "AWT-Windows" daemon prio=6 tid=0x0ec70800 nid=0x3d0 runnable java.lang.Thread.State: RUNNABLE ESI=0x00000000 0x00000000 is pointing to unknown location EDI=0x000000c0 0x000000c0 is pointing to unknown location Top of Stack: (sp=0x0f86f7dc) 0x0f86f7dc: 0f86f7f4 00001000 000005fa 0f9e8768 0x0f86f7ec: 000003e8 000005fa 0f9e8768 6d15ed4b 0x0f86f7fc: 00000000 0f9e89e4 0f9e8768 0f9e8768 0x0f86f80c: 0f86f7ec 0f86f988 000003e8 000005fa 0x0f86f81c: 0f9e8768 6d16271f 44bf4000 447a0000 0x0f86f82c: 000005fa 000003e8 0f9e89d0 6d1631e1 0x0f86f83c: 6d16367d 00000000 00000015 000005fa 0x0f86f84c: 000003e8 00009824 0ec70918 00000001 Instructions: (pc=0x6d166b30) 0x6d166b20: 05 00 20 00 00 50 c1 e2 05 8d 44 24 14 50 8b fa 0x6d166b30: 8b 16 57 c1 e1 05 51 56 ff 52 2c 85 c0 0f 8c 93 Stack: , sp=0x0f86f7dc, free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C C C C C C C C Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j sun.awt.windows.WToolkit.eventLoop()V+0 j sun.awt.windows.WToolkit.run()V+52 j java.lang.Thread.run()V+11 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x0fa08000 JavaThread "D3D Screen Updater" daemon 0x0fa06800 JavaThread "main" 0x0fa07400 JavaThread "SimulationThread" 0x0fa06400 JavaThread "AWT-EventQueue-0" 0x0f9e7400 JavaThread "AWT-Shutdown" 0x0f9d2000 JavaThread "RMI Reaper" 0x0f9d1800 JavaThread "RMI TCP Accept-0" daemon 0x0f983800 JavaThread "GC Daemon" daemon 0x0f983000 JavaThread "RMI RenewClean-" daemon 0x0f982c00 JavaThread "RMI Scheduler(0)" daemon 0x002c9c00 JavaThread "DestroyJavaVM" 0x0ec72800 JavaThread "BlueJ worker thread" =>0x0ec70800 JavaThread "AWT-Windows" daemon 0x0ec6ec00 JavaThread "Java2D Disposer" daemon 0x0ebc5400 JavaThread "Low Memory Detector" daemon 0x0ebbac00 JavaThread "CompilerThread0" daemon 0x0ebad800 JavaThread "JDWP Command Reader" daemon 0x0ebabc00 JavaThread "JDWP Event Helper Thread" daemon 0x0ebaa800 JavaThread "JDWP Transport Listener: dt_shmem" daemon 0x0eb9f400 JavaThread "Attach Listener" daemon 0x0eb96800 JavaThread "Signal Dispatcher" daemon 0x0eb95800 JavaThread "Surrogate Locker Thread (CMS)" daemon 0x0eb6ac00 JavaThread "Finalizer" daemon 0x0eb66400 JavaThread "Reference Handler" daemon Other Threads: 0x0eb61400 VMThread 0x0ebd6c00 WatcherThread VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap par new generation total 14784K, used 12444K
Transpire Transpire

2011/5/8

#
static double map(double x) { return 750 - x; } static int map(int x) { return 750 - x; } This is my kludge. I always forget to use it...
davmac davmac

2011/5/9

#
That big error log you post is from the JDK - so it's a JDK bug, not really a Greenfoot bug. Try updating your display drivers if possible as it looks like it might be display related. As to the co-ordinate system: one arbitrary co-ordinate system is really as good as any other. (For historical reasons, lots of computer software uses a system in which downwards is positive on the y-axis. The reason has to do with how the display memory is laid out and how CRT monitors refresh their image - from top to bottom).
Transpire Transpire

2011/5/10

#
Well yes, but it's 2011. One arbitrary coordinate system is not as good as any other. Does it make sense to think upside down - that setLocation(getX(), getY() + 5) should move you down? Also - any idea why performance in my scenarios is so bad, especially when it comes to setting images? For example, both the book scenario piano-complete and my current project - reimplementation of DoodleJump - have noticeable lag when changing images, wheras, people have made very responsive wave simulators. Also, is there a way to move the current world location? Unbounded worlds don't help very much if the viewpoint is fixed. Can you tell me how images are positioned for images that have even widths or heights?
davmac davmac

2011/5/10

#
Transpire wrote...
Well yes, but it's 2011. One arbitrary coordinate system is not as good as any other. Does it make sense to think upside down - that setLocation(getX(), getY() + 5) should move you down?
Why does it make more sense that it should move you up?
Also - any idea why performance in my scenarios is so bad, especially when it comes to setting images? For example, both the book scenario piano-complete and my current project - reimplementation of DoodleJump - have noticeable lag when changing images, wheras, people have made very responsive wave simulators.
If you're constructing new images each time, then the image has to be loaded from disk and de-compressed. Typically people solve this problem by having static variables hold copies of the images that are needed.
Also, is there a way to move the current world location? Unbounded worlds don't help very much if the viewpoint is fixed.
No, there's not. If you want to have a "view point" you have to simulate it by moving the objects within the world and changing the background yourself.
Can you tell me how images are positioned for images that have even widths or heights?
It's not specified :)
Transpire Transpire

2011/5/10

#
Forgive the odd quote boxes, this forum doesn't seem to properly supported nesting.
davmac wrote...
Transpire wrote...
Well yes, but it's 2011. One arbitrary coordinate system is not as good as any other. Does it make sense to think upside down - that setLocation(getX(), getY() + 5) should move you down?
Why does it make more sense that it should move you up?
Because... that's how it works in math? The cartesian plane? Up == Positive? When you're flying a plane, you don't say, "Pilot, decrease your altitude."
davmac wrote...
Also - any idea why performance in my scenarios is so bad, especially when it comes to setting images? For example, both the book scenario piano-complete and my current project - reimplementation of DoodleJump - have noticeable lag when changing images, wheras, people have made very responsive wave simulators.
If you're constructing new images each time, then the image has to be loaded from disk and de-compressed. Typically people solve this problem by having static variables hold copies of the images that are needed.
What do you mean by constructing new images? I use setImage(String str), is that constructing a new image? How exactly would I go about saving the image in a static variable? Wouldn't the static variable just hold a string? Do I construct a GreenfootImage and save that?
davmac wrote...
Also, is there a way to move the current world location? Unbounded worlds don't help very much if the viewpoint is fixed.
No, there's not. If you want to have a "view point" you have to simulate it by moving the objects within the world and changing the background yourself.
Wonderful. Just what I needed!
davmac wrote...
Can you tell me how images are positioned for images that have even widths or heights?
It's not specified :)
So pixel-perfect physics turns into a haphazard guess-check-recompile... I'll try to determine the algorithim used, either by looking at the source code, or by constructing a 5*5 world and placing in a 4*4 object with differently colored pixels. Is there a way to set only the x or the y location? Running into race conditions due to multithreading isn't very fun; see below. Finally... is multithreading advisable with Greenfoot? Has anyone done it? I was trying to make extra smooth movement... determining at which point in time I needed to move a pixel down and then move it. But my thread kept on doing weird things; I have a feeling Greenfoot isn't build to handle multithreading.
davmac davmac

2011/5/10

#
Because... that's how it works in math? The cartesian plane? Up == Positive? When you're flying a plane, you don't say, "Pilot, decrease your altitude."
Well, I think "math" and "the cartesian plane" are two different things, and of course altitude is measured as the distance up from sea level, but the top of a scenario world is not "up" unless you happen to choose that definition (yes, it's generally at the top of the screen which is "up" in the real world, but we're talking about a view of a model). In any case, it's not worth arguing over - it won't be changed.
What do you mean by constructing new images? I use setImage(String str), is that constructing a new image?
Yes, indirectly.
How exactly would I go about saving the image in a static variable?
static GreenfootImage image = new GreenfootImage("somefile.png");
Wouldn't the static variable just hold a string? Do I construct a GreenfootImage and save that?
No the first, yes to the second.
davmac davmac

2011/5/10

#
Finally... is multithreading advisable with Greenfoot? Has anyone done it? I was trying to make extra smooth movement... determining at which point in time I needed to move a pixel down and then move it. But my thread kept on doing weird things; I have a feeling Greenfoot isn't build to handle multithreading.
It is extremely inadvisable. Greenfoot is not meant for multi-threading. The Greenfoot API is not thread-safe. You perhaps have some misconceptions about what Greenfoot is for. It is a teaching/learning tool for beginner programmers. It is not meant for multi-threading, and it is not meant for pixel-perfect physics simulations.
Transpire Transpire

2011/5/10

#
I know it isn't *intended* to any of those things, but plenty of people have uploaded scenarios far more complex and powerful than what I'm trying to do. By pixel-perfect, I merely mean that when a block falls down, it should stop without part of its image going into the floor. Hard to do without knowing exactly where its image is in relation to its logical location. I'm not trying to make the next Mario or anything.
Builderboy2005 Builderboy2005

2011/5/10

#
I can assure you nobody has written anything that uses Threads to control smooth movement before. I am also not quite sure why you are wanting to use Threads in order to control movement in the first place? Either way, the ambiguity of Greenfoot rotation should not prevent you from controlling your object with pixel perfect rotation, and if a single pixel is that important, simply adding a row and column to your image should solve every and all problems you have with rotation. Also I would like to point out that converting Greenfoot coordinates to the more mathematically accurate version where Y increases with height would not only break most if not all previous Greenfoot games, but also set up new users with a different set of rules than is used in the entirety of java. As Greenfoot is meant for helping students learn java, reversing the coordinates would only serve to confuse newer members.
davmac davmac

2011/5/10

#
What BuilderBoy2005 says is spot on. In addition, I should point out that Greenfoot's built-in collision checking does work with pixel-perfect accuracy; for instance, getIntersectingObjects() in the Actor class can tell you if a block has fallen "into" the floor (as long as the floor is also an Actor).
Transpire Transpire

2011/5/11

#
Builderboy2005 wrote...
I can assure you nobody has written anything that uses Threads to control smooth movement before. I am also not quite sure why you are wanting to use Threads in order to control movement in the first place? Either way, the ambiguity of Greenfoot rotation should not prevent you from controlling your object with pixel perfect rotation, and if a single pixel is that important, simply adding a row and column to your image should solve every and all problems you have with rotation.
Right; I've added a single row and column. I'm not talking about rotation; I don't have a single setRotation call in my project. Let me copy-paste something I emailed someone else:
I had two options for physically accurate gravity: save the location of the player, then evaluate d = d0 + v0t + 1/2at2 each time, resetting the inital value and the velocity every time, storing this all with doubles, and setting the location rounded every time. However, this essentially "teleports" the player to accurate locations. However, at high speeds, the player can in effect be going so fast that he "falls" through a platform. To visualize this, imagine you are in a car. This car is magic - it instantaneously moves you every second to a new location. Now imagine you are going 1000 miles per hour. This is approximately 447 meters per second. Now imagine there is a brick wall 5 meters in front of you. An actual car going 1000mph will crash. However, your car will "teleport" 447 meters further on and completely avoid the wall. This was undesirable. My second option was to use the quadratic equation, to find at which time I would have fully moved one pixel. This had the advantage of allowing me to memoize the function, as it would be a pure function. However, this didn't work since Greenfoot is wholly incapable of multithreading. When I have more time, I will evaluate d = d0 + v0t + 1/2at2, check if there are any platforms that I would pass through if I moved to that location, and if there are, move to right above that location and then begin to bounce off.
Also I would like to point out that converting Greenfoot coordinates to the more mathematically accurate version where Y increases with height would not only break most if not all previous Greenfoot games, but also set up new users with a different set of rules than is used in the entirety of java. As Greenfoot is meant for helping students learn java, reversing the coordinates would only serve to confuse newer members.
So you're saying that Swing and AWT use the Greenfoot style? I suppose if that's true - I don't know anything about either package - it sort of makes sense. Then again, Greenfoot isn't a UI builder.
What BuilderBoy2005 says is spot on. In addition, I should point out that Greenfoot's built-in collision checking does work with pixel-perfect accuracy; for instance, getIntersectingObjects() in the Actor class can tell you if a block has fallen "into" the floor (as long as the floor is also an Actor).
Right... so I guess most people code their own. The connect-4 implementations seems particularly impressive. By the way; thanks for the image-caching tip. It significantly improved performance.
nccb nccb

2011/5/12

#
If you want sub-pixel accuracy in your location (which I think would solve your problem), you can do so. The SmoothMover class shows how to wrap the Actor to store the location as a double rather than an int. Then you can do floating-point operations on the location without ever needing to sacrifice accuracy. Greenfoot being incapable of multithreading is not the problem; even if you could work out at what time you would move one pixel, you'd still have problems with delaying to exactly that time. Pretty much all games use a system similar to Greenfoot; you calculate one discrete frame at a given time, and use the time since the last frame to work out how far everything has moved. Swing, AWT, Microsoft Windows, X Windows, and pretty much all 2D graphic systems use Y going downwards, as do image editing programs like GIMP. Greenfoot would definitely be the odd one out if Y went upwards. The confusing thing is that in 3D graphics systems (OpenGL and Direct3D), the general convention is that Y goes upwards, although those systems are completely flexible, so you can have Y going upwards and as long as your camera is oriented in the same way, you won't notice.
Transpire Transpire

2011/5/13

#
nccb wrote...
If you want sub-pixel accuracy in your location (which I think would solve your problem), you can do so. The SmoothMover class shows how to wrap the Actor to store the location as a double rather than an int. Then you can do floating-point operations on the location without ever needing to sacrifice accuracy.
No, it wouldn't solve my problem. I had coded double accuracy into my Actor. The issue isn't that I'm losing precision, it's that movement isn't continuous and that my actor can move, say, 30.5 pixels down instantly. If it's 0.5 pixels above a 20 pixel tall platform, it'll teleport through.
Greenfoot being incapable of multithreading is not the problem; even if you could work out at what time you would move one pixel, you'd still have problems with delaying to exactly that time. Pretty much all games use a system similar to Greenfoot; you calculate one discrete frame at a given time, and use the time since the last frame to work out how far everything has moved.
My idea was that the game logic wouldn't be so tightly bound to the rendering. I could update the position without it being painted.
Swing, AWT, Microsoft Windows, X Windows, and pretty much all 2D graphic systems use Y going downwards, as do image editing programs like GIMP. Greenfoot would definitely be the odd one out if Y went upwards. The confusing thing is that in 3D graphics systems (OpenGL and Direct3D), the general convention is that Y goes upwards, although those systems are completely flexible, so you can have Y going upwards and as long as your camera is oriented in the same way, you won't notice.
Thanks for clearing that up.
Builderboy2005 Builderboy2005

2011/5/13

#
How about each frame instead of moving your Actor 30.5 pixels in one step, do it in a series of 10 smaller substeps?
There are more replies on the next page.
1
2