> > > > > > 8 bytes: filename (without ext.) of the patterndata
> > > [snip]
> > > 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.
>
> If you put a file ID there instead of a file name, you are breaking the
> standard.
This standard (what a bullshit, btw) differs per game. Besides, if it's a
place to store the filename, the 'number' of another file-system can also be
seen as a filename, only in another form.
> > 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.
>
> Even in the non-library case, file names can be stored outside this file.
> If you are planning on using a library later on, this is probably the
> better approach, as it makes the introduction of the library system
easier.
It makes editing harder. If you change something, it will have to be changed
in the source too. This is much more simple, and allows non-coding people to
use it in an easy way as well. And that's what all this actually is about,
isn't it?
Besides, I know it can be done outside the files. Ofcourse. But at the
moment, I only see disadvantages of doing so (complexity, mainly), while I
see no advantages...
> Look at the sample kit value in MBM files. I never used it to find the kit
> file name in my own programs.
Is it there??? Ahhh... If I had know it...
It was probably hardly used because the replayer didn't support it.
> > 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.
>
> Source doesn't have to be assembly. You could use XML or a simple ASCII
> format. Or use assembly with all macros so it is readable.
Yeah, right. Do it yourself.
> > 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.
>
> Great! :)
Glad everybody (well...) is happy now.
> > 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.
>
> Ah, you wanted to make the design in such a way that your existing
> implementation would fit...
:)
Okay maybe I have the wrong 'attitude' here...
[about notes in MBWAVE]
> The problem may be that the file size would increase rapidly if you store
> frequencies (2 bytes instead of 1).
As if I care about that. It gives the composer more possibilities, and on a
somewhat slower system (which the MSX is imho) preprocessing can be a very
good thing. 24 wave channels are really consuming lots of time... This way
it can be lookup note, send it to OPL4, lookup next note.
> > 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.
>
> Like Konami does it: store channels separately.
Don't know.
Like KousTracker did. It was really done exellent, except for the editor
which really sucked. But the idea was very good.
> > 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.
>
> I was thinking about that as well, but I never really started it.
It would be very useful... I'll see. If I feel like it (or rather, am not in
the mood to work on existing projects). It will be fun I think...
> But hey! It's another separate edit and use format... I like those! :)
:)
> > NOP did about the same thing in
> > Unknown Reality I think...
>
> I'm not sure they did. I know they complained about the MBM player being
> too slow. But I think that in all parts that really need the speed, they
> used SampBox instead of MBM.
Prolly.
> In the Almost Real Copper Bars part, the music is played MSX-AUDIO only if
> you have both MSX-AUDIO and MSX-MUSIC, otherwise the replayer would take
> longer than the V-blank period.
:) Well I also need the V-blank period so... shriek...
> > It is not only loading space but also temporary space, for example to
> > save the background if you display a menu.
>
> Saving GFX is easier in VRAM. Besides, you can redraw instead of store the
> background. Somehow the graphics could be plotted before, so why not
> generate them again?
Saving GFX is easier in VRAM only when you have space. But you are right,
redrawing is better. Then the RAM can be used for something else (there
always will be other things).
> > 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...
>
> An "engine descriptor file": it specifies what data the toolkit can and
> can't generate for that particular engine. Yes, I think that's a good
idea.
> It makes it easier to use one editor for more than one engine. And to
> easily adjust the editor if the engine gets more possibilities.
Yes. However, it makes the editor more complex.
By the way, I would really like to see someone actually starting to code the
editor instead of only all this talking. Otherwise, at some point the
discussion will be kind of over (not in the near future though, seen the
amount of messages on this topic :)), and it will be forgotten...
> > 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).
>
> But if you load the palette in 2 parts, isn't that an indication that the
> data isn't really that strongly connected?
No!?! I don't load it in two parts?!? In one part, and then I send it to the
VDP with a fade-effect over it.
> > 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.
>
> Compiling, compiling... No need to store filenames in the engine files.
And
> the palette itself will end up with a whole bunch of other script/scenario
> data.
I still don't see the advantage of why not to store the palette with the
image. It belongs there!!! And concerning the script, it will definately not
end up there. If you want effects or a different palette, you will have to
hard-code it in the engine, and call it from the script using for example
'AltPalette {alt.palette.data}'... But by default, the palette coming with
the engine will be used. Otherwise you would have to define the palette for
every characterset. To hell with overview! Let's make an unnnessecary mess
of it!!! Unnessecary, because I see no disadvantages of storing it where it
belongs.
I always thought .GE5 was much more useful than the .SC5 & .CO5 MCCM used...
Except ofcourse for the additional size and the palette being stored at the
end of the file instead of the start. But that's a disadvantage of the file
format itself, not of the idea. It can be changed.
> > Why LDIR and not directly load it to the correct location? And it
> > results in less administational stuff.
>
> I always load to #8000. I think there was a reason for this, but I've been
> doing it for so long, I can't remember why I started.
Terrible. Bad, bad habit.
Moving 16k takes up an awful lot of time (it is even noticable!).
> > > 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.
>
> Not run-length... SQueeZe!
>
> My own variation on the POPCOM algorithm. It gets very good compression
> ratios. Sometimes better than GIF. It's based on storing repeated patterns
> as "offset -x, length n" references.
Is it fast?
Gimme info about it (private?).
> > > 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.
>
> The script/scenario file. The game needs a scenario as well, otherwise it
> can't do anything useful with the graphics (even if the palette is right).
I never came up with the correct word for such a file. A script, ofcourse.
Yes, I'm in favor. The actual actions are programmed in Assembly, but their
connection and content/variations are stored in a script (which we should
btw. also define).
> The part where you store "if the player leaves the current area here, he
> will go to area 51". And where you keep non-GFX animation data,
> conversations etc.
k.
> > No, not really.
>
> Scenario:
> You reserve space for 3 palettes in your code. In the editor, you create 4
> palettes. You don't need the 4th yet, so you forget to update the code.
> When you then test your code, the 4th palette will overwrite some other
> data, because no space was reserved for it.
Then f*cking limit the editor. That's what the TASM-like file is for!
Besides, the same limit also goes if you use scripts. Do you think the
engine will have even anything to do with the word 'fast' anymore if you
start reading (and animating) the palette (and a lot of other things) right
from the script? Yuk....
> > And it will decrease the size of the 'scripts' (which are in RAM
permanently).
>
> You only need the scripts for the current area in memory. So where you
> store the palette doesn't matter in space.
Prolly, yes.
...we really need to define those scripts...
> > 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 thought that approach would be too slow, but Peter wrote that PA3 uses
> it, so that proves it does work fast enough.
It is not really fast, but also not really slow. It's just that it's the
only way without wasting lots of memory on a second map or something like
that. Which would by the way be even slower I think.
By the way, PA3 is not really a good example here because it has got all the
VDP time only for displaying a few sprites. PA3 has got loads of time left,
so if it were very speed-consuming, PA3 would be the last game in which you
would notice.
(btw, this is not a negative thing)
> > 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
>
> It didn't get through, which is a good thing, since you shouldn't post
> attachments to the list.
I forgot... :)
(I really ALWAYS do).
It was quite small though... Anyways, it's online.
> > > 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.
>
> I count as "horizontal" and "vertical". OK, maybe "direction" is not the
> proper word. "Dimension" maybe?
Better. But using direction is better, because then you can also make
difference between 4 and 8-directions (including diagonal directions). You
can't call those the 3rd and the 4th dimension, can't you???
> > 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.
>
> In PA3 (Sunrise Island), there is a forest of leaf trees and in the screen
> next to it, it's a forest of pine trees! But because you can't walk
> directly from that one screen to the other, I didn't notice until I made a
> big graphical map.
See what I mean??? And there's no transition, it would be on a straight
line. Would look really stupid and 'fake' in a scrolling engine...
> It's a very nice map, by the way! (the shape of the islands is ...)
:)
~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
****
