heya,
using triangles instead of diamonds or squares is possible yeah, it
might be wierd/difficult to program though. I dont have alot of 2d
programming experience but i have a little and i think youd be
better off using a shape like this if your going orthographic:
/__/ (with a top of course too).
That would give you a different perspective from the diamond format,
though.
In any case, using tiles and having a graphic for each tile is a
very common technique. You wouldnt have to make a seperate surface
for each tile, in fact if you look at old games they often have 1
graphics file with alot of pictures in it. What they do is load up
the graphics into one “surface” basicly and if they just draw the
part of the surface that has the picture they want. Does that make
sense?
Well, yes - but not these days. Old games did this either because they
had custom blitters that sheared the graphics into the /_/ shape, or
because they were using h/w blitting, like the Amiga, for example.
However, if you use software rendering, RLE acceleration and
non-rectangular tiles, it’s not a good idea to use a single surface
for all tiles. When you clip, blitting from an RLE surface, the RLE
blitter will have to scan RLE runs to find out which ones to render,
so it can be rather expensive.
And yeah, for a map file, its fairly common to have an ascii map
file where different characters mean different things. For
instance, if ‘X’ is a wall, ’ ’ is empty space, ‘Q’ is a door, and
D are blocks that you cant move you could have a map like below
(looks like something outa zelda 1!):
XXXXXXQXXXXXXX
X X
X D D X
X Q
X D D X
X X
XXXXXXQXXXXXXX
and when you drew it to the screen youd just draw the right
graphics depending on what the map said was drawn there. The good
thing about this too is you can edit the map files yourself by hand
in a text file, much easier to work with.
It’s even easier to just draw the map in the game, in an "edit mode"
of some kind. 
Of course, then you’ll have to hack a simple editor, but if you’re
going to edit tons of maps with tons of graphics - especially if
there are multilayered tiles, background sprites, parallax and stuff
like that - it’s going to be worth it.
Also note that ASCII maps don’t map very well to isometric
perspectives. (Pun is a free bonus.) It gets a bit hard to see what
you’re doing, but I supposed you get used to it…
also if you are doing your game orthographicly, you could have
square pictures but draw them crookedly so it looks like //
instead of like ||.
Yep, but then you’d have to use OpenGL, or hack custom blitters.
Well, you could just blit one pixel row at a time, but that’s
h*lluva lot of calls to SDL_BlitSurface()…
Besides, it doesn’t really buy you much compared to the diamond shape.
Diamons give you a slighly higher number of lines per tile, but
that’s pretty irrelevant. Whether you roll your own diamond blitters
or use SDL’s RLE (which can handle diamonds just fine), it’s only a
plain block copy per line.
If you use your own blitters, you can indeed pack the diamonds and
still get them out, but with RLE, the apparently unused space
actually doesn’t exist in the RLE encoded surfaces. Each run of
transparent pixels is replaced with a “skip instruction”, which
doesn’t cost much more than the corresponding logic in a custom
blitter.
That way you wouldnt have to make // shaped
pictures since you would have to worry about cutting off the parts
that shouldnt be drawn. So basicly in your graphics files, your
tiles would look like || but they would be designed to look good
like /__/ because thats how you draw them to the screen.
That only makes graphics editing harder. It’s much easier to get the
graphics right if you can just draw it like it will look in the game.
Besides, I don’t know of any graphics applications (GIMP, PhotoShop,
PantShop Pro, Corel PhotoPaint [or whatever it’s called] etc) that
can take shearing and transformations like that into account when
applying filters and stuff. Aspect ratio compensation is about as far
as that goes.
Drawing
|| graphics like // is VERY fast compared to drawing triangle
textures or crazy stuff like that.
It’s slower than plain RLE blits of any sensibly shaped colorkeyed
surfaces, though, unless possibly if you hack your own blitters.
Not many cycles you can save there, though. I wouldn’t bother.
I dont have alot of this kind of game experience but i hope i
cleared it up a little!
I would say you’ve managed to complicate stuff a little.
What you’re suggesting would indeed work, and it would probably make
sense in some situations, but since we have either SDL_RLEACCEL or
h/w accelerated colorkeying in SDL, we allready have the perfect
swiss army knive for this kind of stuff. Why hack weird software
blitters when there already is one that covers it all, and that
allows you to use tile formats that are also compatible with 2D
hardware acceleration? (Only OpenGL and Direct3D can efficiently
transform tiles while blitting. Anything with colorkey or alpha can
do diamonds.)
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Sunday 25 May 2003 05.36, Atrix Wolfe wrote:
