People keep on saying this. How exactly are linked lists going to be
too slow for a particle engine? What in the world would you use,
arrays? This is exactly the sort of place you should use linked lists.
Linked lists are very slow for sorting and searching, due to their
sequential nature.
Also, if you use STL vice a home grown solution you get searching etc and
near (if not 100%) auto growth
on the fly ;) push_back baby push_back ;)
-Ron
-Original Message-
From: Persuter [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 27, 2002 08:38
To: [EMAIL PROTECTED]
Subject:
I'm confused now since it it's more than a short while after the release.
Will the SDK be out after 1.1.1.1?
What do you consider to be a short while? In a cosmic sense it's only been a
fraction of a millisecond since the 1.1.1.0 update was released. :)
Jeffrey botman Broome
Uh. I imagine if he wanted to know the relevance in the cosmic sense of time
he would have asked some nutcase philosphy mailing list.
Instead he asked a nutcase HL coding list.
- Original Message -
From: botman [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, June 28, 2002 3:24
--
[ Picked text/plain from multipart/alternative ]
I have a hunch that They Who Give (aka Valve) would not conciously NOT
release the SDK nor just forget.
Daniel Koppes wrote:
Uh. I imagine if he wanted to know the relevance in the cosmic sense of time
he would have asked some nutcase
Good things come to those who wait ;)
-Original Message-
From: Martin Webrant [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 27, 2002 10:56
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] 1.1.0.0 SDK Question
I'm confused now since it it's more than a short while after
the
Hello Chris,
Thursday, June 27, 2002, 8:07:57 PM, you wrote:
CTNB This is a question relating more to the Qc file than eveyrthing else, but if
CTNB you're using the original Displacer model then this will be on nto help to
CTNB you. Check that the model ( using the HLMV) has the attachments
At 09:27 AM 6/27/02 -0700, you wrote:
[ Picked text/plain from multipart/alternative ]
I have a hunch that They Who Give (aka Valve) would not conciously NOT
release the SDK nor just forget.
You know, I think we've been going easy on these mod developers for too long.
Agreed. Let's 'forget' to
Ok, ive basically got it working, but theres 2 problems.
1. The button lags behind my mouse, and ofter the cursor leaves the button when you
drag it. For now im just
makig it stop dragging if this happens, but Id really like to make it catch upto the
mouse.
2. Everytime first time cursorMoved
As long as you make sure that you're careful about allocating memory,
you should be fine. My particle engine utilizes two lists per system,
one for particles to be displayed and one for trash particles to be
reused. Eventually what I might want to do is simply have an engine list
for the
I've had this sorta problem before, what you need to do is keep track of the
mouse position, like, x / y and oldx oldy. then you move the button
according to the difference between the two. Hope that helps
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
Linked lists are the best way I know of to do a particle engine.
You save processor time during allocation of new particles and even more
during deallocation. The ability to have virtually infinite particles is
also a plus.
- Original Message -
From: Tom [EMAIL PROTECTED]
To: [EMAIL
I don't have the time to get into this argument, but there is a reason that
games like Half-life\QuakeX prefer static allocation; speed! There is no
reason you need infinite particles.
Basically this boils down to the good 'ol speed vs. memory argument. People
have argued this for decades.
I
Look Scott, if you don't have the time to enter this argument then simply
don't. That must of been the most arrogant comment I've heard this week.
- Original Message -
From: Scott Velasquez [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, June 27, 2002 4:31 PM
Subject: RE:
umm not exactly sure how u mean to do that kuja, but wouldnt it require a think
function?
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
(This weapon is server-side) I have used the glock .qc file to compile a
model and it shares the same animations. I copyed the mp5 from hl
exactly(for my weapon code) and i change it to my gun and such. When I
change the animations to the glock ones:
enum desert_e
{
DESERT_IDLE1 = 0,
Look Scott, if you don't have the time to enter this argument then simply
don't. That must of been the most arrogant comment I've heard this week.
There haven't been that many posts this week. :)
It didn't seem like an arrogant post to me, just somebody stating their
opinion. Don't get your
well he does have a point. linked lists arent exactly the fastest things
around. They however are easy to implement; so chances of bugs, and further
yet memory leaks are lower if you understand what the concepts are. In the
end i suppose it just boils down to personal preferences.
- Original
Yeah, it boils down to whether it runs fast enough for your application.
Static memory allocation is going to be somewhat quicker, but I just
CAN'T see the justification, personally. Especially given the HIGHLY
variable nature of the beast, in that one minute you might have no
particles, the next
This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
Siiigh, I have SUCH a tendency to put everything in the header. :-) I
want to move a chunk of data, about 700 or 800 bytes, though it can
probably be compressed down to 400-500 with a good bit of
At least we came to some sort of consensus.
To Botman:
I just did not appreciate Scott's, I am too smart, I know I am right, I
don't have the time for this... attitude. Then again, I haven't really
talked to very many people this week either... :P
- Original Message -
From: Persuter
In my OpenGL system I just have one linked list for all of my particle
entities. To render I simply go through the entire list. To add a particle I
simply dynamically allocate one add it to the end. For removing a particle,
I deallocate it and update the links of the one before and after it. Very
- Original Message -
From: Miguel Aleman [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, June 27, 2002 11:04 PM
Subject: Re: [hlcoders] Particle System
Look Scott, if you don't have the time to enter this argument then simply
don't. That must of been the most arrogant comment
Iain, I'm not sure how you interpreted Scott's comment. If he mean what you
said he could have said something such as Sorry I cannot be more detailed,
but I'm too busy to debate... or I'm short on time, but in a nutshell my
opinion is However, he insisted on saying something much more
EXACTLY. So quit dissing Percy's poor particle system and answer his
OTHER question! /me points frantically.
Persuter
-Original Message-
From: [EMAIL PROTECTED] [mailto:hlcoders-
[EMAIL PROTECTED]] On Behalf Of Miguel Aleman
Sent: Thursday, June 27, 2002 10:34 PM
To: [EMAIL
Resending this since I sent it from the wrong account before and it bounced.
B) Instead of sending an updatedata command for each field, encode
the data into a big long char stream and send it over. First of all,
there are problems with sending encoded chars, specifically the problem
LOL, just making sure I got my point across. :-)
- Original Message -
From: Persuter [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, June 27, 2002 10:15 PM
Subject: RE: [hlcoders] Particle System
EXACTLY. So quit dissing Percy's poor particle system and answer his
OTHER
Sure, having the ability to create a *variable* number of particles is a
plus by using a linked list over an array. Why have 20,000 dormant
classes/structures taking up memory when you don't have to? How about
allocating new particles? Are you supposed to scan through the entire
array
each
I hesitate to even suggest this, since my ignorance of networking is truly
astronomical. But this just occurred to me, so I throw it out for what it's
worth. How difficult would it be to establish a separate TCP connection
from client to server (over a different port, I guess)? Then you could
I have considered it. Two problems: One is, I'm not quite sure how to
get the IP of the client from the server, or vice versa for that matter.
Secondly, I don't know UNIX sockets that well, and I'd have to port it
over for the Linux dedicated server. But it's something I've considered.
Persuter
How often do you have to transfer these large amounts?
if you need updates only once in a couple seconds you could perhaps
disperse the data transfer so that you dont get alot of lag at the same
time? sort of an asynchronious low-priority transfer maybe?
a separate tcp/ip connection is not very
Hello Sergei,
Friday, June 28, 2002, 7:21:19 AM, you wrote:
Are we talking about standart HAlf-ife messaging system?
SVL How often do you have to transfer these large amounts?
SVL if you need updates only once in a couple seconds you could perhaps
SVL disperse the data transfer so that you
Amen Jim! Thanks for bringing some sense to this frenzy :)
new and delete (malloc and free) have to search for memory to allocate.
If you look at how some simple memory heaps are coded, its essentially a
large array (the heap) with utility functions that scan it linearly
looking for places to
33 matches
Mail list logo
