Re: [hlcoders] Client side radar question
extern vec3_t v_origin, v_angles; These are declared in view.cpp, and are updated every frame prior to rendering. -randomnine- I have completed a clientside vgui radar which works with player coordinates entirely found in the client code. However, this works fine and all, but the coordinates including the angles of even the client only gets updated as many as 10 times a second. So what happens is it looks like the radar is running about 10fps and its really choppy especially if you turn around really fast. So I was thinking about doing some kind of prediction where I delay the update a whole 10th of a second, just enough so I know the next angle of the client and I do some kind of interpolation in-between updates bases off the real time between real frames and the angle between the first and the second. in other words I fake the missing in between frames. I could do this, but it would be a lot of work for something that's already done. Is there any other way to get the client viewangle ACCURATELY every frame? Right now I use base_player-angles[1]; where base_player is real client cl_entity_t *base_player = gEngfuncs.GetEntityByIndex( m_nEntIndexOrigin ); I use that angle as a subtraction to the raw_angle I find using the acos between both origins of the client and the current target. Anyway, it just seems like the angle only gets updates 10 times a second (roughly). My radar is running every frame. So should I proceed with prediction, or should I find another variable or view angle which is more accurate? -- ___ 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] PNG format
Message-ID: [EMAIL PROTECTED] Priority: NORMAL X-Mailer: Execmail for Win32 Version 5.0.1 Build (55) MIME-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Return-Path: [EMAIL PROTECTED] X-OriginalArrivalTime: 25 Oct 2003 03:56:31.0605 (UTC) FILETIME=[F9B61250:01C39AAB] JPG support? That's great. But what about the lossless PNG format? It supports full color with alpha channel, too and can be extremly small! Let me guess, there is no free decoder available? libpng (http://www.libpng.org/pub/png/) it is, after all, a standard developed with no patent protection or anything of the like in mind. GIF anyone? yeah, that's why. the PNG format can also be loaded by zlib and libmng, and source code is available if you want to write your own decoder. -randomnine- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] i needed to post this; opinions please;)
Also my loading does MipMap as well for the sake of speed over distances. this fella says it best: The two main problems with texture mapping are the following: - if a texel covers many pixels, you get a patchwork quilt of the texture. - if a pixel covers many texels, you get ugly flashing artifacts. (http://xarch.tu-graz.ac.at/home/rurban/news/comp.graphics.algorithms/gfx/gfx1.html#mip) mipmapping is far more important for preventing texture aliasing than for reducing render times on distant objects. still very impressed that you're conning the HL engine into doing what you want without any waste. respect :) -randomnine- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Stupid ?'s
I'm sure someone will find something. You can't just dump HTML parsing in the MOTD VGUI routines and expect it to be bug free. when was the last time you saw a pure HTML exploit in a modern browser? HTML is a data format, not a programming language. About the worst you could do is crash the browser (eg. the game), and even exploits of that level are rare. But why bother? Then you're keeping up an HL server no-one can join. -randomnine- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] (no subject)
On Thu, 17 Jul 2003 20:53:23 -0700 Chris Foss [EMAIL PROTECTED] wrote: I agree, but perhaps it's better off in CHud::VidInit... - Original Message - From: @lph@ Bet@ [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, July 17, 2003 7:30 PM Subject: [hlcoders] (no subject) _ MSN Search, le moteur de recherche qui pense comme vous ! http://search.msn.fr ___ 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 - wod ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: Script languages (was Re: [hlcoders] Half-Life 2: Programming, Hmm?)
Anyway, that's all for the sake of chatting. Now we know that we'll be able to use C++ in HL2. Still, I think it would be great if they added a good script language as a second option. /me wonders how hard it would be to port the source to Java... -randomnine- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: Script languages (was Re: [hlcoders] Half-Life 2: Programming, Hmm?)
Anyway, I'm sorry if that sounded arrogant. I should have added: most people I talked with about that. :) I've met lots of persons who think that script languages are toy languages, which is not justified by the current state of the art (http://home.pacbell.net/ouster/scripting.html). He states initially and in closing that scripting languages and system programming languages (C, C++, ...Java) do and should complement each other. The remainder of the article is largely a head-to-head comparison of Tcl and C/C++ solely in the areas where Tcl's strengths come through. Tcl's GUI code is compared directly with the Win32 API and MFC, and the 25-fold expansion in code blamed directly on the strong typing in C++ (section 3). It is written by the creator of Tcl, whose reputation relies in part upon the success of Tcl. It is hosted on his personal website. To be entirely fair, the author makes some good points. It's unfortunate that he then undermines these by wildly exaggerating his claims by so blatantly picking and choosing his statistics. -randomnine- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: Script languages (was Re: [hlcoders] Half-Life 2: Programming, Hmm?)
/me wonders how hard it would be to port the source to Java... /me wonders how hard it would be to port the source to ASM... Aren't there tools that'll do that automatically? From what I've heard the compiled ASM runs as fast as the original C++, even. Exactly as fast. :p -randomnine- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: Script languages (was Re: [hlcoders] Half-Life 2: Programming, Hmm?)
On Mon, 2 Jun 2003 14:14:05 +1200 Phil [EMAIL PROTECTED] wrote: Aren't there tools that'll do that automatically? From what I've heard the compiled ASM runs as fast as the original C++, even. ASM runs much faster than C++ because it's a lower-level programming language. Some could argue that it's the fastest understandable (if) programming language. ...just joking. -_- I meant the ASM that a compiler would generate from the C++, as with the method in Jonah's post. Which would naturally run exactly as fast as the C++ it was generated from, because it'd have been generated by the same routines as used in compilation. -randomnine- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] estimated release date foe hl2 sdk?
I seem to remember seeing that the SDK for HL2 will be released ahead of the full game. Is there a target release date for the SDK? I doubt this applies to us. A coding SDK would be basically useless without a copy of the engine. Even with well documented APIs, though then we'd at least be able to get acquainted with the system. More likely, they'll hold the coding SDK back at least until the game goes gold, so they have the room to make changes in response to things picked up QA without hurting community relations by releasing two versions of the SDK *before the game comes out*. -randomnine- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] c++ vs. scripts
Any person who is not trained in the basics of programming (algorithms + data = programs) and how to express them in a computer language is -- by definition -- not a programmer. This is the same distinction made between real hackers and mere script kiddies. The way you say this, you're basically saying that *I* am not a programmer, and am limited to copy and paste. I've never taken a lesson in my life, I've never been trained and I'm willing to bet a LOT of people that could do circles around you haven't either. You can teach yourself to program, but both teacher and student need to be the right kind of person. This was aimed at people who are untrained in the respect of being unable to implement new algorithms in code. You're clearly better than that. Edge has managed to procure some information from insiders at Sony though. Apparently, PlayStation3 will be even more difficult to program than the PlayStation2 was, though according to contacts inside SCB RD, this is partly deliberate, in a bid to eliminate developers who don't have the technical skill to develop for the platform. - p.12, Edge #124 Referring back to the original discussion... Power and flexibility are necessary to give HL2 technically interesting mods. Simplicity and ease of use are clearly secondary. However, a well-documented SDK would be nice, and would make it easier to use this power and flexibility - to those who know what they're doing. Unskilled programmers who don't know what they're doing are basically irrelevant, as they are unlikely to produce anything of importance until they improve - whether with a simplified scripting language or a powerful and well-supported language like C++ or Java. -randomnine- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Motion Blur
i've done this sort of thing a couple of times without using the accumulation buffer: accum buffer and stencil buffer aren't always around and i don't think HL requests either of them, so they're usually a bit dodgy and often software emulated. look at glCopyTexSubImage2D. the idea is, you copy the entire screen into a texture, then use that texture to do funky stuff - like blending it a few times over the screen in slightly different places for cool blurs, or mapping it onto a viewmodel or some simple triangles just in front of the view for some really, really cool effects (like it's being refracted through glass, or projected on the inside of a mech cockpit, that sort of thing... pretty slick stuff). what you're probably wanting to do is capture each frame into a texture, then render the previous few screens onto the current one. this is always going to be slow, but it probably won't give you 4 fps - i have a gf2 mx and that kind of load would put it to around 25 fps in normal HL, down from 50 fps, in 1024x768 16-bit. fuck it - i've been meaning to upload a li'l tech demo with source to cover full screen linear and radial blurring and overbright from gltexcopy. it'll have to wait another week or so, though. i'm kinda busy x_x -randomnine- 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) ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
