On Wed, 31 May 2000, Laurens Holst wrote: > > > > > 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. > 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. Look at the sample kit value in MBM files. I never used it to find the kit file name in my own programs. > 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. > 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! :) > 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... > 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. The problem may be that the file size would increase rapidly if you store frequencies (2 bytes instead of 1). > 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. > 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. 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. 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. > 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? > 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. > 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? > 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. > 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. > > 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. > > 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). > > 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!!! 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. > > 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. 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. > 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. > 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. > 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. > > 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? > 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. It's a very nice map, by the way! (the shape of the islands is ...) 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 ****
