[CF-Devel] map bug
Michael Toennies
mtx93 at informatik.uni-bremen.de
Wed Nov 1 09:55:04 CST 2000
Hi
Hm, the layers is a great idea. I think, when i read both mails,
we need some work in this part of the interface.
The problem i see, also with my changes, is that we must work on
all 3 parts of crossfire at once: server, client and editor.
This looks like a big task.
But when we do it yet, with some other changes in mind, we can
give cf a good step. I think there are more problems like this one,
lets make a list and find some solutions.
The server crew is fine and work hard.
I will make the dx client and if needed i can
do some changes to the linux client too.
So we need one who rewrite the editor. That a theme on the list
some weeks ago. We need it.
The old editor is also outdated and the interface is not the best.
Better editor will give us better and more maps, thats a always true rule.
Who will make it?
MichToen
>
MWedel wrote:
>
>
>This is actually true for many items. I'll look into a more
>
general >fix
>
>than the old double floor fix that you originally see (that fix
>
>was that
>
>if there were two floors, you would see both of them to make
>
>things look
>
>better).
>
>
> But the more general long term approach is to have a stacking
>
value >that
>
>the client can set. Way back when, crossfire only used bitmasks
>
>with no
>
>masking, so it only made sense to draw one image per space.
>
>Then Xpm came
>
>around with masking, so it made sense to draw 2 items >per
>
space. But that
>
>got into the case you see - character standing >on a building that is on
>
>top of something else which doesn't look >very good, so double
>
floor patch
>
>came about.
>
>
Why bother with a stacking value? If you just tell the server or
>
client to
>
use a 4 layered system, all of the images that need to be placed on the
>
screen can easily be handled. Treat the floors as the bottom layer (0),
>
building components next (1), then items (2), and finaly animated
>
creatures
>
(3), you should be able to solve the problem without any significant
>
increase in processing.
>
>
> I briefly tried drawing all items on a space. Aside from consuming >a
>
>lot of cpu time (but back then that was on a 20 mhz 68020 - >sun3/60, 3
>
>mips), at some point it just didn't look very good because
>
>everything sort
>
>of got muddled together and it just looked like a >blob.
>
>
> the cpu performance should not be as much of an issue -
>
especially >if we
>
>make some linked lists to more quickly identify the items to >draw. But
>
>determining what items to draw may get difficult (for >example,
>
if standing
>
>on the store, you want the store to be drawn and >the ground beneath the
>
>store, but you don't want the store to bubble >up on top of swords and
>
>other things dropped there (we'll ignore the >fact that this happens
>
>anyways right now when maps are saved due to
>
>the way multi part objects are handled).
>
>
> but if you then need to look through a space each time an item is
>
>inserted/deleted and update a stack of visibility for all those >spaces,
>
>that can get expensive cpu wise. Think of the effects of a
>
>large fireball
>
>case in a room full of monsters that have treasure or >other
>
items beneath
>
>them (or that they drop as they die).
>
>
> Another thing on the long TODO list is to just update how the >server
>
>deals with map updates. Right now, whenever anything is
>
>inserted/removed
>
>from any space on any map, the server determines how >that space
>
now looks.
>
> What I really want to do is only determine >what the spaces that the
>
>player sees looks like - who cares what >something 20 spaces off the map
>
>may look like. This would entail >adding a bitmask to the map
>
structures
>
>which shows which spaces are >up to date (as they are/were in
>
the players
>
>view, got updated, and >haven't changed yet), and which are
>
stale. Before
>
>we send the map to >the player, we update all these stale spaces.
>
>
> When something is inserted/removed, we just mark the space stale >and
>
>leave it at that until it goes within view.
>
>_______________________________________________
>
>crossfire-devel mailing list
>
>
crossfire-devel at lists.real-time.com
>
>
https://mailman.real-time.com/mailman/listinfo/crossfire-devel
>
>
_________________________________________________________________________
>
Get Your Private, Free E-mail from MSN Hotmail at
http://www.hotmail.com.
>
>
Share information about yourself, create your own public profile at
>
http://profiles.msn.com.
>
>
_______________________________________________
>
crossfire-devel mailing list
>
crossfire-devel at lists.real-time.com
>
https://mailman.real-time.com/mailman/listinfo/crossfire-devel
>
More information about the crossfire
mailing list