> > 4 bytes: "RPGm"
>
> No version number?
I thought about it, but no. Just don't start creating
(and distributing) an editor until the fileformat
includes everything.
In this case it shouldn't give any trouble since it's
a quite simple fileformat. Eventually, any additions
can always be added to the end of the file.
> > 8 bytes: filename (without ext.) of the
> patterndata
>
> Should this information be in the map file?
Yes. Easier to program AND to edit (the correct
tilemap is automatically read from the file and
loaded).
> > 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?
Programming 'limitations'. Powers of two are much
easier. And hey, why not???
> Also, I think using 16 bit sizes shouldn't be a
> problem, since the Z80 can
> perform 16 bit addition.
The problem is the address space. And using 16-bit
address spaces (like width 512) makes it harder to
program at several point in the engine. 256x64 is wide
enough I think.
> > 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.
Engine: 16k
Tilemap: 16k
Replayer: 16k
Music: 16k
"Storyline": 16k
Loading-space: 16k
Battle-mode: 16k
Animations, additional gfx, reserve space: 16k
--------------- +
128k
And besides, it is harder to program. Like the above,
it's _possible_, and it won't take too much time away
either. But it will increase the complexity of the
engine and therefor results in:
- Higher bug probability-rate and therefor
- Takes longer to program the engine.
- Less easy to adapt.
> > 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.
Yah whatever.
> 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?
> Why would it be a good idea to have a separate
> design and edit format?
Yes?
> 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
[...]
> while generating the engine file.
Whatever you want. Hell, use 47 different edit-modes
if you want. As long as the 'final mode' is as
described.
> > 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.
Do as you wish. You know my opinion on edit-modes.
> I think the palette could be stored independantly of
> the graphics data. The
> graphics data will end up in VRAM, the palette in
> RAM.
In the same file is
- more logical, since the palette belongs to the gfx,
it's silly to store it independantly. Requires more
administration, disk-space, complexity, yuck.
- It doesn't make it more complex for the engine or
something like that. It's even easier, less files to
look up and open.
However the multiple palettes idea is good. However,
it is hard to implement it all in the same file,
because there are many possibilities. Like in a
thunderstorm the palette should flash every now and
then, while in lava only the red colors must fade. It
is easier to hard-code it in the engine I think. I
will leave room for such extensions in my engine.
> 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.
Yes??? I doubt it... 256 different 8x8 tiles... Isn't
that enough??? Only for big screens. But for that is
is wise to use real graphics.
Besides, that would require the tilemap to be 16-bit.
Hello, we're dealing with MSX here!!! Gotta live with
the limits! Alhough it is possible, you can in that
case forget about large maps or running at 128k
though.
> 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.
I don't get the 'two backgrounds'-part. The gfx are
quite limited, I really doubt they have a 16-bit
tilemap.
> 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).
The location in the tilemap.
Row 0: walkthrough
Row 1: walkthrough
Row 2: non-walkthrough
Row 3: non-walkthrough
Row 4: non-walkthrough
Row 5: non-walkthrough
Row 6: trigger-tiles (damaging and event-tiles)
Row 7: Overlay with background
Row 8: Overlay without background (engine use only)
The latter brings me to the point that the tilemap
fileformat has to be extended with 8x128=1024 bytes
for the 8th row, which is kind of a mirror of the 7th
row, but then without background.
> 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.
Animation is not really an option in my engine (at
least as far as I can see it now). The animations are
reserved for the battle-mode.
In case of an animation-supporting engine, I suggest
to define row 5 as 'animation-row', and add a few rows
after the 8th with the different animated tiles.
> 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.
Really, I know my profession. The GEM-video engine
does the same (Patriek's is based on my 'smart'
concept-video engine).
In my RPG-engine I don't do it like this. Why not???
Well, it should ALWAYS scroll smooth, also in 'bad'
conditions in which all the background differ from the
previous.
> 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.
Ofcourse. See the "transparent row" in the tilemap.
It's all there. You know what? This way, transparant
tiles are even rendered transparantly only if there is
a character standing behind it!
> 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.
Sorry to say, but the things you state are kind of
obvious. VDP-optimizing is the most fun part of (MSX)
programming!!! (at least, IMHO)
> 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.
A scrolling engine is not much harder than a
non-scrolling engine (for me it is even easier because
I have more experience with it). Programming a
smooth-scrolling engine really sucks though, believe
me.
Also, imho, a scrolling engine looks much, much better
than a 'solid' one like the PA series have. I think
the only reason they created a solid engine for PA3
(which was still used in the later games because they
didn't want to -or couldn't- re-program it all,
editors and engine etc.) was because it was originally
programmed in Basic. And scrolling is a bit too much
for a Basic environment. They couldn't change it to a
scrolling engine afterwards because the RAM map and
design style (how the screens 'fit' together) is
entirely different.
> 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.
I agree with you on this point. An editor is much
harder to create than a game-engine. An engine just
has to process the pre-formatted data and display it
on screen, display a character and let it wander
around in 4 directions and occasionally talk to
someone.
The editor is much more complex, because it needs a
user-interface and additional options like undo
(hard!!!)(or rather space consuming), conversion of
different file-formats, handling of several
file-modes, specific drawing options varying from
'fill the entire screen with this character' to
'resize screen' to 'combine these tiles into a shape
(which also needs (a shape-editor) and handle it as if
one tile was put' (for use with drawing for example
trees).
The Strategic Army-editor is a big stand-alone program
with it's own development from the engine (they
already differed a lot when I was still using 8x8
tiles). The file is larger, the source more complex,
and it still doesn't offer a lot of options like undo
and the last one described above (it does feature map
resize). By the way, I am not talking about the
RPG-engine now, if you hadn't understood yet.
~Grauw
__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/
****
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
****
