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

2013/5/20

Is there a world subclass that lets you have a large world but a small, movable, viewing window?

m_p_v_13 m_p_v_13

2013/5/20

#
Is there a world subclass that lets you have a large world but a small, movable, viewing window? I am modeling runners, and instead of world-wrapping, I want to have a long, straight race, with the viewing window following the leading pack. I looked at a couple of examples involving moving all the actors to simulate scrolling, and this is more complex than I wanted.
bourne bourne

2013/5/20

#
There are no World subclasses. Actors' images though can be used to paint a "world like" viewing window. But I think moving all the actors is somewhat the straightforward approach (for a single viewing window).
danpost danpost

2013/5/20

#
@bourne, I think what he wants here is a super class (extending World) that is a side-scroller whose main actor is changeable (sort of like the 'SWorld' class of my Scrolling SuperWorld scenario).
bourne bourne

2013/5/20

#
@danpost, That sounds like a good implementation (so it follows/centers-on a given Actor?)
m_p_v_13 m_p_v_13

2013/5/22

#
I was looking for a reasonably general extension of the World class that someone may have created so that a (smaller than the whole world) viewing window can be specified independently and dynamically.
danpost danpost

2013/5/22

#
I am not totally sure I understand what you mean; but, maybe the following would be a way to do what you want to do. How about adding a dummy object into the world as the main actor (the one that the camera follows). Then, moving that object to where you want to view would cause the scrolling to find that area in the large area. The dummy object can be a transparent pixel-sized object.
bourne bourne

2013/5/22

#
I'm pretty sure you can't have a World inside of another World. You can only switch between them.
danpost danpost

2013/5/22

#
@m_p_v_13, check out my new scenario, PIP Actor Class.
m_p_v_13 m_p_v_13

2013/5/23

#
@danpost and others, This is the assistant (i.e. dad) to the original poster. I am helping her with this independent study school project. @danpost, The PIP class is very interesting. I don't see how it applies to what we were looking for. We would like one world in which a particular rectangular window to actually display on the screen can be chosen dynamically. With the greenfoot World class you are working (i.e. doing the logic for actor interactions) in the coordinate system of the display window. The scrolling extensions I looked at seem to modify all the actor locations to effect scrolling. I would like to have a fixed coordinate system, in which a stationary object always has the same (x,y) value, and then be able to specify where the display window is in that fixed coordinate system. Ideally I could also specify the size of the display window (to be able to effect a zoom function) but it is not essential (I suspect it would be hard to implement and probably need to modify the greenfoot classes). Perhaps, I could get my fixed coordinate system by implementing transformation methods and a state variable to store the Worlds display window location relative to the fixed coordinate system. I would also need a method to set the display window location, which under the covers would change the location of all actors in the display coordinate system (i.e. what the scrolling extensions do). For example, in the simplest and clumsiest way, something like: - convertToXFixed(x), convertToYFixed(y), convertToX(xFixed), convertToY(yFixed) implemented in World extension These methods would be used to convert between the World's coordinates (i.e. relative to display) and the fixed coordinates. If actor logic is to be implemented in the fixed coordinates, the conversion must be done before/after every call to greenfoot classes that take/return coordinates. Alternatively, all those methods could be overridden with fixed coordinate versions. - getXFixedDisplay(), getYFixedDisplay() implemented in World extension Used by other methods to do transform between coordinate systems - setDisplayLocation(xFixed, yFixed) implemented in World extension This methods would change the x,y of all the actors (i.e. what the Scrolling extensions do) and the display window location state variable. It should delay the effect until the start of the next World act() cycle to prevent concurrency problems. Perhaps this is all MOOT. If an actor never keeps location information around between invocations of act() and everything in the world is represented by an actor there is no difference between using the fixed or display coordinate system. So for example, in the runner scenario, if there is a finish line, it has to be an actor. We can't just store it's location some other way in a "fixed" coordinate system. I still think it would be a nice addition to put display window functionality (e.g. move, rotate, size/zoom) into greenfoot. Thoughts.......? Thanks,
m_p_v_13 m_p_v_13

2013/5/23

#
Well, there are situations where an actor needs to keep absolute location information around across act() invocations. For instance, to keep track of it's, or someone else's, absolute velocity.
You need to login to post a reply.