[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Enigma-devel] Scroll mode problem
Re: [Enigma-devel] Scroll mode problem
Sun, 26 Jun 2005 15:09:57 +0200
On Sun, 2005-06-26 at 07:57 +0000, Karen Pouelle wrote:
> The description "scroll but align to screens" was a lie.
I would not necessarily call it a "lie" simply because your perception
of a "screen" is a little different. Maybe it's a little inaccurate, or
it may need a better description, but it's not as if anybody
intentionally fooled you.
FWIW, I just added two new functions to the Lua interface:
display.SetScrollBoundary (0.5) -- this is the default
display.SetScrollBoundary (0.0) -- this is what you want, with no
display.ResizeGameArea (20, 13) -- this is the deafult
display.ResizeGameArea (15, 10) -- use a smaller area
I hope this solves the problem.
Of course, it is up to the level designers to use this feature wisely:
the player has no chance to see any traps (water, abyss, etc.) in
adjacent screens if he has to move the marble _outside_ the current
screen to cause the screen flip.
> Ingo van Lil <address@hidden> wrote:
> > If you want to put it like that, yes. But it's more reasonable than
> > letting the ball roll (partially) out of the screen.
> I'm not sure I follow your reasoning of degrees. Letting the ball
> roll through the doorway and only then transition into the next
> screen is reasonable when the design of the level requires it
> to do so. Be it more or less reasonable, it's still reasonable.
> "The ball is supposed to..." sounds like you want to dictate
> the effect an actor will create with the screen in everyone's
> level, and not put that choice into their hands.
> Why do you make it a question of which scroll mode is
> more globally reasonable when I'm asking for the option
> for the designer of the level to choose which is more
> reasonable in a particular level? If I say "letting the actor
> begin leaving the screen before flipping or scrolling to the
> next screen" for my particuarl level, then it is - because I
> have reasoned it so. I'm not asking to change all levels,
> but to give me and others the option to choose what I
> (and possibly others) believe to be more reasonable.
> Let's look at some recent works to see how they've gotten
> around the problem I'm describing. Maybe you didn't
> try the level I pasted into the last email, instead just sending
> off a line to say you don't like developing, making Enigma
> "Here is a little level of mine ("Four Elemental Tests")
> [4lments.lua]. It includes four tests based on speed, intelligence,
> dexterity and patience ; it's an all-in-one level." -- Moonpearl12
> In this level, the four theme rooms are bordered with stones
> which, with the exception of the bumper stones in the Earth
> room, serve only to divide the rooms. Notice in the Fire theme
> room (see attached thumbnail) that the walls for the Earth and
> Water room are visible on the east and south sides respectively.
> The theme of the rooms had to be a compromise of border stones
> due to the problem I'm describing - no scroll option to truly
> "scroll but align to screens."
> Had those stones been a more functional part of the rooms, they
> would have been revealed before entering the room. The Air room
> is bordered by the bump stones from the Earth room for no
> other reason than there is no screen scroll mode available to
> move them out of view.
> The point is - I wish to make a functional section of an adjacent
> screen not visible until a transition begins from one screen to the
> next, and providing a scroll mode that does this would allow me to
> get on with what I'm doing - attempting to add to the value of Enigma
> by asking for more options for level designers, and creating levels
> I'm just asking for a scroll mode that actually does "scroll but
> align to screens." on the horizontal and vertical thresholds,
> instead of begining the transition too soon and making the
> scroll short of an entire screen by one block - which isn't
> suitable for my current level creation.
> Is there something in the code that doesn't allow more than 4 scroll
> options? I'll gladly look into the code if you believe there's a
> legitimate reason there for not adding new scroll options.
> But so far, I'm not buying your reasons against considering this -
> This idea to have this style of screen scrolling and/or flipping
> seems a bit overdue to me.
> Enigma-devel mailing list