Re: [pygame] Hi, I'm new... , isometrics (long)

[Simon Britnell <ughbash@yahoo.com>]

--- Glen Wheeler <wheelege@tsn.cc> wrote:
> Being turn-based, I imagine the various complexities
> of the graphical representation and speed are much
> simpler

I don't think the difference will be substantial.  If
a character is walking from A to B, you still want to
handle UI events while watching the walk.  You
probably also want an option to make the walk happen
in accelerated time for impatient players.

> Hmmm, thinking about this isometric diablo-esque
> engine, would I treat this as a whole bunch of cells
> that are basically squashed-diamond in shape?

I've been thinking a lot about building a similar
engine.  What you do will depend on how much you need
from your world.  More below ...

I'd keep a *very* clean seperation between the
mechanical game world and the drawn game world, maybe
even going so far as to have a quick & dirty top down
2d representation that you can use for debugging the
mechanical world independant of the complex graphics. 
When I say simple, I mean simple - labelled coloured
squares that take 5/8ths of no time to write.

Your mechanical and graphical representation will
depend a lot on exactly what you expect to represent
in  your world.  Factors such as map size and real
dimensions play a key role.  Generally, More features
= more complexity = more cycles to draw.  If
everything will be displayed as fixed size playing
peices on a flat map (all same altitude), you can
pretty much just draw everything in two parts, split
along the vertical line that's closest to the front of
the screen (bottom of the diamond) and zbuffer on the
rear left and right corners of everything to determine
draw order.  If you want things to be able to fly
above the single level, this is not much more
difficult.  If you want to map really big areas, you
may not want to use the 2d array of  cells approach
and instead map surfaces and objects which have x,y
coordinates.  If you want to model a lot of outdoor
areas, you'll probably want an array type height field
map, and the problem of what gets drawn in front of
what becomes more interesting.

> Scrolling...that could be processor-intensive.
> Perhaps it should jump-scroll, instead of smooth
> scroll.

Most of the stuff you will be drawing on the screen
will be imobile, which means that you can render it
once onto a backing store and not worry about it
again, until some animation happens on it.  Event
then, you need only recompute the parts that overlap
the animation.  For scrolling, this means that you can
render the scenery in an area (eg) 9 times the size of
your screen and only animate in the visible section. 
When the screen scrolls, you have a background thread
that begins repainting the scrolled area out of view. 
A simple mutex can be used to prevent scrolling onto
areas that aren't painted yet.  It's not perfect, but
it's enough smoke and mirrors for most uses.


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
____________________________________
pygame mailing list
pygame-users@seul.org
http://pygame.seul.org