> I meant "number 102" by "#102". The statement above is compatible with
both
> 8-bit and 16-bit tiles. It actually is an approach to remove the need for
a
> separate data map, thus reducing the number of bits per tile!
Okay, I get it.
By the way, I never had the intent to maintain more than one map.
The number within the tilemap can indicate the tile ofcourse, but the range
in which it is can also identify its function. A walkthrough wall, like in
your example, can simply be an image of a wall in the walkable tile range
(#00-#3F).
And yes, I know the idea of mapped patter properties is better than fixed
pattern properties. It's just for the example now (just assume #00-#3F is
mapped to the 'walkable'-property)
> > Using 16-bit
> > tilemaps and variable sizes (which is absolutely not nessecary) CAN be
done,
> > but it will make the code more complex.
>
> 16-bit is hardly more complex than 8-bit. It uses a lot more memory:
> that's the problem.
>
> Why do you think variable map sizes (opposed to only powers-of-two) are
> hard? Please outline some algorithm or piece of code that would increase
> significantly in complexity.
You are absolutely right. As said in my other message, I changed it. The
dimensions can now range from 2x1 to 256x256, as long as the total map
doesn't exeed 16k (so in fact the 256x256 is not possible, but 234x58 is).
There is -at least in my engine- still one limitation: the X-dimension of
the map has to be even. But that's only required when you use the v9938
smooth 60Hz mode. In all other modes, this is not a required.
> > > This approach gives more flexibility than the PA3-like fixed
background.
> > > But it also uses more memory.
> >
> > 1 map is still the smallest. And it can be done.
>
> True. But there is nothing wrong with exploring the alternatives before
> you select one. In fact, I think it's part of good design.
Perhaps. But if the same result can be reached with one map, with very
little concessions (none know by me so far), the choice is clear to me.
> > > > * bitmap gfx for use in the statusbar (like in sd-sn)
> > >
> > > I think not all characters should have this. It looks real nice, but
it
> > > does require a lot of graphics, putting a burden on both the GFX
artist
> > > and on the VRAM.
> >
> > If they are not too big they can be loaded from disk really fast.
>
> I really hate it when in RPGs pictures are loaded whenever you talk to
> someone. First disadvantage is that the music is interrupted, second is
> that the spinning up of the drive will take time, independent of how
> little data is loaded.
One word: harddisk.
Other word: cache
Third word: >128 support
Ah, fourth word: compression
> Both in-game battles and separate battle screens have their own
advantages.
> There are examples of good games in either category.
True.
> > IF you choose to let the enemies be visible.
>
> Personally, I think that invisible enemies are not a good idea. I didn't
> really like that in DS6. And even in DS6, enemies can become visible,
> either after you flee from them or after using an item. Also, the enemies
> in caves and villages were always visible.
>
> Invisible enemies do make the engine a lot simpler: you only have to know
> the chances of an encounter, you don't have to model the enemy's
behaviour.
> But I think this simplicity hurts the gameplay.
Hmmm... I indeed also like enemies being visible. But at the other hand, I
have nothing against invisible enemies. It only makes the game more complex.
And at least in my v9938 smooth-engine, it can't be done (takes too much
time). But ofcourse, it's a choice.
~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
****
