I... don't... know. The only times I've used a doubly linked list is when I
need things to stay in proper order, as aposed to reversing on a load, such
as events, and my command_table was switched to a linked list. I don't see
why you can't use it all the time (pointers are like 4 bytes!). I'd much
rather strip it from a doubly linked list then remove it from a not. But,
I'ma look into this and see what I come up with, and post some info later
(Unless I find its used to keep things in proper order...)
Davion
From: Jed Yang <[EMAIL PROTECTED]>
To: [email protected]
Subject: Re: Linked lists, new element
Date: Fri, 06 Feb 2004 08:48:29 -0800
I am also using buckets with some minor differences.
Strangely that there has been a discussion on events,
I just wrote my event system three days ago...
Is there some good event systems out there?
The reason I wrote my own is I am not writing a ROM mud
(I started from scratch). But I can still read some codes
and get some new ideas.
At what point (as in usage and common operations frequency) in a linked
list should I use some more memory and change it to a doubly linked list?
This will save the loop of finding the previous item, which might be
inefficient for lists really long. This is my personal thought, for
I have not taken any algorithm/computer science course yet.
Thanks in advance,
Htam
Michael Barton wrote:
I lied. He's right. I just looked and my code doesn't use 2 loops
through the event
queue. It used to have 2 loops, but I guess I got rid of it at some
point.
There is one thing I have done that I think is worth noting...
To cut down on CPU,
#define BUCKET_COUNT 64
event *event_list[BUCKET_COUNT];
int current_bucket;
I actually have 64 queues, and each one is 1/64th the size.
I advance current_bucket each time I pass through my process_events
function.
New events are added to bucket (e->ttl+current_bucket)%BUCKET_COUNT and
ttl is set to
ttl/BUCKET_COUNT.
You'll notice this is similar to a radix sort or the hashing used to store
room mob
and obj indexes.
A fairly small change, and if you use a large enough array, you should
mostly only be
processing events that will be fired on that pulse.
--Palrich.
----- Original Message ----- From: "Davion Kalhen"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, February 05, 2004 8:18 PM
Subject: Re: Linked lists, new element
Ug. I'm sorry about this, but this morning after getting home from work,
I
posted stuff on the event list posted by Jeremy I believe it was, and I
don't think it sent... if it did, my bad ;). I can't remember your exact
code at all (After 12 hour shifts, the memory goes down the toilet). But,
I
remember you had two for loops in your update function. If yours is
called
as often as mine (Every cycle) that can much up some serious CPU if your
lists are large enough. I'd say switch to a doubly linked list (->next
->prev), or right before the "event->delay-- <= 0" do the check to see if
its to be killed, if it is, even_last->next = event->next, etc. You know
the
drill. But that should cut down on the CPU usage alittle and it
eliminates
that redundant for loop. I hope this helps.
Davion
_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=dept/features&pgmarket=en-ca&RU=http%3a%2f%2fjoin.msn.com%2f%3fpage%3dmisc%2fspecialoffers%26pgmarket%3den-ca
--
ROM mailing list
[email protected]
http://www.rom.org/cgi-bin/mailman/listinfo/rom
--
ROM mailing list
[email protected]
http://www.rom.org/cgi-bin/mailman/listinfo/rom
_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=dept/features&pgmarket=en-ca&RU=http%3a%2f%2fjoin.msn.com%2f%3fpage%3dmisc%2fspecialoffers%26pgmarket%3den-ca
