--- Maarten ter Huurne <[EMAIL PROTECTED]> wrote:
> > > No version number?
> >
> > I thought about it, but no. Just don't start creating
> > (and distributing) an editor until the fileformat
> > includes everything.
>
> Especially if you want to distribute an editor that is not final (I
> am in
> favor of early releases, btw), changes in the file format can be
> expected.
[...blablabla...]
Okay, you are right.
Define: right after the ID is a version BYTE, format v#h.l...
> > 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.
>
> Additions can be, but not all changes are additions. For example,
> what if
> you want to allow 3-layer maps in addition to 2-layer maps? Or if you
> upgrade a value from 8-bit to 16-bit?
The map is 1-layer.
> > > > 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).
>
> When this description becomes the engine format and not the edit
> format, I
> don't think it's needed anymore.
Owww... blwe! I really think it's useful. You are right that if you use
some kind of library-file a filename is perhaps not used. But in that
case you can put a file ID in there, or any other useful info for the
file system.
And ofcourse there are cases in which it isn't needed at all, but that
entirely depends on the file system used. Besides, in developer-stage
most programs probably don't use a library (yet). So I think it is a
very good idea to include it. It can always be ignored later on.
> About loading: maybe you don't even load from files. For speed,
> loading
> from a library file is better. Some library systems keep a directory
> of all
> filenames plus locations, but other systems (like mine) use compiled
> tables: the MSX program doesn't know the name of the file the data
> came
> from, only its offset in the library file and the file length. The
> advantages of the compile system are that it's more compact and that
> mismatched ("file not found") are detected at compile time instead of
> run
> time.
But still it would be easy to have the info which characterset belongs
to a field in the tilemap-file instead of in the source. Because then
you can easier change a file without having to change the source. This
is useful because far from all map-editors will be
assembly-programmers.
> > > > 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'.
>
> You were right to put it between quotes. I don't think other values
> are an
> actual limitation.
You are right. At this time, I even have already implemented variable
map sizes. So the sizes can now vary from 1-256 (where 256 == 0), as
long as the tilemap is not larger than 16k.
> Assume you want a map that is as large as the screen, that would be
> impossible unless the screenHeight and screenWidth are powers of 2.
> Which
> is unlikely, because (assuming SCREEN5 and 8x8 tiles) 32 * 8 pixels =
> 256
> pixels, which leaves no room for a border, and 16 * 8 = 128 pixels,
> which
> is only half a screen.
You can always use black tiles to fill.
But I already implemented it, so it's -in my engine- no longer an
issue. Why is it suddenly so simple? Well, I now use X and Y
co-ordinates for the position on the map. I used to have a
memory-address only, in which I ANDed the lower byte and checked if the
value was zero. That's why I only wanted powers of 2.
> > > 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.
>
> On second thought, I guess you're right: all coordinates would have
> to be
> 16-bit: that of the player, of the object, the monsters, the NPCs
> etc.
Precisely. It would make everything much more complex. Remember the Z80
has far from complete 16-bit support. And the MSX hasn't got much
memory by default...
> > 256x64 is wide enough I think.
>
> I think 256x256 is large enough, Ultima V (PC) used that and that was
> a
> really large map...
That would be 64k. Inacceptable. Not only because it is difficult to
program, but the MSX then also hasn't got enough memory.
> 256x64 is a consequence of a 16K limit on the map data itself, an
> issue to
> be discussed elsewhere (this was about 8 or 16 bit sizes for map
> width and
> height).
You are right. Still, 16-bit sizes are definately not recommended (see
above). And I think one can easily live with the limit of a max. width
of 256.
> > Engine: 16k
> > Tilemap: 16k
> > Replayer: 16k
> > Music: 16k
> > "Storyline": 16k
> > Loading-space: 16k
> > Battle-mode: 16k
> > Animations, additional gfx, reserve space: 16k
> > --------------- +
> > 128k
>
> You forgot system RAM space. System RAM eats up about 11K (#D400 and
> up).
And the free space is used by the file system kernel of a library file.
The animations, additional gfx and reserve space is not that nessecary,
it will probably be stored in VRAM. And if there is not enough space
then it will have to be loaded from disk (or from mem, if you have
>128k).
> Music and replayer can fit into 16K together, with a little effort:
> - MBWAVE driver doesn't fit, but that can be helped by separating
> initialisation code (alternative wave headers) from the rest, or
> decreasing the number of channels.
> - MBM driver + song can fit, I did that before.
> - MML driver Kinrou 5th is less than 6K, songs fit within remaining
> 10K.
Don't forget the speed issue. In fact, MBWAVE-files are very badly
organizes. For example, the note is stored in the file, while it would
be way better if the frequency was stored in the file. This would
greatly reduce the replayer-size and result in a huge speed-up. Also,
frequencies can be calculated on-edit in MBWAVE, resulting in much more
freedom than only those three base frequencies.
Also, the notes could be seperated by length-bytes. Then there is a
counter on for ever channel which is set to a new value every note
which is played. Those counters then count to zero, and if they reach
it, the next note is played, etc. etc. etc.
That's what I actually need in my engine, because I have not very much
time left to do stuff. I will try to make a converter for the .MWM
files and create a new replayer. NOP did about the same thing in
Unknown Reality I think...
> Leaving loading space unused is not necessary.
It is not only loading space but also temporary space, for example to
save the background if you display a menu.
> Anyway, why not allow the designer of the game to make these choices?
> He
> can decide to use a small replayer, fewer graphics, more than 128K
> RAM or
> whatever he thinks is needed to make a larger map fit.
That would suggest I will have to make the engine really flexible. It
is easy for the map-editor, but for the engine it is quite hard...
> My suggestion: put an option in the toolkit that will tell you the
> map size
> in bytes. The game designer can decide how much space is reserved for
> the
> map data. Maybe the reserved space is even different for individual
> scenes
> in the game. For example, a peaceful village doesn't need a battle
> mode,
> that space can be used for map data instead.
As said, also think about the engine, not only about the editor.
> > 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:
>
> That depends on how the engine maps the memory. Maybe it can use two
> pages
> (#4000-#BFFF) with map data at the same time. Maybe it puts the map
> in VRAM
> and keeps only the visible part of the map in RAM.
I'll see what I can do.
> What I want to say is: don't assume "we'll need this limit" before
> you
> actually have the reasons why you need it. It is possible that some
> engine
> implementation will have trouble with a map larger than 16K. Then
> that is
> the time to impose a limit. But it should be a limit on the engine,
> not on
> the file format, to avoid loss of flexibility.
Maybe it's a good idea to have a special pre-setup file in which the
external file format and the limits the editor should have are defined.
Just like TASM can also be adapted to multiple processors...
> > 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.
>
> Disk space is not an issue: a palette is 32 bytes.
>
> About administration: you'll have to administrate anyway. To allow
> palette
> fades, the palette must be in RAM somewhere. You can't just load it,
> send
> it to the VDP and then forget the palette.
Who is talking about sending it to the VDP and forgetting about it???
It is loaded (and kept) into RAM, sent to the VDP, and then the rest of
the file is loaded to the VRAM (indirectly through RAM ofcourse).
> A map depends on a certain set of tile GFX, yet these are not stored
> in the
> same file either.
Because those can be shared. Palette-settings are quite specific to the
characterset though. It is easier and more logical to store it with the
patterndata. Otherwise the filename of the belonging palette has to be
stored and it has to be loaded seperately. Much more trouble for the
same result. And your directory will be flooded with .PAL-files.
> I remembered programs I made in the past and I noticed that I almost
> never
> put the palette in a file. In my latest projects, I put the palette
> together with the script tables. The advantage is that it is directly
> at
> the place the program needs it, you don't have to load and LDIR it
> first.
Why LDIR and not directly load it to the correct location? And it
results in less administational stuff.
> Another thing is that I always compress graphics. Using compressed
> graphics
> conserves disk space and reduces loading time. Decompression is
> easier if
> all data is actually graphics.
Hmmm... run-lenght??? Good idea.
> > - 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.
>
> The engine wouldn't load the palette from a separate file, it would
> just
> load it from a different file than the graphics.
Which file??? The graphics-file (the palette is part of the graphics,
the graphics don't look correct if there is no palette) seems the most
logical choice to me.
> > 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.
>
> If the palette is in the script section, it can be treated like
> animation:
> every N interrupts a new palette "frame" is selected.
What do you mean by 'the scripts section'??? Share your thoughts about
this!!!
> Putting it in the GFX file will make multiple palettes more risky:
> you
> always have to make sure there is enough space to store all the
> palettes
> when you load them.
No, not really. And it will decrease the size of the 'scripts' (which
are in RAM permanently).
> > 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.
>
> You misunderstood what I mean by layers. I do think that 256
> different
> tiles is enough.
Fortunately.
> But I'm not sure that 256 values per tile is enough to
> describe the map. Flags (open/wall), triggers etc could also be
> stored in
> the map data. See for example the design that Maarten van Strien
> made.
Those functions simply depend on the position of the tile in the
patterndata (hence on the patternnumber). For example, everything
ranging from #C0 to #CF is a trigger, and by combining the X and
Y-position the start-address of the routine processing the event is
looked up in a table.
I created a .GE5 file explaining my thougths about this. It is attached, and
if it doesn't get through you can look at http://grauw.blehq.org/saa.gif
Remark: I am not sure about the 'character disloction' yet... It can be done
this way, but it is more complex to the engine. The other option is to adapt
the patterns instead of adapting (read: dislocating) the character. I (now)
actually think, for speed's sake, the latter is preferred.
> > > [PA3 engine]
> > I don't get the 'two backgrounds'-part.
>
> There are two background bitmaps per scene, 176x80 in size. For one
> game
> screen (176x160), one bitmap is plotted twice, once for the upper
> half of
> the game screen and once for the bottom half. For every screen in a
> scene,
> you can select which one of the two backgrounds is used.
I still don't get it!!!
??????????? What's the use??? Why not use one single larger map???
(you need >16k anyway in both cases so not considering the file size)
> > > Another issue: how should properties of tiles be
> > > handled?
> >
> > 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)
>
> I think it's better to make a table that maps tile number to tile
> properties. So if you want to know the properties of tile 23, you
> read
> index 23 in the table and that value contains the properties of the
> tile.
You're right. I also got that idea and already decided to do it like
that. That way, you have much more flexibility. The things stated above
can then be mapped like this in the table.
> A 256-byte table would be needed for 8 bits of properties, 512 bytes
> for
> 16 bits of properties.
That's acceptable. A good concession, trade 256 bytes for much more
flexibility.
> > 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.
>
> Please explain what you mean by "overlay with background" and
> "overlay
> without background"...
Well, take a look at SAA.GIF... You see the last dark-blue line??? That's
the one which has a background behind it. That one is always displayed. Now,
if there is a character in front of it, it will also be displayed, and the
'overlay without background' (the one below it, the first line in the
lighter-blue grid) will then be TIMPed over the character again.
> > 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.
>
> Well, you will want to animate the player and NPC sprites at least, I
> think. Animations that are not sprites are optional, although very
> pretty.
Yes. I have already implemented that.
> An idea: passive NPCs could be used as animations. For example: a
> waving
> flag could be a sprite. It doesn't attack you, it doesn't talk to
> you, it
> only animates. If the amount of animations is relatively small, such
> an
> approach would be feasible and it wouldn't complicate the engine.
My idea! (we're really on the same wavelength aren't we?) A
sprite-property would have to be created to not let it move but to let
it keep animating, even though it is not moving.
> > > 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.
>
> Relax, I'm not attacking you!
:) sorry if I sounded a bit 'attacked'...
> I think this is interesting info for people interested in games
> engines.
> Some people already know it, some people don't.
True.
> > 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.
>
> That is one way to handle it. But if you make an engine that will
> perform
> well in the worst case, it cannot do as much as an engine that
> performs
> well 95% of the time.
True. But you can't really do that with a smooth scrolling engine.
I have decided, by the way, that my engine will have 4 modes:
- v9938 smooth, border cloaking @ 50Hz (not at 60Hz)
- v9938 non-smooth, animations, speed-optimizations
- v9958 smooth, animations
- v9990 smooth, animations
> Look at shoot-em-ups, many of them have slowdown when there are lots
> of
> enemies. Sure, that's annoying, but wouldn't it be more annoying if
> there
> could never be many enemies at the same time?
>
> It's a trade-off. Your choice for "always smooth" is a clear one, but
> it's
> not the only good choice.
In this case it would look terrible. I don't care if very occasionally,
when accidentally too many characters are moving on the screen, there
is a slight 'stotter'. But anything more than that is -for me- not
acceptable in a smooth scrolling engine.
> > > 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!
>
> That trick only works if the number of combinations of background
> tiles and
> transparant foreground tiles is not too large. If there are 10
> background
> tiles and 40 transparant foreground tiles, there are 400
> combinations,
> which takes up quite a bit of VRAM.
You will have to design maps with that in the back of your head, yes.
But for example fences are almost always on grass. And 'shadow' is
almost always in door-openings (as are door-triggers, by the way).
It's much faster for the engine to handle...
> Ofcourse it is unlikely that all possible combinations actually occur
> in
> the map, but it would be a lot of work for the engine to determine
> which
> combinations are used and which aren't. This is better left to the
> editor, like I described in one of my previous mails.
Yes, that's what I'm saying. The editor should pre-format it that way...
> > > 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.
>
> It looks very obvious when you read it. But you have to design the
> engine
> in such a way that it can take advantage of this trick.
Have I told about the engine-modes yet??? Hmmm... yes, I have.
So I will also add an engine structured this way. But I chose for smooth
scrolling in the first place, not fast 8x8 scrolling. That's why I don't use
tricks like this (in the smooth scroll engine). Actually, I probably will,
to be able to have more characters moving at the same time on the screen.
But not now yet, I want to see how far I can go with in the worst case.
> And it even influences the map data structure. For example, if you
> use a
> 2-layer map, it could be faster to store the data as one layer of
> pairs
> than as two layers of single values.
Not nessecarily. When you have two 16k maps, the only thing you have to do
to switch to the other map is SET 6,H or RES 6,H...
> > Programming a
> > smooth-scrolling engine really sucks though, believe
> > me.
>
> Yes, I believe that!
>
> I once made a smooth scroll diskmagazine look-alike. It looked like
> the
> final part of Almost Real, but more advanced: it could be scrolled up
> or
> down by the reader.
>
> A game engine has to scroll in 2 directions, so that makes it even
> more
> complex. And there is activity on the screen, soft-sprites and such.
Correction: 4 directions.
> > Also, imho, a scrolling engine looks much, much better
> > than a 'solid' one like the PA series have.
>
> I do think that the PA3 engine is good enough to make fun games. I am
> looking forward to the public release of the engine. By using this
> engine,
> people can get more experience at creating RPGs.
True.
> > 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.)
>
> PA3 was the first in the series that was written in assembly. After
> PA3
> Stefan Boer stopped and Peter Meulendijks had to create code,
> scenario and
> graphics for The Lost World and Realms of Adventure. I cannot blame
> him if
> he didn't want to do an engine redesign as well.
Ofcourse not. From origin, Peter was a graphic artist (and an RPG designer).
He learned Assembly to be able to adapt the Lost World to his wished (right,
Peter?).
> > 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 RAM map is not the real problem, I think. Moving from a fixed
> size map
> to a map with arbitrary sizes requires some changes in the RAM map
> handling
> engine, but not too much. But apart from plotting the map, handling
> enemies
> etc is also very different, adapting that would be a lot of work.
I am not talking about simple conversion (although that would still be kind
of a job, because you don't want to have to convert new stuff again
everytime, the editor would have to be modified to handle 'converted' maps),
but I am talking about the different screens 'fitting' together. If you
would do that you would probably see a 'grid' in the field on the rows and
columns where originally the screen-borders were.
> Maybe adapting the tools was a problem, I cannot tell because I
> didn't see
> them yet.
I don't know either.
~Grauw
--
>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<
email me: [EMAIL PROTECTED] or ICQ: 10196372
visit my homepage at http://grauw.blehq.org/
>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<
****
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
****
