Re: [hlcoders] OT: Screen res effects ping/latency or not?
Thanks for that Jeff, I see that the ping would slow down at the clients end because the pc is handling other matters rather than sifting through the packets as fast as it can. - Original Message - From: botman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, March 18, 2003 7:20 PM Subject: Re: [hlcoders] OT: Screen res effects ping/latency or not? I just wanted to get the opinions of some respected programmer to know if lowering your screen resolution will help reduce your ping and hopefully get a simply explaination why. I personally think it does make a difference but the person I've spoken to about it points out that rendering for graphics is client side. But i know that things off screen aren't completely sending information to the client since they aren't being rendered and that I'd imagine this extends to distant obects which wouldn't be rendered at lower resolutions and thus reduce the network traffic a bit as if it was off screen. I think it really depends on your video settings. The most noticeable difference will probably be using the default Software rendering mode (instead of OpenGL or Direct3D). Reducing the resolution will require less pixels to be drawn which will take less CPU time to render a frame. This will increase your framerate. If the CPU is spending less time rendering pixels, it has more time to spend sending network packets (up until the point it reaches the cvar network limits). The people who would notice this the most are people using Software rendering mode, with slow CPUs, low amounts of RAM and high speed network connections. As you mentioned, things outside the PVS (potentially visible set) don't need to be sent to a client, but the framerate of the client won't (or shouldn't) effect how often the server sends packets to the client. The server will have it's own independent framerate and will send any necessary data to the client during each of the server frames. If the server is heavily loaded, then there won't be much the client can do to improve the latency between the client and the server (if anything sending more data to the server will only cause it to slow down ever so slightly). The framerate of the client will effect how often it can send data to the server. A low framerate on the client will more than likely mean that the client is CPU bound and won't be able to send network data as quickly as it should. Anything that increases the framerate on the client could potentially reduce some of the latency between that client and the server. Jeffrey botman Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Viewport Question
First it's fogging, then it's particle systems. .. viewports must be the new
'black' this year. :)
- Original Message -
From: Alexander Jochum [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, January 21, 2003 8:13 AM
Subject: [hlcoders] Viewport Question
Hi there
I added Bigguys viewport system to my mod now
I have a few question...
1)
How can I create a viewport above a specific entity lets say I know the
origin etc...
2)
Is it possible to draw a viewport over a vgui menu ??
Everytime I have a vgui menu opened and draw the viewport, it's behind the
menu
and through the grid of the vgui menu it's grayed.. ( oh it doesn't matter
if I draw the vgui menu first and then the viewport...)
What I want is a clear second viewport over a vgui menu...
3)
How is it possible to draw a viewport without the v_model ??
I use this Code at the moment to Setup my viewport
(it doesn't anything else then drawing the main viewport again...)
void VP_EntityTest ( struct ref_params_s *pparams, vp_s *vp )
{
// this block is the only required data
pparams-viewport[0] = XRES(vp-x);
pparams-viewport[1] = YRES(vp-y);
pparams-viewport[2] = XRES(vp-wide);
pparams-viewport[3] = YRES(vp-tall);
pparams-onlyClientDraw = vp-clientOnly;
}
THX
__
Ihnen fehlen die richtigen Worte fur Ihre SMS? WEB.DE FreeMail hat die
besten Sprueche fur Sie. http://freemail.web.de/features/?mc=021169
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Multiple viewports in HL?
The problem seems to relate to my Gforce4 4200 card, I've tried various driver versions with the same bizzare effect ranging from full screen blurring to a HOM effect only when the view turns and it's rendered were some surfaces should be. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 15, 2003 11:55 AM Subject: [hlcoders] Multiple viewports in HL? There are instructions in HLTV.doc that describe how to make multiple viewports in HL. (the mechanism HLRally are using to make a rear-view mirror.) I've been trying out this feature, and although it works fine on my machine (and on most other people's), one person is getting a hall-of-mirrors effect all over the window that's being drawn first. (Apparently it works fine in Direct3D, but not in OpenGL. We want to use OpenGL...) So: Is there anything produced by Valve which uses the multiple -viewports feature? It would be nice to know whether that has problems too, or whether it's my fault for setting something up wrong. And apart from that - is this a known problem? Any suggestions as to what might be going wrong? Any workarounds? -- Laurie Cheers ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Motion Blur
Using a colour glow shell to duplicate the model several times mkaing them progressively less opaque and then somehow finding a way to delay the animation of the duplicates to be behind the current frame of the actual model. I'd wager that rendering them with a delay would surfice. For information about using glow shells to create duplicate of models that copy their movement have a look in the spirt of HL forums where Laurie has been developing the trick to help create mirrored floors. - Original Message - From: Michael Shimmins [EMAIL PROTECTED] To: HLCoders [EMAIL PROTECTED] Sent: Sunday, January 12, 2003 3:00 AM Subject: [hlcoders] Motion Blur This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] Hi all, I'm trying (in vain) to apply a motion blur effect to the view in HL. I've tried doing this using the accumulation buffer in OpenGL which slows the frame rate down to 4 frames per second. Does anyone have any other ideas about how to do motion blur? Cheers, Michael Shimmins mailto:[EMAIL PROTECTED] The Absconder Effect (http://www.tae-mod.com) ___ Important - This email and any attachments may be confidential. If received in error, please contact us and delete all copies. Before opening or using attachments, check them for viruses and defects. Regardless of any loss, damage or consequence, whether caused by the negligence of the sender or not, resulting directly or indirectly from the use of any attached files our liability is limited to resupplying any affected attachments. Any representations or opinions expressed are those of the individual sender, and not necessarily those of Sesechial Software. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Creating a persistant statistic database?
I help moderate the VERC Wanted forums and someone recently posted a request for a programmer to create a database system for an on-line RPG mod using HL. Now my knowledge of the networking side of HL is somewhere between zero and minus one but something in my gut says it can't be done. I know that it's possible to get information from games written to HTML documents (as some sites display player stats on websites from various games) but is it possible for a HL server to draw information from a database like a web server and allow for a designer to create an RPG like leveling system? I know that it'd be easier to simply store the stats locally in an encoded file but it's always possible for those to be hacked which is why the person who posted wants to take this other route. Any suggestions or advice for me relay to the designer would be most appreciated. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Creating a persistant statistic database?
Ok thnx, I'll pass the information on. - Original Message - From: botman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 09, 2003 5:19 PM Subject: Re: [hlcoders] Creating a persistant statistic database? I help moderate the VERC Wanted forums and someone recently posted a request for a programmer to create a database system for an on-line RPG mod using HL. Now my knowledge of the networking side of HL is somewhere between zero and minus one but something in my gut says it can't be done. I know that it's possible to get information from games written to HTML documents (as some sites display player stats on websites from various games) but is it possible for a HL server to draw information from a database like a web server and allow for a designer to create an RPG like leveling system? I know that it'd be easier to simply store the stats locally in an encoded file but it's always possible for those to be hacked which is why the person who posted wants to take this other route. Any suggestions or advice for me relay to the designer would be most appreciated. It is true that you can't use the Half-Life client/server network stream to send your own custom data back and forth (other than the standard client - server network packets containing entity information). However, there's nothing to stop a client or server from creating it's own Windows/Linux socket network connection to a server (using some other IP port than what the client and server are using). The database server that you connect to could store persistent information using MySQL, flat ASCII text files, or whatever you wanted. Servers could connect to this database server and retrieve information for clients, then use the Half-Life engine network protocol to stream this data to the client (sent as entity information), or the clients create a network connection to the persistent database server directly (although this might lead to client side hacking if the client used a network proxy to modify the data coming from the database). Jeffrey botman Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] models flickering
I'd suggest you pick up the Spirit of HL source code as this was solved by Laurie. - Original Message - From: botman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 09, 2003 7:03 PM Subject: Re: [hlcoders] models flickering Everyone knows that monster models will flicker if monster is moving on train or platform. In BShift this is somehow fixed... Does anyone know how it can be fixed? If you are talking about monsters positions rapidly jumping, that's due to network lag between the server and the client (even in single player). The monster entities all exist on the server and they have to be sent to the client in order for them to be rendered. Each time the position changes, a packet with the new position must be sent to the client (even in single player). The faster the monster is moving, the faster his position is changing and the greater the jumping effect will be (moving from old position to new position). You could make the monster's positions predicted similar to the way player positions are predicted in multiplayer network games. Jeffrey botman Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] models flickering
I'm not suggesting that you take it all but it does solve the juddering problem for NPC's in motion. Yeah and i know that Spirit isn't fantastically stable for multiplayer but as i said, you don't need to incorperate it all. - Original Message - From: Pat Magnan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 09, 2003 8:04 PM Subject: Re: [hlcoders] models flickering At 07:46 PM 1/9/2003 +, you wrote: I'd suggest you pick up the Spirit of HL source code as this was solved by Laurie. Not really, trust me, the movewith stuff doesn't work too well on Network games. We incorporated it, and things just don't work right. Client side prediction may actually make it viable however. - Original Message - From: botman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 09, 2003 7:03 PM Subject: Re: [hlcoders] models flickering Everyone knows that monster models will flicker if monster is moving on train or platform. In BShift this is somehow fixed... Does anyone know how it can be fixed? If you are talking about monsters positions rapidly jumping, that's due to network lag between the server and the client (even in single player). The monster entities all exist on the server and they have to be sent to the client in order for them to be rendered. Each time the position changes, a packet with the new position must be sent to the client (even in single player). The faster the monster is moving, the faster his position is changing and the greater the jumping effect will be (moving from old position to new position). You could make the monster's positions predicted similar to the way player positions are predicted in multiplayer network games. Jeffrey botman Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Collision problem after rescaling
I think you need to cut back on sniffing that superglue Omega. :) We can all see what it's doing to your poor brain. - Original Message - From: omega [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 08, 2003 9:56 PM Subject: RE: [hlcoders] Collision problem after rescaling Doh, I just re-read your original post and see me mentioned. Silly me. Anyway, I'll have to try and find my source to figure out what I did. If you figure it out before I get back to you, I'll apologize in advance, im not sure what cd I backed that mods source up to, and I have cd's all over the place (im a horrible mess.. heh) -omega Blackened Interactive - http://blackened-interactive.com Front Line Force - http://www.flfmod.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jim Hunter, M.D. Sent: January 8, 2003 3:37 PM To: '[EMAIL PROTECTED]' Subject: RE: [hlcoders] Collision problem after rescaling www.nofadz.com/blackened/hltuts/rescale.html I wrote that a long time ago, it covers pretty much all of your problems, bowever there are some extra stuff I had to do later to fix a few other issues; but I can't quite remember what I had to do. Actually, I did everything in that tutorial (thanks for writing it, btw) and it worked except for the problem with not colliding correctly with the monsters (or other players). World collisions worked just fine. Then while trying to fix the problem with the player-monster and player-player collisions, I ran across the mail in the archive from Robin Walker at VALVe mentioning the bug in GetHullBounds (the values not getting copied into mins and maxs since there is not an operator float * in the Vector class). After fixing that, the world collision problems appeared. Jim ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Engine enhacements been added in next HL patch?
Ok thnx for that, i had some trouble finding anything going through the archieve. Still, we don't know if the mpatch is expected any time soon or later on towards the middle of the year,. - Original Message - From: MoD [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, January 04, 2003 1:20 AM Subject: Re: [hlcoders] Engine enhacements been added in next HL patch? - Original Message - From: Chris 'Tal-N' Blane [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 03, 2003 4:12 PM Subject: [hlcoders] Engine enhacements been added in next HL patch? One of my dev team somehow got word that the next HL patch might include some if not all of the engine enhancements from CS:CZ, mainly the added model capabilities like alpha maps. No need to get word, it was posted by a @valvesoftware.com : Quote follows: From: Adrian Finol [EMAIL PROTECTED] To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Subject: RE: [hlcoders] Transparent color on model? X-Original-Date: Mon, 23 Dec 2002 12:22:34 -0800 Date: Mon, 23 Dec 2002 12:22:34 -0800 There will be after we release the next patch. You can assign rendermodes to textures, like additive. You can also mask out colors in a texture. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, December 23, 2002 10:57 AM To: [EMAIL PROTECTED] Subject: [hlcoders] Transparent color on model? All: Is there a way to make a single color on a model transparent, like the alphatest color on a sprite? Thanks, Scott ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Engine enhacements been added in next HL patch?
One of my dev team somehow got word that the next HL patch might include some if not all of the engine enhancements from CS:CZ, mainly the added model capabilities like alpha maps. I've not heard any mention of this from the usual sources but it seems possible now that CS:CZ has been handed over to Ritual Entertainment and had an addtional delay added to it's release. Since Ritual aren't usually affiliated with Valve (unlike gearbox who tend to work hand in hand with them) and the extended delay it would seem to make sense to make the enhancements now as the work has been done plus we wont be seeing CS:CZ for another 3 months now at the earliest. Any comments from you folks at Gearbox about this or does this come under the restrictions of your NDA so you can't speak about it with the public? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Engine enhacements been added in next HL patch?
Thnx for an informed opinion about that botman, although it's not the official word it sounds like there certainly alot of doubt as to the position Valve might take on this issue. I find it funny how you said they'd never risk something that would break any mods, especially as i remember some mod teams having to 'fix' themselves regularly after the spree of networking changes that followed 1.1.0.0, somehow i don't think that the model engine enhancements would break anything since it's adding to the rendering functions rather than starting from scratch. (of course I'm assuming that you guys didn't rip the guts out to make the enhancements) I'll cross my fingers and hope that we do have some promising news from Gabe or someone, if not then I'll see what I can get from Chris Bokitch since the lads at Valve don't appear check this mailing list regularly so they could miss this. Thnx again. - Original Message - From: botman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 03, 2003 2:53 PM Subject: Re: [hlcoders] Engine enhacements been added in next HL patch? One of my dev team somehow got word that the next HL patch might include some if not all of the engine enhancements from CS:CZ, mainly the added model capabilities like alpha maps. I've not heard any mention of this from the usual sources but it seems possible now that CS:CZ has been handed over to Ritual Entertainment and had an addtional delay added to it's release. Since Ritual aren't usually affiliated with Valve (unlike gearbox who tend to work hand in hand with them) and the extended delay it would seem to make sense to make the enhancements now as the work has been done plus we wont be seeing CS:CZ for another 3 months now at the earliest. Any comments from you folks at Gearbox about this or does this come under the restrictions of your NDA so you can't speak about it with the public? Even though I work at Gearbox, I'm not an official spokesman for them so don't take this as a Gearbox sanctioned reply. It's just my personal opinion, so take it for what it's worth (practically nothing). I'm not sure what Ritual has or has not done with the Half-Life engine in support of CZ, but there were changes made to the engine by Gearbox in support of the CZ work that they did (99% of which was before I went to work for Gearbox). Valve always had access to the work that Gearbox was doing, and I presume Valve always had access to the work that Rogue did before Gearbox picked up the project. Any changes made to the engine to support MODs or expansions (like OpFor, for example) would be available in future releases of the engine. I've never known Valve to remove a feature from the engine, only expand it to include new features, so backing out an existing feature probably won't happen unless that conflicts with something that Valve and/or Ritual REALLY wants to put in and there's no way to support both. In some cases, this would break any MODs that used that feature and Valve doesn't want to do that. Whether or not Valve and/or Ritual preserves engine changes made by Gearbox (or Rogue) will be completely up to Valve and Ritual, Gearbox doesn't really have any control over this as far as I know. Ritual may want to rip out many of the changes made by Gearbox and replace it with their own. Ritual might also want to preserve all of the changes made by Gearbox so that they can concentrate on game content and not worry too much about engine changes. Again, only Valve or Ritual can tell you what gets done in the end. My guess is that you won't know what changes have been made until the game is released. Usually the release notes contain a list of changes that tells you what features were added and what bugs were fixed. From this list of feature changes you can sometimes determine what types of engine changes were made (for example being able to render view models transparently). One thing that I find interesting is that Ritual is using QERadiant instead of Hammer. Perhaps Ritual's level designers (all hail Levelord!) are just more familiar with QERadiant and didn't want to have to learn a different interface, but I wonder if there were any missing features from QERadiant that had to be ported from Hammer to support CZ. Jeffrey botman Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Engine enhacements been added in next HL patch?
I'm not much of a programmer, I just handle the all management and various design aspects of the project I leave the programming to Laurie and James. :) Odds are that after i get done with this I'll spend a year learning C++ since that the last area for me to gain experience in. Odds are we'll have Hl2 to play around with then and knowing my bloody luck C++ is a redundent language by then. - Original Message - From: Mark Gornall [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 03, 2003 3:21 PM Subject: RE: [hlcoders] Engine enhacements been added in next HL patch? ...maybe if you asked a specific coding question they may be more inclined to answer ;) __ This mail has been scanned for all known viruses by UUNET delivered through the MessageLabs Virus Control Centre. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Engine enhacements been added in next HL patch?
I've used QEradient for HL editing and i have to say that it's a damn nightmare trying to set the damn thing u pto use WADs, but i simply couldn't settle with it once i got past the traumatic set up. I hate to sound like one of the brainwashed masses but WC/Hammer simply is perfect for Quake engine editing I've been using some form of WC since way back when it was first designed for the original Quake although it has come along in leaps and bounds since then. - Original Message - From: Nick McLaren [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 03, 2003 4:01 PM Subject: RE: [hlcoders] Engine enhacements been added in next HL patch? One thing that I find interesting is that Ritual is using QERadiant instead of Hammer. Perhaps Ritual's level designers (all hail Levelord!) are just more familiar with QERadiant and didn't want to have to learn a different interface, but I wonder if there were any missing features from QERadiant that had to be ported from Hammer to support CZ. Jeffrey botman Broome From what I understand, it IS a modified QERadiant, though I haven't been able to find out exactly what was changed/added yet. Granted none of this is set in stone yet, I'm told that this new modified QERadiant package will be distributed with CS:CZ for level creators to play with. That can only be good for all of us. =) - Nick McLaren, CCNA, SCSA Battle LAN Technical Admin [EMAIL PROTECTED] http://www.battlelan.com/ - ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] impact decal
The source uses a single set of decals for all bullet holes. I've been using a colour decal for my bullet holes for DT so it'll be available in the next build. It's part of one of the wads' but I can't remember exactly which one atm. Probably decals i think. Original Message - From: brian c.strider [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 02, 2002 4:46 PM Subject: [hlcoders] impact decal hello folks, I was curious if anyone knew where the impact decals for the mp5 were referenced? I have searched but haven't been able to find them. I am trying to a custom decal to replace the impact decal for the mp5. proubably fairly easy to find, but oh well, thanks Brian Striker2 Strider ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Config vars for improved graphics?
Correct me if I'm getting confused but surely HL uses as much memory as needed and considering the sort of spec machines around nowadays and the capabilities of gfx cards then having several Mb of texture memory for each npc isn't such an issue. Or does the HL engine have internal limitations that hold it back in regards to assigning memory usage? - Original Message - From: Pat Magnan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 17, 2002 8:36 PM Subject: Re: [hlcoders] Config vars for improved graphics? I believe the precise verbiage from the Modelling for Halflife document states that 'textures may be no more than 1024 pixels in any direction'. Textures most assuredly can be 512 x 512, no configuration value needed. They compile with studiomdl or they don't, it will tell you if it's 'too big'. There's no default, just a limit on what studiomdl allows. By the way, 1024 x 1024 textures are about a meg of texture memory, if you only have 3 models on screen at any one time, that's a reasonable amount of memory to consume. Otherwise, I think you're just wasting texture memory for nothing. We've sized down weapon textures in photoshop, and found very little difference between a 512 x 512 texture and a 256 x 256 one, if it's done correctly. Don't forget, they're being applied to objects that are only 200 pixels large on screen, if that. Or are you talking about map textures? I'd suggest: http://www.valve-erc.com/resources/?page=zhlt I haven't found anything there that deals specifically with increasing the dimensions, just the max texture memory. As I understand it, DOD pushed this a little too hard in one release, and then scaled back, limiting mappers after that experience. Halflife may be old, but modern gfx systems, while stunning compared to what we had in 98, are still lacking to throw away texture memory frivilously. I'd spend it where it matters, i.e. on your 'main' weapons, or frequently seen models, etc. If your artists can't work in those constraints, maybe they should consider another profession ;), tell them they should be happy not to be working with 4 bit palettes :) Maybe I'm confused, but I don't know what config file you are asking about either ;). Pat 'sluggo' Magnan Tour of Duty mod http://www.tourofdutymod.com At 01:49 AM 10/17/2002 -0400, you wrote: This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] I remember hearing somewhere that there were 2 or more config vars you could set to improve the graphics resolution of the HL engine over the default values. I think one had to do with raising Texture sizes from 256 to 512 or 1024, and there were one or two others. Can anyone tell me what the correct config file command line syntax would be to set those, and what those variable names were? If you have a good URL that explains that would be great. Thanks. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Config vars for improved graphics?
The difference is that while a multiplayer mod needs to load all of the models and all of the weapons, it has a higher memory useage. Luckily I'm working on a single player project so we have more direct control over what is precashed and what isn't. So if there's a way to all for 1024x1024 texture then please don't hold back, i doubt we'd use them much but it would nice to have that option available. - Original Message - From: Commando [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 17, 2002 8:24 PM Subject: Re: [hlcoders] Config vars for improved graphics? At 07:53 PM 17/10/2002 +0100, you wrote: Correct me if I'm getting confused but surely HL uses as much memory as needed and considering the sort of spec machines around nowadays and the capabilities of gfx cards then having several Mb of texture memory for each npc isn't such an issue. Or does the HL engine have internal limitations that hold it back in regards to assigning memory usage? I don't think that HL has internal limitations that hold back it's memory usage, but no matter how powerful todays machines are, memory will be exhausted at some point. Many computers today have 128-256 meg of memory and 32-64meg of memory on the graphics card. The memory on the graphics card is not just being used by the textures, it is also being used by the models and maps and for all that graphics processing that the card does. Using textures that are 1meg big can add up very quickly. How many textures are used in the average map? Don't forget player models, v_models, p_models w_models for every weapon, map models, monsters, sprites, decals, etc. That can quickly add up to 64 meg for textures alone. Whatever the gfx card cannot handle, gets put in main memory, but that is limited too. Depending on the map, our mod uses around 125meg of memory and we keep our textures as small as is reasonably possible. DoD, CS and even HL are similar. Add to that the memory being used by the OS and services running on your computer. Right now, I only have a few programs open (not HL) and I am using 307 meg (damn windows wastage ;) ) of which 227 is not cached. So, if you use too much memory, you get delays as memory is swapped between main memory and graphics memory, then if you use way too much, you start getting major lag when stuff starts swapping to your HD. Not to mention how long it will take your level to load if all of your textures are 1meg (1024x1024). Also, like sluggo said, most models display at about 200 pixels in-game, do detail above about 256 pixels is a bit of a waste. The renders that your modelers do and you post on your web site will look great, but the players in-game will not be able to tell the difference. So, you should still be budgeting everything in your mod and expending memory where it will make the most difference (ie the most used weapon, a common map texture) and saving wherever you can. Today's machines have more memory, but it is not unlimited. Rob Prouse (Commando) Tour of Duty Mod http://www.tourofdutymod.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Config vars for improved graphics?
I thought something like that would be engine side? - Original Message - From: Peter Immarco [EMAIL PROTECTED] To: HLCODERS [EMAIL PROTECTED] Sent: Thursday, October 17, 2002 6:49 AM Subject: [hlcoders] Config vars for improved graphics? This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] I remember hearing somewhere that there were 2 or more config vars you could set to improve the graphics resolution of the HL engine over the default values. I think one had to do with raising Texture sizes from 256 to 512 or 1024, and there were one or two others. Can anyone tell me what the correct config file command line syntax would be to set those, and what those variable names were? If you have a good URL that explains that would be great. Thanks. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] custom effects
As far as I'm aware the best solution would be create addtional bitfields rather than flags since HL has a limitation on how many flags can be used on an entity, however you can have many bitfields as you want. - Original Message - From: John Carr [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 19, 2002 8:48 PM Subject: [hlcoders] custom effects is there any way to get the client.dll to apply effects to entities according to what flags are set. what i want to do is something like the temp ent's flags like smoke trail etc but i wondered if it could be done to ordinary entities (eg player entity has a FL_AURA flag set so get particle sys to emit aura particles). the only way i can see to do it is to either create some custom system that hooks HUD_ProcessPlayerState and records all entites that have flags set and then processes them in the drawtriangle func or create a temp ent to follow objects that need these custom effects and reuse unneeded flags. would the first way even work? is there a better way? (without too many network messages?) ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Are their any full details on what CS:CZ is adding to the engine?
Yeah but surely something has to be altered in the code to apply the new things. From what Ive gathered so far they've made significant changes to what the models are capable of, now surely this would have some effect on the new SDK they said was going to be released. - Original Message - From: Michael Shimmins [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, June 15, 2002 10:05 AM Subject: Re: [hlcoders] Are their any full details on what CS:CZ is adding to the engine? The SDK is the two dlls, it doesn't have the engine with it. Although there are some engine files there for reference, thats all they're for, reference. Even if you do edit them, the changes wont be in game. Quite a simple question which only Gearbox and Valve can probably answer. I'm just curious as the new SDK which will 'eventually' be released will include these additions and I'd like to know in advance what to expect. Also is there a rough outline for the time when this new SDK with the engine additions will be released? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Are their any full details on what CS:CZ is adding to the engine?
Quite a simple question which only Gearbox and Valve can probably answer. I'm just curious as the new SDK which will 'eventually' be released will include these additions and I'd like to know in advance what to expect. Also is there a rough outline for the time when this new SDK with the engine additions will be released? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] triApi speed problems
Ahh now Bitmap said to me that we were going to be having this code donated on the basis that we don't share it. But if that's ok with you then I'm fine with it. - Original Message - From: Persuter [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 13, 2002 3:40 AM Subject: RE: [hlcoders] triApi speed problems Given that my particle engine is completely free for anyone to use, I invite pasting of the code. Persuter -Original Message- From: [EMAIL PROTECTED] [mailto:hlcoders- [EMAIL PROTECTED]] On Behalf Of Chris 'Tal-N' Blane Sent: Sunday, May 12, 2002 1:40 PM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] triApi speed problems Yeah i don't mind Rainmaker posting the explosion code since the particle engine is needed as well to make use of it so cut and pasters can't use it. - Original Message - From: Miguel Aleman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, May 12, 2002 1:48 AM Subject: Re: [hlcoders] triApi speed problems VSYNC puts a limit on overall frame rate, and it would not change in the presence of particle blending. Chris, do you mind posting the section of code you are using to render the particle to make sure you are doing it correctly. I can get thousands of particles on screen before a major slowdown. - Original Message - From: Chris 'Tal-N' Blane [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, May 11, 2002 7:33 PM Subject: Re: [hlcoders] triApi speed problems I'd love to tell ya it worked... but it's still the same problem. :( Anyone else got any ideas. ( it was on originally btw and tuning it off didn't help) And these are the most recent drivers from Nvidia [4.13.01.2832 version] - Original Message - From: Maximilian Marx [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, May 12, 2002 1:16 AM Subject: Re: [hlcoders] triApi speed problems when using detonator driver go to control panel - display - settings - advanced - geforce2 - advanced - opengl settings - vertical sync - always off - Original Message - From: Chris 'Tal-N' Blane [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, May 12, 2002 2:01 AM Subject: Re: [hlcoders] triApi speed problems Would this vsynch be a HL setting or something in device manager/display properties? - Original Message - From: botman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, May 12, 2002 12:53 AM Subject: Re: [hlcoders] triApi speed problems Read the other post for more details, why would this effect one system of a higher spec 1.1Ghz 512Mb Ram with the same gfx card but not a far slower one? Do you have VSYNC enabled on one video card (the fast one) and disabled on the other (the slow one)? Check the video adapter settings in the control panel to see if VSYNC is enabled or not. (P.S. most people will have VSYNC enabled since this is the default). Jeffrey botman Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Re: triApi speed problems
This is a multi-part message in MIME format. -- It's not an easily solvable problem otherwise we wouldn't have asked. Anyway until Rain posts the code the most i can do is attatch the testmod with the added particle explosion effects. Just load up any map ad use explosive weapons and use net_graph to take a note of the frame rate. This version currently uses 5 particles per explosion and the frame rate drop from 70 to 40 on my machine even now. Put more than 2 blasts near to each other for the most obvious effect though. Let's hope that attachments work on this list. This one is 752kb. - Original Message - From: Dynerman David M [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 13, 2002 4:48 PM Subject: RE: [hlcoders] Re: triApi speed problems Anyone else find it funny that on this coding mailing list this thread (with probably an easily solvable coding problem) has not posted source code in about 5 days of its existence? :D david -Original Message- From: Josh Coyne [mailto:[EMAIL PROTECTED]] Sent: Monday, May 13, 2002 10:23 AM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] Re: triApi speed problems D: nastey - Original Message - From: David Flor [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 13, 2002 11:09 AM Subject: RE: [hlcoders] Re: triApi speed problems Generally, if I remember correctly, under a standard Win2K installation, the applications take 2Gb and the system takes the rest. In Win2K ADVANCED SERVER, there's a way to get 3Gb for the app and 1Gb for the system. Using different APIs provided in Windows, it is possible to have an application use more than that, but it's not pretty... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of JR Sent: Monday, May 13, 2002 2:04 AM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] Re: triApi speed problems Maybe Windows takes up the other Gb? :) - Original Message - From: Tom [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, May 12, 2002 11:51 PM Subject: Re: [hlcoders] Re: triApi speed problems is it supost to use 3GB or are you just a sloppy programmer :) - Original Message - From: David Flor [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 13, 2002 6:13 AM Subject: RE: [hlcoders] Re: triApi speed problems Because he CAN! I have 1Gb on one machine, w/ 768Mb on my secondary. Trust me, it's real comforting to know that memory won't be an issue. And I have written heavily database intensive applications that use every bit of those 4Gb (well, 3Gb, if you want to get technical...). Tnx Rgds... David Flor Lead Programmer, The Opera - http://opera.redeemedsoft.com/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Roachfood - the-coming.com Sent: Sunday, May 12, 2002 11:25 PM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] Re: triApi speed problems what in God's name do you need 4 gig of ram for besides some sort of bragging rights? Geezus I have 512 and i never use more than 300. =) You win the ram contest... Roachie - Original Message - From: Kuja [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, May 12, 2002 7:23 PM Subject: RE: [hlcoders] Re: triApi speed problems Send it here also, I have a really awesome computer that should be able to handle anything Specs: 1.5ghz athlon tb, 4 gigs of ram, ATI Radeon 8500. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Chris Foss Sent: Sunday, May 12, 2002 8:12 PM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] Re: triApi speed problems From: Chris 'Tal-N' Blane [EMAIL PROTECTED] Ask Rain, i was only have old source before this was developed. I can send the testmod folder but i don't think that the list allows for attatchments no matter how small. Well, send it here, I'll test it on my box... specs: K6-2 350, voodoo3, 320mb ram I'll see if it's hardware dependant. E-Mail: [EMAIL PROTECTED] ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http
Re: [hlcoders] Re: triApi speed problems
Nope it didn't work. I'll upload to our FTP and make a link available here then. - Original Message - From: Chris 'Tal-N' Blane [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 13, 2002 7:16 PM Subject: Re: [hlcoders] Re: triApi speed problems This is a multi-part message in MIME format. -- It's not an easily solvable problem otherwise we wouldn't have asked. Anyway until Rain posts the code the most i can do is attatch the testmod with the added particle explosion effects. Just load up any map ad use explosive weapons and use net_graph to take a note of the frame rate. This version currently uses 5 particles per explosion and the frame rate drop from 70 to 40 on my machine even now. Put more than 2 blasts near to each other for the most obvious effect though. Let's hope that attachments work on this list. This one is 752kb. - Original Message - From: Dynerman David M [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 13, 2002 4:48 PM Subject: RE: [hlcoders] Re: triApi speed problems Anyone else find it funny that on this coding mailing list this thread (with probably an easily solvable coding problem) has not posted source code in about 5 days of its existence? :D david -Original Message- From: Josh Coyne [mailto:[EMAIL PROTECTED]] Sent: Monday, May 13, 2002 10:23 AM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] Re: triApi speed problems D: nastey - Original Message - From: David Flor [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 13, 2002 11:09 AM Subject: RE: [hlcoders] Re: triApi speed problems Generally, if I remember correctly, under a standard Win2K installation, the applications take 2Gb and the system takes the rest. In Win2K ADVANCED SERVER, there's a way to get 3Gb for the app and 1Gb for the system. Using different APIs provided in Windows, it is possible to have an application use more than that, but it's not pretty... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of JR Sent: Monday, May 13, 2002 2:04 AM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] Re: triApi speed problems Maybe Windows takes up the other Gb? :) - Original Message - From: Tom [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, May 12, 2002 11:51 PM Subject: Re: [hlcoders] Re: triApi speed problems is it supost to use 3GB or are you just a sloppy programmer :) - Original Message - From: David Flor [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 13, 2002 6:13 AM Subject: RE: [hlcoders] Re: triApi speed problems Because he CAN! I have 1Gb on one machine, w/ 768Mb on my secondary. Trust me, it's real comforting to know that memory won't be an issue. And I have written heavily database intensive applications that use every bit of those 4Gb (well, 3Gb, if you want to get technical...). Tnx Rgds... David Flor Lead Programmer, The Opera - http://opera.redeemedsoft.com/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Roachfood - the-coming.com Sent: Sunday, May 12, 2002 11:25 PM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] Re: triApi speed problems what in God's name do you need 4 gig of ram for besides some sort of bragging rights? Geezus I have 512 and i never use more than 300. =) You win the ram contest... Roachie - Original Message - From: Kuja [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, May 12, 2002 7:23 PM Subject: RE: [hlcoders] Re: triApi speed problems Send it here also, I have a really awesome computer that should be able to handle anything Specs: 1.5ghz athlon tb, 4 gigs of ram, ATI Radeon 8500. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Chris Foss Sent: Sunday, May 12, 2002 8:12 PM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] Re: triApi speed problems From: Chris 'Tal-N' Blane [EMAIL PROTECTED] Ask Rain, i was only have old source before this was developed. I can send the testmod folder but i don't think that the list allows for attatchments no matter how small. Well, send it here, I'll test it on my box... specs: K6-2 350, voodoo3, 320mb ram I'll see if it's hardware dependant. E-Mail: [EMAIL PROTECTED] ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com
Re: [hlcoders] Re: triApi speed problems
Yeah i realised, here's the URL to the file. www.c4software.net/dt/bug/TestMod.zip Let me know the details of the test on your system pleez. Oh and don't load up boot_camp becasue this version contains an early alpha of our inventory system so you won't be able to test on that map. - Original Message - From: Yacketta, Ronald [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 13, 2002 7:32 PM Subject: RE: [hlcoders] Re: triApi speed problems Sorry, but attachments of any size/format are rejected by the list. Post a URL link to it -Original Message- From: Chris 'Tal-N' Blane [mailto:[EMAIL PROTECTED]] Sent: Monday, May 13, 2002 14:17 To: [EMAIL PROTECTED] Subject: Re: [hlcoders] Re: triApi speed problems This is a multi-part message in MIME format. -- It's not an easily solvable problem otherwise we wouldn't have asked. Anyway until Rain posts the code the most i can do is attatch the testmod with the added particle explosion effects. Just load up any map ad use explosive weapons and use net_graph to take a note of the frame rate. This version currently uses 5 particles per explosion and the frame rate drop from 70 to 40 on my machine even now. Put more than 2 blasts near to each other for the most obvious effect though. Let's hope that attachments work on this list. This one is 752kb. - Original Message - From: Dynerman David M [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 13, 2002 4:48 PM Subject: RE: [hlcoders] Re: triApi speed problems Anyone else find it funny that on this coding mailing list this thread (with probably an easily solvable coding problem) has not posted source code in about 5 days of its existence? :D david -Original Message- From: Josh Coyne [mailto:[EMAIL PROTECTED]] Sent: Monday, May 13, 2002 10:23 AM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] Re: triApi speed problems D: nastey - Original Message - From: David Flor [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 13, 2002 11:09 AM Subject: RE: [hlcoders] Re: triApi speed problems Generally, if I remember correctly, under a standard Win2K installation, the applications take 2Gb and the system takes the rest. In Win2K ADVANCED SERVER, there's a way to get 3Gb for the app and 1Gb for the system. Using different APIs provided in Windows, it is possible to have an application use more than that, but it's not pretty... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of JR Sent: Monday, May 13, 2002 2:04 AM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] Re: triApi speed problems Maybe Windows takes up the other Gb? :) - Original Message - From: Tom [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, May 12, 2002 11:51 PM Subject: Re: [hlcoders] Re: triApi speed problems is it supost to use 3GB or are you just a sloppy programmer :) - Original Message - From: David Flor [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 13, 2002 6:13 AM Subject: RE: [hlcoders] Re: triApi speed problems Because he CAN! I have 1Gb on one machine, w/ 768Mb on my secondary. Trust me, it's real comforting to know that memory won't be an issue. And I have written heavily database intensive applications that use every bit of those 4Gb (well, 3Gb, if you want to get technical...). Tnx Rgds... David Flor Lead Programmer, The Opera - http://opera.redeemedsoft.com/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Roachfood - the-coming.com Sent: Sunday, May 12, 2002 11:25 PM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] Re: triApi speed problems what in God's name do you need 4 gig of ram for besides some sort of bragging rights? Geezus I have 512 and i never use more than 300. =) You win the ram contest... Roachie - Original Message - From: Kuja [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, May 12, 2002 7:23 PM Subject: RE: [hlcoders] Re: triApi speed problems Send it here also, I have a really awesome computer that should be able to handle anything Specs: 1.5ghz athlon tb, 4 gigs of ram, ATI Radeon 8500. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Chris Foss Sent: Sunday, May 12, 2002 8:12 PM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] Re: triApi speed problems
Re: [hlcoders] Re: triApi speed problems
Ahhi didnt' think that the explosion.mdl was still needed casue it was from an old way we attempted. I'll reupload it with that back in then. And no it isn't netgraph casusing it because it frame rate still drops the same with the r-speeds and developer 1 set up. - Original Message - From: Kuja [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 13, 2002 7:53 PM Subject: RE: [hlcoders] Re: triApi speed problems Error: ModNumForNames Model explosion.mdl not found. Also, you mentioned that you used net_graph to check on your fps? if you have a slower computer net_graph on anything but 3 will slow you down tremendously. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Chris 'Tal-N' Blane Sent: Monday, May 13, 2002 2:42 PM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] Re: triApi speed problems Yeah i realised, here's the URL to the file. www.c4software.net/dt/bug/TestMod.zip Let me know the details of the test on your system pleez. Oh and don't load up boot_camp becasue this version contains an early alpha of our inventory system so you won't be able to test on that map. - Original Message - From: Yacketta, Ronald [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 13, 2002 7:32 PM Subject: RE: [hlcoders] Re: triApi speed problems Sorry, but attachments of any size/format are rejected by the list. Post a URL link to it -Original Message- From: Chris 'Tal-N' Blane [mailto:[EMAIL PROTECTED]] Sent: Monday, May 13, 2002 14:17 To: [EMAIL PROTECTED] Subject: Re: [hlcoders] Re: triApi speed problems This is a multi-part message in MIME format. -- It's not an easily solvable problem otherwise we wouldn't have asked. Anyway until Rain posts the code the most i can do is attatch the testmod with the added particle explosion effects. Just load up any map ad use explosive weapons and use net_graph to take a note of the frame rate. This version currently uses 5 particles per explosion and the frame rate drop from 70 to 40 on my machine even now. Put more than 2 blasts near to each other for the most obvious effect though. Let's hope that attachments work on this list. This one is 752kb. - Original Message - From: Dynerman David M [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 13, 2002 4:48 PM Subject: RE: [hlcoders] Re: triApi speed problems Anyone else find it funny that on this coding mailing list this thread (with probably an easily solvable coding problem) has not posted source code in about 5 days of its existence? :D david -Original Message- From: Josh Coyne [mailto:[EMAIL PROTECTED]] Sent: Monday, May 13, 2002 10:23 AM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] Re: triApi speed problems D: nastey - Original Message - From: David Flor [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 13, 2002 11:09 AM Subject: RE: [hlcoders] Re: triApi speed problems Generally, if I remember correctly, under a standard Win2K installation, the applications take 2Gb and the system takes the rest. In Win2K ADVANCED SERVER, there's a way to get 3Gb for the app and 1Gb for the system. Using different APIs provided in Windows, it is possible to have an application use more than that, but it's not pretty... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of JR Sent: Monday, May 13, 2002 2:04 AM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] Re: triApi speed problems Maybe Windows takes up the other Gb? :) - Original Message - From: Tom [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, May 12, 2002 11:51 PM Subject: Re: [hlcoders] Re: triApi speed problems is it supost to use 3GB or are you just a sloppy programmer :) - Original Message - From: David Flor [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 13, 2002 6:13 AM Subject: RE: [hlcoders] Re: triApi speed problems Because he CAN! I have 1Gb on one machine, w/ 768Mb on my secondary. Trust me, it's real comforting to know that memory won't be an issue. And I have written heavily database intensive applications that use every bit of those 4Gb (well, 3Gb, if you want to get technical...). Tnx Rgds... David Flor Lead Programmer, The Opera - http://opera.redeemedsoft.com/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Roachfood - the-coming.com Sent: Sunday, May 12, 2002 11:25 PM To: [EMAIL
Re: [hlcoders] Re: triApi speed problems
I think that's the problems since the scale of the sprites were always large. - Original Message - From: Tom [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 13, 2002 9:07 PM Subject: Re: [hlcoders] Re: triApi speed problems On my system 1.2ghz Tbird, 256meg ram, GF2 gts the fps drops from 71 to 37 when it explodes, _but_ most of the time the explosion isnt on screen for long enough to even see it! I think the problem is that you are streching the sprites 2 much and because of this your getting large areas of alpha blending which means that alot of calcuations must be done to get the right colour behind the sprites. - Original Message - From: Chris 'Tal-N' Blane [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 13, 2002 8:11 PM Subject: Re: [hlcoders] Re: triApi speed problems Ahhi didnt' think that the explosion.mdl was still needed casue it was from an old way we attempted. I'll reupload it with that back in then. And no it isn't netgraph casusing it because it frame rate still drops the same with the r-speeds and developer 1 set up. - Original Message - From: Kuja [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 13, 2002 7:53 PM Subject: RE: [hlcoders] Re: triApi speed problems Error: ModNumForNames Model explosion.mdl not found. Also, you mentioned that you used net_graph to check on your fps? if you have a slower computer net_graph on anything but 3 will slow you down tremendously. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Chris 'Tal-N' Blane Sent: Monday, May 13, 2002 2:42 PM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] Re: triApi speed problems Yeah i realised, here's the URL to the file. www.c4software.net/dt/bug/TestMod.zip Let me know the details of the test on your system pleez. Oh and don't load up boot_camp becasue this version contains an early alpha of our inventory system so you won't be able to test on that map. - Original Message - From: Yacketta, Ronald [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 13, 2002 7:32 PM Subject: RE: [hlcoders] Re: triApi speed problems Sorry, but attachments of any size/format are rejected by the list. Post a URL link to it -Original Message- From: Chris 'Tal-N' Blane [mailto:[EMAIL PROTECTED]] Sent: Monday, May 13, 2002 14:17 To: [EMAIL PROTECTED] Subject: Re: [hlcoders] Re: triApi speed problems This is a multi-part message in MIME format. -- It's not an easily solvable problem otherwise we wouldn't have asked. Anyway until Rain posts the code the most i can do is attatch the testmod with the added particle explosion effects. Just load up any map ad use explosive weapons and use net_graph to take a note of the frame rate. This version currently uses 5 particles per explosion and the frame rate drop from 70 to 40 on my machine even now. Put more than 2 blasts near to each other for the most obvious effect though. Let's hope that attachments work on this list. This one is 752kb. - Original Message - From: Dynerman David M [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 13, 2002 4:48 PM Subject: RE: [hlcoders] Re: triApi speed problems Anyone else find it funny that on this coding mailing list this thread (with probably an easily solvable coding problem) has not posted source code in about 5 days of its existence? :D david -Original Message- From: Josh Coyne [mailto:[EMAIL PROTECTED]] Sent: Monday, May 13, 2002 10:23 AM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] Re: triApi speed problems D: nastey - Original Message - From: David Flor [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 13, 2002 11:09 AM Subject: RE: [hlcoders] Re: triApi speed problems Generally, if I remember correctly, under a standard Win2K installation, the applications take 2Gb and the system takes the rest. In Win2K ADVANCED SERVER, there's a way to get 3Gb for the app and 1Gb for the system. Using different APIs provided in Windows, it is possible to have an application use more than that, but it's not pretty... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of JR Sent: Monday, May 13, 2002 2:04 AM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] Re: triApi speed problems Maybe Windows takes up the other Gb? :) - Original Message - From: Tom [EMAIL PROTECTED
Re: [hlcoders] Re: triApi speed problems
I suggest a cvar anyway since we'd like DarkTruths' graphical features to be customizable to the player spec. - Original Message - From: Kuja [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 13, 2002 10:29 PM Subject: RE: [hlcoders] Re: triApi speed problems I really beg to differ. My test results show something more sinister hardware side. Could you have your coder come up with a cvar so I can test different numbers of particles? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Chris 'Tal-N' Blane Sent: Monday, May 13, 2002 5:21 PM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] Re: triApi speed problems I think that's the problems since the scale of the sprites were always large. - Original Message - From: Tom [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 13, 2002 9:07 PM Subject: Re: [hlcoders] Re: triApi speed problems On my system 1.2ghz Tbird, 256meg ram, GF2 gts the fps drops from 71 to 37 when it explodes, _but_ most of the time the explosion isnt on screen for long enough to even see it! I think the problem is that you are streching the sprites 2 much and because of this your getting large areas of alpha blending which means that alot of calcuations must be done to get the right colour behind the sprites. - Original Message - From: Chris 'Tal-N' Blane [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 13, 2002 8:11 PM Subject: Re: [hlcoders] Re: triApi speed problems Ahhi didnt' think that the explosion.mdl was still needed casue it was from an old way we attempted. I'll reupload it with that back in then. And no it isn't netgraph casusing it because it frame rate still drops the same with the r-speeds and developer 1 set up. - Original Message - From: Kuja [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 13, 2002 7:53 PM Subject: RE: [hlcoders] Re: triApi speed problems Error: ModNumForNames Model explosion.mdl not found. Also, you mentioned that you used net_graph to check on your fps? if you have a slower computer net_graph on anything but 3 will slow you down tremendously. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Chris 'Tal-N' Blane Sent: Monday, May 13, 2002 2:42 PM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] Re: triApi speed problems Yeah i realised, here's the URL to the file. www.c4software.net/dt/bug/TestMod.zip Let me know the details of the test on your system pleez. Oh and don't load up boot_camp becasue this version contains an early alpha of our inventory system so you won't be able to test on that map. - Original Message - From: Yacketta, Ronald [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 13, 2002 7:32 PM Subject: RE: [hlcoders] Re: triApi speed problems Sorry, but attachments of any size/format are rejected by the list. Post a URL link to it -Original Message- From: Chris 'Tal-N' Blane [mailto:[EMAIL PROTECTED]] Sent: Monday, May 13, 2002 14:17 To: [EMAIL PROTECTED] Subject: Re: [hlcoders] Re: triApi speed problems This is a multi-part message in MIME format. -- It's not an easily solvable problem otherwise we wouldn't have asked. Anyway until Rain posts the code the most i can do is attatch the testmod with the added particle explosion effects. Just load up any map ad use explosive weapons and use net_graph to take a note of the frame rate. This version currently uses 5 particles per explosion and the frame rate drop from 70 to 40 on my machine even now. Put more than 2 blasts near to each other for the most obvious effect though. Let's hope that attachments work on this list. This one is 752kb. - Original Message - From: Dynerman David M [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 13, 2002 4:48 PM Subject: RE: [hlcoders] Re: triApi speed problems Anyone else find it funny that on this coding mailing list this thread (with probably an easily solvable coding problem) has not posted source code in about 5 days of its existence? :D david -Original Message- From: Josh Coyne [mailto:[EMAIL PROTECTED]] Sent: Monday, May 13, 2002 10:23 AM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] Re: triApi speed problems D: nastey - Original Message - From: David Flor [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 13, 2002 11:09 AM Subject: RE: [hlcoders] Re: triApi speed problems
Re: [hlcoders] Re: triApi speed problems
We'd like to get it working smoothly before work on it's apprerence, the final plan is to also create debris of the same type as the materials around it similar to how material sounds are made. - Original Message - From: Chris Foss [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 13, 2002 10:59 PM Subject: Re: [hlcoders] Re: triApi speed problems Well, the results are in, that's a purdy explosion, you got there. AMD K6-2 350,320mb ram, Voodoo3 3000 Crossfire: 800x600: 13-15 FPS in the open. framerate drop not noticible. your explosion needs to be taller, though. it'd be a cool effect for a heavier than air gas cloud... - Original Message - From: Chris 'Tal-N' Blane [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 13, 2002 2:21 PM Subject: Re: [hlcoders] Re: triApi speed problems I think that's the problems since the scale of the sprites were always large. - Original Message - From: Tom [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 13, 2002 9:07 PM Subject: Re: [hlcoders] Re: triApi speed problems On my system 1.2ghz Tbird, 256meg ram, GF2 gts the fps drops from 71 to 37 when it explodes, _but_ most of the time the explosion isnt on screen for long enough to even see it! I think the problem is that you are streching the sprites 2 much and because of this your getting large areas of alpha blending which means that alot of calcuations must be done to get the right colour behind the sprites. - Original Message - From: Chris 'Tal-N' Blane [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 13, 2002 8:11 PM Subject: Re: [hlcoders] Re: triApi speed problems Ahhi didnt' think that the explosion.mdl was still needed casue it was from an old way we attempted. I'll reupload it with that back in then. And no it isn't netgraph casusing it because it frame rate still drops the same with the r-speeds and developer 1 set up. - Original Message - From: Kuja [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 13, 2002 7:53 PM Subject: RE: [hlcoders] Re: triApi speed problems Error: ModNumForNames Model explosion.mdl not found. Also, you mentioned that you used net_graph to check on your fps? if you have a slower computer net_graph on anything but 3 will slow you down tremendously. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Chris 'Tal-N' Blane Sent: Monday, May 13, 2002 2:42 PM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] Re: triApi speed problems Yeah i realised, here's the URL to the file. www.c4software.net/dt/bug/TestMod.zip Let me know the details of the test on your system pleez. Oh and don't load up boot_camp becasue this version contains an early alpha of our inventory system so you won't be able to test on that map. - Original Message - From: Yacketta, Ronald [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 13, 2002 7:32 PM Subject: RE: [hlcoders] Re: triApi speed problems Sorry, but attachments of any size/format are rejected by the list. Post a URL link to it -Original Message- From: Chris 'Tal-N' Blane [mailto:[EMAIL PROTECTED]] Sent: Monday, May 13, 2002 14:17 To: [EMAIL PROTECTED] Subject: Re: [hlcoders] Re: triApi speed problems This is a multi-part message in MIME format. -- It's not an easily solvable problem otherwise we wouldn't have asked. Anyway until Rain posts the code the most i can do is attatch the testmod with the added particle explosion effects. Just load up any map ad use explosive weapons and use net_graph to take a note of the frame rate. This version currently uses 5 particles per explosion and the frame rate drop from 70 to 40 on my machine even now. Put more than 2 blasts near to each other for the most obvious effect though. Let's hope that attachments work on this list. This one is 752kb. - Original Message - From: Dynerman David M [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 13, 2002 4:48 PM Subject: RE: [hlcoders] Re: triApi speed problems Anyone else find it funny that on this coding mailing list this thread (with probably an easily solvable coding problem) has not posted source code in about 5 days of its existence? :D david -Original Message- From: Josh Coyne [mailto:[EMAIL PROTECTED]] Sent: Monday, May 13, 2002 10:23 AM To: [EMAIL PROTECTED] Subject
Re: [hlcoders] No TriAPI fog in D3D?!
Hhehe if you've seen recent discussions I'd say that the GF card might have a few things to answer for. :) - Original Message - From: Reedbeta [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, May 14, 2002 4:44 AM Subject: Re: [hlcoders] No TriAPI fog in D3D?! Hmm, dunno about glide but I don't think D3D is dead quite yet :-) OGL is much better from a programming perspective IMHO, much easier to use, and you get free cross-platform compatibility as well...plus the wonderful GeForce series of chipsets are made to work with it :-) --- Chris 'Tal-N' Blane [EMAIL PROTECTED] wrote: As i understand it the fog needed to be called directly from OpenGL function to avoid the errors created with sprites and entities using the additive render mode. I'd suggest getting a decent gfx card casue D3D and Glide and offically dead. - Original Message - From: Mazor [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, May 14, 2002 3:54 AM Subject: [hlcoders] No TriAPI fog in D3D?! This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] I noticed they fixed the fog effect in HL1109, but it no longer works in D3D is there a workaround for this, or is it perminantly like that? -Mazor ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders __ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] triApi speed problems
Yeah i don't mind Rainmaker posting the explosion code since the particle engine is needed as well to make use of it so cut and pasters can't use it. - Original Message - From: Miguel Aleman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, May 12, 2002 1:48 AM Subject: Re: [hlcoders] triApi speed problems VSYNC puts a limit on overall frame rate, and it would not change in the presence of particle blending. Chris, do you mind posting the section of code you are using to render the particle to make sure you are doing it correctly. I can get thousands of particles on screen before a major slowdown. - Original Message - From: Chris 'Tal-N' Blane [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, May 11, 2002 7:33 PM Subject: Re: [hlcoders] triApi speed problems I'd love to tell ya it worked... but it's still the same problem. :( Anyone else got any ideas. ( it was on originally btw and tuning it off didn't help) And these are the most recent drivers from Nvidia [4.13.01.2832 version] - Original Message - From: Maximilian Marx [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, May 12, 2002 1:16 AM Subject: Re: [hlcoders] triApi speed problems when using detonator driver go to control panel - display - settings - advanced - geforce2 - advanced - opengl settings - vertical sync - always off - Original Message - From: Chris 'Tal-N' Blane [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, May 12, 2002 2:01 AM Subject: Re: [hlcoders] triApi speed problems Would this vsynch be a HL setting or something in device manager/display properties? - Original Message - From: botman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, May 12, 2002 12:53 AM Subject: Re: [hlcoders] triApi speed problems Read the other post for more details, why would this effect one system of a higher spec 1.1Ghz 512Mb Ram with the same gfx card but not a far slower one? Do you have VSYNC enabled on one video card (the fast one) and disabled on the other (the slow one)? Check the video adapter settings in the control panel to see if VSYNC is enabled or not. (P.S. most people will have VSYNC enabled since this is the default). Jeffrey botman Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] triApi speed problems
The problem is that by system copes fine even when dozens of decals overlap. I am already aware of that issue however thnx. - Original Message - From: Matthew Lewis [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, May 12, 2002 6:13 PM Subject: [hlcoders] triApi speed problems It's not just the triAPI that slows down. Decals will also bring the engine to a crawl. Try this: Walk up to a wall and fire a weapon that leaves a scorch mark decal. Make a few scorch marks (3 to 5) that overlap and fill much of the screen. The frate rate will plummet to single digits. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] (no subject)
Que: Enevitable 'What's an entity' question. :) - Original Message - From: Oskar 'Zoot' Lindgren [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, May 12, 2002 7:59 PM Subject: Re: [hlcoders] (no subject) make a entity.. - Original Message - From: Brandon Robertson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, May 12, 2002 8:56 PM Subject: [hlcoders] (no subject) Where is the code for placing player models in my game? I already have the models made, i just wanna know how to get them in my mod. _ Join the world's largest e-mail service with MSN Hotmail. http://www.hotmail.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Re: triApi speed problems
Ask Rain, i was only have old source before this was developed. I can send the testmod folder but i don't think that the list allows for attatchments no matter how small. - Original Message - From: Tom [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, May 12, 2002 10:01 PM Subject: Re: [hlcoders] Re: triApi speed problems whats the exact code you use to draw them? - Original Message - From: Chris 'Tal-N' Blane [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, May 12, 2002 8:33 PM Subject: Re: [hlcoders] Re: triApi speed problems 5 sprites? hardly pushing any gfx card very hard. - Original Message - From: Tom [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, May 12, 2002 8:00 PM Subject: Re: [hlcoders] Re: triApi speed problems triapi is nothing more than an opengl/d3d wrapper, all the calls you make just get sent to the renderer. Its not triapi which is slowing down, its you trying to draw too many sprites. - Original Message - From: Chris 'Tal-N' Blane [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, May 12, 2002 7:45 PM Subject: Re: [hlcoders] Re: triApi speed problems Rainmaker's system = 700mhz, ge3, 384 ram Tal-N's system = 1.1Ghz, Gf2, 512Mb Bitmap's system = 400MHz, Gf2, 128Mb. Slow down occours worse on my system although the drop is to the same point as Bimtap's machine. Two different machines hitting the exact same low fps, very odd. I'd say that Ken Birdwell might be able to give some details on the TriAPI since he was one of the people who designed it. - Original Message - From: Frazee [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, May 12, 2002 6:32 PM Subject: [hlcoders] Re: triApi speed problems This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] Ok, I did try the triangles (triangles, not triangle fan or the like) and it did have quite an increase on my system (700mhz, ge3, 384 ram), so that it never ever drops below 30 no matter what I do. It is probably my gfx card. I am sure it isn't my client-server messaging, it is pretty efficient (though I probably will want to avoid that later if it is possible to do like client side weapons, which I am sure it is). I checked all of the looping, to make sure it wasn't doing anything unnecessary. As far as I can see, it is efficient. At any rate, since my slower system with a ge3 runs it faster, it makes me think it is the tri api rather than my code. So you valve peeps. got any hints on how to squeeze more juice outa this thing? -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] triApi speed problems
Just a comment from me. I'm the prioject leader, this is the particle system kindly donated to us by friends in Hostile Intent. Just the engine mind you, not the implementation. The effect ISN'T consistant. On a PIII 350 with GF2 MX it runs fine, yet on some other systems ( mine in particular) which is a higher spec and the same gfx card and drivers the frame frate drops by about 50fps when a single one of these explosions occours. At first it use to occour even when the blast couldn't be seen but we've gotten around then so that while there's a slight drop it hardly noticeable. This suggested to us that it' wasn't graphics related since the effect wasn't on screen and wasn't even in the same leaf or the rendering pipeline. But the point is that we need to know if it's a duff particle engine which isn't properly handling the effect when blending occours or if the functions are being called quite right. Any hints or suggests are most welcome not matter how small, we've done as much as we're aware of to avoid this serious frame rate issue. - Original Message - From: Frazee [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, May 12, 2002 12:00 AM Subject: [hlcoders] triApi speed problems This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] I have a particle system for my mod, which is really quite nice. Problem is, as soon as multiple particles start blending it slows down. For instance, with explosions I have cut it down to 5 particles (yeah, 10 polys). But that is still slow on some systems. Not to mention when you combine explosions. I have optimized it all I can, and decided to come to you guys. One thing I didn't try is 2 triangles rather than the quad. if that will help I will try. Can you just tell me how to get the most juice out of this thing? Thanks. -- ___ To unsubscribe, edit your list preferences, or view the list archives, ple ase visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] triApi speed problems
Well, that idea of moving away from Quads appears to have sped things up but I haven't noticed a marked improvment ( hopefully he sent the right updated) client file). All i can tell you is that I cap my frame rate at 70fps and it used to drop to 20fps ( exactly ) with a 50particle explosion. Now with the blast cut to 5 particles the drop is from 70 to 40fps. Which is still significant. BUT one of our other test machines reported the same drop to exactly 20fps even though is was a PII 450 with 256Mb and 32Mb card (unknown brand). So it's odd how it stops at 20fps on both machines. But the effect is more noticable when the particles blend/overlap, almost as if the transpareceny rendering is what is slowing it down. 4 sachel charges using sprites down't casue any issues normally for me. But then using 3d explosions with the current standing of 5 particles each the frame ratedrop to 20fps for a brief period. But if you spread the packs out and detonate and the blast effects don't intersect then the drop in frame rate is as if only one was blown up. If you need any more details feel fre to ask. I'll remember to add you name to our credits' thnx list when this is released next year - even if it doesn't help. - Original Message - From: Miguel Aleman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, May 12, 2002 12:38 AM Subject: Re: [hlcoders] triApi speed problems How about some more information about the frame rates of the slower system. Does it run over 50fps with the particles on screen? - Original Message - From: Chris 'Tal-N' Blane [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, May 11, 2002 6:11 PM Subject: Re: [hlcoders] triApi speed problems Read the other post for more details, why would this effect one system of a higher spec 1.1Ghz 512Mb Ram with the same gfx card but not a far slower one? - Original Message - From: Miguel Aleman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, May 12, 2002 12:11 AM Subject: Re: [hlcoders] triApi speed problems On some videocards, Quads are extremely slow due to the way they are calculated. Use triangle strips instead of quads when possible (like in a particle engine). - Original Message - From: Chris 'Tal-N' Blane [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, May 11, 2002 6:03 PM Subject: Re: [hlcoders] triApi speed problems Just a comment from me. I'm the prioject leader, this is the particle system kindly donated to us by friends in Hostile Intent. Just the engine mind you, not the implementation. The effect ISN'T consistant. On a PIII 350 with GF2 MX it runs fine, yet on some other systems ( mine in particular) which is a higher spec and the same gfx card and drivers the frame frate drops by about 50fps when a single one of these explosions occours. At first it use to occour even when the blast couldn't be seen but we've gotten around then so that while there's a slight drop it hardly noticeable. This suggested to us that it' wasn't graphics related since the effect wasn't on screen and wasn't even in the same leaf or the rendering pipeline. But the point is that we need to know if it's a duff particle engine which isn't properly handling the effect when blending occours or if the functions are being called quite right. Any hints or suggests are most welcome not matter how small, we've done as much as we're aware of to avoid this serious frame rate issue. - Original Message - From: Frazee [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, May 12, 2002 12:00 AM Subject: [hlcoders] triApi speed problems This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] I have a particle system for my mod, which is really quite nice. Problem is, as soon as multiple particles start blending it slows down. For instance, with explosions I have cut it down to 5 particles (yeah, 10 polys). But that is still slow on some systems. Not to mention when you combine explosions. I have optimized it all I can, and decided to come to you guys. One thing I didn't try is 2 triangles rather than the quad. if that will help I will try. Can you just tell me how to get the most juice out of this thing? Thanks. -- ___ To unsubscribe, edit your list preferences, or view the list archives, ple ase visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] triApi speed problems
Would this vsynch be a HL setting or something in device manager/display properties? - Original Message - From: botman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, May 12, 2002 12:53 AM Subject: Re: [hlcoders] triApi speed problems Read the other post for more details, why would this effect one system of a higher spec 1.1Ghz 512Mb Ram with the same gfx card but not a far slower one? Do you have VSYNC enabled on one video card (the fast one) and disabled on the other (the slow one)? Check the video adapter settings in the control panel to see if VSYNC is enabled or not. (P.S. most people will have VSYNC enabled since this is the default). Jeffrey botman Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] triApi speed problems
I'd love to tell ya it worked... but it's still the same problem. :( Anyone else got any ideas. ( it was on originally btw and tuning it off didn't help) And these are the most recent drivers from Nvidia [4.13.01.2832 version] - Original Message - From: Maximilian Marx [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, May 12, 2002 1:16 AM Subject: Re: [hlcoders] triApi speed problems when using detonator driver go to control panel - display - settings - advanced - geforce2 - advanced - opengl settings - vertical sync - always off - Original Message - From: Chris 'Tal-N' Blane [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, May 12, 2002 2:01 AM Subject: Re: [hlcoders] triApi speed problems Would this vsynch be a HL setting or something in device manager/display properties? - Original Message - From: botman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, May 12, 2002 12:53 AM Subject: Re: [hlcoders] triApi speed problems Read the other post for more details, why would this effect one system of a higher spec 1.1Ghz 512Mb Ram with the same gfx card but not a far slower one? Do you have VSYNC enabled on one video card (the fast one) and disabled on the other (the slow one)? Check the video adapter settings in the control panel to see if VSYNC is enabled or not. (P.S. most people will have VSYNC enabled since this is the default). Jeffrey botman Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] [OT] question to valve, curious
I did hear along time ago (probably a year after HL's release) that HL was supposed to start totally different with you actually making your way onto the train at the beginning (which is obviously where the released HL picked up), i remember hearing that these maps still existed. I would like to see those out of sheer curiosity. Chris 'Tal-N' Blane [C4 Software CEO] www.c4software.net - Original Message - From: [DRP]Avatar-X To: [EMAIL PROTECTED] Sent: Tuesday, December 04, 2001 2:07 PM Subject: Re: [hlcoders] [OT] question to valve, curious Yeah, and it's several years later now, and the SDK has gone from a sign-up-and-have-it-mailed CD to a anyone-can-download package. Maybe Valve will change their minds, I'd love to see the old maps in use somewhere. -av Biggs wrote: I asked this question years ago right after HL was released. The whole reason i wanted HL was because of most of what i saw in the demos that never made it in the game. I asked if they would concider releasing the old maps, monsters and other various stuff as kinda like an SDK addon. The answer i got was no.~Biggs - Original Message - From: Andrew Foss To: [EMAIL PROTECTED] Sent: Tuesday, December 04, 2001 12:59 AM Subject: [hlcoders] [OT] question to valve, curiousI was digging around in my old CD's box, when I came upon a diamond viper driver disc. it contained a Half-life trailer.upon watching it, I noticed some cool bits. almost all the monsters in the demo are not seen in the game. (the models still exist) there are also a bunch of maps that didn't make the cut. Datacore is an example, it was originally a singleplayer map.My question is this:Since HL is actually HL2, because a lot of code, maps, textures, and models were cut/not in the final game, do you still have any of the old stuff laying around, and B: would you consider releasing any of it? I would love to see the original maps, because they look pretty cool. also, does the smelling gibs code work? can the mosters smell out the stinky bodies? :)--cannibal -- - [DRP]Avatar-X SillyZone Homepage: www.thesillyzone.com SillyZone Forums: forum.thesillyzone.com My Homepage: www.cyberwyre.com
