On Thu, 25 May 2000, Laurens Holst wrote:
> > For example, a good editor needs multilevel undo/redo, which requires some
> > good design or it will eat your memory very fast. Also, the user interface
> > is very important, and it's hard to design a good UI.
>
> Okay, then stop talking and make an editor!
Good design includes that you don't just start programming, but decide
exactly what it is you want to make first.
> tilemap file format:
I think it would be better to describe the kinds of maps the program should
support before defining the file format. Now you're doing it in reverse: by
defining the file format, you define what kinds op maps are possible.
> 4 bytes: "RPGm"
No version number?
> 8 bytes: filename (without ext.) of the patterndata
Should this information be in the map file?
> 1 byte: width (in tiles), possible values 256 (=0), 128, 64, 32, 16, 8
> 1 byte: heigth (in tiles), possible values - see above
Why only powers of two?
Also, I think using 16 bit sizes shouldn't be a problem, since the Z80 can
perform 16 bit addition.
> n bytes: actual data (max. size 16k)
Why limit the map size? There is no evidence (yet) that handling maps
larger than 16K is too hard on the engine. It is certainly not a problem
for the editor.
> The actual data is -with for example width 128- simply the tiledata of
> (0,0)-(128,0) + (0,1)-(128,1) + (0,2)-(128,2), etcetera...
That should be (0,0)-(127,0). But I understand what you mean.
I'm not sure I like this format. I would prefer 2 map formats: one for
designing a map and one that the engine can handle. The design format
contains more structure info, the engine format is optimised for easy
handling by the engine.
Why would it be a good idea to have a separate design and edit format?
I'll give a few reasons, I think there are more.
When designing a map, there will be groups of tiles that form objects. For
example a tree in a forest, or a large rock, or a house in a village. It
would be easy for the map designer to group the right tiles into an object
and place objects on the map. In this way, you can move a tree one tile to
the right, instead of having to move all tiles in the tree to the right. If
the tree doesn't have a rectangular shape, moving the tree object is a lot
easier. Another advantage would be that the designer can decide to modify
the tree object and doesn't have to redraw all trees on the map.
Or you can allow objects to consist of multiple layers. For example an
apple tree would be a tree object combined with a couple of apples, which
are 1-tile graphics with a transparant background. When generating the
engine format files, the toolkit can create pattern graphics that have an
apple superimposed upon the tree graphics.
Another advantage: you have drawn a lot of patterns, but haven't used them
all. To save memory, you could delete the unused ones and rearrange all the
patterns to make sure patterns 0..X-1 are used and patterns X and higher
are unused. But this would require massive editing on the map file!
However, if you use a separate engine format, the toolkit could
automatically detect which patterns are unused and renumber all patterns
while generating the engine file.
> patterndata fileformat:
> 4 bytes: "RPGp"
> The patterns and palet are in screen 5-format.
An engine that works in SCREEN5 will only accept SCREEN5 graphics. But I
don't see the point of limiting the toolkit to SCREEN5. I suggest we use
32-bit graphics (RGB+alpha) in the toolkit. Games in SCREEN8, one of the
YJK screen modes or for GFX9000 can make use of the higher number of
colors.
I think the palette could be stored independantly of the graphics data. The
graphics data will end up in VRAM, the palette in RAM. And a single scene
may have more than one palette, for example a vulcanic cave or an outdoors
scene in a lightning storm.
And also for the pattern data, I think there should be a separate design
file and engine file. This is necessary to allow a higher color depth for
the design file. It's also necessary for the "delete unused patterns
and then reorder" step I described above. And there is another advantage:
the design file wouldn't have to be limited to 256x64 pixels, it could be
any dimension.
There are also some issues you didn't address. For example, you assumed
that 1 layer of tiles would be enough. I doubt that. Birdseye games like
Metal Gear and Zelda use only 1 layer. But most RPGs, like Xak and SD
Snatcher, use more than 1 layer.
Pumpkin Adventure 3 used a nice system. I'll describe it from memory,
someone please correct any mistakes. It has one background layer, chosen
from a set of two fixed backgrounds per scene (the background is a repeated
large graphic), and one foreground layer. In this way, you can walk behind
objects, but in that case there will always be the background below the
foreground tile. So it's not possible to have just any combination of two
tiles at the same position.
Another issue: how should properties of tiles be handled? For example, what
tiles you can walk through (open ground) and what tiles block you (walls).
And there could be tiles that cause damage (lava, thorns), or cause your
movement to become different (ice, water, strong wind). Or tiles that
trigger special events (character or monster appears, sound is played,
secret is revealed).
And animations haven't been discussed yet. Sprites (either real VDP sprites
or copied sprites) are necessary and maybe we also want animations in the
background (like YS3) or in the foreground.
I listened to Cas talking about the Core Dump engine on a couple of
occasions and learned a few things from that. In SCREEN5 games, the VDP
speed is often limiting. By choosing the VDP commands carefully, you can
get a much better frame rate.
For example, don't copy blocks that haven't changed from the previous frame
to this one. If most of the screen is filled with grass tiles, many of
those tiles don't change if the screen is scrolled.
Another thing is to know whether a tile needs transparant copy or not.
Copying with transparancy is a lot slower. A tile doesn't need transparant
copy if it doesn't contain transparant pixels.
And finally, if you know a background tile will be completely covered by a
foreground tile (the foreground tile doesn't contain transparant pixels),
don't copy the background tile in the first place.
Maybe we could first make a non-scrolling engine, like that of Pumpkin
Adventure 3. Once that works, the first games can be made and a scrolling
engine could be developed for the next generation of games.
The same for the toolkit: I described some advanced features that would be
very nice to have, but most are not necessary to produce a game. So first a
simple toolkit could be made and features added later. But it's important
to have a structure that allows the adding of features.
Bye,
Maarten
****
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED]
and put "unsubscribe msx [EMAIL PROTECTED]" (without the quotes) in
the body (not the subject) of the message.
Problems? contact [EMAIL PROTECTED]
More information on MSX can be found in the following places:
The MSX faq: http://www.faq.msxnet.org/
The MSX newsgroup: comp.sys.msx
The MSX IRC channel: #MSX on Undernet
****
