subject:"\[hlcoders\] Source Engine 2\!\!\!"

The idea of GPU is a method to take load off o the main CPU, to put it onto 
another processor that has the only purpose of processing the graphics you are 
doing.

A form of delegating between multiple chips, as I understood it.

This way, you have one chip working specifically on the graphics, and the other 
doing everything else.

And you are right---a software render cannot compete with a GPU on an even 
field.

You missed the point where Linux does not take up as much system resources, 
typically, as the latest versions of Windows does.

The idea being, to get a software renderer on Linux, to work on the same level 
as a hardware renderer on Windows.

Like I said, you can typically get Linux, to run in a GBA... you cannot fit 
anything else into there (maybe pong, I guess?). A GBA typically clocks in at 
about 67.5MHz IIRC, with next to no RAM.

Windows 7, kind of requires 1GiB at a minimum for RAM, and you are going to 
need at least 1 or 2 GHz to get it running.

My idea, again, in case you missed it, was to try to take up this saved 
overhead, use it for software rendering, to make it comparable to the hardware 
rendering on Windows.

The idea being:

If you can get that kind of comparable speed on Linux with Software 
Rendering... this would make graphics card companies more inclined to make 
drivers for Linux--as this shows how much more resources you can fit games 
into.

I mean, no idea how this point was lost, when what started this train of 
thought was that Nvidia and ATI had issues supporting Linux with their 
drivers.

The software rendering engine would never be more than used as a form of 
insane PoC idea. Or at least, never commercially.

It would be a demo, that would be aimed at getting the attention of hardware 
driver developers to target linux for these drivers.

A publicity stunt was what I was suggesting.

~Katrina

On Tuesday, June 15, 2010 02:45:33 pm Adam Buckland wrote:
 I was under the impression that the whole point of building GPUs in
 the first place was because it was impossible to build a software
 renderer of comparable speed :P
 
 On 15 June 2010 20:39, Bob Somers magicbob...@gmail.com wrote:
  Trying to make a software renderer compete with a dedicated GPU is
  kind of, uh, an exercise in futility.
 
  --Bob
  On Mon, Jun 14, 2010 at 11:20 PM, Katrina Payne
  fullmetalhar...@nimhlabs.com wrote:
  Well, considering how crazy this idea is... that is likely all I would be
  having with it...
 
  Regardless of whether or not it works.
 
  This is like Joker from Batman type crazy here...
 
  So, yeah, I will X3
 
  The issue is I have too much other crap on my plate right now--however, I 
am
  certain there are other crazy people on this mailing list who have the 
time
  for this suggestion.
 
  On Tuesday, June 15, 2010 12:14:42 am Bob Somers wrote:
  Uh, have fun with that.
 
  --Bob
  On Mon, Jun 14, 2010 at 8:20 PM, Katrina Payne
  fullmetalhar...@nimhlabs.com wrote:
   This also adds a rather odd burden here, that allows Linux to get a 
better
   standing for gaming.
  
   It is not that unknown that without mixing, Linux generally does not
  require
   anywhere near as much over head to run as windows.
  
   The minimum requirements to run a GUI on Linux is about 256MiB of RAM.
  This
   even includes GUIs like KDE and Gnome. Though XFCE and LXCE would be
  better if
   you really did only have 256MiB of RAM (well if you were using a DE... 
and
  not
   a slimmed down WM with only a few programs loaded into it)
  
   You can do just fine win 1GiB of RAM.
  
   Linux also, as an OS can run on some old Intel boards--that running an 
OS
  on
   would other wise be insane today. a Pentium 1 can still get (some) use
  with
   Linux.
  
   Not enough to really be noteworthy as a desktop PC... but, this is a 
lot
  less
   than the least you will get Windows 7 onto.
  
   So we have a nice toss up here:
  
   1: Linux requires Software Rendering in place. IE: how rendering was 
done,
   before we got silly things like TNT and Voodoo on the market.
  
   2: Linux requires significantly less overhead to run, as far as OS 
goes.
  
   If we can get it so that we can show Steam running on Linux, using 
mostly
   Software Rendering, and getting it to run as fast as the same game on
  Windows,
   on comparable hardware...
  
   This will definitely sell Linux as an OS...
  
   Which in turn will get various Graphics Card makers on board to add 
their
   support.
  
   You know--I kind of want to see somebody work on that goal then. I am
  almost
   ready to dig up some old books that go over the theory of 3d 
programming,
  just
   to pull make a software rendering engine for this idea.
  
   On Monday, June 14, 2010 07:59:45 pm Darren VanBuren wrote:
   Yes, 3D drivers are definitely quite lacking on the GNU/Linux front,
   but if Valve shows support for the development of these drivers, this
   may prompt certain GPU manufacturers to step up their GNU/Linux 
driver

Re: [hlcoders] Source Engine 2!!!

2010-06-18 Thread joshua simmons

You will never get any speed out of a software renderer, and using Linux
won't change that.

I don't think you quite understand the fundamental differences between CPU
architecture and a massively parallel gpu architecture.

On 18 Jun 2010 18:41, Katrina Payne fullmetalhar...@nimhlabs.com wrote:

The idea of GPU is a method to take load off o the main CPU, to put it onto
another processor that has the only purpose of processing the graphics you
are
doing.

A form of delegating between multiple chips, as I understood it.

This way, you have one chip working specifically on the graphics, and the
other
doing everything else.

And you are right---a software render cannot compete with a GPU on an even
field.

You missed the point where Linux does not take up as much system resources,
typically, as the latest versions of Windows does.

The idea being, to get a software renderer on Linux, to work on the same
level
as a hardware renderer on Windows.

Like I said, you can typically get Linux, to run in a GBA... you cannot fit
anything else into there (maybe pong, I guess?). A GBA typically clocks in
at
about 67.5MHz IIRC, with next to no RAM.

Windows 7, kind of requires 1GiB at a minimum for RAM, and you are going to
need at least 1 or 2 GHz to get it running.

My idea, again, in case you missed it, was to try to take up this saved
overhead, use it for software rendering, to make it comparable to the
hardware
rendering on Windows.

The idea being:

If you can get that kind of comparable speed on Linux with Software
Rendering... this would make graphics card companies more inclined to make
drivers for Linux--as this shows how much more resources you can fit games
into.

I mean, no idea how this point was lost, when what started this train of
thought was that Nvidia and ATI had issues supporting Linux with their
drivers.

The software rendering engine would never be more than used as a form of
insane PoC idea. Or at least, never commercially.

It would be a demo, that would be aimed at getting the attention of hardware
driver developers to target linux for these drivers.

A publicity stunt was what I was suggesting.

~Katrina


On Tuesday, June 15, 2010 02:45:33 pm Adam Buckland wrote:
 I was under the impression that the wh...
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Source Engine 2!!!

2010-06-18 Thread Bob Somers

Yeah, no offense, but I don't think you fully understand the
differences between the CPU/GPU.

The fact that you can get Linux running on a lower powered machine
doesn't mean much when it comes to raw graphics horsepower. These
resource savings are almost entirely on the CPU/RAM side. A software
renderer would run just as poorly on a Linux machine as a Windows
machine because a CPU is not designed for graphics processing, it's
designed for serial, general purpose computing.

The hardware graphics pipeline gets you matrix/vector computations,
per-vertex lighting, view projection transformations, clipping and
culling, scan conversion, texture lookups, and in modern hardware,
vertex and fragment shader engines and geometry tessellation, all
massively parallel in hardware. Even a low-range GPU can crank through
graphics operations like a hot knife through butter compared to a
high-range CPU.

It's not a matter of having extra resources. The point is that those
extra resources won't get you very far compared to a hardware
graphics pipeline, because they're not specialized. Modern CPUs run
best when context switching is kept to a minimum, because they have
huge cores that offer a lot of general purpose functionality. GPUs
have (nowadays) hundreds of small, highly-specialized cores designed
specifically for the operations in the graphics pipeline.

There's not a whole lot consumers can do to get ATI to up their game
on their Linux drivers, other than contact them and complain about
driver support. Honestly the best thing that could happen right now to
level the playing field is to have a major game publisher (anybody at
Valve reading this? :D) announce Linux support, preferably with a
runs best on nVidia because their Linux drivers don't suck campaign.
Big companies like ATI don't respond to something until it bites them
in their pocketbook.

--Bob






On Fri, Jun 18, 2010 at 1:48 AM, joshua simmons simmons...@gmail.com wrote:
 You will never get any speed out of a software renderer, and using Linux
 won't change that.

 I don't think you quite understand the fundamental differences between CPU
 architecture and a massively parallel gpu architecture.

 On 18 Jun 2010 18:41, Katrina Payne fullmetalhar...@nimhlabs.com wrote:

 The idea of GPU is a method to take load off o the main CPU, to put it onto
 another processor that has the only purpose of processing the graphics you
 are
 doing.

 A form of delegating between multiple chips, as I understood it.

 This way, you have one chip working specifically on the graphics, and the
 other
 doing everything else.

 And you are right---a software render cannot compete with a GPU on an even
 field.

 You missed the point where Linux does not take up as much system resources,
 typically, as the latest versions of Windows does.

 The idea being, to get a software renderer on Linux, to work on the same
 level
 as a hardware renderer on Windows.

 Like I said, you can typically get Linux, to run in a GBA... you cannot fit
 anything else into there (maybe pong, I guess?). A GBA typically clocks in
 at
 about 67.5MHz IIRC, with next to no RAM.

 Windows 7, kind of requires 1GiB at a minimum for RAM, and you are going to
 need at least 1 or 2 GHz to get it running.

 My idea, again, in case you missed it, was to try to take up this saved
 overhead, use it for software rendering, to make it comparable to the
 hardware
 rendering on Windows.

 The idea being:

 If you can get that kind of comparable speed on Linux with Software
 Rendering... this would make graphics card companies more inclined to make
 drivers for Linux--as this shows how much more resources you can fit games
 into.

 I mean, no idea how this point was lost, when what started this train of
 thought was that Nvidia and ATI had issues supporting Linux with their
 drivers.

 The software rendering engine would never be more than used as a form of
 insane PoC idea. Or at least, never commercially.

 It would be a demo, that would be aimed at getting the attention of hardware
 driver developers to target linux for these drivers.

 A publicity stunt was what I was suggesting.

 ~Katrina


 On Tuesday, June 15, 2010 02:45:33 pm Adam Buckland wrote:
 I was under the impression that the wh...
 ___
 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] Source Engine 2!!!

Right--we will just go with the idea that I do not understand the 
architectural difference here.

As well, I really did not understand it as being any more significant than a 
CPU vs a FPU--or something like that really. Even then, typically, there are 
ways to emulate floating point operations without a FPU, or in the case of some 
early Pentiums, a faulty FPU. Yes, you do lose some speed, but... well, I 
dunno, when one platform only really requires 100MHz for a decent running 
speed... and the other requires 2GHz... I really have to wonder what exactly 
these insanely different fundamental differences are.

How about this, any terms I can Google that will give me any way to learn more 
about these really large differences you speak of?

I mean unless these graphics cards have some phenomenon bios that contains 
most of the functions for drawing primitives, I really cannot confess to 
knowing what you are talking about here.

So, I will request some Google search terms, here.

I mean, we should be able to have remarkably large amount of room to play with 
in the cycles for doing what we want software wise. I mean--yeah...

Going to have to ask to explain these fundamental differences--or point to 
place that can.

As under my understanding, all a chip, be it CPU, FPU or GPU could do was 
load, store, do stuff with the registers it has, and possibly a few simple 
operations based on the data in the registers, or data being pointed to in the 
arguments.

So, yeah going to have to ask for a link on what exactly these differences are 
(or at least some decent keywords)--as my current comprehension of how 
hardware itself works does not allow for having any clue what you are talking 
about here.

Especially when, you are saying that an OS that only really requires 100MHz 
for base running, when having this software rendering, cannot compete with an 
OS that requires 2GHz of CPU with a GPU.

I mean--this is kind of hellova wack right here. Especially when my suggestion 
was that, apart from the GPU, the hardware this was being tested on would be 
at a similar level.

That is, the OS with the lower overhead, running on a current platform setup, 
as is the OS with the higher overhead. Just the higher overhead has the GPU.

Yeah... please, you guys are making no sense here. At this point, you are 
talking about a fundamental difference that I cannot fathom even really exists 
in any of my understanding how how computer hardware works or even evolved 
over the decades.

You may as well be chiding me for not understanding the 96 Hour Day or 
something at this point.

So, again, I ask for your Axioms.

~Katrina

On Friday, June 18, 2010 02:48:00 am joshua simmons wrote:
 You will never get any speed out of a software renderer, and using Linux
 won't change that.
 
 I don't think you quite understand the fundamental differences between CPU
 architecture and a massively parallel gpu architecture.
 
 On 18 Jun 2010 18:41, Katrina Payne fullmetalhar...@nimhlabs.com wrote:
 
 The idea of GPU is a method to take load off o the main CPU, to put it onto
 another processor that has the only purpose of processing the graphics you
 are
 doing.
 
 A form of delegating between multiple chips, as I understood it.
 
 This way, you have one chip working specifically on the graphics, and the
 other
 doing everything else.
 
 And you are right---a software render cannot compete with a GPU on an even
 field.
 
 You missed the point where Linux does not take up as much system resources,
 typically, as the latest versions of Windows does.
 
 The idea being, to get a software renderer on Linux, to work on the same
 level
 as a hardware renderer on Windows.
 
 Like I said, you can typically get Linux, to run in a GBA... you cannot fit
 anything else into there (maybe pong, I guess?). A GBA typically clocks in
 at
 about 67.5MHz IIRC, with next to no RAM.
 
 Windows 7, kind of requires 1GiB at a minimum for RAM, and you are going to
 need at least 1 or 2 GHz to get it running.
 
 My idea, again, in case you missed it, was to try to take up this saved
 overhead, use it for software rendering, to make it comparable to the
 hardware
 rendering on Windows.
 
 The idea being:
 
 If you can get that kind of comparable speed on Linux with Software
 Rendering... this would make graphics card companies more inclined to make
 drivers for Linux--as this shows how much more resources you can fit games
 into.
 
 I mean, no idea how this point was lost, when what started this train of
 thought was that Nvidia and ATI had issues supporting Linux with their
 drivers.
 
 The software rendering engine would never be more than used as a form of
 insane PoC idea. Or at least, never commercially.
 
 It would be a demo, that would be aimed at getting the attention of hardware
 driver developers to target linux for these drivers.
 
 A publicity stunt was what I was suggesting.
 
 ~Katrina
 
 
 On Tuesday, June 15, 2010 02:45:33 pm Adam Buckland wrote:
  I was

Re: [hlcoders] Source Engine 2!!!

Reply follows inline

On Friday, June 18, 2010 04:40:24 am Bob Somers wrote:
 Yeah, no offense, but I don't think you fully understand the
 differences between the CPU/GPU.

Yeah, I do not think I do either.

 The fact that you can get Linux running on a lower powered machine
 doesn't mean much when it comes to raw graphics horsepower. These
 resource savings are almost entirely on the CPU/RAM side. A software
 renderer would run just as poorly on a Linux machine as a Windows
 machine because a CPU is not designed for graphics processing, it's
 designed for serial, general purpose computing.

Yes, I know. However, it never gets used for such regardless.

All serial general purpose computing comes down to is adding numbers together, 
subtracting them, dividing, multiplying (sometimes), dividing (sometimes), 
modulus (sometimes) and popping and pushing them from memory.

Typically other hardware reads what is in this memory, and will do a direct 
thoughtless production of this.

For example, on some simple console systems, all the display will do, is read 
from a certain spot of memory and follow what is in there, for displaying 
tiles on the screen, or try to deal with various OAM/sprite values to post 
onto the screen.

All the CPU does is put that data there--and the hardware does what it wants 
with it--typically without questions.

 The hardware graphics pipeline gets you matrix/vector computations,
 per-vertex lighting, view projection transformations, clipping and
 culling, scan conversion, texture lookups, and in modern hardware,
 vertex and fragment shader engines and geometry tessellation, all
 massively parallel in hardware. Even a low-range GPU can crank through
 graphics operations like a hot knife through butter compared to a
 high-range CPU.

Right... okay... I hear that it does this...

But how.

How does the GPU do this in a way that the CPU cannot? Are there special 
opcodes that do these actions.

I mean, the idea of a texture lookup op code seems kind of silly to me.

What is it, that the GPU does, to do this--that makes it better.

It is nice you say this as a summary--but... what are the insides of the 
beast?

 It's not a matter of having extra resources. The point is that those
 extra resources won't get you very far compared to a hardware
 graphics pipeline, because they're not specialized. Modern CPUs run
 best when context switching is kept to a minimum, because they have
 huge cores that offer a lot of general purpose functionality. GPUs
 have (nowadays) hundreds of small, highly-specialized cores designed
 specifically for the operations in the graphics pipeline.

Except, I figured that they both were just large amounts of transistors grouped 
closer together in a certain way. Just to an insanely clustered amount.

So, you are suggesting that a GPU is not so much a Processing Unit, in 
comparison to some form of Midi or other Sound Output device?

I mean, the abstract is really nice and all... but that is all it is, an 
abstract that you are using to argue that a GPU can handle stuff a CPU cannot.

Please, I am going to ask for the various specifics on this matter.

As until then, I am still going to have no what you are talking about...

And likely will start going glassy eyed in much the same way a scientist would 
when you say something is Magic.

This is a very nice abstract on this...

But... it tells me nothing on the exact differences in the engine here. It just 
says, they are there--and really, I am not certain I can believe that at 
face value really.

No offense to you particularly, but I have had some fools try to get me to 
trust that stuff. Usually upon investigation, I learned they were the biggest 
handitards on the planet.

Now, since you are right, and likely, this may take more than an email that 
this mailing list can take, perhaps, link me to a white paper somewhere? Or 
something on the matter.

As until you do, your explaination may as well be a verbose variant of:

Q: What is the fundamental difference between a GPU and CPU

A: Magic.

 There's not a whole lot consumers can do to get ATI to up their game
 on their Linux drivers, other than contact them and complain about
 driver support. Honestly the best thing that could happen right now to
 level the playing field is to have a major game publisher (anybody at
 Valve reading this? :D) announce Linux support, preferably with a
 runs best on nVidia because their Linux drivers don't suck campaign.
 Big companies like ATI don't respond to something until it bites them
 in their pocketbook.
 
 --Bob

That is another method--but I am not certain it will happen. It would be nice 
though.

 On Fri, Jun 18, 2010 at 1:48 AM, joshua simmons simmons...@gmail.com 
wrote:
  You will never get any speed out of a software renderer, and using Linux
  won't change that.
 
  I don't think you quite understand the fundamental differences between CPU
  architecture and a massively parallel gpu architecture.
 
  On 18 Jun

Re: [hlcoders] Source Engine 2!!!

2010-06-18 Thread Bob Somers

Katrina, I'm not giving lectures on computer graphics here. Google has
all the information you asked for. If you'd like, I can also recommend
some graphics textbooks which would clear things up. Also, saying a
Linux system running on a 100 MHz machine is comparable to Windows
running on a 2 GHz machine is a ridiculous overstatement. They are not
that radically different. If you're so convinced you can make the
words best software renderer, by all means go do it. I'm sure at the
very least you can wave your SIGGRAPH paper in our faces when you're
done.

Josh, I'm not sure you can call it better Linux support if their 3D
support is... well... really bad. They may have opened up their
hardware spec so that the free drivers can get rolling (I have tried
the new drivers in Fedora 13 and they are quite good so far), but the
free drivers are at least a year behind their Windows counterpart in
terms of supporting the full features of the cards. There is virtually
zero shader support in the free drivers at this point. nVidia's
drivers, on the other hand, may be proprietary, but at least you can
get decent 3D performance out of the machine on a current distro. The
proprietary ATI driver has decent support and performance, but it
won't run on anything newer than Fedora 11. (Sorry if I keep
referencing things in terms of Fedora versions, it's my distro of
choice.)

I'm all for free software, don't get me wrong. I would love for
nothing more than to have free alternative drivers for ATI and nVidia
cards, but if gaming is really going to be commercially viable on the
Linux desktop it's the performance that matters. No publisher is going
to bother trying to ship a game for Linux where the poor driver
support is going to cause them support headaches all day long.

--Bob




On Fri, Jun 18, 2010 at 4:38 AM, joshua simmons simmons...@gmail.com wrote:
 Actually to be honest ATI have vastly better Linux support, it just does not
 extend to 3d yet. Since they opened the specs for their hardware, and now
 support the open source driver, it is making leaps forward. This is in stark
 contrast to NVIDIA's totally closed development. I mean NVIDIA don't even
 support kms because the kernel exports for it are gpl only.

 On 18 Jun 2010 20:43, Bob Somers magicbob...@gmail.com wrote:

 Yeah, no offense, but I don't think you fully understand the
 differences between the CPU/GPU.

 The fact that you can get Linux running on a lower powered machine
 doesn't mean much when it comes to raw graphics horsepower. These
 resource savings are almost entirely on the CPU/RAM side. A software
 renderer would run just as poorly on a Linux machine as a Windows
 machine because a CPU is not designed for graphics processing, it's
 designed for serial, general purpose computing.

 The hardware graphics pipeline gets you matrix/vector computations,
 per-vertex lighting, view projection transformations, clipping and
 culling, scan conversion, texture lookups, and in modern hardware,
 vertex and fragment shader engines and geometry tessellation, all
 massively parallel in hardware. Even a low-range GPU can crank through
 graphics operations like a hot knife through butter compared to a
 high-range CPU.

 It's not a matter of having extra resources. The point is that those
 extra resources won't get you very far compared to a hardware
 graphics pipeline, because they're not specialized. Modern CPUs run
 best when context switching is kept to a minimum, because they have
 huge cores that offer a lot of general purpose functionality. GPUs
 have (nowadays) hundreds of small, highly-specialized cores designed
 specifically for the operations in the graphics pipeline.

 There's not a whole lot consumers can do to get ATI to up their game
 on their Linux drivers, other than contact them and complain about
 driver support. Honestly the best thing that could happen right now to
 level the playing field is to have a major game publisher (anybody at
 Valve reading this? :D) announce Linux support, preferably with a
 runs best on nVidia because their Linux drivers don't suck campaign.
 Big companies like ATI don't respond to something until it bites them
 in their pocketbook.

 --Bob







 On Fri, Jun 18, 2010 at 1:48 AM, joshua simmons simmons...@gmail.com
 wrote:
 You will never...

 ___
 To unsubscribe, edit your list preferences, or v...
 ___
 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] Source Engine 2!!!

That is good, I never asked for a lecture anywhere.

If anything, I asked for some terms I could use in Google. A mantra or some 
such concept I guess.

I also asked for text books and white papers.

No where did I ask for a lecture.

I even flat out stated many times that what you were to explain would be too 
long for an email to fit, so the idea that I would be asking for a lecture is 
ludicrous.

Now then, rather than saying this obvious statement, how about you just tell 
me some google search mantra to use (as really, my mind is blank for any 
keywords I could use that would get me anything meaningful), a set of text 
books, or maybe a white paper?

I do not appreciate feeling like I am being talked down to.

It is also statements like this below, that make me think you are disregarding 
my suggestions, as, if you were not disregarding them, you would have just 
gave those text book titles, or some keywords to search with, or at the very 
least a basic white paper.

Had it been some standard of programming, I could attack ISO, RFC, Working 
Draft, Recommendation, Best Practices, Primer or Howto to something like 
GPU.

In this case, I do not expect any of those to work.

Now then, please, stop talking to me like a fool, and blantantly disregarding 
stuff I have asked for, and brushing me off as somebody expecting a lecture 
over 
a mailing list--or some such retarded notion you have gotten into what I am 
asking for here.

Thank you

~Katrina

On Friday, June 18, 2010 05:58:37 am Bob Somers wrote:
 Katrina, I'm not giving lectures on computer graphics here. Google has
 all the information you asked for. If you'd like, I can also recommend
 some graphics textbooks which would clear things up

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Source Engine 2!!!

Hi,

The major differences are that while a CPU has one processing core (or
today, two processing core), any older GPU has quite a lot of processing
units that run at a very low speed but are specialized in certain areas,
this way the load is really divided. Also just a comment, several labs are
starting to use GPU to do MAJOR calculations specially because of their high
paralel processing oportunity.

And for instance Shader calculation is a very expensive method, but for
instance most of the more modern cards have several shader processing units
in which their architecture and also their basic functionality are optimized
to do this shader calculation that would make a CPU cry.

The major differences Katrina between the two is that a CPU is a generic
processing unit, which contain a lot of commands and functionalities, while
a GPU contains quite a lot of VERY specialized processing cores. This
differences is what makes it be really faster than using Software rendering,
specially since some with Software rendering you would need to emulate some
features that are basic nowadays with the GPUs, and do so much calculations
in a serial way, while trying to maintain a decent 3d output. So again i
say, the most important feature of the GPUs is their paralel programming.

2010/6/18 Katrina Payne fullmetalhar...@nimhlabs.com

 That is good, I never asked for a lecture anywhere.

 If anything, I asked for some terms I could use in Google. A mantra or some
 such concept I guess.

 I also asked for text books and white papers.

 No where did I ask for a lecture.

 I even flat out stated many times that what you were to explain would be
 too
 long for an email to fit, so the idea that I would be asking for a lecture
 is
 ludicrous.

 Now then, rather than saying this obvious statement, how about you just
 tell
 me some google search mantra to use (as really, my mind is blank for any
 keywords I could use that would get me anything meaningful), a set of text
 books, or maybe a white paper?

 I do not appreciate feeling like I am being talked down to.

 It is also statements like this below, that make me think you are
 disregarding
 my suggestions, as, if you were not disregarding them, you would have just
 gave those text book titles, or some keywords to search with, or at the
 very
 least a basic white paper.

 Had it been some standard of programming, I could attack ISO, RFC, Working
 Draft, Recommendation, Best Practices, Primer or Howto to something like
 GPU.

 In this case, I do not expect any of those to work.

 Now then, please, stop talking to me like a fool, and blantantly
 disregarding
 stuff I have asked for, and brushing me off as somebody expecting a lecture
 over
 a mailing list--or some such retarded notion you have gotten into what I am
 asking for here.

 Thank you

 ~Katrina

 On Friday, June 18, 2010 05:58:37 am Bob Somers wrote:
  Katrina, I'm not giving lectures on computer graphics here. Google has
  all the information you asked for. If you'd like, I can also recommend
  some graphics textbooks which would clear things up

 ___
 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] Source Engine 2!!!

Thanks ZuM

I apologise, I may have been misinterpreting the TLA, of GPU to mean Graphics 
Processing Unit... I guess I must be interpreting it wrong, as what you 
described was a cluster, not a unit.

Though, this is not the first time a hardware or software term was fairly 
misleading.

Thank you, as now I understand it is not a unit, but a cluster of units.

Sorry for the issues, I may have caused in my misinterpretation of what the 
TLA indicated.

Back to your regularly scheduled mailing list.

~Katrina

On Friday, June 18, 2010 06:25:03 am ZuM wrote:
 Hi,
 
 The major differences are that while a CPU has one processing core (or
 today, two processing core), any older GPU has quite a lot of processing
 units that run at a very low speed but are specialized in certain areas,
 this way the load is really divided. Also just a comment, several labs are
 starting to use GPU to do MAJOR calculations specially because of their high
 paralel processing oportunity.
 
 And for instance Shader calculation is a very expensive method, but for
 instance most of the more modern cards have several shader processing units
 in which their architecture and also their basic functionality are optimized
 to do this shader calculation that would make a CPU cry.
 
 The major differences Katrina between the two is that a CPU is a generic
 processing unit, which contain a lot of commands and functionalities, while
 a GPU contains quite a lot of VERY specialized processing cores. This
 differences is what makes it be really faster than using Software rendering,
 specially since some with Software rendering you would need to emulate some
 features that are basic nowadays with the GPUs, and do so much calculations
 in a serial way, while trying to maintain a decent 3d output. So again i
 say, the most important feature of the GPUs is their paralel programming.
 
 2010/6/18 Katrina Payne fullmetalhar...@nimhlabs.com
 
  That is good, I never asked for a lecture anywhere.
 
  If anything, I asked for some terms I could use in Google. A mantra or 
some
  such concept I guess.
 
  I also asked for text books and white papers.
 
  No where did I ask for a lecture.
 
  I even flat out stated many times that what you were to explain would be
  too
  long for an email to fit, so the idea that I would be asking for a lecture
  is
  ludicrous.
 
  Now then, rather than saying this obvious statement, how about you just
  tell
  me some google search mantra to use (as really, my mind is blank for any
  keywords I could use that would get me anything meaningful), a set of text
  books, or maybe a white paper?
 
  I do not appreciate feeling like I am being talked down to.
 
  It is also statements like this below, that make me think you are
  disregarding
  my suggestions, as, if you were not disregarding them, you would have just
  gave those text book titles, or some keywords to search with, or at the
  very
  least a basic white paper.
 
  Had it been some standard of programming, I could attack ISO, RFC, Working
  Draft, Recommendation, Best Practices, Primer or Howto to something like
  GPU.
 
  In this case, I do not expect any of those to work.
 
  Now then, please, stop talking to me like a fool, and blantantly
  disregarding
  stuff I have asked for, and brushing me off as somebody expecting a lecture
  over
  a mailing list--or some such retarded notion you have gotten into what I 
am
  asking for here.
 
  Thank you
 
  ~Katrina
 
  On Friday, June 18, 2010 05:58:37 am Bob Somers wrote:
   Katrina, I'm not giving lectures on computer graphics here. Google has
   all the information you asked for. If you'd like, I can also recommend
   some graphics textbooks which would clear things up

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Source Engine 2!!!

The concept is the same of a cluster, but it is in a single processing unit.
A cluster requires several processing units, this is the main difference (or
else we cound consider an I7 a cluster, but anyway).

This is all i know how to explain, but basically the GPU is specialized in
several areas where a normal CPU isn`t and would suffer to emulate.
Also the calculation of vector and matrix operations (which are the most
common in Graphics) are really faster because of, again, the speciallized
architecture for this.

I don`t have a link to any white paper that i can remember right now, but
please have a look at this link of wikipedia, that may help you understand a
little more about GPUs and then you`ll clearly see the reason why it`s
almost impossible to emulate through software at a decent speed.

http://en.wikipedia.org/wiki/Graphics_processing_unit

2010/6/18 Katrina Payne fullmetalhar...@nimhlabs.com

 Thanks ZuM

 I apologise, I may have been misinterpreting the TLA, of GPU to mean
 Graphics
 Processing Unit... I guess I must be interpreting it wrong, as what you
 described was a cluster, not a unit.

 Though, this is not the first time a hardware or software term was fairly
 misleading.

 Thank you, as now I understand it is not a unit, but a cluster of units.

 Sorry for the issues, I may have caused in my misinterpretation of what the
 TLA indicated.

 Back to your regularly scheduled mailing list.

 ~Katrina

 On Friday, June 18, 2010 06:25:03 am ZuM wrote:
  Hi,
 
  The major differences are that while a CPU has one processing core (or
  today, two processing core), any older GPU has quite a lot of processing
  units that run at a very low speed but are specialized in certain areas,
  this way the load is really divided. Also just a comment, several labs
 are
  starting to use GPU to do MAJOR calculations specially because of their
 high
  paralel processing oportunity.
 
  And for instance Shader calculation is a very expensive method, but for
  instance most of the more modern cards have several shader processing
 units
  in which their architecture and also their basic functionality are
 optimized
  to do this shader calculation that would make a CPU cry.
 
  The major differences Katrina between the two is that a CPU is a generic
  processing unit, which contain a lot of commands and functionalities,
 while
  a GPU contains quite a lot of VERY specialized processing cores. This
  differences is what makes it be really faster than using Software
 rendering,
  specially since some with Software rendering you would need to emulate
 some
  features that are basic nowadays with the GPUs, and do so much
 calculations
  in a serial way, while trying to maintain a decent 3d output. So again i
  say, the most important feature of the GPUs is their paralel programming.
 
  2010/6/18 Katrina Payne fullmetalhar...@nimhlabs.com
 
   That is good, I never asked for a lecture anywhere.
  
   If anything, I asked for some terms I could use in Google. A mantra or
 some
   such concept I guess.
  
   I also asked for text books and white papers.
  
   No where did I ask for a lecture.
  
   I even flat out stated many times that what you were to explain would
 be
   too
   long for an email to fit, so the idea that I would be asking for a
 lecture
   is
   ludicrous.
  
   Now then, rather than saying this obvious statement, how about you just
   tell
   me some google search mantra to use (as really, my mind is blank for
 any
   keywords I could use that would get me anything meaningful), a set of
 text
   books, or maybe a white paper?
  
   I do not appreciate feeling like I am being talked down to.
  
   It is also statements like this below, that make me think you are
   disregarding
   my suggestions, as, if you were not disregarding them, you would have
 just
   gave those text book titles, or some keywords to search with, or at the
   very
   least a basic white paper.
  
   Had it been some standard of programming, I could attack ISO, RFC,
 Working
   Draft, Recommendation, Best Practices, Primer or Howto to something
 like
   GPU.
  
   In this case, I do not expect any of those to work.
  
   Now then, please, stop talking to me like a fool, and blantantly
   disregarding
   stuff I have asked for, and brushing me off as somebody expecting a
 lecture
   over
   a mailing list--or some such retarded notion you have gotten into what
 I
 am
   asking for here.
  
   Thank you
  
   ~Katrina
  
   On Friday, June 18, 2010 05:58:37 am Bob Somers wrote:
Katrina, I'm not giving lectures on computer graphics here. Google
 has
all the information you asked for. If you'd like, I can also
 recommend
some graphics textbooks which would clear things up

 ___
 To unsubscribe, edit your list preferences, or view the list archives,
 please visit:
 http://list.valvesoftware.com/mailman/listinfo/hlcoders


___
To

Re: [hlcoders] Source Engine 2!!!

2010-06-18 Thread Jeffrey botman Broome

This may help...

http://www.youtube.com/watch?v=fKK933KK6Gg

:)


On 6/18/2010 6:36 AM, Katrina Payne wrote:
 Reply follows inline

 On Friday, June 18, 2010 04:40:24 am Bob Somers wrote:

 Yeah, no offense, but I don't think you fully understand the
 differences between the CPU/GPU.
  
 Yeah, I do not think I do either.



___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Source Engine 2!!!

Ah, thanks, that described the main issue here.

The reliance of Eulerian Geometry. It also explains why I suck at FPS.

Well, this likely means I am going to stay away from any form of 3d 
programming in the future, as most of the Eulerian Axioms I have been told 
tend to be things that I tend to have issues seeing how people can agree with 
that.

But then, I am the person that I typically try to copy various conventions of 
art styles rather than try to draw realistically... because well, in recent 
years I have learned that I do not even perceive the world in an Eulerian 
manner.

So yeah, this is kind of a good thing really, I can now stop exploring 3d 
Programming. As well, the whole thing will mostly only cause more issues than 
it is worth, as I have never been able to agree with the basic Axioms that 
make up Geometry.

And well--a few of the articles on that link just made that really apparent.

Hmm--well, I suppose there is not much I can really do about this now. I mean, 
I could write up some Axioms on Noneulerian Geometry... but nobody apart from 
me would find them useful--so I may as well be twiddling my thumbs and doing 
basket weaving... actually those two options would be thought of as more 
useful.

Well, thanks--that link kind of helped me out in more ways than one.

Just have to grok what I have learned from this for a bit.

~Katrina

On Friday, June 18, 2010 06:51:28 am ZuM wrote:
 The concept is the same of a cluster, but it is in a single processing unit.
 A cluster requires several processing units, this is the main difference (or
 else we cound consider an I7 a cluster, but anyway).
 
 This is all i know how to explain, but basically the GPU is specialized in
 several areas where a normal CPU isn`t and would suffer to emulate.
 Also the calculation of vector and matrix operations (which are the most
 common in Graphics) are really faster because of, again, the speciallized
 architecture for this.
 
 I don`t have a link to any white paper that i can remember right now, but
 please have a look at this link of wikipedia, that may help you understand a
 little more about GPUs and then you`ll clearly see the reason why it`s
 almost impossible to emulate through software at a decent speed.
 
 http://en.wikipedia.org/wiki/Graphics_processing_unit
 
 2010/6/18 Katrina Payne fullmetalhar...@nimhlabs.com
 
  Thanks ZuM
 
  I apologise, I may have been misinterpreting the TLA, of GPU to mean
  Graphics
  Processing Unit... I guess I must be interpreting it wrong, as what you
  described was a cluster, not a unit.
 
  Though, this is not the first time a hardware or software term was fairly
  misleading.
 
  Thank you, as now I understand it is not a unit, but a cluster of units.
 
  Sorry for the issues, I may have caused in my misinterpretation of what 
the
  TLA indicated.
 
  Back to your regularly scheduled mailing list.
 
  ~Katrina
 
  On Friday, June 18, 2010 06:25:03 am ZuM wrote:
   Hi,
  
   The major differences are that while a CPU has one processing core (or
   today, two processing core), any older GPU has quite a lot of processing
   units that run at a very low speed but are specialized in certain areas,
   this way the load is really divided. Also just a comment, several labs
  are
   starting to use GPU to do MAJOR calculations specially because of their
  high
   paralel processing oportunity.
  
   And for instance Shader calculation is a very expensive method, but for
   instance most of the more modern cards have several shader processing
  units
   in which their architecture and also their basic functionality are
  optimized
   to do this shader calculation that would make a CPU cry.
  
   The major differences Katrina between the two is that a CPU is a generic
   processing unit, which contain a lot of commands and functionalities,
  while
   a GPU contains quite a lot of VERY specialized processing cores. This
   differences is what makes it be really faster than using Software
  rendering,
   specially since some with Software rendering you would need to emulate
  some
   features that are basic nowadays with the GPUs, and do so much
  calculations
   in a serial way, while trying to maintain a decent 3d output. So again i
   say, the most important feature of the GPUs is their paralel 
programming.
  
   2010/6/18 Katrina Payne fullmetalhar...@nimhlabs.com
  
That is good, I never asked for a lecture anywhere.
   
If anything, I asked for some terms I could use in Google. A mantra or
  some
such concept I guess.
   
I also asked for text books and white papers.
   
No where did I ask for a lecture.
   
I even flat out stated many times that what you were to explain would
  be
too
long for an email to fit, so the idea that I would be asking for a
  lecture
is
ludicrous.
   
Now then, rather than saying this obvious statement, how about you 
just
tell
me some google search mantra to use (as really, my mind is

Re: [hlcoders] Source Engine 2!!!

2010-06-18 Thread joshua simmons

Oh yeah I understand. There is only very rudmentry 3d support, in no way
capable of supporting any game. My point was more on the radical rate at
which they are evolving in comparison. Even the purely reverse engineered
open source NVIDIA driver is out doing the proprietary one in terms of 2d.
Now I of course realise there is a big jump from that to capable 3d, but
considering (iirc) amd have developers working on the open source driver, I
see it as mainly a matter of time before it becomes a viable alternative.

On 18 Jun 2010 22:01, Bob Somers magicbob...@gmail.com wrote:

Katrina, I'm not giving lectures on computer graphics here. Google has
all the information you asked for. If you'd like, I can also recommend
some graphics textbooks which would clear things up. Also, saying a
Linux system running on a 100 MHz machine is comparable to Windows
running on a 2 GHz machine is a ridiculous overstatement. They are not
that radically different. If you're so convinced you can make the
words best software renderer, by all means go do it. I'm sure at the
very least you can wave your SIGGRAPH paper in our faces when you're
done.

Josh, I'm not sure you can call it better Linux support if their 3D
support is... well... really bad. They may have opened up their
hardware spec so that the free drivers can get rolling (I have tried
the new drivers in Fedora 13 and they are quite good so far), but the
free drivers are at least a year behind their Windows counterpart in
terms of supporting the full features of the cards. There is virtually
zero shader support in the free drivers at this point. nVidia's
drivers, on the other hand, may be proprietary, but at least you can
get decent 3D performance out of the machine on a current distro. The
proprietary ATI driver has decent support and performance, but it
won't run on anything newer than Fedora 11. (Sorry if I keep
referencing things in terms of Fedora versions, it's my distro of
choice.)

I'm all for free software, don't get me wrong. I would love for
nothing more than to have free alternative drivers for ATI and nVidia
cards, but if gaming is really going to be commercially viable on the
Linux desktop it's the performance that matters. No publisher is going
to bother trying to ship a game for Linux where the poor driver
support is going to cause them support headaches all day long.

--Bob





On Fri, Jun 18, 2010 at 4:38 AM, joshua simmons simmons...@gmail.com
wrote:
 Actually to be h...

 To unsubscribe, edit your list preferences, or view the list archives,
please visit:
 http://list...
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Source Engine 2!!!

2010-06-18 Thread Jonathan Murphy

Katrina, you might be interested in reading up on Real Time
Raytracing, which is an alternative to rasterisation (GPU) based
rendering and is/has been extensively researched and even implemented.

http://en.m.wikipedia.org/wiki/Ray_tracing_(graphics)
http://en.m.wikipedia.org/wiki/Quake_Wars:_Ray_Traced

At the moment though it seems GPUs are going to stay very mainstream.

On Saturday, June 19, 2010, joshua simmons simmons...@gmail.com wrote:
 Oh yeah I understand. There is only very rudmentry 3d support, in no way
 capable of supporting any game. My point was more on the radical rate at
 which they are evolving in comparison. Even the purely reverse engineered
 open source NVIDIA driver is out doing the proprietary one in terms of 2d.
 Now I of course realise there is a big jump from that to capable 3d, but
 considering (iirc) amd have developers working on the open source driver, I
 see it as mainly a matter of time before it becomes a viable alternative.

 On 18 Jun 2010 22:01, Bob Somers magicbob...@gmail.com wrote:

 Katrina, I'm not giving lectures on computer graphics here. Google has
 all the information you asked for. If you'd like, I can also recommend
 some graphics textbooks which would clear things up. Also, saying a
 Linux system running on a 100 MHz machine is comparable to Windows
 running on a 2 GHz machine is a ridiculous overstatement. They are not
 that radically different. If you're so convinced you can make the
 words best software renderer, by all means go do it. I'm sure at the
 very least you can wave your SIGGRAPH paper in our faces when you're
 done.

 Josh, I'm not sure you can call it better Linux support if their 3D
 support is... well... really bad. They may have opened up their
 hardware spec so that the free drivers can get rolling (I have tried
 the new drivers in Fedora 13 and they are quite good so far), but the
 free drivers are at least a year behind their Windows counterpart in
 terms of supporting the full features of the cards. There is virtually
 zero shader support in the free drivers at this point. nVidia's
 drivers, on the other hand, may be proprietary, but at least you can
 get decent 3D performance out of the machine on a current distro. The
 proprietary ATI driver has decent support and performance, but it
 won't run on anything newer than Fedora 11. (Sorry if I keep
 referencing things in terms of Fedora versions, it's my distro of
 choice.)

 I'm all for free software, don't get me wrong. I would love for
 nothing more than to have free alternative drivers for ATI and nVidia
 cards, but if gaming is really going to be commercially viable on the
 Linux desktop it's the performance that matters. No publisher is going
 to bother trying to ship a game for Linux where the poor driver
 support is going to cause them support headaches all day long.

 --Bob





 On Fri, Jun 18, 2010 at 4:38 AM, joshua simmons simmons...@gmail.com
 wrote:
 Actually to be h...

 To unsubscribe, edit your list preferences, or view the list archives,
 please visit:
 http://list...
 ___
 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] Source Engine 2!!!

2010-06-18 Thread Harry Pidcock

Ray traced polygon rendering is quite an expensive task on a CPU.

But real time point cloud rendering can be done on it quite well.

http://www.youtube.com/watch?v=Q-ATtrImCx4

Yes its a bit cheesy, but that's because Bruce Dell doesn't have a marketing 
budget.


This video is rendered in real time on a single core CPU, although it is 
only rendering at like 800x600,
if the algorithm had some parallelism, maybe even have it developed for 
GPUs/hardware specialization. Then it would certainly be
able to render large amounts of detail at a higher resolution.

Although it doesn't have any advanced shading, it is still quite interesting 
to see such a complex static environment drawn with a single CPU thread.

Of course there are huge computational and memory issues with bone 
animation, shading, transparency etc. So don't think you will see this in 
the next 5 - 10years.

--
From: Jonathan Murphy nuclearfri...@gmail.com
Sent: Saturday, June 19, 2010 12:31 AM
To: Discussion of Half-Life Programming hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Source Engine 2!!!

 Katrina, you might be interested in reading up on Real Time
 Raytracing, which is an alternative to rasterisation (GPU) based
 rendering and is/has been extensively researched and even implemented.

 http://en.m.wikipedia.org/wiki/Ray_tracing_(graphics)
 http://en.m.wikipedia.org/wiki/Quake_Wars:_Ray_Traced

 At the moment though it seems GPUs are going to stay very mainstream.

 On Saturday, June 19, 2010, joshua simmons simmons...@gmail.com wrote:
 Oh yeah I understand. There is only very rudmentry 3d support, in no way
 capable of supporting any game. My point was more on the radical rate at
 which they are evolving in comparison. Even the purely reverse engineered
 open source NVIDIA driver is out doing the proprietary one in terms of 
 2d.
 Now I of course realise there is a big jump from that to capable 3d, but
 considering (iirc) amd have developers working on the open source driver, 
 I
 see it as mainly a matter of time before it becomes a viable alternative.

 On 18 Jun 2010 22:01, Bob Somers magicbob...@gmail.com wrote:

 Katrina, I'm not giving lectures on computer graphics here. Google has
 all the information you asked for. If you'd like, I can also recommend
 some graphics textbooks which would clear things up. Also, saying a
 Linux system running on a 100 MHz machine is comparable to Windows
 running on a 2 GHz machine is a ridiculous overstatement. They are not
 that radically different. If you're so convinced you can make the
 words best software renderer, by all means go do it. I'm sure at the
 very least you can wave your SIGGRAPH paper in our faces when you're
 done.

 Josh, I'm not sure you can call it better Linux support if their 3D
 support is... well... really bad. They may have opened up their
 hardware spec so that the free drivers can get rolling (I have tried
 the new drivers in Fedora 13 and they are quite good so far), but the
 free drivers are at least a year behind their Windows counterpart in
 terms of supporting the full features of the cards. There is virtually
 zero shader support in the free drivers at this point. nVidia's
 drivers, on the other hand, may be proprietary, but at least you can
 get decent 3D performance out of the machine on a current distro. The
 proprietary ATI driver has decent support and performance, but it
 won't run on anything newer than Fedora 11. (Sorry if I keep
 referencing things in terms of Fedora versions, it's my distro of
 choice.)

 I'm all for free software, don't get me wrong. I would love for
 nothing more than to have free alternative drivers for ATI and nVidia
 cards, but if gaming is really going to be commercially viable on the
 Linux desktop it's the performance that matters. No publisher is going
 to bother trying to ship a game for Linux where the poor driver
 support is going to cause them support headaches all day long.

 --Bob





 On Fri, Jun 18, 2010 at 4:38 AM, joshua simmons simmons...@gmail.com
 wrote:
 Actually to be h...

 To unsubscribe, edit your list preferences, or view the list archives,
 please visit:
 http://list...
 ___
 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






 No virus found in this incoming message.
 Checked by AVG - www.avg.com
 Version: 9.0.829 / Virus Database: 271.1.1/2945 - Release Date: 06/18/10 
 04:35:00
 

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Source Engine 2!!!

2010-06-18 Thread Harry Jeffery

I believe John Carmack is hoping to use voxels in id Tech 6. That
engine's only 10 years away so who knows, this could be the future but
we wont find out until we get there.

On 18 June 2010 17:26, Harry Pidcock haz...@tpg.com.au wrote:
 Ray traced polygon rendering is quite an expensive task on a CPU.

 But real time point cloud rendering can be done on it quite well.

 http://www.youtube.com/watch?v=Q-ATtrImCx4

 Yes its a bit cheesy, but that's because Bruce Dell doesn't have a marketing
 budget.


 This video is rendered in real time on a single core CPU, although it is
 only rendering at like 800x600,
 if the algorithm had some parallelism, maybe even have it developed for
 GPUs/hardware specialization. Then it would certainly be
 able to render large amounts of detail at a higher resolution.

 Although it doesn't have any advanced shading, it is still quite interesting
 to see such a complex static environment drawn with a single CPU thread.

 Of course there are huge computational and memory issues with bone
 animation, shading, transparency etc. So don't think you will see this in
 the next 5 - 10years.

 --
 From: Jonathan Murphy nuclearfri...@gmail.com
 Sent: Saturday, June 19, 2010 12:31 AM
 To: Discussion of Half-Life Programming hlcoders@list.valvesoftware.com
 Subject: Re: [hlcoders] Source Engine 2!!!

 Katrina, you might be interested in reading up on Real Time
 Raytracing, which is an alternative to rasterisation (GPU) based
 rendering and is/has been extensively researched and even implemented.

 http://en.m.wikipedia.org/wiki/Ray_tracing_(graphics)
 http://en.m.wikipedia.org/wiki/Quake_Wars:_Ray_Traced

 At the moment though it seems GPUs are going to stay very mainstream.

 On Saturday, June 19, 2010, joshua simmons simmons...@gmail.com wrote:
 Oh yeah I understand. There is only very rudmentry 3d support, in no way
 capable of supporting any game. My point was more on the radical rate at
 which they are evolving in comparison. Even the purely reverse engineered
 open source NVIDIA driver is out doing the proprietary one in terms of
 2d.
 Now I of course realise there is a big jump from that to capable 3d, but
 considering (iirc) amd have developers working on the open source driver,
 I
 see it as mainly a matter of time before it becomes a viable alternative.

 On 18 Jun 2010 22:01, Bob Somers magicbob...@gmail.com wrote:

 Katrina, I'm not giving lectures on computer graphics here. Google has
 all the information you asked for. If you'd like, I can also recommend
 some graphics textbooks which would clear things up. Also, saying a
 Linux system running on a 100 MHz machine is comparable to Windows
 running on a 2 GHz machine is a ridiculous overstatement. They are not
 that radically different. If you're so convinced you can make the
 words best software renderer, by all means go do it. I'm sure at the
 very least you can wave your SIGGRAPH paper in our faces when you're
 done.

 Josh, I'm not sure you can call it better Linux support if their 3D
 support is... well... really bad. They may have opened up their
 hardware spec so that the free drivers can get rolling (I have tried
 the new drivers in Fedora 13 and they are quite good so far), but the
 free drivers are at least a year behind their Windows counterpart in
 terms of supporting the full features of the cards. There is virtually
 zero shader support in the free drivers at this point. nVidia's
 drivers, on the other hand, may be proprietary, but at least you can
 get decent 3D performance out of the machine on a current distro. The
 proprietary ATI driver has decent support and performance, but it
 won't run on anything newer than Fedora 11. (Sorry if I keep
 referencing things in terms of Fedora versions, it's my distro of
 choice.)

 I'm all for free software, don't get me wrong. I would love for
 nothing more than to have free alternative drivers for ATI and nVidia
 cards, but if gaming is really going to be commercially viable on the
 Linux desktop it's the performance that matters. No publisher is going
 to bother trying to ship a game for Linux where the poor driver
 support is going to cause them support headaches all day long.

 --Bob





 On Fri, Jun 18, 2010 at 4:38 AM, joshua simmons simmons...@gmail.com
 wrote:
 Actually to be h...

 To unsubscribe, edit your list preferences, or view the list archives,
 please visit:
 http://list...
 ___
 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






 No virus found in this incoming message.
 Checked by AVG - www.avg.com
 Version: 9.0.829 / Virus Database: 271.1.1/2945 - Release Date: 06/18/10

Re: [hlcoders] Source Engine 2!!!

2010-06-18 Thread Joel R.

Voxels were the first thing used in 3d graphics, they are pretty horrible
compared to today's standards.

On Fri, Jun 18, 2010 at 12:42 PM, Harry Jeffery
harry101jeff...@googlemail.com wrote:

I believe John Carmack is hoping to use voxels in id Tech 6. That
engine's only 10 years away so who knows, this could be the future but
we wont find out until we get there.

On 18 June 2010 17:26, Harry Pidcock haz...@tpg.com.au wrote:
Ray traced polygon rendering is quite an expensive task on a CPU.

But real time point cloud rendering can be done on it quite well.

http://www.youtube.com/watch?v=Q-ATtrImCx4

Yes its a bit cheesy, but that's because Bruce Dell doesn't have a
marketing
budget.

Although it doesn't have any advanced shading, it is still quite
interesting
to see such a complex static environment drawn with a single CPU thread.

Of course there are huge computational and memory issues with bone
animation, shading, transparency etc. So don't think you will see this in
the next 5 - 10years.

Katrina, you might be interested in reading up on Real Time
Raytracing, which is an alternative to rasterisation (GPU) based
rendering and is/has been extensively researched and even implemented.

http://en.m.wikipedia.org/wiki/Ray_tracing_(graphics)http://en.m.wikipedia.org/wiki/Ray_tracing_%28graphics%29
http://en.m.wikipedia.org/wiki/Quake_Wars:_Ray_Traced

At the moment though it seems GPUs are going to stay very mainstream.

On Saturday, June 19, 2010, joshua simmons simmons...@gmail.com
wrote:
Oh yeah I understand. There is only very rudmentry 3d support, in no
way
capable of supporting any game. My point was more on the radical rate
at
which they are evolving in comparison. Even the purely reverse
engineered
open source NVIDIA driver is out doing the proprietary one in terms of
2d.
Now I of course realise there is a big jump from that to capable 3d,
but
considering (iirc) amd have developers working on the open source
driver,
I
see it as mainly a matter of time before it becomes a viable
alternative.

On 18 Jun 2010 22:01, Bob Somers magicbob...@gmail.com wrote:

Katrina, I'm not giving lectures on computer graphics here. Google has
all the information you asked for. If you'd like, I can also recommend
some graphics textbooks which would clear things up. Also, saying a
Linux system running on a 100 MHz machine is comparable to Windows
running on a 2 GHz machine is a ridiculous overstatement. They are not
that radically different. If you're so convinced you can make the
words best software renderer, by all means go do it. I'm sure at the
very least you can wave your SIGGRAPH paper in our faces when you're
done.

Josh, I'm not sure you can call it better Linux support if their 3D
support is... well... really bad. They may have opened up their
hardware spec so that the free drivers can get rolling (I have tried
the new drivers in Fedora 13 and they are quite good so far), but the
free drivers are at least a year behind their Windows counterpart in
terms of supporting the full features of the cards. There is virtually
zero shader support in the free drivers at this point. nVidia's
drivers, on the other hand, may be proprietary, but at least you can
get decent 3D performance out of the machine on a current distro. The
proprietary ATI driver has decent support and performance, but it
won't run on anything newer than Fedora 11. (Sorry if I keep
referencing things in terms of Fedora versions, it's my distro of
choice.)

I'm all for free software, don't get me wrong. I would love for
nothing more than to have free alternative drivers for ATI and nVidia
cards, but if gaming is really going to be commercially viable on the
Linux desktop it's the performance that matters. No publisher is going
to bother trying to ship a game for Linux where the poor driver
support is going to cause them support headaches all day long.

--Bob

On Fri, Jun 18, 2010 at 4:38 AM, joshua simmons simmons...@gmail.com
wrote:
Actually to be h...

To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list...
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman

Re: [hlcoders] Source Engine 2!!!

2010-06-18 Thread Marek Sieradzki

On Fri, Jun 18, 2010 at 8:30 PM, Joel R. joelru...@gmail.com wrote:
 Voxels were the first thing used in 3d graphics, they are pretty horrible
 compared to today's standards.

You're retarded.

Sorry, couldn't help myself, whole this thread is written mostly by
people who don't know what they're talking about.

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Source Engine 2!!!

That's the plan. He's hoping to do something similar to id tech 5's
megatexture technology for geometry. It's called sparse voxel octree
technology

Basically(from what I understand), the idea is to make the voxels very
very small to allow for high fidelity, but to only load the depth of
the octree that could be seen at the current resolution, therefore
allowing for incredibly detailed models, that only stream the small
details if they could be seen at the current resolution. This is a big
step up from LOD where the programmer basically has to guess where to
swap the models out (and they need to be separate models)

On 18 June 2010 18:42, Harry Jeffery harry101jeff...@googlemail.com wrote:
 I believe John Carmack is hoping to use voxels in id Tech 6. That
 engine's only 10 years away so who knows, this could be the future but
 we wont find out until we get there.

 On 18 June 2010 17:26, Harry Pidcock haz...@tpg.com.au wrote:
 Ray traced polygon rendering is quite an expensive task on a CPU.

 But real time point cloud rendering can be done on it quite well.

 http://www.youtube.com/watch?v=Q-ATtrImCx4

 Yes its a bit cheesy, but that's because Bruce Dell doesn't have a marketing
 budget.


 This video is rendered in real time on a single core CPU, although it is
 only rendering at like 800x600,
 if the algorithm had some parallelism, maybe even have it developed for
 GPUs/hardware specialization. Then it would certainly be
 able to render large amounts of detail at a higher resolution.

 Although it doesn't have any advanced shading, it is still quite interesting
 to see such a complex static environment drawn with a single CPU thread.

 Of course there are huge computational and memory issues with bone
 animation, shading, transparency etc. So don't think you will see this in
 the next 5 - 10years.

 --
 From: Jonathan Murphy nuclearfri...@gmail.com
 Sent: Saturday, June 19, 2010 12:31 AM
 To: Discussion of Half-Life Programming hlcoders@list.valvesoftware.com
 Subject: Re: [hlcoders] Source Engine 2!!!

 Katrina, you might be interested in reading up on Real Time
 Raytracing, which is an alternative to rasterisation (GPU) based
 rendering and is/has been extensively researched and even implemented.

 http://en.m.wikipedia.org/wiki/Ray_tracing_(graphics)
 http://en.m.wikipedia.org/wiki/Quake_Wars:_Ray_Traced

 At the moment though it seems GPUs are going to stay very mainstream.

 On Saturday, June 19, 2010, joshua simmons simmons...@gmail.com wrote:
 Oh yeah I understand. There is only very rudmentry 3d support, in no way
 capable of supporting any game. My point was more on the radical rate at
 which they are evolving in comparison. Even the purely reverse engineered
 open source NVIDIA driver is out doing the proprietary one in terms of
 2d.
 Now I of course realise there is a big jump from that to capable 3d, but
 considering (iirc) amd have developers working on the open source driver,
 I
 see it as mainly a matter of time before it becomes a viable alternative.

 On 18 Jun 2010 22:01, Bob Somers magicbob...@gmail.com wrote:

 Katrina, I'm not giving lectures on computer graphics here. Google has
 all the information you asked for. If you'd like, I can also recommend
 some graphics textbooks which would clear things up. Also, saying a
 Linux system running on a 100 MHz machine is comparable to Windows
 running on a 2 GHz machine is a ridiculous overstatement. They are not
 that radically different. If you're so convinced you can make the
 words best software renderer, by all means go do it. I'm sure at the
 very least you can wave your SIGGRAPH paper in our faces when you're
 done.

 Josh, I'm not sure you can call it better Linux support if their 3D
 support is... well... really bad. They may have opened up their
 hardware spec so that the free drivers can get rolling (I have tried
 the new drivers in Fedora 13 and they are quite good so far), but the
 free drivers are at least a year behind their Windows counterpart in
 terms of supporting the full features of the cards. There is virtually
 zero shader support in the free drivers at this point. nVidia's
 drivers, on the other hand, may be proprietary, but at least you can
 get decent 3D performance out of the machine on a current distro. The
 proprietary ATI driver has decent support and performance, but it
 won't run on anything newer than Fedora 11. (Sorry if I keep
 referencing things in terms of Fedora versions, it's my distro of
 choice.)

 I'm all for free software, don't get me wrong. I would love for
 nothing more than to have free alternative drivers for ATI and nVidia
 cards, but if gaming is really going to be commercially viable on the
 Linux desktop it's the performance that matters. No publisher is going
 to bother trying to ship a game for Linux where the poor driver
 support is going to cause them support headaches all day long.

 --Bob





 On Fri, Jun 18, 2010 at 4:38 AM, joshua

Re: [hlcoders] Source Engine 2!!!

2010-06-18 Thread Harry Jeffery

Cant wait to see the minimum memory requirements. 24GB's of ram anyone?

On 18 June 2010 20:06, Adam Buckland adamjbuckl...@gmail.com wrote:
 That's the plan. He's hoping to do something similar to id tech 5's
 megatexture technology for geometry. It's called sparse voxel octree
 technology

 Basically(from what I understand), the idea is to make the voxels very
 very small to allow for high fidelity, but to only load the depth of
 the octree that could be seen at the current resolution, therefore
 allowing for incredibly detailed models, that only stream the small
 details if they could be seen at the current resolution. This is a big
 step up from LOD where the programmer basically has to guess where to
 swap the models out (and they need to be separate models)

 On 18 June 2010 18:42, Harry Jeffery harry101jeff...@googlemail.com wrote:
 I believe John Carmack is hoping to use voxels in id Tech 6. That
 engine's only 10 years away so who knows, this could be the future but
 we wont find out until we get there.

 On 18 June 2010 17:26, Harry Pidcock haz...@tpg.com.au wrote:
 Ray traced polygon rendering is quite an expensive task on a CPU.

 But real time point cloud rendering can be done on it quite well.

 http://www.youtube.com/watch?v=Q-ATtrImCx4

 Yes its a bit cheesy, but that's because Bruce Dell doesn't have a marketing
 budget.


 This video is rendered in real time on a single core CPU, although it is
 only rendering at like 800x600,
 if the algorithm had some parallelism, maybe even have it developed for
 GPUs/hardware specialization. Then it would certainly be
 able to render large amounts of detail at a higher resolution.

 Although it doesn't have any advanced shading, it is still quite interesting
 to see such a complex static environment drawn with a single CPU thread.

 Of course there are huge computational and memory issues with bone
 animation, shading, transparency etc. So don't think you will see this in
 the next 5 - 10years.

 --
 From: Jonathan Murphy nuclearfri...@gmail.com
 Sent: Saturday, June 19, 2010 12:31 AM
 To: Discussion of Half-Life Programming hlcoders@list.valvesoftware.com
 Subject: Re: [hlcoders] Source Engine 2!!!

 Katrina, you might be interested in reading up on Real Time
 Raytracing, which is an alternative to rasterisation (GPU) based
 rendering and is/has been extensively researched and even implemented.

 http://en.m.wikipedia.org/wiki/Ray_tracing_(graphics)
 http://en.m.wikipedia.org/wiki/Quake_Wars:_Ray_Traced

 At the moment though it seems GPUs are going to stay very mainstream.

 On Saturday, June 19, 2010, joshua simmons simmons...@gmail.com wrote:
 Oh yeah I understand. There is only very rudmentry 3d support, in no way
 capable of supporting any game. My point was more on the radical rate at
 which they are evolving in comparison. Even the purely reverse engineered
 open source NVIDIA driver is out doing the proprietary one in terms of
 2d.
 Now I of course realise there is a big jump from that to capable 3d, but
 considering (iirc) amd have developers working on the open source driver,
 I
 see it as mainly a matter of time before it becomes a viable alternative.

 On 18 Jun 2010 22:01, Bob Somers magicbob...@gmail.com wrote:

 Katrina, I'm not giving lectures on computer graphics here. Google has
 all the information you asked for. If you'd like, I can also recommend
 some graphics textbooks which would clear things up. Also, saying a
 Linux system running on a 100 MHz machine is comparable to Windows
 running on a 2 GHz machine is a ridiculous overstatement. They are not
 that radically different. If you're so convinced you can make the
 words best software renderer, by all means go do it. I'm sure at the
 very least you can wave your SIGGRAPH paper in our faces when you're
 done.

 Josh, I'm not sure you can call it better Linux support if their 3D
 support is... well... really bad. They may have opened up their
 hardware spec so that the free drivers can get rolling (I have tried
 the new drivers in Fedora 13 and they are quite good so far), but the
 free drivers are at least a year behind their Windows counterpart in
 terms of supporting the full features of the cards. There is virtually
 zero shader support in the free drivers at this point. nVidia's
 drivers, on the other hand, may be proprietary, but at least you can
 get decent 3D performance out of the machine on a current distro. The
 proprietary ATI driver has decent support and performance, but it
 won't run on anything newer than Fedora 11. (Sorry if I keep
 referencing things in terms of Fedora versions, it's my distro of
 choice.)

 I'm all for free software, don't get me wrong. I would love for
 nothing more than to have free alternative drivers for ATI and nVidia
 cards, but if gaming is really going to be commercially viable on the
 Linux desktop it's the performance that matters. No publisher is going
 to bother trying to ship a game

Re: [hlcoders] Source Engine 2!!!

2010-06-18 Thread Joel R.

Please enlighten me then, Marek. Voxels can be better the smaller they are,
and in a few years will be better suited when we have more powerful
computers. Many are still struggling to even play TF2 with their current
machines. So yes, I'm retarded because I thought ahead of your small mind.

On Fri, Jun 18, 2010 at 2:06 PM, Adam Buckland adamjbuckl...@gmail.comwrote:

That's the plan. He's hoping to do something similar to id tech 5's
megatexture technology for geometry. It's called sparse voxel octree
technology

On 18 June 2010 17:26, Harry Pidcock haz...@tpg.com.au wrote:
Ray traced polygon rendering is quite an expensive task on a CPU.

But real time point cloud rendering can be done on it quite well.

http://www.youtube.com/watch?v=Q-ATtrImCx4

Yes its a bit cheesy, but that's because Bruce Dell doesn't have a
marketing
budget.

Although it doesn't have any advanced shading, it is still quite
interesting
to see such a complex static environment drawn with a single CPU thread.

Of course there are huge computational and memory issues with bone
animation, shading, transparency etc. So don't think you will see this
in
the next 5 - 10years.

Katrina, you might be interested in reading up on Real Time
Raytracing, which is an alternative to rasterisation (GPU) based
rendering and is/has been extensively researched and even implemented.

http://en.m.wikipedia.org/wiki/Ray_tracing_(graphics)http://en.m.wikipedia.org/wiki/Ray_tracing_%28graphics%29
http://en.m.wikipedia.org/wiki/Quake_Wars:_Ray_Traced

At the moment though it seems GPUs are going to stay very mainstream.

On 18 Jun 2010 22:01, Bob Somers magicbob...@gmail.com wrote:

Re: [hlcoders] Source Engine 2!!!

Hey guys, let`s not start with any flames please, the discussion was nice
and long without anyone making any type of insults to another ones :).

Does anyone remember when Carmack said it was going to be release?
Because in my opinion this possibility is going to require a hell of a
computer to render even simple scenes, so i don`t know when this type of
rendering would be capable to be used in a game.

2010/6/18 Joel R. joelru...@gmail.com

Please enlighten me then, Marek. Voxels can be better the smaller they
are,
and in a few years will be better suited when we have more powerful
computers. Many are still struggling to even play TF2 with their current
machines. So yes, I'm retarded because I thought ahead of your small mind.

On Fri, Jun 18, 2010 at 2:06 PM, Adam Buckland adamjbuckl...@gmail.com
wrote:

That's the plan. He's hoping to do something similar to id tech 5's
megatexture technology for geometry. It's called sparse voxel octree
technology

On 18 June 2010 17:26, Harry Pidcock haz...@tpg.com.au wrote:
Ray traced polygon rendering is quite an expensive task on a CPU.

But real time point cloud rendering can be done on it quite well.

http://www.youtube.com/watch?v=Q-ATtrImCx4

Yes its a bit cheesy, but that's because Bruce Dell doesn't have a
marketing
budget.

This video is rendered in real time on a single core CPU, although it
is
only rendering at like 800x600,
if the algorithm had some parallelism, maybe even have it developed
for
GPUs/hardware specialization. Then it would certainly be
able to render large amounts of detail at a higher resolution.

Although it doesn't have any advanced shading, it is still quite
interesting
to see such a complex static environment drawn with a single CPU
thread.

Of course there are huge computational and memory issues with bone
animation, shading, transparency etc. So don't think you will see this
in
the next 5 - 10years.

Katrina, you might be interested in reading up on Real Time
Raytracing, which is an alternative to rasterisation (GPU) based
rendering and is/has been extensively researched and even
implemented.

http://en.m.wikipedia.org/wiki/Ray_tracing_(graphics)http://en.m.wikipedia.org/wiki/Ray_tracing_%28graphics%29
http://en.m.wikipedia.org/wiki/Ray_tracing_%28graphics%29
http://en.m.wikipedia.org/wiki/Quake_Wars:_Ray_Traced

At the moment though it seems GPUs are going to stay very mainstream.

On Saturday, June 19, 2010, joshua simmons simmons...@gmail.com
wrote:
Oh yeah I understand. There is only very rudmentry 3d support, in no
way
capable of supporting any game. My point was more on the radical
rate
at
which they are evolving in comparison. Even the purely reverse
engineered
open source NVIDIA driver is out doing the proprietary one in terms
of
2d.
Now I of course realise there is a big jump from that to capable 3d,
but
considering (iirc) amd have developers working on the open source
driver,
I
see it as mainly a matter of time before it becomes a viable
alternative.

On 18 Jun 2010 22:01, Bob Somers magicbob...@gmail.com wrote:

Katrina, I'm not giving lectures on computer graphics here. Google
has
all the information you asked for. If you'd like, I can also
recommend
some graphics textbooks which would clear things up. Also, saying a
Linux system running on a 100 MHz machine is comparable to Windows
running on a 2 GHz machine is a ridiculous overstatement. They are
not
that radically different. If you're so convinced you can make the
words best software renderer, by all means go do it. I'm sure at the
very least you can wave your SIGGRAPH paper in our faces when you're
done.

Josh, I'm not sure you can call it better Linux support if their 3D
support is... well... really bad. They may have opened up their
hardware spec so

Re: [hlcoders] Source Engine 2!!!

2010-06-18 Thread Ryan Sheffer

That looks impressive, I wonder how you model objects.

~Ryan

On Jun 18, 2010, at 9:26 AM, Harry Pidcock haz...@tpg.com.au wrote:

 Ray traced polygon rendering is quite an expensive task on a CPU.

 But real time point cloud rendering can be done on it quite well.

 http://www.youtube.com/watch?v=Q-ATtrImCx4

 Yes its a bit cheesy, but that's because Bruce Dell doesn't have a  
 marketing
 budget.


 This video is rendered in real time on a single core CPU, although  
 it is
 only rendering at like 800x600,
 if the algorithm had some parallelism, maybe even have it developed  
 for
 GPUs/hardware specialization. Then it would certainly be
 able to render large amounts of detail at a higher resolution.

 Although it doesn't have any advanced shading, it is still quite  
 interesting
 to see such a complex static environment drawn with a single CPU  
 thread.

 Of course there are huge computational and memory issues with bone
 animation, shading, transparency etc. So don't think you will see  
 this in
 the next 5 - 10years.

 --
 From: Jonathan Murphy nuclearfri...@gmail.com
 Sent: Saturday, June 19, 2010 12:31 AM
 To: Discussion of Half-Life Programming hlcoders@list.valvesoftware.com 
 
 Subject: Re: [hlcoders] Source Engine 2!!!

 Katrina, you might be interested in reading up on Real Time
 Raytracing, which is an alternative to rasterisation (GPU) based
 rendering and is/has been extensively researched and even  
 implemented.

 http://en.m.wikipedia.org/wiki/Ray_tracing_(graphics)
 http://en.m.wikipedia.org/wiki/Quake_Wars:_Ray_Traced

 At the moment though it seems GPUs are going to stay very mainstream.

 On Saturday, June 19, 2010, joshua simmons simmons...@gmail.com  
 wrote:
 Oh yeah I understand. There is only very rudmentry 3d support, in  
 no way
 capable of supporting any game. My point was more on the radical  
 rate at
 which they are evolving in comparison. Even the purely reverse  
 engineered
 open source NVIDIA driver is out doing the proprietary one in  
 terms of
 2d.
 Now I of course realise there is a big jump from that to capable  
 3d, but
 considering (iirc) amd have developers working on the open source  
 driver,
 I
 see it as mainly a matter of time before it becomes a viable  
 alternative.

 On 18 Jun 2010 22:01, Bob Somers magicbob...@gmail.com wrote:

 Katrina, I'm not giving lectures on computer graphics here. Google  
 has
 all the information you asked for. If you'd like, I can also  
 recommend
 some graphics textbooks which would clear things up. Also, saying a
 Linux system running on a 100 MHz machine is comparable to Windows
 running on a 2 GHz machine is a ridiculous overstatement. They are  
 not
 that radically different. If you're so convinced you can make the
 words best software renderer, by all means go do it. I'm sure at the
 very least you can wave your SIGGRAPH paper in our faces when you're
 done.

 Josh, I'm not sure you can call it better Linux support if their 3D
 support is... well... really bad. They may have opened up their
 hardware spec so that the free drivers can get rolling (I have tried
 the new drivers in Fedora 13 and they are quite good so far), but  
 the
 free drivers are at least a year behind their Windows counterpart in
 terms of supporting the full features of the cards. There is  
 virtually
 zero shader support in the free drivers at this point. nVidia's
 drivers, on the other hand, may be proprietary, but at least you can
 get decent 3D performance out of the machine on a current distro.  
 The
 proprietary ATI driver has decent support and performance, but it
 won't run on anything newer than Fedora 11. (Sorry if I keep
 referencing things in terms of Fedora versions, it's my distro of
 choice.)

 I'm all for free software, don't get me wrong. I would love for
 nothing more than to have free alternative drivers for ATI and  
 nVidia
 cards, but if gaming is really going to be commercially viable on  
 the
 Linux desktop it's the performance that matters. No publisher is  
 going
 to bother trying to ship a game for Linux where the poor driver
 support is going to cause them support headaches all day long.

 --Bob





 On Fri, Jun 18, 2010 at 4:38 AM, joshua simmons simmons...@gmail.com 
 
 wrote:
 Actually to be h...

 To unsubscribe, edit your list preferences, or view the list  
 archives,
 please visit:
 http://list...
 ___
 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






 No virus found in this incoming message.
 Checked by AVG - www.avg.com
 Version: 9.0.829 / Virus Database: 271.1.1/2945 - Release Date:  
 06/18/10
 04:35:00

Re: [hlcoders] Source Engine 2!!!

2010-06-18 Thread Justin Krenz

I believe he was referring to your claim about voxels being the first
thing used in 3d. Vector graphics (lines/edges) were the first things
used in 3d with games like Battlezone and Star Wars at the arcades..

If you think voxels are so great, what did you think about Kevin
Silverman's voxlap engine? http://voxelstein3d.sourceforge.net/

On Fri, Jun 18, 2010 at 2:23 PM, Joel R. joelru...@gmail.com wrote:
Please enlighten me then, Marek. Voxels can be better the smaller they are,
and in a few years will be better suited when we have more powerful
computers. Many are still struggling to even play TF2 with their current
machines. So yes, I'm retarded because I thought ahead of your small mind.

On Fri, Jun 18, 2010 at 2:06 PM, Adam Buckland adamjbuckl...@gmail.comwrote:

That's the plan. He's hoping to do something similar to id tech 5's
megatexture technology for geometry. It's called sparse voxel octree
technology

On 18 June 2010 17:26, Harry Pidcock haz...@tpg.com.au wrote:
Ray traced polygon rendering is quite an expensive task on a CPU.

But real time point cloud rendering can be done on it quite well.

http://www.youtube.com/watch?v=Q-ATtrImCx4

Yes its a bit cheesy, but that's because Bruce Dell doesn't have a
marketing
budget.

Although it doesn't have any advanced shading, it is still quite
interesting
to see such a complex static environment drawn with a single CPU thread.

Of course there are huge computational and memory issues with bone
animation, shading, transparency etc. So don't think you will see this
in
the next 5 - 10years.

Katrina, you might be interested in reading up on Real Time
Raytracing, which is an alternative to rasterisation (GPU) based
rendering and is/has been extensively researched and even implemented.

http://en.m.wikipedia.org/wiki/Ray_tracing_(graphics)http://en.m.wikipedia.org/wiki/Ray_tracing_%28graphics%29
http://en.m.wikipedia.org/wiki/Quake_Wars:_Ray_Traced

At the moment though it seems GPUs are going to stay very mainstream.

On 18 Jun 2010 22:01, Bob Somers magicbob...@gmail.com wrote:

Re: [hlcoders] Source Engine 2!!!

id Tech 5 with MegaTexture will be released next year and will run on
PC, Mac, Xbox 360 PS3

id Tech 6 will be designed for next-gen consoles, so who knows when
it'll be released!

On 18 June 2010 21:48, Justin Krenz kre...@gmail.com wrote:
I believe he was referring to your claim about voxels being the first
thing used in 3d. Vector graphics (lines/edges) were the first things
used in 3d with games like Battlezone and Star Wars at the arcades..

If you think voxels are so great, what did you think about Kevin
Silverman's voxlap engine? http://voxelstein3d.sourceforge.net/

On Fri, Jun 18, 2010 at 2:06 PM, Adam Buckland
adamjbuckl...@gmail.comwrote:

That's the plan. He's hoping to do something similar to id tech 5's
megatexture technology for geometry. It's called sparse voxel octree
technology

On 18 June 2010 17:26, Harry Pidcock haz...@tpg.com.au wrote:
Ray traced polygon rendering is quite an expensive task on a CPU.

But real time point cloud rendering can be done on it quite well.

http://www.youtube.com/watch?v=Q-ATtrImCx4

Yes its a bit cheesy, but that's because Bruce Dell doesn't have a
marketing
budget.

Although it doesn't have any advanced shading, it is still quite
interesting
to see such a complex static environment drawn with a single CPU thread.

Of course there are huge computational and memory issues with bone
animation, shading, transparency etc. So don't think you will see this
in
the next 5 - 10years.

Katrina, you might be interested in reading up on Real Time
Raytracing, which is an alternative to rasterisation (GPU) based
rendering and is/has been extensively researched and even implemented.

http://en.m.wikipedia.org/wiki/Ray_tracing_(graphics)http://en.m.wikipedia.org/wiki/Ray_tracing_%28graphics%29
http://en.m.wikipedia.org/wiki/Quake_Wars:_Ray_Traced

At the moment though it seems GPUs are going to stay very mainstream.

On 18 Jun 2010 22:01, Bob Somers magicbob...@gmail.com wrote:

Josh, I'm not sure you can call it better Linux support if their 3D
support is... well... really bad

Re: [hlcoders] Source Engine 2!!!

2010-06-18 Thread Allan Button

We are all missing a huge part of the picture here.

Yes, driver support is bad in Linux. We can all agree on that. But there are 
people right now, I mean right this very second! Playing TF2 in Wine/Crossover. 
Meaning they already have done the work to get the drivers running on Linux. 
Would it not be better to support these players with a native build?

I am a programmer, I have done coding for Linux, Windows and Mac. I think they 
should port over 1 game to Linux, see if anybody even uses it. Say HL2 for 
example.

They have Linux bins of SRCDS, so they already know how to bring an engine 
over, and they understand fully Linux networking and file system.

My 2 cents. If nobody is interested in them, I'll take them back. Economic 
recession you know.

Allan

-Original Message-
From: hlcoders-boun...@list.valvesoftware.com 
[mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Justin Krenz
Sent: Friday, June 18, 2010 4:49 PM
To: Discussion of Half-Life Programming
Subject: Re: [hlcoders] Source Engine 2!!!

I believe he was referring to your claim about voxels being the first thing 
used in 3d.  Vector graphics (lines/edges) were the first things used in 3d 
with games like Battlezone and Star Wars at the arcades..

If you think voxels are so great, what did you think about Kevin Silverman's 
voxlap engine?  http://voxelstein3d.sourceforge.net/

On Fri, Jun 18, 2010 at 2:23 PM, Joel R. joelru...@gmail.com wrote:
 Please enlighten me then, Marek.  Voxels can be better the smaller 
 they are, and in a few years will be better suited when we have more 
 powerful computers.  Many are still struggling to even play TF2 with 
 their current machines.  So yes, I'm retarded because I thought ahead of your 
 small mind.

 On Fri, Jun 18, 2010 at 2:06 PM, Adam Buckland adamjbuckl...@gmail.comwrote:

 That's the plan. He's hoping to do something similar to id tech 5's 
 megatexture technology for geometry. It's called sparse voxel octree 
 technology

 Basically(from what I understand), the idea is to make the voxels 
 very very small to allow for high fidelity, but to only load the 
 depth of the octree that could be seen at the current resolution, 
 therefore allowing for incredibly detailed models, that only stream 
 the small details if they could be seen at the current resolution. 
 This is a big step up from LOD where the programmer basically has to 
 guess where to swap the models out (and they need to be separate 
 models)

 On 18 June 2010 18:42, Harry Jeffery harry101jeff...@googlemail.com
 wrote:
  I believe John Carmack is hoping to use voxels in id Tech 6. That 
  engine's only 10 years away so who knows, this could be the future 
  but we wont find out until we get there.
 
  On 18 June 2010 17:26, Harry Pidcock haz...@tpg.com.au wrote:
  Ray traced polygon rendering is quite an expensive task on a CPU.
 
  But real time point cloud rendering can be done on it quite well.
 
  http://www.youtube.com/watch?v=Q-ATtrImCx4
 
  Yes its a bit cheesy, but that's because Bruce Dell doesn't have a
 marketing
  budget.
 
 
  This video is rendered in real time on a single core CPU, although 
  it is only rendering at like 800x600, if the algorithm had some 
  parallelism, maybe even have it developed for GPUs/hardware 
  specialization. Then it would certainly be able to render large 
  amounts of detail at a higher resolution.
 
  Although it doesn't have any advanced shading, it is still quite
 interesting
  to see such a complex static environment drawn with a single CPU thread.
 
  Of course there are huge computational and memory issues with bone 
  animation, shading, transparency etc. So don't think you will see 
  this
 in
  the next 5 - 10years.
 
  --
  From: Jonathan Murphy nuclearfri...@gmail.com
  Sent: Saturday, June 19, 2010 12:31 AM
  To: Discussion of Half-Life Programming 
 hlcoders@list.valvesoftware.com
  Subject: Re: [hlcoders] Source Engine 2!!!
 
  Katrina, you might be interested in reading up on Real Time 
  Raytracing, which is an alternative to rasterisation (GPU) based 
  rendering and is/has been extensively researched and even implemented.
 
  http://en.m.wikipedia.org/wiki/Ray_tracing_(graphics)http://en.m
  .wikipedia.org/wiki/Ray_tracing_%28graphics%29
  http://en.m.wikipedia.org/wiki/Quake_Wars:_Ray_Traced
 
  At the moment though it seems GPUs are going to stay very mainstream.
 
  On Saturday, June 19, 2010, joshua simmons simmons...@gmail.com
 wrote:
  Oh yeah I understand. There is only very rudmentry 3d support, 
  in no
 way
  capable of supporting any game. My point was more on the radical 
  rate
 at
  which they are evolving in comparison. Even the purely reverse
 engineered
  open source NVIDIA driver is out doing the proprietary one in 
  terms of 2d.
  Now I of course realise there is a big jump from that to capable 
  3d,
 but
  considering (iirc) amd have developers working on the open 
  source

Re: [hlcoders] Source Engine 2!!!

2010-06-18 Thread Harry Jeffery

Platforms a source engine game (ported by valve themselves) run on:
Windows, Mac OS X, Xbox 360, Playstation 3.

I can only see one thing missing; linux.

On 18 June 2010 22:13, Allan Button abut...@netaccess.ca wrote:
 We are all missing a huge part of the picture here.

 Yes, driver support is bad in Linux. We can all agree on that. But there are 
 people right now, I mean right this very second! Playing TF2 in 
 Wine/Crossover. Meaning they already have done the work to get the drivers 
 running on Linux. Would it not be better to support these players with a 
 native build?

 I am a programmer, I have done coding for Linux, Windows and Mac. I think 
 they should port over 1 game to Linux, see if anybody even uses it. Say HL2 
 for example.

 They have Linux bins of SRCDS, so they already know how to bring an engine 
 over, and they understand fully Linux networking and file system.

 My 2 cents. If nobody is interested in them, I'll take them back. Economic 
 recession you know.

 Allan

 -Original Message-
 From: hlcoders-boun...@list.valvesoftware.com 
 [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Justin Krenz
 Sent: Friday, June 18, 2010 4:49 PM
 To: Discussion of Half-Life Programming
 Subject: Re: [hlcoders] Source Engine 2!!!

 I believe he was referring to your claim about voxels being the first thing 
 used in 3d.  Vector graphics (lines/edges) were the first things used in 3d 
 with games like Battlezone and Star Wars at the arcades..

 If you think voxels are so great, what did you think about Kevin Silverman's 
 voxlap engine?  http://voxelstein3d.sourceforge.net/

 On Fri, Jun 18, 2010 at 2:23 PM, Joel R. joelru...@gmail.com wrote:
 Please enlighten me then, Marek.  Voxels can be better the smaller
 they are, and in a few years will be better suited when we have more
 powerful computers.  Many are still struggling to even play TF2 with
 their current machines.  So yes, I'm retarded because I thought ahead of 
 your small mind.

 On Fri, Jun 18, 2010 at 2:06 PM, Adam Buckland 
 adamjbuckl...@gmail.comwrote:

 That's the plan. He's hoping to do something similar to id tech 5's
 megatexture technology for geometry. It's called sparse voxel octree
 technology

 Basically(from what I understand), the idea is to make the voxels
 very very small to allow for high fidelity, but to only load the
 depth of the octree that could be seen at the current resolution,
 therefore allowing for incredibly detailed models, that only stream
 the small details if they could be seen at the current resolution.
 This is a big step up from LOD where the programmer basically has to
 guess where to swap the models out (and they need to be separate
 models)

 On 18 June 2010 18:42, Harry Jeffery harry101jeff...@googlemail.com
 wrote:
  I believe John Carmack is hoping to use voxels in id Tech 6. That
  engine's only 10 years away so who knows, this could be the future
  but we wont find out until we get there.
 
  On 18 June 2010 17:26, Harry Pidcock haz...@tpg.com.au wrote:
  Ray traced polygon rendering is quite an expensive task on a CPU.
 
  But real time point cloud rendering can be done on it quite well.
 
  http://www.youtube.com/watch?v=Q-ATtrImCx4
 
  Yes its a bit cheesy, but that's because Bruce Dell doesn't have a
 marketing
  budget.
 
 
  This video is rendered in real time on a single core CPU, although
  it is only rendering at like 800x600, if the algorithm had some
  parallelism, maybe even have it developed for GPUs/hardware
  specialization. Then it would certainly be able to render large
  amounts of detail at a higher resolution.
 
  Although it doesn't have any advanced shading, it is still quite
 interesting
  to see such a complex static environment drawn with a single CPU thread.
 
  Of course there are huge computational and memory issues with bone
  animation, shading, transparency etc. So don't think you will see
  this
 in
  the next 5 - 10years.
 
  --
  From: Jonathan Murphy nuclearfri...@gmail.com
  Sent: Saturday, June 19, 2010 12:31 AM
  To: Discussion of Half-Life Programming 
 hlcoders@list.valvesoftware.com
  Subject: Re: [hlcoders] Source Engine 2!!!
 
  Katrina, you might be interested in reading up on Real Time
  Raytracing, which is an alternative to rasterisation (GPU) based
  rendering and is/has been extensively researched and even implemented.
 
  http://en.m.wikipedia.org/wiki/Ray_tracing_(graphics)http://en.m
  .wikipedia.org/wiki/Ray_tracing_%28graphics%29
  http://en.m.wikipedia.org/wiki/Quake_Wars:_Ray_Traced
 
  At the moment though it seems GPUs are going to stay very mainstream.
 
  On Saturday, June 19, 2010, joshua simmons simmons...@gmail.com
 wrote:
  Oh yeah I understand. There is only very rudmentry 3d support,
  in no
 way
  capable of supporting any game. My point was more on the radical
  rate
 at
  which they are evolving in comparison. Even the purely reverse
 engineered
  open

Re: [hlcoders] Source Engine 2!!!

2010-06-18 Thread Jeffrey botman Broome

...and iPhone/iPad is essentially Mac OS X, so it's next!!!1!1!  :)

On 6/18/2010 4:32 PM, Harry Jeffery wrote:
 Platforms a source engine game (ported by valve themselves) run on:
 Windows, Mac OS X, Xbox 360, Playstation 3.

 I can only see one thing missing; linux.

 On 18 June 2010 22:13, Allan Buttonabut...@netaccess.ca  wrote:

 We are all missing a huge part of the picture here.

 Yes, driver support is bad in Linux. We can all agree on that. But there are 
 people right now, I mean right this very second! Playing TF2 in 
 Wine/Crossover. Meaning they already have done the work to get the drivers 
 running on Linux. Would it not be better to support these players with a 
 native build?

 I am a programmer, I have done coding for Linux, Windows and Mac. I think 
 they should port over 1 game to Linux, see if anybody even uses it. Say HL2 
 for example.

 They have Linux bins of SRCDS, so they already know how to bring an engine 
 over, and they understand fully Linux networking and file system.

 My 2 cents. If nobody is interested in them, I'll take them back. Economic 
 recession you know.

 Allan

 -Original Message-
 From: hlcoders-boun...@list.valvesoftware.com 
 [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Justin Krenz
 Sent: Friday, June 18, 2010 4:49 PM
 To: Discussion of Half-Life Programming
 Subject: Re: [hlcoders] Source Engine 2!!!

 I believe he was referring to your claim about voxels being the first thing 
 used in 3d.  Vector graphics (lines/edges) were the first things used in 3d 
 with games like Battlezone and Star Wars at the arcades..

 If you think voxels are so great, what did you think about Kevin Silverman's 
 voxlap engine?  http://voxelstein3d.sourceforge.net/

 On Fri, Jun 18, 2010 at 2:23 PM, Joel R.joelru...@gmail.com  wrote:
  
 Please enlighten me then, Marek.  Voxels can be better the smaller
 they are, and in a few years will be better suited when we have more
 powerful computers.  Many are still struggling to even play TF2 with
 their current machines.  So yes, I'm retarded because I thought ahead of 
 your small mind.

 On Fri, Jun 18, 2010 at 2:06 PM, Adam 
 Bucklandadamjbuckl...@gmail.comwrote:


 That's the plan. He's hoping to do something similar to id tech 5's
 megatexture technology for geometry. It's called sparse voxel octree
 technology

 Basically(from what I understand), the idea is to make the voxels
 very very small to allow for high fidelity, but to only load the
 depth of the octree that could be seen at the current resolution,
 therefore allowing for incredibly detailed models, that only stream
 the small details if they could be seen at the current resolution.
 This is a big step up from LOD where the programmer basically has to
 guess where to swap the models out (and they need to be separate
 models)

 On 18 June 2010 18:42, Harry Jefferyharry101jeff...@googlemail.com
 wrote:
  
 I believe John Carmack is hoping to use voxels in id Tech 6. That
 engine's only 10 years away so who knows, this could be the future
 but we wont find out until we get there.

 On 18 June 2010 17:26, Harry Pidcockhaz...@tpg.com.au  wrote:

 Ray traced polygon rendering is quite an expensive task on a CPU.

 But real time point cloud rendering can be done on it quite well.

 http://www.youtube.com/watch?v=Q-ATtrImCx4

 Yes its a bit cheesy, but that's because Bruce Dell doesn't have a
  
 marketing
  
 budget.


 This video is rendered in real time on a single core CPU, although
 it is only rendering at like 800x600, if the algorithm had some
 parallelism, maybe even have it developed for GPUs/hardware
 specialization. Then it would certainly be able to render large
 amounts of detail at a higher resolution.

 Although it doesn't have any advanced shading, it is still quite
  
 interesting
  
 to see such a complex static environment drawn with a single CPU thread.

 Of course there are huge computational and memory issues with bone
 animation, shading, transparency etc. So don't think you will see
 this
  
 in
  
 the next 5 - 10years.

 --
 From: Jonathan Murphynuclearfri...@gmail.com
 Sent: Saturday, June 19, 2010 12:31 AM
 To: Discussion of Half-Life Programming
  
 hlcoders@list.valvesoftware.com
  
 Subject: Re: [hlcoders] Source Engine 2!!!

  
 Katrina, you might be interested in reading up on Real Time
 Raytracing, which is an alternative to rasterisation (GPU) based
 rendering and is/has been extensively researched and even implemented.

 http://en.m.wikipedia.org/wiki/Ray_tracing_(graphics)http://en.m
 .wikipedia.org/wiki/Ray_tracing_%28graphics%29
 http://en.m.wikipedia.org/wiki/Quake_Wars:_Ray_Traced

 At the moment though it seems GPUs are going to stay very mainstream.

 On Saturday, June 19, 2010, joshua simmonssimmons...@gmail.com

 wrote

Re: [hlcoders] Source Engine 2!!!

2010-06-18 Thread Allan Button

And WII. But IMHO, Wii is not enjoyable for FPS. The control system is to 
forced.

Original Nintendo only had about 6 zapper games, and hundreds of controller 
games. But on Wii every FPS is like a zapper game. Give me some analog sticks 
por favor.

Allan

-Original Message-
From: hlcoders-boun...@list.valvesoftware.com 
[mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Harry Jeffery
Sent: Friday, June 18, 2010 5:33 PM
To: Discussion of Half-Life Programming
Subject: Re: [hlcoders] Source Engine 2!!!

Platforms a source engine game (ported by valve themselves) run on:
Windows, Mac OS X, Xbox 360, Playstation 3.

I can only see one thing missing; linux.

On 18 June 2010 22:13, Allan Button abut...@netaccess.ca wrote:
 We are all missing a huge part of the picture here.

 Yes, driver support is bad in Linux. We can all agree on that. But there are 
 people right now, I mean right this very second! Playing TF2 in 
 Wine/Crossover. Meaning they already have done the work to get the drivers 
 running on Linux. Would it not be better to support these players with a 
 native build?

 I am a programmer, I have done coding for Linux, Windows and Mac. I think 
 they should port over 1 game to Linux, see if anybody even uses it. Say HL2 
 for example.

 They have Linux bins of SRCDS, so they already know how to bring an engine 
 over, and they understand fully Linux networking and file system.

 My 2 cents. If nobody is interested in them, I'll take them back. Economic 
 recession you know.

 Allan

 -Original Message-
 From: hlcoders-boun...@list.valvesoftware.com 
 [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Justin 
 Krenz
 Sent: Friday, June 18, 2010 4:49 PM
 To: Discussion of Half-Life Programming
 Subject: Re: [hlcoders] Source Engine 2!!!

 I believe he was referring to your claim about voxels being the first thing 
 used in 3d.  Vector graphics (lines/edges) were the first things used in 3d 
 with games like Battlezone and Star Wars at the arcades..

 If you think voxels are so great, what did you think about Kevin 
 Silverman's voxlap engine?  http://voxelstein3d.sourceforge.net/

 On Fri, Jun 18, 2010 at 2:23 PM, Joel R. joelru...@gmail.com wrote:
 Please enlighten me then, Marek.  Voxels can be better the smaller 
 they are, and in a few years will be better suited when we have more 
 powerful computers.  Many are still struggling to even play TF2 with 
 their current machines.  So yes, I'm retarded because I thought ahead of 
 your small mind.

 On Fri, Jun 18, 2010 at 2:06 PM, Adam Buckland 
 adamjbuckl...@gmail.comwrote:

 That's the plan. He's hoping to do something similar to id tech 5's 
 megatexture technology for geometry. It's called sparse voxel octree 
 technology

 Basically(from what I understand), the idea is to make the voxels 
 very very small to allow for high fidelity, but to only load the 
 depth of the octree that could be seen at the current resolution, 
 therefore allowing for incredibly detailed models, that only stream 
 the small details if they could be seen at the current resolution.
 This is a big step up from LOD where the programmer basically has to 
 guess where to swap the models out (and they need to be separate
 models)

 On 18 June 2010 18:42, Harry Jeffery 
 harry101jeff...@googlemail.com
 wrote:
  I believe John Carmack is hoping to use voxels in id Tech 6. That 
  engine's only 10 years away so who knows, this could be the future 
  but we wont find out until we get there.
 
  On 18 June 2010 17:26, Harry Pidcock haz...@tpg.com.au wrote:
  Ray traced polygon rendering is quite an expensive task on a CPU.
 
  But real time point cloud rendering can be done on it quite well.
 
  http://www.youtube.com/watch?v=Q-ATtrImCx4
 
  Yes its a bit cheesy, but that's because Bruce Dell doesn't have 
  a
 marketing
  budget.
 
 
  This video is rendered in real time on a single core CPU, 
  although it is only rendering at like 800x600, if the algorithm 
  had some parallelism, maybe even have it developed for 
  GPUs/hardware specialization. Then it would certainly be able to 
  render large amounts of detail at a higher resolution.
 
  Although it doesn't have any advanced shading, it is still quite
 interesting
  to see such a complex static environment drawn with a single CPU thread.
 
  Of course there are huge computational and memory issues with 
  bone animation, shading, transparency etc. So don't think you 
  will see this
 in
  the next 5 - 10years.
 
  --
  From: Jonathan Murphy nuclearfri...@gmail.com
  Sent: Saturday, June 19, 2010 12:31 AM
  To: Discussion of Half-Life Programming 
 hlcoders@list.valvesoftware.com
  Subject: Re: [hlcoders] Source Engine 2!!!
 
  Katrina, you might be interested in reading up on Real Time 
  Raytracing, which is an alternative to rasterisation (GPU) based 
  rendering and is/has been extensively researched and even implemented.
 
  http

Re: [hlcoders] Source Engine 2!!!

2010-06-18 Thread Tobias Kammersgaard

No Source Engine 2 wasn't the surprise for E3. End of thread tbh.

- ScarT


On 18 June 2010 23:32, Harry Jeffery harry101jeff...@googlemail.com wrote:

 Platforms a source engine game (ported by valve themselves) run on:
 Windows, Mac OS X, Xbox 360, Playstation 3.

 I can only see one thing missing; linux.

 On 18 June 2010 22:13, Allan Button abut...@netaccess.ca wrote:
  We are all missing a huge part of the picture here.
 
  Yes, driver support is bad in Linux. We can all agree on that. But there
 are people right now, I mean right this very second! Playing TF2 in
 Wine/Crossover. Meaning they already have done the work to get the drivers
 running on Linux. Would it not be better to support these players with a
 native build?
 
  I am a programmer, I have done coding for Linux, Windows and Mac. I think
 they should port over 1 game to Linux, see if anybody even uses it. Say HL2
 for example.
 
  They have Linux bins of SRCDS, so they already know how to bring an
 engine over, and they understand fully Linux networking and file system.
 
  My 2 cents. If nobody is interested in them, I'll take them back.
 Economic recession you know.
 
  Allan
 
  -Original Message-
  From: hlcoders-boun...@list.valvesoftware.com [mailto:
 hlcoders-boun...@list.valvesoftware.com] On Behalf Of Justin Krenz
  Sent: Friday, June 18, 2010 4:49 PM
  To: Discussion of Half-Life Programming
  Subject: Re: [hlcoders] Source Engine 2!!!
 
  I believe he was referring to your claim about voxels being the first
 thing used in 3d.  Vector graphics (lines/edges) were the first things used
 in 3d with games like Battlezone and Star Wars at the arcades..
 
  If you think voxels are so great, what did you think about Kevin
 Silverman's voxlap engine?  http://voxelstein3d.sourceforge.net/
 
  On Fri, Jun 18, 2010 at 2:23 PM, Joel R. joelru...@gmail.com wrote:
  Please enlighten me then, Marek.  Voxels can be better the smaller
  they are, and in a few years will be better suited when we have more
  powerful computers.  Many are still struggling to even play TF2 with
  their current machines.  So yes, I'm retarded because I thought ahead of
 your small mind.
 
  On Fri, Jun 18, 2010 at 2:06 PM, Adam Buckland adamjbuckl...@gmail.com
 wrote:
 
  That's the plan. He's hoping to do something similar to id tech 5's
  megatexture technology for geometry. It's called sparse voxel octree
  technology
 
  Basically(from what I understand), the idea is to make the voxels
  very very small to allow for high fidelity, but to only load the
  depth of the octree that could be seen at the current resolution,
  therefore allowing for incredibly detailed models, that only stream
  the small details if they could be seen at the current resolution.
  This is a big step up from LOD where the programmer basically has to
  guess where to swap the models out (and they need to be separate
  models)
 
  On 18 June 2010 18:42, Harry Jeffery harry101jeff...@googlemail.com
  wrote:
   I believe John Carmack is hoping to use voxels in id Tech 6. That
   engine's only 10 years away so who knows, this could be the future
   but we wont find out until we get there.
  
   On 18 June 2010 17:26, Harry Pidcock haz...@tpg.com.au wrote:
   Ray traced polygon rendering is quite an expensive task on a CPU.
  
   But real time point cloud rendering can be done on it quite well.
  
   http://www.youtube.com/watch?v=Q-ATtrImCx4
  
   Yes its a bit cheesy, but that's because Bruce Dell doesn't have a
  marketing
   budget.
  
  
   This video is rendered in real time on a single core CPU, although
   it is only rendering at like 800x600, if the algorithm had some
   parallelism, maybe even have it developed for GPUs/hardware
   specialization. Then it would certainly be able to render large
   amounts of detail at a higher resolution.
  
   Although it doesn't have any advanced shading, it is still quite
  interesting
   to see such a complex static environment drawn with a single CPU
 thread.
  
   Of course there are huge computational and memory issues with bone
   animation, shading, transparency etc. So don't think you will see
   this
  in
   the next 5 - 10years.
  
   --
   From: Jonathan Murphy nuclearfri...@gmail.com
   Sent: Saturday, June 19, 2010 12:31 AM
   To: Discussion of Half-Life Programming 
  hlcoders@list.valvesoftware.com
   Subject: Re: [hlcoders] Source Engine 2!!!
  
   Katrina, you might be interested in reading up on Real Time
   Raytracing, which is an alternative to rasterisation (GPU) based
   rendering and is/has been extensively researched and even
 implemented.
  
   http://en.m.wikipedia.org/wiki/Ray_tracing_(graphics)http://en.m
   .wikipedia.org/wiki/Ray_tracing_%28graphics%29
   http://en.m.wikipedia.org/wiki/Quake_Wars:_Ray_Traced
  
   At the moment though it seems GPUs are going to stay very
 mainstream.
  
   On Saturday, June 19, 2010, joshua simmons simmons...@gmail.com
  wrote

Re: [hlcoders] Source Engine 2!!!

Wii?

On 18 June 2010 22:32, Harry Jeffery harry101jeff...@googlemail.com wrote:
 Platforms a source engine game (ported by valve themselves) run on:
 Windows, Mac OS X, Xbox 360, Playstation 3.

 I can only see one thing missing; linux.

 On 18 June 2010 22:13, Allan Button abut...@netaccess.ca wrote:
 We are all missing a huge part of the picture here.

 Yes, driver support is bad in Linux. We can all agree on that. But there are 
 people right now, I mean right this very second! Playing TF2 in 
 Wine/Crossover. Meaning they already have done the work to get the drivers 
 running on Linux. Would it not be better to support these players with a 
 native build?

 I am a programmer, I have done coding for Linux, Windows and Mac. I think 
 they should port over 1 game to Linux, see if anybody even uses it. Say HL2 
 for example.

 They have Linux bins of SRCDS, so they already know how to bring an engine 
 over, and they understand fully Linux networking and file system.

 My 2 cents. If nobody is interested in them, I'll take them back. Economic 
 recession you know.

 Allan

 -Original Message-
 From: hlcoders-boun...@list.valvesoftware.com 
 [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Justin Krenz
 Sent: Friday, June 18, 2010 4:49 PM
 To: Discussion of Half-Life Programming
 Subject: Re: [hlcoders] Source Engine 2!!!

 I believe he was referring to your claim about voxels being the first thing 
 used in 3d.  Vector graphics (lines/edges) were the first things used in 3d 
 with games like Battlezone and Star Wars at the arcades..

 If you think voxels are so great, what did you think about Kevin Silverman's 
 voxlap engine?  http://voxelstein3d.sourceforge.net/

 On Fri, Jun 18, 2010 at 2:23 PM, Joel R. joelru...@gmail.com wrote:
 Please enlighten me then, Marek.  Voxels can be better the smaller
 they are, and in a few years will be better suited when we have more
 powerful computers.  Many are still struggling to even play TF2 with
 their current machines.  So yes, I'm retarded because I thought ahead of 
 your small mind.

 On Fri, Jun 18, 2010 at 2:06 PM, Adam Buckland 
 adamjbuckl...@gmail.comwrote:

 That's the plan. He's hoping to do something similar to id tech 5's
 megatexture technology for geometry. It's called sparse voxel octree
 technology

 Basically(from what I understand), the idea is to make the voxels
 very very small to allow for high fidelity, but to only load the
 depth of the octree that could be seen at the current resolution,
 therefore allowing for incredibly detailed models, that only stream
 the small details if they could be seen at the current resolution.
 This is a big step up from LOD where the programmer basically has to
 guess where to swap the models out (and they need to be separate
 models)

 On 18 June 2010 18:42, Harry Jeffery harry101jeff...@googlemail.com
 wrote:
  I believe John Carmack is hoping to use voxels in id Tech 6. That
  engine's only 10 years away so who knows, this could be the future
  but we wont find out until we get there.
 
  On 18 June 2010 17:26, Harry Pidcock haz...@tpg.com.au wrote:
  Ray traced polygon rendering is quite an expensive task on a CPU.
 
  But real time point cloud rendering can be done on it quite well.
 
  http://www.youtube.com/watch?v=Q-ATtrImCx4
 
  Yes its a bit cheesy, but that's because Bruce Dell doesn't have a
 marketing
  budget.
 
 
  This video is rendered in real time on a single core CPU, although
  it is only rendering at like 800x600, if the algorithm had some
  parallelism, maybe even have it developed for GPUs/hardware
  specialization. Then it would certainly be able to render large
  amounts of detail at a higher resolution.
 
  Although it doesn't have any advanced shading, it is still quite
 interesting
  to see such a complex static environment drawn with a single CPU thread.
 
  Of course there are huge computational and memory issues with bone
  animation, shading, transparency etc. So don't think you will see
  this
 in
  the next 5 - 10years.
 
  --
  From: Jonathan Murphy nuclearfri...@gmail.com
  Sent: Saturday, June 19, 2010 12:31 AM
  To: Discussion of Half-Life Programming 
 hlcoders@list.valvesoftware.com
  Subject: Re: [hlcoders] Source Engine 2!!!
 
  Katrina, you might be interested in reading up on Real Time
  Raytracing, which is an alternative to rasterisation (GPU) based
  rendering and is/has been extensively researched and even implemented.
 
  http://en.m.wikipedia.org/wiki/Ray_tracing_(graphics)http://en.m
  .wikipedia.org/wiki/Ray_tracing_%28graphics%29
  http://en.m.wikipedia.org/wiki/Quake_Wars:_Ray_Traced
 
  At the moment though it seems GPUs are going to stay very mainstream.
 
  On Saturday, June 19, 2010, joshua simmons simmons...@gmail.com
 wrote:
  Oh yeah I understand. There is only very rudmentry 3d support,
  in no
 way
  capable of supporting any game. My point was more on the radical
  rate

Re: [hlcoders] Source Engine 2!!!

Yeah, but they would need to port first Steam, because as i can see from
this is that they simply changed the basic classes which are plataform
dependent (at least this is how i would do it, using inheritance and
initiating the right base classes at the beginning that the engine would
use).

But the thing that i believe is that would they do it? Would this investment
pay in return?

2010/6/18 Harry Jeffery harry101jeff...@googlemail.com

 Platforms a source engine game (ported by valve themselves) run on:
 Windows, Mac OS X, Xbox 360, Playstation 3.

 I can only see one thing missing; linux.

 On 18 June 2010 22:13, Allan Button abut...@netaccess.ca wrote:
  We are all missing a huge part of the picture here.
 
  Yes, driver support is bad in Linux. We can all agree on that. But there
 are people right now, I mean right this very second! Playing TF2 in
 Wine/Crossover. Meaning they already have done the work to get the drivers
 running on Linux. Would it not be better to support these players with a
 native build?
 
  I am a programmer, I have done coding for Linux, Windows and Mac. I think
 they should port over 1 game to Linux, see if anybody even uses it. Say HL2
 for example.
 
  They have Linux bins of SRCDS, so they already know how to bring an
 engine over, and they understand fully Linux networking and file system.
 
  My 2 cents. If nobody is interested in them, I'll take them back.
 Economic recession you know.
 
  Allan
 
  -Original Message-
  From: hlcoders-boun...@list.valvesoftware.com [mailto:
 hlcoders-boun...@list.valvesoftware.com] On Behalf Of Justin Krenz
  Sent: Friday, June 18, 2010 4:49 PM
  To: Discussion of Half-Life Programming
  Subject: Re: [hlcoders] Source Engine 2!!!
 
  I believe he was referring to your claim about voxels being the first
 thing used in 3d.  Vector graphics (lines/edges) were the first things used
 in 3d with games like Battlezone and Star Wars at the arcades..
 
  If you think voxels are so great, what did you think about Kevin
 Silverman's voxlap engine?  http://voxelstein3d.sourceforge.net/
 
  On Fri, Jun 18, 2010 at 2:23 PM, Joel R. joelru...@gmail.com wrote:
  Please enlighten me then, Marek.  Voxels can be better the smaller
  they are, and in a few years will be better suited when we have more
  powerful computers.  Many are still struggling to even play TF2 with
  their current machines.  So yes, I'm retarded because I thought ahead of
 your small mind.
 
  On Fri, Jun 18, 2010 at 2:06 PM, Adam Buckland adamjbuckl...@gmail.com
 wrote:
 
  That's the plan. He's hoping to do something similar to id tech 5's
  megatexture technology for geometry. It's called sparse voxel octree
  technology
 
  Basically(from what I understand), the idea is to make the voxels
  very very small to allow for high fidelity, but to only load the
  depth of the octree that could be seen at the current resolution,
  therefore allowing for incredibly detailed models, that only stream
  the small details if they could be seen at the current resolution.
  This is a big step up from LOD where the programmer basically has to
  guess where to swap the models out (and they need to be separate
  models)
 
  On 18 June 2010 18:42, Harry Jeffery harry101jeff...@googlemail.com
  wrote:
   I believe John Carmack is hoping to use voxels in id Tech 6. That
   engine's only 10 years away so who knows, this could be the future
   but we wont find out until we get there.
  
   On 18 June 2010 17:26, Harry Pidcock haz...@tpg.com.au wrote:
   Ray traced polygon rendering is quite an expensive task on a CPU.
  
   But real time point cloud rendering can be done on it quite well.
  
   http://www.youtube.com/watch?v=Q-ATtrImCx4
  
   Yes its a bit cheesy, but that's because Bruce Dell doesn't have a
  marketing
   budget.
  
  
   This video is rendered in real time on a single core CPU, although
   it is only rendering at like 800x600, if the algorithm had some
   parallelism, maybe even have it developed for GPUs/hardware
   specialization. Then it would certainly be able to render large
   amounts of detail at a higher resolution.
  
   Although it doesn't have any advanced shading, it is still quite
  interesting
   to see such a complex static environment drawn with a single CPU
 thread.
  
   Of course there are huge computational and memory issues with bone
   animation, shading, transparency etc. So don't think you will see
   this
  in
   the next 5 - 10years.
  
   --
   From: Jonathan Murphy nuclearfri...@gmail.com
   Sent: Saturday, June 19, 2010 12:31 AM
   To: Discussion of Half-Life Programming 
  hlcoders@list.valvesoftware.com
   Subject: Re: [hlcoders] Source Engine 2!!!
  
   Katrina, you might be interested in reading up on Real Time
   Raytracing, which is an alternative to rasterisation (GPU) based
   rendering and is/has been extensively researched and even
 implemented.
  
   http://en.m.wikipedia.org/wiki

Re: [hlcoders] Source Engine 2!!!

Steam's already running on Linux.

If you want proof, there's the Mac version. When you launch the Mac
version, the first thing that happens is a shell script is executed.
Here's an excerpt

#determine platform
UNAME=`uname`
if [ $UNAME == Linux ]; then
   PLATFORM=linux32
   # prepend our lib path to LD_LIBRARY_PATH
   export LD_LIBRARY_PATH=${STEAMROOT}/${PLATFORM}:$LD_LIBRARY_PATH
else # if [ $UNAME == Darwin ]; then
   PLATFORM=osx32
   # prepend our lib path to LD_LIBRARY_PATH
   export DYLD_LIBRARY_PATH=${STEAMROOT}/${PLATFORM}:$DYLD_LIBRARY_PATH

On 18 June 2010 23:02, ZuM eduardo...@gmail.com wrote:
 Yeah, but they would need to port first Steam, because as i can see from
 this is that they simply changed the basic classes which are plataform
 dependent (at least this is how i would do it, using inheritance and
 initiating the right base classes at the beginning that the engine would
 use).

 But the thing that i believe is that would they do it? Would this investment
 pay in return?

 2010/6/18 Harry Jeffery harry101jeff...@googlemail.com

 Platforms a source engine game (ported by valve themselves) run on:
 Windows, Mac OS X, Xbox 360, Playstation 3.

 I can only see one thing missing; linux.

 On 18 June 2010 22:13, Allan Button abut...@netaccess.ca wrote:
  We are all missing a huge part of the picture here.
 
  Yes, driver support is bad in Linux. We can all agree on that. But there
 are people right now, I mean right this very second! Playing TF2 in
 Wine/Crossover. Meaning they already have done the work to get the drivers
 running on Linux. Would it not be better to support these players with a
 native build?
 
  I am a programmer, I have done coding for Linux, Windows and Mac. I think
 they should port over 1 game to Linux, see if anybody even uses it. Say HL2
 for example.
 
  They have Linux bins of SRCDS, so they already know how to bring an
 engine over, and they understand fully Linux networking and file system.
 
  My 2 cents. If nobody is interested in them, I'll take them back.
 Economic recession you know.
 
  Allan
 
  -Original Message-
  From: hlcoders-boun...@list.valvesoftware.com [mailto:
 hlcoders-boun...@list.valvesoftware.com] On Behalf Of Justin Krenz
  Sent: Friday, June 18, 2010 4:49 PM
  To: Discussion of Half-Life Programming
  Subject: Re: [hlcoders] Source Engine 2!!!
 
  I believe he was referring to your claim about voxels being the first
 thing used in 3d.  Vector graphics (lines/edges) were the first things used
 in 3d with games like Battlezone and Star Wars at the arcades..
 
  If you think voxels are so great, what did you think about Kevin
 Silverman's voxlap engine?  http://voxelstein3d.sourceforge.net/
 
  On Fri, Jun 18, 2010 at 2:23 PM, Joel R. joelru...@gmail.com wrote:
  Please enlighten me then, Marek.  Voxels can be better the smaller
  they are, and in a few years will be better suited when we have more
  powerful computers.  Many are still struggling to even play TF2 with
  their current machines.  So yes, I'm retarded because I thought ahead of
 your small mind.
 
  On Fri, Jun 18, 2010 at 2:06 PM, Adam Buckland adamjbuckl...@gmail.com
 wrote:
 
  That's the plan. He's hoping to do something similar to id tech 5's
  megatexture technology for geometry. It's called sparse voxel octree
  technology
 
  Basically(from what I understand), the idea is to make the voxels
  very very small to allow for high fidelity, but to only load the
  depth of the octree that could be seen at the current resolution,
  therefore allowing for incredibly detailed models, that only stream
  the small details if they could be seen at the current resolution.
  This is a big step up from LOD where the programmer basically has to
  guess where to swap the models out (and they need to be separate
  models)
 
  On 18 June 2010 18:42, Harry Jeffery harry101jeff...@googlemail.com
  wrote:
   I believe John Carmack is hoping to use voxels in id Tech 6. That
   engine's only 10 years away so who knows, this could be the future
   but we wont find out until we get there.
  
   On 18 June 2010 17:26, Harry Pidcock haz...@tpg.com.au wrote:
   Ray traced polygon rendering is quite an expensive task on a CPU.
  
   But real time point cloud rendering can be done on it quite well.
  
   http://www.youtube.com/watch?v=Q-ATtrImCx4
  
   Yes its a bit cheesy, but that's because Bruce Dell doesn't have a
  marketing
   budget.
  
  
   This video is rendered in real time on a single core CPU, although
   it is only rendering at like 800x600, if the algorithm had some
   parallelism, maybe even have it developed for GPUs/hardware
   specialization. Then it would certainly be able to render large
   amounts of detail at a higher resolution.
  
   Although it doesn't have any advanced shading, it is still quite
  interesting
   to see such a complex static environment drawn with a single CPU
 thread.
  
   Of course there are huge computational and memory issues with bone

Re: [hlcoders] Source Engine 2!!!

Yeah, but it is an internet discussion. If everybody was not missing most of 
the picture as they discussed it, then we'd be entering into really weird and 
alien territory.

I have kind of given up on this.

I have also tried to do the whole (WAS: thread) thing that a lot of mailing 
lists use for conventions... though, come to think of it, the convention of 
replying *after* the post is not in place here either.

Well, again, I am kind of glad we have not spiraled into several threads on 
the grammar; speling issuse present here.

Meh--I dunno, the big issue with porting to Linux is from what I have seen on 
the hlds list, Valve really has no idea what to do with Linux. (GAH!? WHY DOES 
THE SERVER FORK?! I mean, most other servers on Linux have not required 
forking for about a decade now... never mind that general purpose benchmarks 
get about 0.9 load for a thread, in comparison to something insanely high like 
300.0 for forking)

So yeah.

You guys talk all silly like. Though, now I understand why my twin sister, 
JTE/JessieTheEchidna/Echidna-Chan, tends to hate developer groups such as 
this.

~Katrina

On Friday, June 18, 2010 03:13:54 pm Allan Button wrote:
 We are all missing a huge part of the picture here.


___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Source Engine 2!!!

2010-06-18 Thread Cory de La Torre

Echidna-Chan. Cool Story bro.

On Fri, Jun 18, 2010 at 4:53 PM, Katrina Payne fullmetalhar...@nimhlabs.com
 wrote:

 Yeah, but it is an internet discussion. If everybody was not missing most
 of
 the picture as they discussed it, then we'd be entering into really weird
 and
 alien territory.

 I have kind of given up on this.

 I have also tried to do the whole (WAS: thread) thing that a lot of
 mailing
 lists use for conventions... though, come to think of it, the convention of
 replying *after* the post is not in place here either.

 Well, again, I am kind of glad we have not spiraled into several threads on
 the grammar; speling issuse present here.

 Meh--I dunno, the big issue with porting to Linux is from what I have seen
 on
 the hlds list, Valve really has no idea what to do with Linux. (GAH!? WHY
 DOES
 THE SERVER FORK?! I mean, most other servers on Linux have not required
 forking for about a decade now... never mind that general purpose
 benchmarks
 get about 0.9 load for a thread, in comparison to something insanely high
 like
 300.0 for forking)

 So yeah.

 You guys talk all silly like. Though, now I understand why my twin sister,
 JTE/JessieTheEchidna/Echidna-Chan, tends to hate developer groups such as
 this.

 ~Katrina

 On Friday, June 18, 2010 03:13:54 pm Allan Button wrote:
  We are all missing a huge part of the picture here.


 ___
 To unsubscribe, edit your list preferences, or view the list archives,
 please visit:
 http://list.valvesoftware.com/mailman/listinfo/hlcoders




-- 
Gear Dev
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Source Engine 2!!!

2010-06-17 Thread Alexander Hirsch

Mesa3D?

On Tue, Jun 15, 2010 at 5:20 AM, Katrina Payne fullmetalhar...@nimhlabs.com
 wrote:

 This also adds a rather odd burden here, that allows Linux to get a better
 standing for gaming.

 It is not that unknown that without mixing, Linux generally does not
 require
 anywhere near as much over head to run as windows.

 The minimum requirements to run a GUI on Linux is about 256MiB of RAM. This
 even includes GUIs like KDE and Gnome. Though XFCE and LXCE would be better
 if
 you really did only have 256MiB of RAM (well if you were using a DE... and
 not
 a slimmed down WM with only a few programs loaded into it)

 You can do just fine win 1GiB of RAM.

 Linux also, as an OS can run on some old Intel boards--that running an OS
 on
 would other wise be insane today. a Pentium 1 can still get (some) use with
 Linux.

 Not enough to really be noteworthy as a desktop PC... but, this is a lot
 less
 than the least you will get Windows 7 onto.

 So we have a nice toss up here:

 1: Linux requires Software Rendering in place. IE: how rendering was done,
 before we got silly things like TNT and Voodoo on the market.

 2: Linux requires significantly less overhead to run, as far as OS goes.

 If we can get it so that we can show Steam running on Linux, using mostly
 Software Rendering, and getting it to run as fast as the same game on
 Windows,
 on comparable hardware...

 This will definitely sell Linux as an OS...

 Which in turn will get various Graphics Card makers on board to add their
 support.

 You know--I kind of want to see somebody work on that goal then. I am
 almost
 ready to dig up some old books that go over the theory of 3d programming,
 just
 to pull make a software rendering engine for this idea.

 On Monday, June 14, 2010 07:59:45 pm Darren VanBuren wrote:
  Yes, 3D drivers are definitely quite lacking on the GNU/Linux front,
  but if Valve shows support for the development of these drivers, this
  may prompt certain GPU manufacturers to step up their GNU/Linux driver
  development.
 
  Darren L. VanBuren
  =
  http://theoks.net/
  On Mon, Jun 14, 2010 at 18:35, Bob Somers magicbob...@gmail.com wrote:
   Something to consider, though, is that the 3D driver support is years
   behind from *ahem* a particular GPU manufacturer. I won't embarrass
   them by saying their name, so I'll just say their initials: ATI.
  
   Their driver support for Linux is, frankly, pathetic at best. The
   Fedora team is trying to solve this with their new free drivers in
   Fedora 13 (which, I'll admit, are quite good), but it's still not up
   to par with what you need to run a game. For example, the new free
   drivers have very little (read: practically none) support for basic
   vertex and fragment shaders. It will be at least another year before
   the free drivers are up to what ATI's crappy proprietary drivers are
   now. Even worse, right now you can get the proprietary drivers running
   on Fedora 11 alright, sort-of on Fedora 12 with some ugly hackery, and
   not at all on Fedora 13. Literally, ATI's Linux drivers are at least
   12 months behind, and the free ones are 12 months behind that.
  
   Unless somebody gives ATI a swift kick in the nuts the situation does
   not look good.
  
   --Bob
  
  
  
  
  
   On Mon, Jun 14, 2010 at 5:01 PM, Darren VanBuren onekop...@gmail.com
 wrote:
   Spoiler Alert. It's like the ratman drawing that says She's watching
   you. Canonical is she in that case.
  
   I'm personally a fan of Fedora, but if Steam on GNU/Linux is
   distributed as a tarball, that'd be best in the interests of Valve.
   Even if some people (mainly Ubuntu users) would be a bit stuck on the
   concept of a tarball, it'd be minimal work for Valve, and maximum
   cross-distribution compatibility.
  
   Darren L. VanBuren
   =
   http://theoks.net/
  
  
  
   On Mon, Jun 14, 2010 at 16:49, Harry Jeffery
   harry101jeff...@googlemail.com wrote:
   It's all down to personal opinion, as long as it does what you need
   quickly and effectively then it's fine. I've yet to see the dark side
   in cannonical so I honestly can't say much about their ethics.
  
   Either way, I 3 Linux and so should Valve.
  
   On 15 June 2010 00:19, Katrina Payne fullmetalhar...@nimhlabs.com
 wrote:
   Well a few points:
  
   The commands in the Linux Commandline... and well those on any UNIX
 or
 UNIX
   Workalike have not really changed since the 1970s. You could pick up
 a
 book on
   BASH or TCSH from the 1970s, and still have most of what you should
 do.
  
   This kind of has allowed for tools to be put around these base
 functions, such
   as autocomplete, history and well--quite a few other really handy
 tools, to be
   added into the Linux CLI, to make its functionality go above and
 beyond
   anything cmd.exe is capable of.
  
   I still have yet to look into Microsoft's PowerShell though.
  
   This is why most Linux users use the CLI. It has developed into an

Re: [hlcoders] Source Engine 2!!!

2010-06-17 Thread Allan Button

BlackMesa3D? Sounds like a new Disney flick.

-Original Message-
From: hlcoders-boun...@list.valvesoftware.com 
[mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Alexander Hirsch
Sent: Thursday, June 17, 2010 9:58 AM
To: Discussion of Half-Life Programming
Subject: Re: [hlcoders] Source Engine 2!!!

Mesa3D?

On Tue, Jun 15, 2010 at 5:20 AM, Katrina Payne fullmetalhar...@nimhlabs.com
 wrote:

 This also adds a rather odd burden here, that allows Linux to get a
 better standing for gaming.

 It is not that unknown that without mixing, Linux generally does not
 require anywhere near as much over head to run as windows.

 The minimum requirements to run a GUI on Linux is about 256MiB of RAM.
 This even includes GUIs like KDE and Gnome. Though XFCE and LXCE would
 be better if you really did only have 256MiB of RAM (well if you were
 using a DE... and not a slimmed down WM with only a few programs
 loaded into it)

 You can do just fine win 1GiB of RAM.

 Linux also, as an OS can run on some old Intel boards--that running an
 OS on would other wise be insane today. a Pentium 1 can still get
 (some) use with Linux.

 Not enough to really be noteworthy as a desktop PC... but, this is a
 lot less than the least you will get Windows 7 onto.

 So we have a nice toss up here:

 1: Linux requires Software Rendering in place. IE: how rendering was
 done, before we got silly things like TNT and Voodoo on the market.

 2: Linux requires significantly less overhead to run, as far as OS goes.

 If we can get it so that we can show Steam running on Linux, using
 mostly Software Rendering, and getting it to run as fast as the same
 game on Windows, on comparable hardware...

 This will definitely sell Linux as an OS...

 Which in turn will get various Graphics Card makers on board to add
 their support.

 You know--I kind of want to see somebody work on that goal then. I am
 almost ready to dig up some old books that go over the theory of 3d
 programming, just to pull make a software rendering engine for this
 idea.

 On Monday, June 14, 2010 07:59:45 pm Darren VanBuren wrote:
  Yes, 3D drivers are definitely quite lacking on the GNU/Linux front,
  but if Valve shows support for the development of these drivers,
  this may prompt certain GPU manufacturers to step up their GNU/Linux
  driver development.

  Darren L. VanBuren
  =
  http://theoks.net/
  On Mon, Jun 14, 2010 at 18:35, Bob Somers magicbob...@gmail.com wrote:
   Something to consider, though, is that the 3D driver support is
   years behind from *ahem* a particular GPU manufacturer. I won't
   embarrass them by saying their name, so I'll just say their initials: ATI.

   Their driver support for Linux is, frankly, pathetic at best. The
   Fedora team is trying to solve this with their new free drivers in
   Fedora 13 (which, I'll admit, are quite good), but it's still not
   up to par with what you need to run a game. For example, the new
   free drivers have very little (read: practically none) support for
   basic vertex and fragment shaders. It will be at least another
   year before the free drivers are up to what ATI's crappy
   proprietary drivers are now. Even worse, right now you can get the
   proprietary drivers running on Fedora 11 alright, sort-of on
   Fedora 12 with some ugly hackery, and not at all on Fedora 13.
   Literally, ATI's Linux drivers are at least
   12 months behind, and the free ones are 12 months behind that.

   Unless somebody gives ATI a swift kick in the nuts the situation
   does not look good.

   --Bob

   On Mon, Jun 14, 2010 at 5:01 PM, Darren VanBuren
   onekop...@gmail.com
 wrote:
   Spoiler Alert. It's like the ratman drawing that says She's
   watching you. Canonical is she in that case.

   I'm personally a fan of Fedora, but if Steam on GNU/Linux is
   distributed as a tarball, that'd be best in the interests of Valve.
   Even if some people (mainly Ubuntu users) would be a bit stuck on
   the concept of a tarball, it'd be minimal work for Valve, and
   maximum cross-distribution compatibility.

   Darren L. VanBuren
   =
   http://theoks.net/

   On Mon, Jun 14, 2010 at 16:49, Harry Jeffery
   harry101jeff...@googlemail.com wrote:
   It's all down to personal opinion, as long as it does what you
   need quickly and effectively then it's fine. I've yet to see the
   dark side in cannonical so I honestly can't say much about their ethics.

   Either way, I 3 Linux and so should Valve.

   On 15 June 2010 00:19, Katrina Payne
   fullmetalhar...@nimhlabs.com
 wrote:
   Well a few points:

   The commands in the Linux Commandline... and well those on any
   UNIX
 or
 UNIX
   Workalike have not really changed since the 1970s. You could
   pick up
 a
 book on
   BASH or TCSH from the 1970s, and still have most of what you
   should
 do.

   This kind of has allowed for tools to be put around these base
 functions

Re: [hlcoders] Source Engine 2!!!

2010-06-17 Thread Adam Buckland

Also, after looking at the Portal 2 gameplay footage from IGN:
http://www.youtube.com/watch?v=5THiN8szSKM (there's 3 parts) am I the
only one that thinks that the lighting system has had to have a large
overhaul to support how the levels change dynamically? (particularly
obvious in the part 1)

On 17 June 2010 14:58, Alexander Hirsch 1ze...@googlemail.com wrote:
 Mesa3D?

 On Tue, Jun 15, 2010 at 5:20 AM, Katrina Payne fullmetalhar...@nimhlabs.com
 wrote:

 This also adds a rather odd burden here, that allows Linux to get a better
 standing for gaming.

 It is not that unknown that without mixing, Linux generally does not
 require
 anywhere near as much over head to run as windows.

 The minimum requirements to run a GUI on Linux is about 256MiB of RAM. This
 even includes GUIs like KDE and Gnome. Though XFCE and LXCE would be better
 if
 you really did only have 256MiB of RAM (well if you were using a DE... and
 not
 a slimmed down WM with only a few programs loaded into it)

 You can do just fine win 1GiB of RAM.

 Linux also, as an OS can run on some old Intel boards--that running an OS
 on
 would other wise be insane today. a Pentium 1 can still get (some) use with
 Linux.

 Not enough to really be noteworthy as a desktop PC... but, this is a lot
 less
 than the least you will get Windows 7 onto.

 So we have a nice toss up here:

 1: Linux requires Software Rendering in place. IE: how rendering was done,
 before we got silly things like TNT and Voodoo on the market.

 2: Linux requires significantly less overhead to run, as far as OS goes.

 If we can get it so that we can show Steam running on Linux, using mostly
 Software Rendering, and getting it to run as fast as the same game on
 Windows,
 on comparable hardware...

 This will definitely sell Linux as an OS...

 Which in turn will get various Graphics Card makers on board to add their
 support.

 You know--I kind of want to see somebody work on that goal then. I am
 almost
 ready to dig up some old books that go over the theory of 3d programming,
 just
 to pull make a software rendering engine for this idea.

 On Monday, June 14, 2010 07:59:45 pm Darren VanBuren wrote:
  Yes, 3D drivers are definitely quite lacking on the GNU/Linux front,
  but if Valve shows support for the development of these drivers, this
  may prompt certain GPU manufacturers to step up their GNU/Linux driver
  development.
 
  Darren L. VanBuren
  =
  http://theoks.net/
  On Mon, Jun 14, 2010 at 18:35, Bob Somers magicbob...@gmail.com wrote:
   Something to consider, though, is that the 3D driver support is years
   behind from *ahem* a particular GPU manufacturer. I won't embarrass
   them by saying their name, so I'll just say their initials: ATI.
  
   Their driver support for Linux is, frankly, pathetic at best. The
   Fedora team is trying to solve this with their new free drivers in
   Fedora 13 (which, I'll admit, are quite good), but it's still not up
   to par with what you need to run a game. For example, the new free
   drivers have very little (read: practically none) support for basic
   vertex and fragment shaders. It will be at least another year before
   the free drivers are up to what ATI's crappy proprietary drivers are
   now. Even worse, right now you can get the proprietary drivers running
   on Fedora 11 alright, sort-of on Fedora 12 with some ugly hackery, and
   not at all on Fedora 13. Literally, ATI's Linux drivers are at least
   12 months behind, and the free ones are 12 months behind that.
  
   Unless somebody gives ATI a swift kick in the nuts the situation does
   not look good.
  
   --Bob
  
  
  
  
  
   On Mon, Jun 14, 2010 at 5:01 PM, Darren VanBuren onekop...@gmail.com
 wrote:
   Spoiler Alert. It's like the ratman drawing that says She's watching
   you. Canonical is she in that case.
  
   I'm personally a fan of Fedora, but if Steam on GNU/Linux is
   distributed as a tarball, that'd be best in the interests of Valve.
   Even if some people (mainly Ubuntu users) would be a bit stuck on the
   concept of a tarball, it'd be minimal work for Valve, and maximum
   cross-distribution compatibility.
  
   Darren L. VanBuren
   =
   http://theoks.net/
  
  
  
   On Mon, Jun 14, 2010 at 16:49, Harry Jeffery
   harry101jeff...@googlemail.com wrote:
   It's all down to personal opinion, as long as it does what you need
   quickly and effectively then it's fine. I've yet to see the dark side
   in cannonical so I honestly can't say much about their ethics.
  
   Either way, I 3 Linux and so should Valve.
  
   On 15 June 2010 00:19, Katrina Payne fullmetalhar...@nimhlabs.com
 wrote:
   Well a few points:
  
   The commands in the Linux Commandline... and well those on any UNIX
 or
 UNIX
   Workalike have not really changed since the 1970s. You could pick up
 a
 book on
   BASH or TCSH from the 1970s, and still have most of what you should
 do.
  
   This kind of has allowed for tools to be put around

Re: [hlcoders] Source Engine 2!!!

2010-06-17 Thread Harry Jeffery

I noticed that too, lighting is one of the major things the source
engine sucks at. Hopefully Source 2011 will make the life of modders
10x easier.

On 17 June 2010 15:11, Adam Buckland adamjbuckl...@gmail.com wrote:
 Also, after looking at the Portal 2 gameplay footage from IGN:
 http://www.youtube.com/watch?v=5THiN8szSKM (there's 3 parts) am I the
 only one that thinks that the lighting system has had to have a large
 overhaul to support how the levels change dynamically? (particularly
 obvious in the part 1)

 On 17 June 2010 14:58, Alexander Hirsch 1ze...@googlemail.com wrote:
 Mesa3D?

 On Tue, Jun 15, 2010 at 5:20 AM, Katrina Payne fullmetalhar...@nimhlabs.com
 wrote:

 This also adds a rather odd burden here, that allows Linux to get a better
 standing for gaming.

 It is not that unknown that without mixing, Linux generally does not
 require
 anywhere near as much over head to run as windows.

 The minimum requirements to run a GUI on Linux is about 256MiB of RAM. This
 even includes GUIs like KDE and Gnome. Though XFCE and LXCE would be better
 if
 you really did only have 256MiB of RAM (well if you were using a DE... and
 not
 a slimmed down WM with only a few programs loaded into it)

 You can do just fine win 1GiB of RAM.

 Linux also, as an OS can run on some old Intel boards--that running an OS
 on
 would other wise be insane today. a Pentium 1 can still get (some) use with
 Linux.

 Not enough to really be noteworthy as a desktop PC... but, this is a lot
 less
 than the least you will get Windows 7 onto.

 So we have a nice toss up here:

 1: Linux requires Software Rendering in place. IE: how rendering was done,
 before we got silly things like TNT and Voodoo on the market.

 2: Linux requires significantly less overhead to run, as far as OS goes.

 If we can get it so that we can show Steam running on Linux, using mostly
 Software Rendering, and getting it to run as fast as the same game on
 Windows,
 on comparable hardware...

 This will definitely sell Linux as an OS...

 Which in turn will get various Graphics Card makers on board to add their
 support.

 You know--I kind of want to see somebody work on that goal then. I am
 almost
 ready to dig up some old books that go over the theory of 3d programming,
 just
 to pull make a software rendering engine for this idea.

 On Monday, June 14, 2010 07:59:45 pm Darren VanBuren wrote:
  Yes, 3D drivers are definitely quite lacking on the GNU/Linux front,
  but if Valve shows support for the development of these drivers, this
  may prompt certain GPU manufacturers to step up their GNU/Linux driver
  development.
 
  Darren L. VanBuren
  =
  http://theoks.net/
  On Mon, Jun 14, 2010 at 18:35, Bob Somers magicbob...@gmail.com wrote:
   Something to consider, though, is that the 3D driver support is years
   behind from *ahem* a particular GPU manufacturer. I won't embarrass
   them by saying their name, so I'll just say their initials: ATI.
  
   Their driver support for Linux is, frankly, pathetic at best. The
   Fedora team is trying to solve this with their new free drivers in
   Fedora 13 (which, I'll admit, are quite good), but it's still not up
   to par with what you need to run a game. For example, the new free
   drivers have very little (read: practically none) support for basic
   vertex and fragment shaders. It will be at least another year before
   the free drivers are up to what ATI's crappy proprietary drivers are
   now. Even worse, right now you can get the proprietary drivers running
   on Fedora 11 alright, sort-of on Fedora 12 with some ugly hackery, and
   not at all on Fedora 13. Literally, ATI's Linux drivers are at least
   12 months behind, and the free ones are 12 months behind that.
  
   Unless somebody gives ATI a swift kick in the nuts the situation does
   not look good.
  
   --Bob
  
  
  
  
  
   On Mon, Jun 14, 2010 at 5:01 PM, Darren VanBuren onekop...@gmail.com
 wrote:
   Spoiler Alert. It's like the ratman drawing that says She's watching
   you. Canonical is she in that case.
  
   I'm personally a fan of Fedora, but if Steam on GNU/Linux is
   distributed as a tarball, that'd be best in the interests of Valve.
   Even if some people (mainly Ubuntu users) would be a bit stuck on the
   concept of a tarball, it'd be minimal work for Valve, and maximum
   cross-distribution compatibility.
  
   Darren L. VanBuren
   =
   http://theoks.net/
  
  
  
   On Mon, Jun 14, 2010 at 16:49, Harry Jeffery
   harry101jeff...@googlemail.com wrote:
   It's all down to personal opinion, as long as it does what you need
   quickly and effectively then it's fine. I've yet to see the dark side
   in cannonical so I honestly can't say much about their ethics.
  
   Either way, I 3 Linux and so should Valve.
  
   On 15 June 2010 00:19, Katrina Payne fullmetalhar...@nimhlabs.com
 wrote:
   Well a few points:
  
   The commands in the Linux Commandline... and well those on any UNIX
 or

Re: [hlcoders] Source Engine 2!!!

2010-06-17 Thread Adam Buckland

You say that, I'm not sure it's that the lighting 'sucks', but more
that it's a pain in the arse for modders because they don't have
server farms to compile lightmaps unlike Valve.

On 17 June 2010 15:20, Harry Jeffery harry101jeff...@googlemail.com wrote:
 I noticed that too, lighting is one of the major things the source
 engine sucks at. Hopefully Source 2011 will make the life of modders
 10x easier.

 On 17 June 2010 15:11, Adam Buckland adamjbuckl...@gmail.com wrote:
 Also, after looking at the Portal 2 gameplay footage from IGN:
 http://www.youtube.com/watch?v=5THiN8szSKM (there's 3 parts) am I the
 only one that thinks that the lighting system has had to have a large
 overhaul to support how the levels change dynamically? (particularly
 obvious in the part 1)

 On 17 June 2010 14:58, Alexander Hirsch 1ze...@googlemail.com wrote:
 Mesa3D?

 On Tue, Jun 15, 2010 at 5:20 AM, Katrina Payne fullmetalhar...@nimhlabs.com
 wrote:

 This also adds a rather odd burden here, that allows Linux to get a better
 standing for gaming.

 It is not that unknown that without mixing, Linux generally does not
 require
 anywhere near as much over head to run as windows.

 The minimum requirements to run a GUI on Linux is about 256MiB of RAM. This
 even includes GUIs like KDE and Gnome. Though XFCE and LXCE would be better
 if
 you really did only have 256MiB of RAM (well if you were using a DE... and
 not
 a slimmed down WM with only a few programs loaded into it)

 You can do just fine win 1GiB of RAM.

 Linux also, as an OS can run on some old Intel boards--that running an OS
 on
 would other wise be insane today. a Pentium 1 can still get (some) use with
 Linux.

 Not enough to really be noteworthy as a desktop PC... but, this is a lot
 less
 than the least you will get Windows 7 onto.

 So we have a nice toss up here:

 1: Linux requires Software Rendering in place. IE: how rendering was done,
 before we got silly things like TNT and Voodoo on the market.

 2: Linux requires significantly less overhead to run, as far as OS goes.

 If we can get it so that we can show Steam running on Linux, using mostly
 Software Rendering, and getting it to run as fast as the same game on
 Windows,
 on comparable hardware...

 This will definitely sell Linux as an OS...

 Which in turn will get various Graphics Card makers on board to add their
 support.

 You know--I kind of want to see somebody work on that goal then. I am
 almost
 ready to dig up some old books that go over the theory of 3d programming,
 just
 to pull make a software rendering engine for this idea.

 On Monday, June 14, 2010 07:59:45 pm Darren VanBuren wrote:
  Yes, 3D drivers are definitely quite lacking on the GNU/Linux front,
  but if Valve shows support for the development of these drivers, this
  may prompt certain GPU manufacturers to step up their GNU/Linux driver
  development.
 
  Darren L. VanBuren
  =
  http://theoks.net/
  On Mon, Jun 14, 2010 at 18:35, Bob Somers magicbob...@gmail.com wrote:
   Something to consider, though, is that the 3D driver support is years
   behind from *ahem* a particular GPU manufacturer. I won't embarrass
   them by saying their name, so I'll just say their initials: ATI.
  
   Their driver support for Linux is, frankly, pathetic at best. The
   Fedora team is trying to solve this with their new free drivers in
   Fedora 13 (which, I'll admit, are quite good), but it's still not up
   to par with what you need to run a game. For example, the new free
   drivers have very little (read: practically none) support for basic
   vertex and fragment shaders. It will be at least another year before
   the free drivers are up to what ATI's crappy proprietary drivers are
   now. Even worse, right now you can get the proprietary drivers running
   on Fedora 11 alright, sort-of on Fedora 12 with some ugly hackery, and
   not at all on Fedora 13. Literally, ATI's Linux drivers are at least
   12 months behind, and the free ones are 12 months behind that.
  
   Unless somebody gives ATI a swift kick in the nuts the situation does
   not look good.
  
   --Bob
  
  
  
  
  
   On Mon, Jun 14, 2010 at 5:01 PM, Darren VanBuren onekop...@gmail.com
 wrote:
   Spoiler Alert. It's like the ratman drawing that says She's watching
   you. Canonical is she in that case.
  
   I'm personally a fan of Fedora, but if Steam on GNU/Linux is
   distributed as a tarball, that'd be best in the interests of Valve.
   Even if some people (mainly Ubuntu users) would be a bit stuck on the
   concept of a tarball, it'd be minimal work for Valve, and maximum
   cross-distribution compatibility.
  
   Darren L. VanBuren
   =
   http://theoks.net/
  
  
  
   On Mon, Jun 14, 2010 at 16:49, Harry Jeffery
   harry101jeff...@googlemail.com wrote:
   It's all down to personal opinion, as long as it does what you need
   quickly and effectively then it's fine. I've yet to see the dark side
   in cannonical so I honestly

Re: [hlcoders] Source Engine 2!!!

2010-06-17 Thread Harry Jeffery

I was referring to dynamic lights specifically.

On 17 June 2010 15:24, Adam Buckland adamjbuckl...@gmail.com wrote:
 You say that, I'm not sure it's that the lighting 'sucks', but more
 that it's a pain in the arse for modders because they don't have
 server farms to compile lightmaps unlike Valve.

 On 17 June 2010 15:20, Harry Jeffery harry101jeff...@googlemail.com wrote:
 I noticed that too, lighting is one of the major things the source
 engine sucks at. Hopefully Source 2011 will make the life of modders
 10x easier.

 On 17 June 2010 15:11, Adam Buckland adamjbuckl...@gmail.com wrote:
 Also, after looking at the Portal 2 gameplay footage from IGN:
 http://www.youtube.com/watch?v=5THiN8szSKM (there's 3 parts) am I the
 only one that thinks that the lighting system has had to have a large
 overhaul to support how the levels change dynamically? (particularly
 obvious in the part 1)

 On 17 June 2010 14:58, Alexander Hirsch 1ze...@googlemail.com wrote:
 Mesa3D?

 On Tue, Jun 15, 2010 at 5:20 AM, Katrina Payne 
 fullmetalhar...@nimhlabs.com
 wrote:

 This also adds a rather odd burden here, that allows Linux to get a better
 standing for gaming.

 It is not that unknown that without mixing, Linux generally does not
 require
 anywhere near as much over head to run as windows.

 The minimum requirements to run a GUI on Linux is about 256MiB of RAM. 
 This
 even includes GUIs like KDE and Gnome. Though XFCE and LXCE would be 
 better
 if
 you really did only have 256MiB of RAM (well if you were using a DE... and
 not
 a slimmed down WM with only a few programs loaded into it)

 You can do just fine win 1GiB of RAM.

 Linux also, as an OS can run on some old Intel boards--that running an OS
 on
 would other wise be insane today. a Pentium 1 can still get (some) use 
 with
 Linux.

 Not enough to really be noteworthy as a desktop PC... but, this is a lot
 less
 than the least you will get Windows 7 onto.

 So we have a nice toss up here:

 1: Linux requires Software Rendering in place. IE: how rendering was done,
 before we got silly things like TNT and Voodoo on the market.

 2: Linux requires significantly less overhead to run, as far as OS goes.

 If we can get it so that we can show Steam running on Linux, using mostly
 Software Rendering, and getting it to run as fast as the same game on
 Windows,
 on comparable hardware...

 This will definitely sell Linux as an OS...

 Which in turn will get various Graphics Card makers on board to add their
 support.

 You know--I kind of want to see somebody work on that goal then. I am
 almost
 ready to dig up some old books that go over the theory of 3d programming,
 just
 to pull make a software rendering engine for this idea.

 On Monday, June 14, 2010 07:59:45 pm Darren VanBuren wrote:
  Yes, 3D drivers are definitely quite lacking on the GNU/Linux front,
  but if Valve shows support for the development of these drivers, this
  may prompt certain GPU manufacturers to step up their GNU/Linux driver
  development.
 
  Darren L. VanBuren
  =
  http://theoks.net/
  On Mon, Jun 14, 2010 at 18:35, Bob Somers magicbob...@gmail.com wrote:
   Something to consider, though, is that the 3D driver support is years
   behind from *ahem* a particular GPU manufacturer. I won't embarrass
   them by saying their name, so I'll just say their initials: ATI.
  
   Their driver support for Linux is, frankly, pathetic at best. The
   Fedora team is trying to solve this with their new free drivers in
   Fedora 13 (which, I'll admit, are quite good), but it's still not up
   to par with what you need to run a game. For example, the new free
   drivers have very little (read: practically none) support for basic
   vertex and fragment shaders. It will be at least another year before
   the free drivers are up to what ATI's crappy proprietary drivers are
   now. Even worse, right now you can get the proprietary drivers running
   on Fedora 11 alright, sort-of on Fedora 12 with some ugly hackery, and
   not at all on Fedora 13. Literally, ATI's Linux drivers are at least
   12 months behind, and the free ones are 12 months behind that.
  
   Unless somebody gives ATI a swift kick in the nuts the situation does
   not look good.
  
   --Bob
  
  
  
  
  
   On Mon, Jun 14, 2010 at 5:01 PM, Darren VanBuren onekop...@gmail.com
 wrote:
   Spoiler Alert. It's like the ratman drawing that says She's watching
   you. Canonical is she in that case.
  
   I'm personally a fan of Fedora, but if Steam on GNU/Linux is
   distributed as a tarball, that'd be best in the interests of Valve.
   Even if some people (mainly Ubuntu users) would be a bit stuck on the
   concept of a tarball, it'd be minimal work for Valve, and maximum
   cross-distribution compatibility.
  
   Darren L. VanBuren
   =
   http://theoks.net/
  
  
  
   On Mon, Jun 14, 2010 at 16:49, Harry Jeffery
   harry101jeff...@googlemail.com wrote:
   It's all down to personal opinion, as long as

Re: [hlcoders] Source Engine 2!!!

2010-06-17 Thread Jonas 'Sortie' Termansen

On 2010-06-17 16:24, Adam Buckland wrote:
 You say that, I'm not sure it's that the lighting 'sucks', but more
 that it's a pain in the arse for modders because they don't have
 server farms to compile lightmaps unlike Valve.

What do you mean? I have an Intel Core i7 920 (8 cores @ 2.66Ghz). 
Combined with heavily optimized maps, that's practically a server farm. ;)

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Source Engine 2!!!

2010-06-17 Thread Tobias Kammersgaard

VMPI is supported for vvis and broken for vrad isn't it?
I haven't checked since the last SDK update, but imagine it isn't fixed.
Which is lame.

- ScarT


On 17 June 2010 16:53, Jonas 'Sortie' Termansen hlcod...@maxsi.dk wrote:

 On 2010-06-17 16:24, Adam Buckland wrote:
  You say that, I'm not sure it's that the lighting 'sucks', but more
  that it's a pain in the arse for modders because they don't have
  server farms to compile lightmaps unlike Valve.
 
 What do you mean? I have an Intel Core i7 920 (8 cores @ 2.66Ghz).
 Combined with heavily optimized maps, that's practically a server farm. ;)

 ___
 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] Source Engine 2!!!

2010-06-17 Thread Matt Hoffman

Pretty sure a fix was found. VVIS worked fine (to my memory) and VRAD
crashed. However if you use LAA on the vrad process, it worked again.

Fix by The Pro here:
http://www.facepunch.com/showpost.php?p=16482883postcount=23

I recall this working, but I do not know if Valve has fixed/broken it since
then.


On Thu, Jun 17, 2010 at 8:20 AM, Tobias Kammersgaard 
tobias.kammersga...@gmail.com wrote:

 VMPI is supported for vvis and broken for vrad isn't it?
 I haven't checked since the last SDK update, but imagine it isn't fixed.
 Which is lame.

 - ScarT


 On 17 June 2010 16:53, Jonas 'Sortie' Termansen hlcod...@maxsi.dk wrote:

  On 2010-06-17 16:24, Adam Buckland wrote:
   You say that, I'm not sure it's that the lighting 'sucks', but more
   that it's a pain in the arse for modders because they don't have
   server farms to compile lightmaps unlike Valve.
  
  What do you mean? I have an Intel Core i7 920 (8 cores @ 2.66Ghz).
  Combined with heavily optimized maps, that's practically a server farm.
 ;)
 
  ___
  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] Source Engine 2!!!

2010-06-17 Thread Bob Somers

New version of the engine uses deferred shading perhaps?

I suppose that would be too much to ask for.

--Bob





On Thu, Jun 17, 2010 at 8:45 AM, Matt Hoffman
lord.matt.hoff...@gmail.com wrote:
 Pretty sure a fix was found. VVIS worked fine (to my memory) and VRAD
 crashed. However if you use LAA on the vrad process, it worked again.

 Fix by The Pro here:
 http://www.facepunch.com/showpost.php?p=16482883postcount=23

 I recall this working, but I do not know if Valve has fixed/broken it since
 then.


 On Thu, Jun 17, 2010 at 8:20 AM, Tobias Kammersgaard 
 tobias.kammersga...@gmail.com wrote:

 VMPI is supported for vvis and broken for vrad isn't it?
 I haven't checked since the last SDK update, but imagine it isn't fixed.
 Which is lame.

 - ScarT


 On 17 June 2010 16:53, Jonas 'Sortie' Termansen hlcod...@maxsi.dk wrote:

  On 2010-06-17 16:24, Adam Buckland wrote:
   You say that, I'm not sure it's that the lighting 'sucks', but more
   that it's a pain in the arse for modders because they don't have
   server farms to compile lightmaps unlike Valve.
  
  What do you mean? I have an Intel Core i7 920 (8 cores @ 2.66Ghz).
  Combined with heavily optimized maps, that's practically a server farm.
 ;)
 
  ___
  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] Source Engine 2!!!

2010-06-15 Thread Bob Somers

Uh, have fun with that.

--Bob





On Mon, Jun 14, 2010 at 8:20 PM, Katrina Payne
fullmetalhar...@nimhlabs.com wrote:
 This also adds a rather odd burden here, that allows Linux to get a better
 standing for gaming.

 It is not that unknown that without mixing, Linux generally does not require
 anywhere near as much over head to run as windows.

 The minimum requirements to run a GUI on Linux is about 256MiB of RAM. This
 even includes GUIs like KDE and Gnome. Though XFCE and LXCE would be better if
 you really did only have 256MiB of RAM (well if you were using a DE... and not
 a slimmed down WM with only a few programs loaded into it)

 You can do just fine win 1GiB of RAM.

 Linux also, as an OS can run on some old Intel boards--that running an OS on
 would other wise be insane today. a Pentium 1 can still get (some) use with
 Linux.

 Not enough to really be noteworthy as a desktop PC... but, this is a lot less
 than the least you will get Windows 7 onto.

 So we have a nice toss up here:

 1: Linux requires Software Rendering in place. IE: how rendering was done,
 before we got silly things like TNT and Voodoo on the market.

 2: Linux requires significantly less overhead to run, as far as OS goes.

 If we can get it so that we can show Steam running on Linux, using mostly
 Software Rendering, and getting it to run as fast as the same game on Windows,
 on comparable hardware...

 This will definitely sell Linux as an OS...

 Which in turn will get various Graphics Card makers on board to add their
 support.

 You know--I kind of want to see somebody work on that goal then. I am almost
 ready to dig up some old books that go over the theory of 3d programming, just
 to pull make a software rendering engine for this idea.

 On Monday, June 14, 2010 07:59:45 pm Darren VanBuren wrote:
 Yes, 3D drivers are definitely quite lacking on the GNU/Linux front,
 but if Valve shows support for the development of these drivers, this
 may prompt certain GPU manufacturers to step up their GNU/Linux driver
 development.

 Darren L. VanBuren
 =
 http://theoks.net/
 On Mon, Jun 14, 2010 at 18:35, Bob Somers magicbob...@gmail.com wrote:
  Something to consider, though, is that the 3D driver support is years
  behind from *ahem* a particular GPU manufacturer. I won't embarrass
  them by saying their name, so I'll just say their initials: ATI.
 
  Their driver support for Linux is, frankly, pathetic at best. The
  Fedora team is trying to solve this with their new free drivers in
  Fedora 13 (which, I'll admit, are quite good), but it's still not up
  to par with what you need to run a game. For example, the new free
  drivers have very little (read: practically none) support for basic
  vertex and fragment shaders. It will be at least another year before
  the free drivers are up to what ATI's crappy proprietary drivers are
  now. Even worse, right now you can get the proprietary drivers running
  on Fedora 11 alright, sort-of on Fedora 12 with some ugly hackery, and
  not at all on Fedora 13. Literally, ATI's Linux drivers are at least
  12 months behind, and the free ones are 12 months behind that.
 
  Unless somebody gives ATI a swift kick in the nuts the situation does
  not look good.
 
  --Bob
 
 
 
 
 
  On Mon, Jun 14, 2010 at 5:01 PM, Darren VanBuren onekop...@gmail.com
 wrote:
  Spoiler Alert. It's like the ratman drawing that says She's watching
  you. Canonical is she in that case.
 
  I'm personally a fan of Fedora, but if Steam on GNU/Linux is
  distributed as a tarball, that'd be best in the interests of Valve.
  Even if some people (mainly Ubuntu users) would be a bit stuck on the
  concept of a tarball, it'd be minimal work for Valve, and maximum
  cross-distribution compatibility.
 
  Darren L. VanBuren
  =
  http://theoks.net/
 
 
 
  On Mon, Jun 14, 2010 at 16:49, Harry Jeffery
  harry101jeff...@googlemail.com wrote:
  It's all down to personal opinion, as long as it does what you need
  quickly and effectively then it's fine. I've yet to see the dark side
  in cannonical so I honestly can't say much about their ethics.
 
  Either way, I 3 Linux and so should Valve.
 
  On 15 June 2010 00:19, Katrina Payne fullmetalhar...@nimhlabs.com
 wrote:
  Well a few points:
 
  The commands in the Linux Commandline... and well those on any UNIX or
 UNIX
  Workalike have not really changed since the 1970s. You could pick up a
 book on
  BASH or TCSH from the 1970s, and still have most of what you should do.
 
  This kind of has allowed for tools to be put around these base
 functions, such
  as autocomplete, history and well--quite a few other really handy
 tools, to be
  added into the Linux CLI, to make its functionality go above and beyond
  anything cmd.exe is capable of.
 
  I still have yet to look into Microsoft's PowerShell though.
 
  This is why most Linux users use the CLI. It has developed into an
 experience
  that is completely unlike the root canal that is

Re: [hlcoders] Source Engine 2!!!

2010-06-15 Thread Katrina Payne

Well, considering how crazy this idea is... that is likely all I would be 
having with it...

Regardless of whether or not it works.

This is like Joker from Batman type crazy here...

So, yeah, I will X3

The issue is I have too much other crap on my plate right now--however, I am 
certain there are other crazy people on this mailing list who have the time 
for this suggestion.

On Tuesday, June 15, 2010 12:14:42 am Bob Somers wrote:
 Uh, have fun with that.
 
 --Bob
 On Mon, Jun 14, 2010 at 8:20 PM, Katrina Payne
 fullmetalhar...@nimhlabs.com wrote:
  This also adds a rather odd burden here, that allows Linux to get a better
  standing for gaming.
 
  It is not that unknown that without mixing, Linux generally does not 
require
  anywhere near as much over head to run as windows.
 
  The minimum requirements to run a GUI on Linux is about 256MiB of RAM. 
This
  even includes GUIs like KDE and Gnome. Though XFCE and LXCE would be 
better if
  you really did only have 256MiB of RAM (well if you were using a DE... and 
not
  a slimmed down WM with only a few programs loaded into it)
 
  You can do just fine win 1GiB of RAM.
 
  Linux also, as an OS can run on some old Intel boards--that running an OS 
on
  would other wise be insane today. a Pentium 1 can still get (some) use 
with
  Linux.
 
  Not enough to really be noteworthy as a desktop PC... but, this is a lot 
less
  than the least you will get Windows 7 onto.
 
  So we have a nice toss up here:
 
  1: Linux requires Software Rendering in place. IE: how rendering was done,
  before we got silly things like TNT and Voodoo on the market.
 
  2: Linux requires significantly less overhead to run, as far as OS goes.
 
  If we can get it so that we can show Steam running on Linux, using mostly
  Software Rendering, and getting it to run as fast as the same game on 
Windows,
  on comparable hardware...
 
  This will definitely sell Linux as an OS...
 
  Which in turn will get various Graphics Card makers on board to add their
  support.
 
  You know--I kind of want to see somebody work on that goal then. I am 
almost
  ready to dig up some old books that go over the theory of 3d programming, 
just
  to pull make a software rendering engine for this idea.
 
  On Monday, June 14, 2010 07:59:45 pm Darren VanBuren wrote:
  Yes, 3D drivers are definitely quite lacking on the GNU/Linux front,
  but if Valve shows support for the development of these drivers, this
  may prompt certain GPU manufacturers to step up their GNU/Linux driver
  development.
 
  Darren L. VanBuren
  =
  http://theoks.net/
  On Mon, Jun 14, 2010 at 18:35, Bob Somers magicbob...@gmail.com wrote:
   Something to consider, though, is that the 3D driver support is years
   behind from *ahem* a particular GPU manufacturer. I won't embarrass
   them by saying their name, so I'll just say their initials: ATI.
  
   Their driver support for Linux is, frankly, pathetic at best. The
   Fedora team is trying to solve this with their new free drivers in
   Fedora 13 (which, I'll admit, are quite good), but it's still not up
   to par with what you need to run a game. For example, the new free
   drivers have very little (read: practically none) support for basic
   vertex and fragment shaders. It will be at least another year before
   the free drivers are up to what ATI's crappy proprietary drivers are
   now. Even worse, right now you can get the proprietary drivers running
   on Fedora 11 alright, sort-of on Fedora 12 with some ugly hackery, and
   not at all on Fedora 13. Literally, ATI's Linux drivers are at least
   12 months behind, and the free ones are 12 months behind that.
  
   Unless somebody gives ATI a swift kick in the nuts the situation does
   not look good.
  
   --Bob
  
  
  
  
  
   On Mon, Jun 14, 2010 at 5:01 PM, Darren VanBuren onekop...@gmail.com
  wrote:
   Spoiler Alert. It's like the ratman drawing that says She's watching
   you. Canonical is she in that case.
  
   I'm personally a fan of Fedora, but if Steam on GNU/Linux is
   distributed as a tarball, that'd be best in the interests of Valve.
   Even if some people (mainly Ubuntu users) would be a bit stuck on the
   concept of a tarball, it'd be minimal work for Valve, and maximum
   cross-distribution compatibility.
  
   Darren L. VanBuren
   =
   http://theoks.net/
  
  
  
   On Mon, Jun 14, 2010 at 16:49, Harry Jeffery
   harry101jeff...@googlemail.com wrote:
   It's all down to personal opinion, as long as it does what you need
   quickly and effectively then it's fine. I've yet to see the dark side
   in cannonical so I honestly can't say much about their ethics.
  
   Either way, I 3 Linux and so should Valve.
  
   On 15 June 2010 00:19, Katrina Payne fullmetalhar...@nimhlabs.com
  wrote:
   Well a few points:
  
   The commands in the Linux Commandline... and well those on any UNIX 
or
  UNIX
   Workalike have not really changed since the 1970s. You could pick up 
a

Re: [hlcoders] Source Engine 2!!!

2010-06-15 Thread Bob Somers

Trying to make a software renderer compete with a dedicated GPU is
kind of, uh, an exercise in futility.

--Bob





On Mon, Jun 14, 2010 at 11:20 PM, Katrina Payne
fullmetalhar...@nimhlabs.com wrote:
 Well, considering how crazy this idea is... that is likely all I would be
 having with it...

 Regardless of whether or not it works.

 This is like Joker from Batman type crazy here...

 So, yeah, I will X3

 The issue is I have too much other crap on my plate right now--however, I am
 certain there are other crazy people on this mailing list who have the time
 for this suggestion.

 On Tuesday, June 15, 2010 12:14:42 am Bob Somers wrote:
 Uh, have fun with that.

 --Bob
 On Mon, Jun 14, 2010 at 8:20 PM, Katrina Payne
 fullmetalhar...@nimhlabs.com wrote:
  This also adds a rather odd burden here, that allows Linux to get a better
  standing for gaming.
 
  It is not that unknown that without mixing, Linux generally does not
 require
  anywhere near as much over head to run as windows.
 
  The minimum requirements to run a GUI on Linux is about 256MiB of RAM.
 This
  even includes GUIs like KDE and Gnome. Though XFCE and LXCE would be
 better if
  you really did only have 256MiB of RAM (well if you were using a DE... and
 not
  a slimmed down WM with only a few programs loaded into it)
 
  You can do just fine win 1GiB of RAM.
 
  Linux also, as an OS can run on some old Intel boards--that running an OS
 on
  would other wise be insane today. a Pentium 1 can still get (some) use
 with
  Linux.
 
  Not enough to really be noteworthy as a desktop PC... but, this is a lot
 less
  than the least you will get Windows 7 onto.
 
  So we have a nice toss up here:
 
  1: Linux requires Software Rendering in place. IE: how rendering was done,
  before we got silly things like TNT and Voodoo on the market.
 
  2: Linux requires significantly less overhead to run, as far as OS goes.
 
  If we can get it so that we can show Steam running on Linux, using mostly
  Software Rendering, and getting it to run as fast as the same game on
 Windows,
  on comparable hardware...
 
  This will definitely sell Linux as an OS...
 
  Which in turn will get various Graphics Card makers on board to add their
  support.
 
  You know--I kind of want to see somebody work on that goal then. I am
 almost
  ready to dig up some old books that go over the theory of 3d programming,
 just
  to pull make a software rendering engine for this idea.
 
  On Monday, June 14, 2010 07:59:45 pm Darren VanBuren wrote:
  Yes, 3D drivers are definitely quite lacking on the GNU/Linux front,
  but if Valve shows support for the development of these drivers, this
  may prompt certain GPU manufacturers to step up their GNU/Linux driver
  development.
 
  Darren L. VanBuren
  =
  http://theoks.net/
  On Mon, Jun 14, 2010 at 18:35, Bob Somers magicbob...@gmail.com wrote:
   Something to consider, though, is that the 3D driver support is years
   behind from *ahem* a particular GPU manufacturer. I won't embarrass
   them by saying their name, so I'll just say their initials: ATI.
  
   Their driver support for Linux is, frankly, pathetic at best. The
   Fedora team is trying to solve this with their new free drivers in
   Fedora 13 (which, I'll admit, are quite good), but it's still not up
   to par with what you need to run a game. For example, the new free
   drivers have very little (read: practically none) support for basic
   vertex and fragment shaders. It will be at least another year before
   the free drivers are up to what ATI's crappy proprietary drivers are
   now. Even worse, right now you can get the proprietary drivers running
   on Fedora 11 alright, sort-of on Fedora 12 with some ugly hackery, and
   not at all on Fedora 13. Literally, ATI's Linux drivers are at least
   12 months behind, and the free ones are 12 months behind that.
  
   Unless somebody gives ATI a swift kick in the nuts the situation does
   not look good.
  
   --Bob
  
  
  
  
  
   On Mon, Jun 14, 2010 at 5:01 PM, Darren VanBuren onekop...@gmail.com
  wrote:
   Spoiler Alert. It's like the ratman drawing that says She's watching
   you. Canonical is she in that case.
  
   I'm personally a fan of Fedora, but if Steam on GNU/Linux is
   distributed as a tarball, that'd be best in the interests of Valve.
   Even if some people (mainly Ubuntu users) would be a bit stuck on the
   concept of a tarball, it'd be minimal work for Valve, and maximum
   cross-distribution compatibility.
  
   Darren L. VanBuren
   =
   http://theoks.net/
  
  
  
   On Mon, Jun 14, 2010 at 16:49, Harry Jeffery
   harry101jeff...@googlemail.com wrote:
   It's all down to personal opinion, as long as it does what you need
   quickly and effectively then it's fine. I've yet to see the dark side
   in cannonical so I honestly can't say much about their ethics.
  
   Either way, I 3 Linux and so should Valve.
  
   On 15 June 2010 00:19, Katrina Payne

Re: [hlcoders] Source Engine 2!!!

2010-06-15 Thread Adam Buckland

I was under the impression that the whole point of building GPUs in
the first place was because it was impossible to build a software
renderer of comparable speed :P

On 15 June 2010 20:39, Bob Somers magicbob...@gmail.com wrote:
 Trying to make a software renderer compete with a dedicated GPU is
 kind of, uh, an exercise in futility.

 --Bob





 On Mon, Jun 14, 2010 at 11:20 PM, Katrina Payne
 fullmetalhar...@nimhlabs.com wrote:
 Well, considering how crazy this idea is... that is likely all I would be
 having with it...

 Regardless of whether or not it works.

 This is like Joker from Batman type crazy here...

 So, yeah, I will X3

 The issue is I have too much other crap on my plate right now--however, I am
 certain there are other crazy people on this mailing list who have the time
 for this suggestion.

 On Tuesday, June 15, 2010 12:14:42 am Bob Somers wrote:
 Uh, have fun with that.

 --Bob
 On Mon, Jun 14, 2010 at 8:20 PM, Katrina Payne
 fullmetalhar...@nimhlabs.com wrote:
  This also adds a rather odd burden here, that allows Linux to get a better
  standing for gaming.
 
  It is not that unknown that without mixing, Linux generally does not
 require
  anywhere near as much over head to run as windows.
 
  The minimum requirements to run a GUI on Linux is about 256MiB of RAM.
 This
  even includes GUIs like KDE and Gnome. Though XFCE and LXCE would be
 better if
  you really did only have 256MiB of RAM (well if you were using a DE... and
 not
  a slimmed down WM with only a few programs loaded into it)
 
  You can do just fine win 1GiB of RAM.
 
  Linux also, as an OS can run on some old Intel boards--that running an OS
 on
  would other wise be insane today. a Pentium 1 can still get (some) use
 with
  Linux.
 
  Not enough to really be noteworthy as a desktop PC... but, this is a lot
 less
  than the least you will get Windows 7 onto.
 
  So we have a nice toss up here:
 
  1: Linux requires Software Rendering in place. IE: how rendering was done,
  before we got silly things like TNT and Voodoo on the market.
 
  2: Linux requires significantly less overhead to run, as far as OS goes.
 
  If we can get it so that we can show Steam running on Linux, using mostly
  Software Rendering, and getting it to run as fast as the same game on
 Windows,
  on comparable hardware...
 
  This will definitely sell Linux as an OS...
 
  Which in turn will get various Graphics Card makers on board to add their
  support.
 
  You know--I kind of want to see somebody work on that goal then. I am
 almost
  ready to dig up some old books that go over the theory of 3d programming,
 just
  to pull make a software rendering engine for this idea.
 
  On Monday, June 14, 2010 07:59:45 pm Darren VanBuren wrote:
  Yes, 3D drivers are definitely quite lacking on the GNU/Linux front,
  but if Valve shows support for the development of these drivers, this
  may prompt certain GPU manufacturers to step up their GNU/Linux driver
  development.
 
  Darren L. VanBuren
  =
  http://theoks.net/
  On Mon, Jun 14, 2010 at 18:35, Bob Somers magicbob...@gmail.com wrote:
   Something to consider, though, is that the 3D driver support is years
   behind from *ahem* a particular GPU manufacturer. I won't embarrass
   them by saying their name, so I'll just say their initials: ATI.
  
   Their driver support for Linux is, frankly, pathetic at best. The
   Fedora team is trying to solve this with their new free drivers in
   Fedora 13 (which, I'll admit, are quite good), but it's still not up
   to par with what you need to run a game. For example, the new free
   drivers have very little (read: practically none) support for basic
   vertex and fragment shaders. It will be at least another year before
   the free drivers are up to what ATI's crappy proprietary drivers are
   now. Even worse, right now you can get the proprietary drivers running
   on Fedora 11 alright, sort-of on Fedora 12 with some ugly hackery, and
   not at all on Fedora 13. Literally, ATI's Linux drivers are at least
   12 months behind, and the free ones are 12 months behind that.
  
   Unless somebody gives ATI a swift kick in the nuts the situation does
   not look good.
  
   --Bob
  
  
  
  
  
   On Mon, Jun 14, 2010 at 5:01 PM, Darren VanBuren onekop...@gmail.com
  wrote:
   Spoiler Alert. It's like the ratman drawing that says She's watching
   you. Canonical is she in that case.
  
   I'm personally a fan of Fedora, but if Steam on GNU/Linux is
   distributed as a tarball, that'd be best in the interests of Valve.
   Even if some people (mainly Ubuntu users) would be a bit stuck on the
   concept of a tarball, it'd be minimal work for Valve, and maximum
   cross-distribution compatibility.
  
   Darren L. VanBuren
   =
   http://theoks.net/
  
  
  
   On Mon, Jun 14, 2010 at 16:49, Harry Jeffery
   harry101jeff...@googlemail.com wrote:
   It's all down to personal opinion, as long as it does what you need
   quickly

Re: [hlcoders] Source Engine 2!!!

2010-06-14 Thread Katrina Payne

Well a few points:

The commands in the Linux Commandline... and well those on any UNIX or UNIX 
Workalike have not really changed since the 1970s. You could pick up a book on 
BASH or TCSH from the 1970s, and still have most of what you should do.

This kind of has allowed for tools to be put around these base functions, such 
as autocomplete, history and well--quite a few other really handy tools, to be 
added into the Linux CLI, to make its functionality go above and beyond 
anything cmd.exe is capable of.

I still have yet to look into Microsoft's PowerShell though.

This is why most Linux users use the CLI. It has developed into an experience 
that is completely unlike the root canal that is cmd.exe. You can actually go 
in, and get some functionality from it. A lot of functionality too. It also 
gives the feeling that the user has more direct control--without that Pesky 
GUI in the way (though, technically, this just has a bunch of other items 
typically in the way, such as init.d, bash, various bash extensions--maybe 
screen... you are just trading one thing in the way, that is, a GUI, for 
another thing, that is a CLI).

Now, that said--there are plenty of Desktop Environments ('DE') that Linux can 
make use of, that pretty much make requirement of CLI use unnecessary. That 
is, between KDE4, LXDE, XFCE, E17 and GNOME2/GTK, the average Linux user 
nearly never has to do anything on the CLI. Unless something has gone horribly 
wrong. In which case, he should be able to get the local Linux Admin to fix it.

As that technically is what he'd do if something went horribly wrong on 
Windows. He'd get his local Windows Expert to fix it.

The required use of the CLI rather than GUI to properly use Linux, is much 
like how using Vi is required rather than EMACS for the proper use of Linux.

Also, I use Fedora, and typically find it a LOT easier to work with than 
Ubuntu. This maybe, because Fedora tries not to be a bunch of asshats to the 
people upstream. The same cannot be said about Canonical, the owners of 
Ubuntu. Where, from what I have seen on their policies by past actions... 
their MAIN desire is to be asshats to the upstream.

I have a long winded rant on why I do not like Ubuntu... I mostly just state 
that nobody uses Ubuntu Linux. Typically most people go over to another Linux 
Distro afterwards, generally agreeing that no matter what Linux Distro they go 
to, be it Fedora, Puppy (well, prior to being based on Ubuntu), Arch, Slack, 
Gentoo, Knoppix, CentOS, LFS, etc., is better than Ubuntu... either that, or 
they return to Windows--only using Ubuntu as a rescue disk setup.

Right, now then. Back to your regular discussion

~Katrina

On Sunday, June 13, 2010 07:20:08 am Harry Jeffery wrote:
 People like the command line because it's very fast to do what you
 want if you know what you are doing. So far ubuntu seems to be the
 most user friendly linux distro and what a majority of linux gamers
 might use.
 
 Personally I'd just use arch-linux and optimize my system...a lot. As
 long as nVidia release decent linux drivers it's all good.
 
 On 13 June 2010 14:01, Adam Buckland adamjbuckl...@gmail.com wrote:
  A couple of things:
 
  Elan Ruskin gave a good talk on porting to consoles at GDC08. The
  slides are on Valve's website. There's something in there that may
  help you here:
 
  #ifdef __GNUC__
  #define MAXSI_THREADED_VARIABLE __thread
  #else
  #define MAXSI_THREADED_VARIABLE __declspec( thread )
  #endif
 
  You may wish to use another define for windows rather than an else
  statement in case you wish to port it somewhere else in the future.
 
  Also I agree, the Mac and Linux ports are incredibly similar. In fact,
  on the Mac port a shell script is executed first to determine whether
  it's running on OS X or Linux.
 
  Finally Linux could be a great consumer platform. Before it can become
  this, it needs to learn that not everyone is a power user, and make
  things simple. Learn from the Mac app bundles, and remove reliance on
  the command line (for example the output is shown on the update
  software). It scares normal users. That, and a lot of power users
  (like myself), don't want to have to rely on the command line for
  everything.
 
  On 13 June 2010 13:28, Jonas 'Sortie' Termansen hlcod...@maxsi.dk wrote:
  I'd like to share a few experiences about porting code and writing
  portable code. Scroll down, if you just want my thoughts on how portable
  the Source Engine is.
 
  Recently I've been porting my in-development digital distribution
  platform to GNU/Linux for the fun of it. Naturally, most of my code
  didn't work right out of the box. But it is worth that several
  subsystems actually worked at the first attempt, or with an edit or two.
  For instance, my string system and parser classes/functions compiled
  right away.
 
  However, stuff like accessing the filesystem, multithreading, user
  interfaces, networking, and so on didn't work because it relied on the

Re: [hlcoders] Source Engine 2!!!

2010-06-14 Thread Harry Jeffery

It's all down to personal opinion, as long as it does what you need
quickly and effectively then it's fine. I've yet to see the dark side
in cannonical so I honestly can't say much about their ethics.

Either way, I 3 Linux and so should Valve.

On 15 June 2010 00:19, Katrina Payne fullmetalhar...@nimhlabs.com wrote:
 Well a few points:

 The commands in the Linux Commandline... and well those on any UNIX or UNIX
 Workalike have not really changed since the 1970s. You could pick up a book on
 BASH or TCSH from the 1970s, and still have most of what you should do.

 This kind of has allowed for tools to be put around these base functions, such
 as autocomplete, history and well--quite a few other really handy tools, to be
 added into the Linux CLI, to make its functionality go above and beyond
 anything cmd.exe is capable of.

 I still have yet to look into Microsoft's PowerShell though.

 This is why most Linux users use the CLI. It has developed into an experience
 that is completely unlike the root canal that is cmd.exe. You can actually go
 in, and get some functionality from it. A lot of functionality too. It also
 gives the feeling that the user has more direct control--without that Pesky
 GUI in the way (though, technically, this just has a bunch of other items
 typically in the way, such as init.d, bash, various bash extensions--maybe
 screen... you are just trading one thing in the way, that is, a GUI, for
 another thing, that is a CLI).

 Now, that said--there are plenty of Desktop Environments ('DE') that Linux can
 make use of, that pretty much make requirement of CLI use unnecessary. That
 is, between KDE4, LXDE, XFCE, E17 and GNOME2/GTK, the average Linux user
 nearly never has to do anything on the CLI. Unless something has gone horribly
 wrong. In which case, he should be able to get the local Linux Admin to fix 
 it.

 As that technically is what he'd do if something went horribly wrong on
 Windows. He'd get his local Windows Expert to fix it.

 The required use of the CLI rather than GUI to properly use Linux, is much
 like how using Vi is required rather than EMACS for the proper use of Linux.

 Also, I use Fedora, and typically find it a LOT easier to work with than
 Ubuntu. This maybe, because Fedora tries not to be a bunch of asshats to the
 people upstream. The same cannot be said about Canonical, the owners of
 Ubuntu. Where, from what I have seen on their policies by past actions...
 their MAIN desire is to be asshats to the upstream.

 I have a long winded rant on why I do not like Ubuntu... I mostly just state
 that nobody uses Ubuntu Linux. Typically most people go over to another Linux
 Distro afterwards, generally agreeing that no matter what Linux Distro they go
 to, be it Fedora, Puppy (well, prior to being based on Ubuntu), Arch, Slack,
 Gentoo, Knoppix, CentOS, LFS, etc., is better than Ubuntu... either that, or
 they return to Windows--only using Ubuntu as a rescue disk setup.

 Right, now then. Back to your regular discussion

 ~Katrina

 On Sunday, June 13, 2010 07:20:08 am Harry Jeffery wrote:
 People like the command line because it's very fast to do what you
 want if you know what you are doing. So far ubuntu seems to be the
 most user friendly linux distro and what a majority of linux gamers
 might use.

 Personally I'd just use arch-linux and optimize my system...a lot. As
 long as nVidia release decent linux drivers it's all good.

 On 13 June 2010 14:01, Adam Buckland adamjbuckl...@gmail.com wrote:
  A couple of things:
 
  Elan Ruskin gave a good talk on porting to consoles at GDC08. The
  slides are on Valve's website. There's something in there that may
  help you here:
 
  #ifdef __GNUC__
  #define MAXSI_THREADED_VARIABLE __thread
  #else
  #define MAXSI_THREADED_VARIABLE __declspec( thread )
  #endif
 
  You may wish to use another define for windows rather than an else
  statement in case you wish to port it somewhere else in the future.
 
  Also I agree, the Mac and Linux ports are incredibly similar. In fact,
  on the Mac port a shell script is executed first to determine whether
  it's running on OS X or Linux.
 
  Finally Linux could be a great consumer platform. Before it can become
  this, it needs to learn that not everyone is a power user, and make
  things simple. Learn from the Mac app bundles, and remove reliance on
  the command line (for example the output is shown on the update
  software). It scares normal users. That, and a lot of power users
  (like myself), don't want to have to rely on the command line for
  everything.
 
  On 13 June 2010 13:28, Jonas 'Sortie' Termansen hlcod...@maxsi.dk wrote:
  I'd like to share a few experiences about porting code and writing
  portable code. Scroll down, if you just want my thoughts on how portable
  the Source Engine is.
 
  Recently I've been porting my in-development digital distribution
  platform to GNU/Linux for the fun of it. Naturally, most of my code
  didn't work right out of the box. But

Re: [hlcoders] Source Engine 2!!!

2010-06-14 Thread Darren VanBuren

Spoiler Alert. It's like the ratman drawing that says She's watching
you. Canonical is she in that case.

I'm personally a fan of Fedora, but if Steam on GNU/Linux is
distributed as a tarball, that'd be best in the interests of Valve.
Even if some people (mainly Ubuntu users) would be a bit stuck on the
concept of a tarball, it'd be minimal work for Valve, and maximum
cross-distribution compatibility.

Darren L. VanBuren
=
http://theoks.net/



On Mon, Jun 14, 2010 at 16:49, Harry Jeffery
harry101jeff...@googlemail.com wrote:
 It's all down to personal opinion, as long as it does what you need
 quickly and effectively then it's fine. I've yet to see the dark side
 in cannonical so I honestly can't say much about their ethics.

 Either way, I 3 Linux and so should Valve.

 On 15 June 2010 00:19, Katrina Payne fullmetalhar...@nimhlabs.com wrote:
 Well a few points:

 The commands in the Linux Commandline... and well those on any UNIX or UNIX
 Workalike have not really changed since the 1970s. You could pick up a book 
 on
 BASH or TCSH from the 1970s, and still have most of what you should do.

 This kind of has allowed for tools to be put around these base functions, 
 such
 as autocomplete, history and well--quite a few other really handy tools, to 
 be
 added into the Linux CLI, to make its functionality go above and beyond
 anything cmd.exe is capable of.

 I still have yet to look into Microsoft's PowerShell though.

 This is why most Linux users use the CLI. It has developed into an experience
 that is completely unlike the root canal that is cmd.exe. You can actually go
 in, and get some functionality from it. A lot of functionality too. It also
 gives the feeling that the user has more direct control--without that Pesky
 GUI in the way (though, technically, this just has a bunch of other items
 typically in the way, such as init.d, bash, various bash extensions--maybe
 screen... you are just trading one thing in the way, that is, a GUI, for
 another thing, that is a CLI).

 Now, that said--there are plenty of Desktop Environments ('DE') that Linux 
 can
 make use of, that pretty much make requirement of CLI use unnecessary. That
 is, between KDE4, LXDE, XFCE, E17 and GNOME2/GTK, the average Linux user
 nearly never has to do anything on the CLI. Unless something has gone 
 horribly
 wrong. In which case, he should be able to get the local Linux Admin to fix 
 it.

 As that technically is what he'd do if something went horribly wrong on
 Windows. He'd get his local Windows Expert to fix it.

 The required use of the CLI rather than GUI to properly use Linux, is much
 like how using Vi is required rather than EMACS for the proper use of 
 Linux.

 Also, I use Fedora, and typically find it a LOT easier to work with than
 Ubuntu. This maybe, because Fedora tries not to be a bunch of asshats to the
 people upstream. The same cannot be said about Canonical, the owners of
 Ubuntu. Where, from what I have seen on their policies by past actions...
 their MAIN desire is to be asshats to the upstream.

 I have a long winded rant on why I do not like Ubuntu... I mostly just state
 that nobody uses Ubuntu Linux. Typically most people go over to another Linux
 Distro afterwards, generally agreeing that no matter what Linux Distro they 
 go
 to, be it Fedora, Puppy (well, prior to being based on Ubuntu), Arch, Slack,
 Gentoo, Knoppix, CentOS, LFS, etc., is better than Ubuntu... either that, or
 they return to Windows--only using Ubuntu as a rescue disk setup.

 Right, now then. Back to your regular discussion

 ~Katrina

 On Sunday, June 13, 2010 07:20:08 am Harry Jeffery wrote:
 People like the command line because it's very fast to do what you
 want if you know what you are doing. So far ubuntu seems to be the
 most user friendly linux distro and what a majority of linux gamers
 might use.

 Personally I'd just use arch-linux and optimize my system...a lot. As
 long as nVidia release decent linux drivers it's all good.

 On 13 June 2010 14:01, Adam Buckland adamjbuckl...@gmail.com wrote:
  A couple of things:
 
  Elan Ruskin gave a good talk on porting to consoles at GDC08. The
  slides are on Valve's website. There's something in there that may
  help you here:
 
  #ifdef __GNUC__
  #define MAXSI_THREADED_VARIABLE __thread
  #else
  #define MAXSI_THREADED_VARIABLE __declspec( thread )
  #endif
 
  You may wish to use another define for windows rather than an else
  statement in case you wish to port it somewhere else in the future.
 
  Also I agree, the Mac and Linux ports are incredibly similar. In fact,
  on the Mac port a shell script is executed first to determine whether
  it's running on OS X or Linux.
 
  Finally Linux could be a great consumer platform. Before it can become
  this, it needs to learn that not everyone is a power user, and make
  things simple. Learn from the Mac app bundles, and remove reliance on
  the command line (for example the output is shown on the update

Re: [hlcoders] Source Engine 2!!!

2010-06-14 Thread Bob Somers

Something to consider, though, is that the 3D driver support is years
behind from *ahem* a particular GPU manufacturer. I won't embarrass
them by saying their name, so I'll just say their initials: ATI.

Their driver support for Linux is, frankly, pathetic at best. The
Fedora team is trying to solve this with their new free drivers in
Fedora 13 (which, I'll admit, are quite good), but it's still not up
to par with what you need to run a game. For example, the new free
drivers have very little (read: practically none) support for basic
vertex and fragment shaders. It will be at least another year before
the free drivers are up to what ATI's crappy proprietary drivers are
now. Even worse, right now you can get the proprietary drivers running
on Fedora 11 alright, sort-of on Fedora 12 with some ugly hackery, and
not at all on Fedora 13. Literally, ATI's Linux drivers are at least
12 months behind, and the free ones are 12 months behind that.

Unless somebody gives ATI a swift kick in the nuts the situation does
not look good.

--Bob





On Mon, Jun 14, 2010 at 5:01 PM, Darren VanBuren onekop...@gmail.com wrote:
 Spoiler Alert. It's like the ratman drawing that says She's watching
 you. Canonical is she in that case.

 I'm personally a fan of Fedora, but if Steam on GNU/Linux is
 distributed as a tarball, that'd be best in the interests of Valve.
 Even if some people (mainly Ubuntu users) would be a bit stuck on the
 concept of a tarball, it'd be minimal work for Valve, and maximum
 cross-distribution compatibility.

 Darren L. VanBuren
 =
 http://theoks.net/



 On Mon, Jun 14, 2010 at 16:49, Harry Jeffery
 harry101jeff...@googlemail.com wrote:
 It's all down to personal opinion, as long as it does what you need
 quickly and effectively then it's fine. I've yet to see the dark side
 in cannonical so I honestly can't say much about their ethics.

 Either way, I 3 Linux and so should Valve.

 On 15 June 2010 00:19, Katrina Payne fullmetalhar...@nimhlabs.com wrote:
 Well a few points:

 The commands in the Linux Commandline... and well those on any UNIX or UNIX
 Workalike have not really changed since the 1970s. You could pick up a book 
 on
 BASH or TCSH from the 1970s, and still have most of what you should do.

 This kind of has allowed for tools to be put around these base functions, 
 such
 as autocomplete, history and well--quite a few other really handy tools, to 
 be
 added into the Linux CLI, to make its functionality go above and beyond
 anything cmd.exe is capable of.

 I still have yet to look into Microsoft's PowerShell though.

 This is why most Linux users use the CLI. It has developed into an 
 experience
 that is completely unlike the root canal that is cmd.exe. You can actually 
 go
 in, and get some functionality from it. A lot of functionality too. It also
 gives the feeling that the user has more direct control--without that Pesky
 GUI in the way (though, technically, this just has a bunch of other items
 typically in the way, such as init.d, bash, various bash extensions--maybe
 screen... you are just trading one thing in the way, that is, a GUI, for
 another thing, that is a CLI).

 Now, that said--there are plenty of Desktop Environments ('DE') that Linux 
 can
 make use of, that pretty much make requirement of CLI use unnecessary. That
 is, between KDE4, LXDE, XFCE, E17 and GNOME2/GTK, the average Linux user
 nearly never has to do anything on the CLI. Unless something has gone 
 horribly
 wrong. In which case, he should be able to get the local Linux Admin to fix 
 it.

 As that technically is what he'd do if something went horribly wrong on
 Windows. He'd get his local Windows Expert to fix it.

 The required use of the CLI rather than GUI to properly use Linux, is much
 like how using Vi is required rather than EMACS for the proper use of 
 Linux.

 Also, I use Fedora, and typically find it a LOT easier to work with than
 Ubuntu. This maybe, because Fedora tries not to be a bunch of asshats to the
 people upstream. The same cannot be said about Canonical, the owners of
 Ubuntu. Where, from what I have seen on their policies by past actions...
 their MAIN desire is to be asshats to the upstream.

 I have a long winded rant on why I do not like Ubuntu... I mostly just state
 that nobody uses Ubuntu Linux. Typically most people go over to another 
 Linux
 Distro afterwards, generally agreeing that no matter what Linux Distro they 
 go
 to, be it Fedora, Puppy (well, prior to being based on Ubuntu), Arch, Slack,
 Gentoo, Knoppix, CentOS, LFS, etc., is better than Ubuntu... either that, or
 they return to Windows--only using Ubuntu as a rescue disk setup.

 Right, now then. Back to your regular discussion

 ~Katrina

 On Sunday, June 13, 2010 07:20:08 am Harry Jeffery wrote:
 People like the command line because it's very fast to do what you
 want if you know what you are doing. So far ubuntu seems to be the
 most user friendly linux distro and what a majority of

Re: [hlcoders] Source Engine 2!!!

2010-06-14 Thread Katrina Payne

This also adds a rather odd burden here, that allows Linux to get a better 
standing for gaming.

It is not that unknown that without mixing, Linux generally does not require 
anywhere near as much over head to run as windows.

The minimum requirements to run a GUI on Linux is about 256MiB of RAM. This 
even includes GUIs like KDE and Gnome. Though XFCE and LXCE would be better if 
you really did only have 256MiB of RAM (well if you were using a DE... and not 
a slimmed down WM with only a few programs loaded into it)

You can do just fine win 1GiB of RAM.

Linux also, as an OS can run on some old Intel boards--that running an OS on 
would other wise be insane today. a Pentium 1 can still get (some) use with 
Linux.

Not enough to really be noteworthy as a desktop PC... but, this is a lot less 
than the least you will get Windows 7 onto.

So we have a nice toss up here:

1: Linux requires Software Rendering in place. IE: how rendering was done, 
before we got silly things like TNT and Voodoo on the market.

2: Linux requires significantly less overhead to run, as far as OS goes.

If we can get it so that we can show Steam running on Linux, using mostly 
Software Rendering, and getting it to run as fast as the same game on Windows, 
on comparable hardware...

This will definitely sell Linux as an OS...

Which in turn will get various Graphics Card makers on board to add their 
support.

You know--I kind of want to see somebody work on that goal then. I am almost 
ready to dig up some old books that go over the theory of 3d programming, just 
to pull make a software rendering engine for this idea.

On Monday, June 14, 2010 07:59:45 pm Darren VanBuren wrote:
 Yes, 3D drivers are definitely quite lacking on the GNU/Linux front,
 but if Valve shows support for the development of these drivers, this
 may prompt certain GPU manufacturers to step up their GNU/Linux driver
 development.
 
 Darren L. VanBuren
 =
 http://theoks.net/
 On Mon, Jun 14, 2010 at 18:35, Bob Somers magicbob...@gmail.com wrote:
  Something to consider, though, is that the 3D driver support is years
  behind from *ahem* a particular GPU manufacturer. I won't embarrass
  them by saying their name, so I'll just say their initials: ATI.
 
  Their driver support for Linux is, frankly, pathetic at best. The
  Fedora team is trying to solve this with their new free drivers in
  Fedora 13 (which, I'll admit, are quite good), but it's still not up
  to par with what you need to run a game. For example, the new free
  drivers have very little (read: practically none) support for basic
  vertex and fragment shaders. It will be at least another year before
  the free drivers are up to what ATI's crappy proprietary drivers are
  now. Even worse, right now you can get the proprietary drivers running
  on Fedora 11 alright, sort-of on Fedora 12 with some ugly hackery, and
  not at all on Fedora 13. Literally, ATI's Linux drivers are at least
  12 months behind, and the free ones are 12 months behind that.
 
  Unless somebody gives ATI a swift kick in the nuts the situation does
  not look good.
 
  --Bob
 
 
 
 
 
  On Mon, Jun 14, 2010 at 5:01 PM, Darren VanBuren onekop...@gmail.com 
wrote:
  Spoiler Alert. It's like the ratman drawing that says She's watching
  you. Canonical is she in that case.
 
  I'm personally a fan of Fedora, but if Steam on GNU/Linux is
  distributed as a tarball, that'd be best in the interests of Valve.
  Even if some people (mainly Ubuntu users) would be a bit stuck on the
  concept of a tarball, it'd be minimal work for Valve, and maximum
  cross-distribution compatibility.
 
  Darren L. VanBuren
  =
  http://theoks.net/
 
 
 
  On Mon, Jun 14, 2010 at 16:49, Harry Jeffery
  harry101jeff...@googlemail.com wrote:
  It's all down to personal opinion, as long as it does what you need
  quickly and effectively then it's fine. I've yet to see the dark side
  in cannonical so I honestly can't say much about their ethics.
 
  Either way, I 3 Linux and so should Valve.
 
  On 15 June 2010 00:19, Katrina Payne fullmetalhar...@nimhlabs.com 
wrote:
  Well a few points:
 
  The commands in the Linux Commandline... and well those on any UNIX or 
UNIX
  Workalike have not really changed since the 1970s. You could pick up a 
book on
  BASH or TCSH from the 1970s, and still have most of what you should do.
 
  This kind of has allowed for tools to be put around these base 
functions, such
  as autocomplete, history and well--quite a few other really handy 
tools, to be
  added into the Linux CLI, to make its functionality go above and beyond
  anything cmd.exe is capable of.
 
  I still have yet to look into Microsoft's PowerShell though.
 
  This is why most Linux users use the CLI. It has developed into an 
experience
  that is completely unlike the root canal that is cmd.exe. You can 
actually go
  in, and get some functionality from it. A lot of functionality too. It 
also
  gives the feeling that

Re: [hlcoders] Source Engine 2!!!

2010-06-13 Thread Janek

+1 with Harry.

Migrating to an other platform (OSX) was the biggest effort : quitting  
Windows context for a context very closed to Linux.
Now adapting code done for OSX to Linux is a minimal effort and it is  
definitely what we all dream about. Of course it's not done yet but  
the first step is done and we can really expect them to condider Linux  
mid-term.

J.

Le 12 juin 2010 à 13:40, Harry Jeffery  
harry101jeff...@googlemail.com a écrit :

 Apple products aren't bad in their own nature. I just hate them
 because of how much apple charge for their computers. Also the whole
 business plan of shutting out ANYTHING and EVERYTHING that apple
 deicdes to compete with is ridiculously stupid. Developing for
 iPad,iPod Touch, iPhone is worse than developing for consoles.

 If apple want people to switch they need to price their products
 according to their value, not 3x their value. $800 for an iPad? My
 $400 netbook can do way more than that thing. A guy built a tablet of
 his own recently, it's running windows 7 and is so much more powerful
 than the iPad in every single way. Oh, and it only cost him $670 for
 all the parts, he didn't buy in bulk either. Cheaper than the iPad,
 and more functional.

 Linux is a far greater platform than OSX, the price, customizabilty
 and the community is amazing. You're not going to get bitched at by
 the community because your program doesn't look the same as all their
 other ones. Source and Steam for Linux, make that the E3 surprise.



 On 12 June 2010 05:44, Katrina Payne fullmetalhar...@nimhlabs.com  
 wrote:
 Well--Apples are not that unfriendly to developers. They are not  
 all the
 friendly though either.

 On Apple, they have access to Obj-C, Mono, C and C++.

 OSX also is a fork of FreeBSD... however a friend of mine is quote  
 as say OSX
 was once BSD, like the Orcs were once Elves.

 Apple Computers is one of the main pushers of WebKit which is one  
 of the most
 highly supportive web renders for the current standard set.

 Apple has also been known to interact and deal with the KDE  
 product--as well
 as a few other FlOSS projects. As tenchically, Webkit is a KDE  
 project.

 Add to that, OSX is the choice OS to talk with IPhone, iTouch, iPad  
 and the
 iPod.

 We also have the graphics, design and film users mostly using Apples.

 The only reason that you do not get as many of the developers as  
 say on
 Linux/BSD is because Apple Hardware is insanely expensive. Myself,  
 if I could
 afford it, I would be buying Apples like nothing else.

 You also get the REALLY insane people talking about Hackintoshes.

 Never mind the constant rumours for the past few years on the idea  
 of the
 iConsole. That is, possibly Apple Computers entering into the  
 gaming console
 market.

 Now--we have Steam and a Mac Source API.

 *looks around*

 Oh right, now to add something else just as crazy as the rest of  
 this: there
 is a fork in MAH EAR!

 Meh--I wish I could get my head out of the clouds and back into  
 reality.

 ~Katrina

 On Friday, June 11, 2010 08:16:02 pm Keeper wrote:
 Thinking about this ... how much development do people think will  
 happen on
 macs?  In the school/academic world, it makes sense because of the
 availability to larger groups of macs.  In the real world,  
 however, most
 people who code don't use macs.  Is that trend changing?  I'm not  
 a mac
 hater, I just know in the business world they aren't generally  
 used for
 this.

 As far as moving the steam platform to mac, that makes total  
 sense.  Outside
 of advertising/art departments macs are known as being home  
 computers.

 Just wondering if it makes sense from a developers standpoint.

 Keeper

 -Original Message-
 From: Byron Mallett [mailto:byrona...@gmail.com]
 Sent: Friday, June 11, 2010 9:23 PM
 To: Discussion of Half-Life Programming
 Subject: Re: [hlcoders] Source Engine 2!!!

 I've managed to get my course coordinator for my Digital media  
 course quite
 interested in the possibilities of Source modding as something to  
 add to our
 Mac lab. Now all we need is an SDK to play around with. :D

 ___
 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] Source Engine 2!!!

2010-06-13 Thread cathal mc nally

And thats the end of that Chapter!!!

Back to what Katrina Said about endifs and indefs for different systems doesn't 
the Cry 3 engine have some kind of system So that when you compile the code on 
the PC the code is simultaneously converted to Xbox and PS3 code. Would 
something similar not just be handy for Mac and Linux. I know the engine would 
need a major re haul as it is but just a thought. That way porting would be a 
piece of (Portal)cake and the SDK would be a little less Rtarded. 

Well i can still dream cant i?

;p

Cathal
Ireland



___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Source Engine 2!!!

2010-06-13 Thread Jonas 'Sortie' Termansen

I'd like to share a few experiences about porting code and writing 
portable code. Scroll down, if you just want my thoughts on how portable 
the Source Engine is.

Recently I've been porting my in-development digital distribution 
platform to GNU/Linux for the fun of it. Naturally, most of my code 
didn't work right out of the box. But it is worth that several 
subsystems actually worked at the first attempt, or with an edit or two. 
For instance, my string system and parser classes/functions compiled 
right away.

However, stuff like accessing the filesystem, multithreading, user 
interfaces, networking, and so on didn't work because it relied on the 
Windows API. The interesting part here is that POSIX does things 
differently; but almost in the same manner as Windows. That means for 
each Windows API call you use, there is often one or more POSIX calls 
that does the same thing (if you add a little abstraction, that is).

Now, some of you heavily suggested the use of #ifdefs all around the 
code. You should not use #ifdefs each time you rely on platform specific 
behavior, but only in shared function calls or in headers. For instance, 
if you have to open a file. On Windows you can call the CreateFile 
function, while POSIX supports the open function. That means for each 
file opening, you need to write something like.

#ifdef linux
int FileHandle = open(Path, Flags);
#elif defined(WIN32)
HANDLE FileName = CreateFile(...)
#endif

Naturally, this isn't very pretty. And if this was used all over the 
Source Engine you would spend a lot of time writing #ifdefs and checking 
platform specific documentation. However, I am not saying #ifdefs are a 
bad idea. But instead of using them all over your code, you should move 
them to a shared class or function that simply implements all this once. 
In my code, I declared an abstract baseclass called MaxsiFileSystem that 
implements all the common functions to access the local filesystem. So 
now when I wish to open a file for reading, I would call:

MaxsiHandle FileHandle = FileSystem()-OpenFile(Path, MAXSI_FILE_READ | 
MAXSI_FILE_SEQUENTIAL);

This additional layer of abstraction makes it very easy to add support 
for new platforms as you just have to define a new child of the abstract 
baseclass. I have also added such a layer for my Window System. This 
means I call my own APIs in my actual code, and then it redirects it to 
the Windows API or GTK+ depending on your platform.

You might also have noticed I implemented a FileSystem() function, in 
the same manner I have implemented a WindowSystem() function that 
returns the window system in use by the current function/class. This 
makes it easy to simply swap the window system on the fly. For instance, 
my source mod links against my distribution platform (LGPL) and my mod 
then implements some of these interfaces. It could implement the 
MaxsiWindowSystem class using VGUI and then my programs could be 
natively drawn ingame with mininal work.

Other porting issues includes how the VS compiler breaks a lot of the 
C99 standard. To counter this, I have simply declared a lot of macros in 
my header files that replaces platform specific behavior. #defines are 
very powerful for this. For example, to declare a thread-specific 
variable, I would use this header define:

#ifdef __GNUC__
#define MAXSI_THREADED_VARIABLE __thread
#else
#define MAXSI_THREADED_VARIABLE __declspec( thread )
#endif

And then use the MAXSI_THREADED_VARIABLE macro to declare each threaded 
variable. My experience is also that the GNU Compilers throw much more 
errors and warnings than the Visual Studio compiler - and it is often 
right to do so. Visual Studio teaches you to write bad 
standards-breaking code, even if you just compile using MinGW you will 
get to fix a lot of issues that makes your code rather non-portable. 
(Like avoiding Microsoft-specific extensions to the C Library, in some 
cases.) But Microsoft did break the standard enough that you might need 
to use some of the above methods for porting, just to get your code 
compiling using MinGW.


Now to return to the Source Engine. In my experience a lot of stuff in 
the SDK code is already defined using interfaces, classes, and such. 
That means the actual porting issues have been outsourced to the Engine. 
This, in turn, means that the SDK code will be rather easy to port 
compared to the Engine. Fortunately, as the Source Engine already is 
highly modular using interfaces, it is easy to just swap a DX renderer 
with OpenGL. As such, they already have the framework to make their code 
work on new platforms - all they have to do is implement their 
interfaces using the local system calls. If you start to do this on the 
low-level interfaces and move upward, then soon your program starts 
working in all its glory.

As for a Steam Client for GNU/Linux. It exists. I lost the link, but it 
seems that Valve uploads nightly builds of their Steam Client, and each 
day it works just a

Re: [hlcoders] Source Engine 2!!!

2010-06-13 Thread Adam Buckland

CryEngine 3 does this because it's game code is scripted, and their
maps aren't compiled in the same way that the Source Engine is for
instance. Therefore when the scripts or maps are changed on the
computer, it's copied to the consoles. To do this on the Source Engine
would require a major rewrite.
On 13 June 2010 11:23, cathal mc nally mcnallycat...@yahoo.ie wrote:
 And thats the end of that Chapter!!!

 Back to what Katrina Said about endifs and indefs for different systems 
 doesn't the Cry 3 engine have some kind of system So that when you compile 
 the code on the PC the code is simultaneously converted to Xbox and PS3 code. 
 Would something similar not just be handy for Mac and Linux. I know the 
 engine would need a major re haul as it is but just a thought. That way 
 porting would be a piece of (Portal)cake and the SDK would be a little less 
 Rtarded.

 Well i can still dream cant i?

 ;p

 Cathal
 Ireland



 ___
 To unsubscribe, edit your list preferences, or view the list archives, please 
 visit:
 http://list.valvesoftware.com/mailman/listinfo/hlcoders





-- 

Bucky

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Source Engine 2!!!

2010-06-13 Thread Gabriel

Valve already said that when they compile a mac and windows version are made. I 
don't know how they are doing this but as the only non modular part of Source 
is the engine, I'm guessing they have a compile script that places in the 
corect modules for mac or windows.

Gabriel Smith

On Jun 13, 2010, at 6:23 AM, cathal mc nally mcnallycat...@yahoo.ie wrote:

And thats the end of that Chapter!!!

Back to what Katrina Said about endifs and indefs for different systems doesn't 
the Cry 3 engine have some kind of system So that when you compile the code on 
the PC the code is simultaneously converted to Xbox and PS3 code. Would 
something similar not just be handy for Mac and Linux. I know the engine would 
need a major re haul as it is but just a thought. That way porting would be a 
piece of (Portal)cake and the SDK would be a little less Rtarded. 

Well i can still dream cant i?

;p

Cathal
Ireland



___
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] Source Engine 2!!!

2010-06-13 Thread Harry Jeffery

People like the command line because it's very fast to do what you
want if you know what you are doing. So far ubuntu seems to be the
most user friendly linux distro and what a majority of linux gamers
might use.

Personally I'd just use arch-linux and optimize my system...a lot. As
long as nVidia release decent linux drivers it's all good.

On 13 June 2010 14:01, Adam Buckland adamjbuckl...@gmail.com wrote:
 A couple of things:

 Elan Ruskin gave a good talk on porting to consoles at GDC08. The
 slides are on Valve's website. There's something in there that may
 help you here:

 #ifdef __GNUC__
 #define MAXSI_THREADED_VARIABLE __thread
 #else
 #define MAXSI_THREADED_VARIABLE __declspec( thread )
 #endif

 You may wish to use another define for windows rather than an else
 statement in case you wish to port it somewhere else in the future.

 Also I agree, the Mac and Linux ports are incredibly similar. In fact,
 on the Mac port a shell script is executed first to determine whether
 it's running on OS X or Linux.

 Finally Linux could be a great consumer platform. Before it can become
 this, it needs to learn that not everyone is a power user, and make
 things simple. Learn from the Mac app bundles, and remove reliance on
 the command line (for example the output is shown on the update
 software). It scares normal users. That, and a lot of power users
 (like myself), don't want to have to rely on the command line for
 everything.

 On 13 June 2010 13:28, Jonas 'Sortie' Termansen hlcod...@maxsi.dk wrote:
 I'd like to share a few experiences about porting code and writing
 portable code. Scroll down, if you just want my thoughts on how portable
 the Source Engine is.

 Recently I've been porting my in-development digital distribution
 platform to GNU/Linux for the fun of it. Naturally, most of my code
 didn't work right out of the box. But it is worth that several
 subsystems actually worked at the first attempt, or with an edit or two.
 For instance, my string system and parser classes/functions compiled
 right away.

 However, stuff like accessing the filesystem, multithreading, user
 interfaces, networking, and so on didn't work because it relied on the
 Windows API. The interesting part here is that POSIX does things
 differently; but almost in the same manner as Windows. That means for
 each Windows API call you use, there is often one or more POSIX calls
 that does the same thing (if you add a little abstraction, that is).

 Now, some of you heavily suggested the use of #ifdefs all around the
 code. You should not use #ifdefs each time you rely on platform specific
 behavior, but only in shared function calls or in headers. For instance,
 if you have to open a file. On Windows you can call the CreateFile
 function, while POSIX supports the open function. That means for each
 file opening, you need to write something like.

 #ifdef linux
 int FileHandle = open(Path, Flags);
 #elif defined(WIN32)
 HANDLE FileName = CreateFile(...)
 #endif

 Naturally, this isn't very pretty. And if this was used all over the
 Source Engine you would spend a lot of time writing #ifdefs and checking
 platform specific documentation. However, I am not saying #ifdefs are a
 bad idea. But instead of using them all over your code, you should move
 them to a shared class or function that simply implements all this once.
 In my code, I declared an abstract baseclass called MaxsiFileSystem that
 implements all the common functions to access the local filesystem. So
 now when I wish to open a file for reading, I would call:

 MaxsiHandle FileHandle = FileSystem()-OpenFile(Path, MAXSI_FILE_READ |
 MAXSI_FILE_SEQUENTIAL);

 This additional layer of abstraction makes it very easy to add support
 for new platforms as you just have to define a new child of the abstract
 baseclass. I have also added such a layer for my Window System. This
 means I call my own APIs in my actual code, and then it redirects it to
 the Windows API or GTK+ depending on your platform.

 You might also have noticed I implemented a FileSystem() function, in
 the same manner I have implemented a WindowSystem() function that
 returns the window system in use by the current function/class. This
 makes it easy to simply swap the window system on the fly. For instance,
 my source mod links against my distribution platform (LGPL) and my mod
 then implements some of these interfaces. It could implement the
 MaxsiWindowSystem class using VGUI and then my programs could be
 natively drawn ingame with mininal work.

 Other porting issues includes how the VS compiler breaks a lot of the
 C99 standard. To counter this, I have simply declared a lot of macros in
 my header files that replaces platform specific behavior. #defines are
 very powerful for this. For example, to declare a thread-specific
 variable, I would use this header define:

 #ifdef __GNUC__
 #define MAXSI_THREADED_VARIABLE __thread
 #else
 #define MAXSI_THREADED_VARIABLE __declspec( thread )
 #endif

 And

Re: [hlcoders] Source Engine 2!!!

2010-06-13 Thread Harry Jeffery

I asked about how they were developing for both platforms a while
back, Alfred Reynold's answer:

Hey Harry, we actually have our own internal tool we developed that uses a 
custom project definition format that is processed into the appropriate output 
files for each platform (so vcproj's under Windows, Xcode projects under OSX).



- Alfred

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Source Engine 2!!!

2010-06-13 Thread Jonas 'Sortie' Termansen


 Elan Ruskin gave a good talk on porting to consoles at GDC08. The
 slides are on Valve's website. There's something in there that may
 help you here:

 #ifdef __GNUC__
 #define MAXSI_THREADED_VARIABLE __thread
 #else
 #define MAXSI_THREADED_VARIABLE __declspec( thread )
 #endif

 You may wish to use another define for windows rather than an else
 statement in case you wish to port it somewhere else in the future.


Of course. I should have noted that the examples I showed was not the 
actual code. I try to be very religious about my #ifdefs. But if I port 
this to another platform and try to compile, I will just get compiler 
errors that are easy to track back to this #ifdef. Then in this case it 
will be rather easy to fix it. But thanks a lot for pointing this out 
anyways, I tried to make a point about proper #ifdefs in my original 
post, but I cut it because it didn't feel relevant. I will check out the 
slides, though.

Thanks,
Jonas 'Sortie' Termansen.

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Source Engine 2!!!

2010-06-12 Thread Harry Jeffery

Apple products aren't bad in their own nature. I just hate them
because of how much apple charge for their computers. Also the whole
business plan of shutting out ANYTHING and EVERYTHING that apple
deicdes to compete with is ridiculously stupid. Developing for
iPad,iPod Touch, iPhone is worse than developing for consoles.

If apple want people to switch they need to price their products
according to their value, not 3x their value. $800 for an iPad? My
$400 netbook can do way more than that thing. A guy built a tablet of
his own recently, it's running windows 7 and is so much more powerful
than the iPad in every single way. Oh, and it only cost him $670 for
all the parts, he didn't buy in bulk either. Cheaper than the iPad,
and more functional.

Linux is a far greater platform than OSX, the price, customizabilty
and the community is amazing. You're not going to get bitched at by
the community because your program doesn't look the same as all their
other ones. Source and Steam for Linux, make that the E3 surprise.



On 12 June 2010 05:44, Katrina Payne fullmetalhar...@nimhlabs.com wrote:
 Well--Apples are not that unfriendly to developers. They are not all the
 friendly though either.

 On Apple, they have access to Obj-C, Mono, C and C++.

 OSX also is a fork of FreeBSD... however a friend of mine is quote as say OSX
 was once BSD, like the Orcs were once Elves.

 Apple Computers is one of the main pushers of WebKit which is one of the most
 highly supportive web renders for the current standard set.

 Apple has also been known to interact and deal with the KDE product--as well
 as a few other FlOSS projects. As tenchically, Webkit is a KDE project.

 Add to that, OSX is the choice OS to talk with IPhone, iTouch, iPad and the
 iPod.

 We also have the graphics, design and film users mostly using Apples.

 The only reason that you do not get as many of the developers as say on
 Linux/BSD is because Apple Hardware is insanely expensive. Myself, if I could
 afford it, I would be buying Apples like nothing else.

 You also get the REALLY insane people talking about Hackintoshes.

 Never mind the constant rumours for the past few years on the idea of the
 iConsole. That is, possibly Apple Computers entering into the gaming console
 market.

 Now--we have Steam and a Mac Source API.

 *looks around*

 Oh right, now to add something else just as crazy as the rest of this: there
 is a fork in MAH EAR!

 Meh--I wish I could get my head out of the clouds and back into reality.

 ~Katrina

 On Friday, June 11, 2010 08:16:02 pm Keeper wrote:
 Thinking about this ... how much development do people think will happen on
 macs?  In the school/academic world, it makes sense because of the
 availability to larger groups of macs.  In the real world, however, most
 people who code don't use macs.  Is that trend changing?  I'm not a mac
 hater, I just know in the business world they aren't generally used for
 this.

 As far as moving the steam platform to mac, that makes total sense.  Outside
 of advertising/art departments macs are known as being home computers.

 Just wondering if it makes sense from a developers standpoint.

 Keeper

 -Original Message-
 From: Byron Mallett [mailto:byrona...@gmail.com]
 Sent: Friday, June 11, 2010 9:23 PM
 To: Discussion of Half-Life Programming
 Subject: Re: [hlcoders] Source Engine 2!!!

 I've managed to get my course coordinator for my Digital media course quite
 interested in the possibilities of Source modding as something to add to our
 Mac lab. Now all we need is an SDK to play around with. :D

 ___
 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] Source Engine 2!!!

2010-06-12 Thread Katrina Payne

 into reality.
 
  ~Katrina
 
  On Friday, June 11, 2010 08:16:02 pm Keeper wrote:
  Thinking about this ... how much development do people think will happen 
on
  macs?  In the school/academic world, it makes sense because of the
  availability to larger groups of macs.  In the real world, however, most
  people who code don't use macs.  Is that trend changing?  I'm not a mac
  hater, I just know in the business world they aren't generally used for
  this.
 
  As far as moving the steam platform to mac, that makes total sense. 
 Outside
  of advertising/art departments macs are known as being home computers.
 
  Just wondering if it makes sense from a developers standpoint.
 
  Keeper
 
  -Original Message-
  From: Byron Mallett [mailto:byrona...@gmail.com]
  Sent: Friday, June 11, 2010 9:23 PM
  To: Discussion of Half-Life Programming
  Subject: Re: [hlcoders] Source Engine 2!!!
 
  I've managed to get my course coordinator for my Digital media course 
quite
  interested in the possibilities of Source modding as something to add to 
our
  Mac lab. Now all we need is an SDK to play around with. :D

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Source Engine 2!!!

2010-06-12 Thread Harry Jeffery

 of the developers as say on
  Linux/BSD is because Apple Hardware is insanely expensive. Myself, if I
 could
  afford it, I would be buying Apples like nothing else.
 
  You also get the REALLY insane people talking about Hackintoshes.
 
  Never mind the constant rumours for the past few years on the idea of the
  iConsole. That is, possibly Apple Computers entering into the gaming
 console
  market.
 
  Now--we have Steam and a Mac Source API.
 
  *looks around*
 
  Oh right, now to add something else just as crazy as the rest of this:
 there
  is a fork in MAH EAR!
 
  Meh--I wish I could get my head out of the clouds and back into reality.
 
  ~Katrina
 
  On Friday, June 11, 2010 08:16:02 pm Keeper wrote:
  Thinking about this ... how much development do people think will happen
 on
  macs?  In the school/academic world, it makes sense because of the
  availability to larger groups of macs.  In the real world, however, most
  people who code don't use macs.  Is that trend changing?  I'm not a mac
  hater, I just know in the business world they aren't generally used for
  this.
 
  As far as moving the steam platform to mac, that makes total sense.
  Outside
  of advertising/art departments macs are known as being home computers.
 
  Just wondering if it makes sense from a developers standpoint.
 
  Keeper
 
  -Original Message-
  From: Byron Mallett [mailto:byrona...@gmail.com]
  Sent: Friday, June 11, 2010 9:23 PM
  To: Discussion of Half-Life Programming
  Subject: Re: [hlcoders] Source Engine 2!!!
 
  I've managed to get my course coordinator for my Digital media course
 quite
  interested in the possibilities of Source modding as something to add to
 our
  Mac lab. Now all we need is an SDK to play around with. :D

 ___
 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] Source Engine 2!!!

2010-06-12 Thread Katrina Payne

:
   Well--Apples are not that unfriendly to developers. They are not all 
the
   friendly though either.
  
   On Apple, they have access to Obj-C, Mono, C and C++.
  
   OSX also is a fork of FreeBSD... however a friend of mine is quote as 
say
  OSX
   was once BSD, like the Orcs were once Elves.
  
   Apple Computers is one of the main pushers of WebKit which is one of 
the
  most
   highly supportive web renders for the current standard set.
  
   Apple has also been known to interact and deal with the KDE product--as
  well
   as a few other FlOSS projects. As tenchically, Webkit is a KDE project.
  
   Add to that, OSX is the choice OS to talk with IPhone, iTouch, iPad and
  the
   iPod.
  
   We also have the graphics, design and film users mostly using Apples.
  
   The only reason that you do not get as many of the developers as say on
   Linux/BSD is because Apple Hardware is insanely expensive. Myself, if I
  could
   afford it, I would be buying Apples like nothing else.
  
   You also get the REALLY insane people talking about Hackintoshes.
  
   Never mind the constant rumours for the past few years on the idea of 
the
   iConsole. That is, possibly Apple Computers entering into the gaming
  console
   market.
  
   Now--we have Steam and a Mac Source API.
  
   *looks around*
  
   Oh right, now to add something else just as crazy as the rest of this:
  there
   is a fork in MAH EAR!
  
   Meh--I wish I could get my head out of the clouds and back into 
reality.
  
   ~Katrina
  
   On Friday, June 11, 2010 08:16:02 pm Keeper wrote:
   Thinking about this ... how much development do people think will 
happen
  on
   macs?  In the school/academic world, it makes sense because of the
   availability to larger groups of macs.  In the real world, however, 
most
   people who code don't use macs.  Is that trend changing?  I'm not a 
mac
   hater, I just know in the business world they aren't generally used 
for
   this.
  
   As far as moving the steam platform to mac, that makes total sense.
   Outside
   of advertising/art departments macs are known as being home computers.
  
   Just wondering if it makes sense from a developers standpoint.
  
   Keeper
  
   -Original Message-
   From: Byron Mallett [mailto:byrona...@gmail.com]
   Sent: Friday, June 11, 2010 9:23 PM
   To: Discussion of Half-Life Programming
   Subject: Re: [hlcoders] Source Engine 2!!!
  
   I've managed to get my course coordinator for my Digital media course
  quite
   interested in the possibilities of Source modding as something to add 
to
  our
   Mac lab. Now all we need is an SDK to play around with. :D

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Source Engine 2!!!

2010-06-12 Thread Byron Mallett

 not
 wanting
 to
   pay for stuff (Like I said earlier, Linux users tend to be more anal
 about
   paying for anything that should get paid for).
  
   This topic kind of came about as an Off Topic tangent, based on me
 pointing
 out
   that the hlcoders mailing list should probably get a leak into whatever
 the
   API changes will be, based on the E3 Surprise, so as to allow for early
   adoption.
  
   Yeah--some of it got tidied out, it appears
  
   ~Katrina
  
   On 12 June 2010 05:44, Katrina Payne fullmetalhar...@nimhlabs.com
 wrote:
Well--Apples are not that unfriendly to developers. They are not all
 the
friendly though either.
   
On Apple, they have access to Obj-C, Mono, C and C++.
   
OSX also is a fork of FreeBSD... however a friend of mine is quote
 as
 say
   OSX
was once BSD, like the Orcs were once Elves.
   
Apple Computers is one of the main pushers of WebKit which is one of
 the
   most
highly supportive web renders for the current standard set.
   
Apple has also been known to interact and deal with the KDE
 product--as
   well
as a few other FlOSS projects. As tenchically, Webkit is a KDE
 project.
   
Add to that, OSX is the choice OS to talk with IPhone, iTouch, iPad
 and
   the
iPod.
   
We also have the graphics, design and film users mostly using
 Apples.
   
The only reason that you do not get as many of the developers as say
 on
Linux/BSD is because Apple Hardware is insanely expensive. Myself,
 if I
   could
afford it, I would be buying Apples like nothing else.
   
You also get the REALLY insane people talking about Hackintoshes.
   
Never mind the constant rumours for the past few years on the idea
 of
 the
iConsole. That is, possibly Apple Computers entering into the gaming
   console
market.
   
Now--we have Steam and a Mac Source API.
   
*looks around*
   
Oh right, now to add something else just as crazy as the rest of
 this:
   there
is a fork in MAH EAR!
   
Meh--I wish I could get my head out of the clouds and back into
 reality.
   
~Katrina
   
On Friday, June 11, 2010 08:16:02 pm Keeper wrote:
Thinking about this ... how much development do people think will
 happen
   on
macs?  In the school/academic world, it makes sense because of the
availability to larger groups of macs.  In the real world, however,
 most
people who code don't use macs.  Is that trend changing?  I'm not a
 mac
hater, I just know in the business world they aren't generally used
 for
this.
   
As far as moving the steam platform to mac, that makes total sense.
Outside
of advertising/art departments macs are known as being home
 computers.
   
Just wondering if it makes sense from a developers standpoint.
   
Keeper
   
-Original Message-
From: Byron Mallett [mailto:byrona...@gmail.com]
Sent: Friday, June 11, 2010 9:23 PM
To: Discussion of Half-Life Programming
Subject: Re: [hlcoders] Source Engine 2!!!
   
I've managed to get my course coordinator for my Digital media
 course
   quite
interested in the possibilities of Source modding as something to
 add
 to
   our
Mac lab. Now all we need is an SDK to play around with. :D

 ___
 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] Source Engine 2!!!

2010-06-11 Thread Harry Jeffery

I'd just lve valve if Source 2010 supported linux and so did steam.

On 11 June 2010 04:06, Katrina Payne fullmetalhar...@nimhlabs.com wrote:
 Yeah--it is kind of irritating that before they moved to Mac OS X people kind
 of were all about the whole it is hard to port from windows

 Now people are doing the whole well, just because it was on Win and OSX does
 not mean any other system is an option

 I dunno--I hope that the new Source engine takes a hint from some of John
 Carmack's work... and is rather insanely platform independant (well, the C/C++
 code anyways) and on top of that: insanely platform aware. That is, if certain
 optimization are on a platform, make use of those (such as rendering hardware,
 systems that can thread (so to not need to use forks), FPU, etc., etc.).

 Remember when the head of Squeenix mentioned that specific platforms were not
 the future?

 If we got this set up with Source and Steam--there would be no stopping this
 delivery method and engine.

 I mean, all it really takes is a few of the follow in key places:

 #ifdef USE_WINDOWS

 #endif

 #ifdef USE_OSX

 #endif

 #ifdef USE_Wii

 #endif

 #ifdef USE_PS3

 #endif

 #ifdef USE_AMIGA

 #endif

 #ifdef USE_LINUX

 #end

 (then have a define passed into your compiler at compile time)

 And, it really is not that hard to find (or create) tool chains, to target a
 different platform. Like say compiling something that will run on an ARM based
 linux from AMD64 Windows.. or from something exotic, like say SPARC Linux to
 MIPS based AMIGA (however, this DOES require that any libraries you will be
 compiling against, be available for what your target platform will be, on the
 system compiling it).

 Though--I REALLY doubt, that this would be part of the announcement.

 I mean, Source and Steam designed in a rather comprehensive manner, to allow
 multiple hardware targets (which, BTW, was why the languages C and C++ were
 created: to target multiple hardware platforms)--I dunno... from what I have
 ranted about here, I may as well put on a tin foil boony hat, and yell on the
 street corner about how they put fluoride in the water. My suggests sound just
 as crazy.

 Here is hoping,
 Katrina Payne

 PS Crosses fingers.

 On Thursday, June 10, 2010 01:07:41 pm Joel R. wrote:
 Is this the big surprise for E3?!  I hope it is, that would so rock!

 ___
 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] Source Engine 2!!!

2010-06-11 Thread Adam amckern McKern

There are quite a few projects that they need to keep running

In order of games i play

1) Left4dead
2) Episodes
3) Counter-Strike
4) TF
5) Portal
6) Hidden projects that they are not talking about yet (Half-Life 3)


Owner Nigredo Studios http://www.nigredostudios.com

--- On Fri, 11/6/10, Katrina Payne fullmetalhar...@nimhlabs.com wrote:

From: Katrina Payne fullmetalhar...@nimhlabs.com
Subject: Re: [hlcoders] Source Engine 2!!!
To: Discussion of Half-Life Programming hlcoders@list.valvesoftware.com
Received: Friday, 11 June, 2010, 1:06 PM

Yeah--it is kind of irritating that before they moved to Mac OS X people kind 
of were all about the whole it is hard to port from windows

Now people are doing the whole well, just because it was on Win and OSX does 
not mean any other system is an option

I dunno--I hope that the new Source engine takes a hint from some of John 
Carmack's work... and is rather insanely platform independant (well, the C/C++ 
code anyways) and on top of that: insanely platform aware. That is, if certain 
optimization are on a platform, make use of those (such as rendering hardware, 
systems that can thread (so to not need to use forks), FPU, etc., etc.).

Remember when the head of Squeenix mentioned that specific platforms were not 
the future?

If we got this set up with Source and Steam--there would be no stopping this 
delivery method and engine.

I mean, all it really takes is a few of the follow in key places:

#ifdef USE_WINDOWS

#endif

#ifdef USE_OSX

#endif

#ifdef USE_Wii

#endif

#ifdef USE_PS3

#endif

#ifdef USE_AMIGA

#endif

#ifdef USE_LINUX

#end

(then have a define passed into your compiler at compile time)

And, it really is not that hard to find (or create) tool chains, to target a 
different platform. Like say compiling something that will run on an ARM based 
linux from AMD64 Windows.. or from something exotic, like say SPARC Linux to 
MIPS based AMIGA (however, this DOES require that any libraries you will be 
compiling against, be available for what your target platform will be, on the 
system compiling it).

Though--I REALLY doubt, that this would be part of the announcement.

I mean, Source and Steam designed in a rather comprehensive manner, to allow 
multiple hardware targets (which, BTW, was why the languages C and C++ were 
created: to target multiple hardware platforms)--I dunno... from what I have 
ranted about here, I may as well put on a tin foil boony hat, and yell on the 
street corner about how they put fluoride in the water. My suggests sound just 
as crazy.

Here is hoping,
Katrina Payne

PS Crosses fingers.

On Thursday, June 10, 2010 01:07:41 pm Joel R. wrote:
 Is this the big surprise for E3?!  I hope it is, that would so rock!

___
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] Source Engine 2!!!

Well--yeah. There would be some older stuff that will have issues... that may 
need to be scrambled to support what essentially would be a majorly updated 
framework.

I dunno--from my lurking so far, the main issue with the porting of these 
games are more the methodology in how the Engine currently works.

Though, it may be possible to set up a system to make the older Source games 
work natively on a cross platform engine of sorts. Most of it would be done 
via having a set of depreciated method calls for anything that would be an 
issue in itself. The depreciated methods would point to newer methods as a 
substitute at first. Until enough time has passed to allow all the code to be 
updated to fit the new engine.

Even that said--it is not like transitioning to these slight changes that 
would be need is really that easy to do.

I think it would be good for how Linux Users are currently seen by Marketing 
departments. As well--typically we are seen as wanting everything for free--
or something silly like that. I dunno--I have generally known most fellow 
Linux users to be more anal about paying for software, in comparison to 
Windows users which I hear over and over again the suggestion of Just Pirate 
it! (which this is entirely anecdotal, but most Linux users I have known 
would not want anything to do with that person)

Again--this is just a pie in the sky dream--it probably is just them 
announcing finally releasing Episodes of Duke Nukem Forever--or something along 
the lines of being more possible.

~ Katrina Payne

On Friday, June 11, 2010 12:27:01 am Adam amckern McKern wrote:
 There are quite a few projects that they need to keep running
 
 In order of games i play
 
 1) Left4dead
 2) Episodes
 3) Counter-Strike
 4) TF
 5) Portal
 6) Hidden projects that they are not talking about yet (Half-Life 3)
 
 
 Owner Nigredo Studios http://www.nigredostudios.com
 
 --- On Fri, 11/6/10, Katrina Payne fullmetalhar...@nimhlabs.com wrote:
 
 From: Katrina Payne fullmetalhar...@nimhlabs.com
 Subject: Re: [hlcoders] Source Engine 2!!!
 To: Discussion of Half-Life Programming hlcoders@list.valvesoftware.com
 Received: Friday, 11 June, 2010, 1:06 PM
 
 Yeah--it is kind of irritating that before they moved to Mac OS X people 
kind 
 of were all about the whole it is hard to port from windows
 
 Now people are doing the whole well, just because it was on Win and OSX 
does 
 not mean any other system is an option
 
 I dunno--I hope that the new Source engine takes a hint from some of John 
 Carmack's work... and is rather insanely platform independant (well, the 
C/C++ 
 code anyways) and on top of that: insanely platform aware. That is, if 
certain 
 optimization are on a platform, make use of those (such as rendering 
hardware, 
 systems that can thread (so to not need to use forks), FPU, etc., etc.).
 
 Remember when the head of Squeenix mentioned that specific platforms were not 
 the future?
 
 If we got this set up with Source and Steam--there would be no stopping this 
 delivery method and engine.
 
 I mean, all it really takes is a few of the follow in key places:
 
 #ifdef USE_WINDOWS
 
 #endif
 
 #ifdef USE_OSX
 
 #endif
 
 #ifdef USE_Wii
 
 #endif
 
 #ifdef USE_PS3
 
 #endif
 
 #ifdef USE_AMIGA
 
 #endif
 
 #ifdef USE_LINUX
 
 #end
 
 (then have a define passed into your compiler at compile time)
 
 And, it really is not that hard to find (or create) tool chains, to target a 
 different platform. Like say compiling something that will run on an ARM 
based 
 linux from AMD64 Windows.. or from something exotic, like say SPARC Linux to 
 MIPS based AMIGA (however, this DOES require that any libraries you will be 
 compiling against, be available for what your target platform will be, on 
the 
 system compiling it).
 
 Though--I REALLY doubt, that this would be part of the announcement.
 
 I mean, Source and Steam designed in a rather comprehensive manner, to allow 
 multiple hardware targets (which, BTW, was why the languages C and C++ were 
 created: to target multiple hardware platforms)--I dunno... from what I have 
 ranted about here, I may as well put on a tin foil boony hat, and yell on 
the 
 street corner about how they put fluoride in the water. My suggests sound 
just 
 as crazy.
 
 Here is hoping,
 Katrina Payne
 
 PS Crosses fingers.
 
 On Thursday, June 10, 2010 01:07:41 pm Joel R. wrote:
  Is this the big surprise for E3?!  I hope it is, that would so rock!

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Source Engine 2!!!

2010-06-11 Thread Adam Buckland

Guys, Valve have already revealed that the surprise is about Portal 2
(mainly to stop people expecting EP3 and being disappointed when it
doesn't arrive).

Therefore it's going to be either
Portal 2 for Linux
or Portal 2 for Wii

On 11 June 2010 08:26, Katrina Payne fullmetalhar...@nimhlabs.com wrote:
 Well--yeah. There would be some older stuff that will have issues... that may
 need to be scrambled to support what essentially would be a majorly updated
 framework.

 I dunno--from my lurking so far, the main issue with the porting of these
 games are more the methodology in how the Engine currently works.

 Though, it may be possible to set up a system to make the older Source games
 work natively on a cross platform engine of sorts. Most of it would be done
 via having a set of depreciated method calls for anything that would be an
 issue in itself. The depreciated methods would point to newer methods as a
 substitute at first. Until enough time has passed to allow all the code to be
 updated to fit the new engine.

 Even that said--it is not like transitioning to these slight changes that
 would be need is really that easy to do.

 I think it would be good for how Linux Users are currently seen by Marketing
 departments. As well--typically we are seen as wanting everything for free--
 or something silly like that. I dunno--I have generally known most fellow
 Linux users to be more anal about paying for software, in comparison to
 Windows users which I hear over and over again the suggestion of Just Pirate
 it! (which this is entirely anecdotal, but most Linux users I have known
 would not want anything to do with that person)

 Again--this is just a pie in the sky dream--it probably is just them
 announcing finally releasing Episodes of Duke Nukem Forever--or something 
 along
 the lines of being more possible.

 ~ Katrina Payne

 On Friday, June 11, 2010 12:27:01 am Adam amckern McKern wrote:
 There are quite a few projects that they need to keep running

 In order of games i play

 1) Left4dead
 2) Episodes
 3) Counter-Strike
 4) TF
 5) Portal
 6) Hidden projects that they are not talking about yet (Half-Life 3)

 
 Owner Nigredo Studios http://www.nigredostudios.com

 --- On Fri, 11/6/10, Katrina Payne fullmetalhar...@nimhlabs.com wrote:

 From: Katrina Payne fullmetalhar...@nimhlabs.com
 Subject: Re: [hlcoders] Source Engine 2!!!
 To: Discussion of Half-Life Programming hlcoders@list.valvesoftware.com
 Received: Friday, 11 June, 2010, 1:06 PM

 Yeah--it is kind of irritating that before they moved to Mac OS X people
 kind
 of were all about the whole it is hard to port from windows

 Now people are doing the whole well, just because it was on Win and OSX
 does
 not mean any other system is an option

 I dunno--I hope that the new Source engine takes a hint from some of John
 Carmack's work... and is rather insanely platform independant (well, the
 C/C++
 code anyways) and on top of that: insanely platform aware. That is, if
 certain
 optimization are on a platform, make use of those (such as rendering
 hardware,
 systems that can thread (so to not need to use forks), FPU, etc., etc.).

 Remember when the head of Squeenix mentioned that specific platforms were not
 the future?

 If we got this set up with Source and Steam--there would be no stopping this
 delivery method and engine.

 I mean, all it really takes is a few of the follow in key places:

 #ifdef USE_WINDOWS

 #endif

 #ifdef USE_OSX

 #endif

 #ifdef USE_Wii

 #endif

 #ifdef USE_PS3

 #endif

 #ifdef USE_AMIGA

 #endif

 #ifdef USE_LINUX

 #end

 (then have a define passed into your compiler at compile time)

 And, it really is not that hard to find (or create) tool chains, to target a
 different platform. Like say compiling something that will run on an ARM
 based
 linux from AMD64 Windows.. or from something exotic, like say SPARC Linux to
 MIPS based AMIGA (however, this DOES require that any libraries you will be
 compiling against, be available for what your target platform will be, on
 the
 system compiling it).

 Though--I REALLY doubt, that this would be part of the announcement.

 I mean, Source and Steam designed in a rather comprehensive manner, to allow
 multiple hardware targets (which, BTW, was why the languages C and C++ were
 created: to target multiple hardware platforms)--I dunno... from what I have
 ranted about here, I may as well put on a tin foil boony hat, and yell on
 the
 street corner about how they put fluoride in the water. My suggests sound
 just
 as crazy.

 Here is hoping,
 Katrina Payne

 PS Crosses fingers.

 On Thursday, June 10, 2010 01:07:41 pm Joel R. wrote:
  Is this the big surprise for E3?!  I hope it is, that would so rock!

 ___
 To unsubscribe, edit your list preferences, or view the list archives, please 
 visit:
 http://list.valvesoftware.com/mailman/listinfo/hlcoders





-- 

Bucky

Re: [hlcoders] Source Engine 2!!!

2010-06-11 Thread Garry Newman

You got a link to this? I'm interested to see it - from what I saw it
looked like they were using the projected texture stuff - is it more
than that? Does it still use lightmaps?

garry

On Fri, Jun 11, 2010 at 2:22 AM, Byron Mallett byrona...@gmail.com wrote:
 Judging by the GameInformer screenshots of Portal 2, it already looks like
 they have some really interesting dynamic lighting going on in there. I'm
 reckoning that our big upgrade will be happening around that time.

 On Fri, Jun 11, 2010 at 10:37 AM, Ben Mears benmea...@gmail.com wrote:

 I'm hoping it's new shoes for TF2 !

 On Thu, Jun 10, 2010 at 2:27 PM, Harry Jeffery 
 harry101jeff...@googlemail.com wrote:

  If they added hats to css I'd move to cspromod and never touch css
  ever again. It's just not right.
 
  On 10 June 2010 23:21, Arg! chillic...@gmail.com wrote:
   i miss duke3d, please do this valve. surely you could buy all the
   assets for a few bucks.
  
   perhaps the announcement is hats for cs:s
  
   On Fri, Jun 11, 2010 at 7:24 AM, 1nsane 1nsane...@gmail.com wrote:
   They could just release everything that was made for Duke Nukem
 Forever
  as
   Duke Nukem Forever Episode 1.
  
   Then 10 years later release EP2. It would make perfect sense!
  
   On Thu, Jun 10, 2010 at 4:25 PM, Dexter dex...@linux.com wrote:
  
   Maybe they're releasing Duke Nukem Forever on a new Source engine.
  
   Or maybe a new version of the Source engine and SDK that doesn't
 break
  with
   every update.
  
   I'm not sure which is more far fetched
  
   On Thu, Jun 10, 2010 at 2:21 PM, Sam samuelga...@gmail.com wrote:
  
Second reason, they lost their code and have to redo everything.
   
I giggled, hard.
   
I doubt the announcement would be anything related to the engine,
  they
could've done that back in GDC, E3 is about entertrainment, not
   development
like GDC is
   
On Thu, Jun 10, 2010 at 5:09 PM, Adam Buckland 
  adamjbuckl...@gmail.com
wrote:
   
 I'm going to go with Jeffrey, and call Portal for the Wii now.
  Valve
 said that they wanted to do a Wii game, so this could be it!

 On 10 June 2010 20:07, Joel R. joelru...@gmail.com wrote:
  Is this the big surprise for E3?!  I hope it is, that would so
  rock!
  ___
  To unsubscribe, edit your list preferences, or view the list
   archives,
 please visit:
  http://list.valvesoftware.com/mailman/listinfo/hlcoders
 
 



 --

 Bucky

 ___
 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



___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Source Engine 2!!!

2010-06-11 Thread Colm Sloan

I'd like to see the girl from Portal as a new character in TF2.
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Source Engine 2!!!

2010-06-11 Thread 1nsane

That was a girl? It seemed quite ugly. Very much so compared to the person
they based it on.

On Fri, Jun 11, 2010 at 11:07 AM, Colm Sloan colmsl...@gmail.com wrote:

 I'd like to see the girl from Portal as a new character in TF2.
 ___
 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] Source Engine 2!!!

2010-06-11 Thread Spencer 'voogru' MacDonald

She got disfigured in a portal mishap.

-Original Message-
From: hlcoders-boun...@list.valvesoftware.com
[mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of 1nsane
Sent: Friday, June 11, 2010 11:45 AM
To: Discussion of Half-Life Programming
Subject: Re: [hlcoders] Source Engine 2!!!

That was a girl? It seemed quite ugly. Very much so compared to the person
they based it on.

On Fri, Jun 11, 2010 at 11:07 AM, Colm Sloan colmsl...@gmail.com wrote:

 I'd like to see the girl from Portal as a new character in TF2.
 ___
 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] Source Engine 2!!!

Nonsense.

The institution reminds us that the companion cube does nothing to threaten 
our personal comfort and desires.

In fact, the whole institute building the portal gun only has our greatest 
safety and peace of mind, when dealing with its associates.

And! They have cake.

Clearly, she was disfigured before she got to the institute--where they are 
giving her the best care.

~Katrina

On Friday, June 11, 2010 10:56:40 am Spencer 'voogru' MacDonald wrote:
 She got disfigured in a portal mishap.
 
 -Original Message-
 From: hlcoders-boun...@list.valvesoftware.com
 [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of 1nsane
 Sent: Friday, June 11, 2010 11:45 AM
 To: Discussion of Half-Life Programming
 Subject: Re: [hlcoders] Source Engine 2!!!
 
 That was a girl? It seemed quite ugly. Very much so compared to the person
 they based it on.
 
 On Fri, Jun 11, 2010 at 11:07 AM, Colm Sloan colmsl...@gmail.com wrote:
 
  I'd like to see the girl from Portal as a new character in TF2.

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Source Engine 2!!!

2010-06-11 Thread Harry Jeffery

Swiftly going back on topic (see what I did there?)...

I think as subscribers to the hlcoders mailing list we deserve a sneak
peak. We promise not to leak it, if we do you can always punish us by
breaking the SDK (again).

:P

On 11 June 2010 21:16, Katrina Payne fullmetalhar...@nimhlabs.com wrote:
 Nonsense.

 The institution reminds us that the companion cube does nothing to threaten
 our personal comfort and desires.

 In fact, the whole institute building the portal gun only has our greatest
 safety and peace of mind, when dealing with its associates.

 And! They have cake.

 Clearly, she was disfigured before she got to the institute--where they are
 giving her the best care.

 ~Katrina

 On Friday, June 11, 2010 10:56:40 am Spencer 'voogru' MacDonald wrote:
 She got disfigured in a portal mishap.

 -Original Message-
 From: hlcoders-boun...@list.valvesoftware.com
 [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of 1nsane
 Sent: Friday, June 11, 2010 11:45 AM
 To: Discussion of Half-Life Programming
 Subject: Re: [hlcoders] Source Engine 2!!!

 That was a girl? It seemed quite ugly. Very much so compared to the person
 they based it on.

 On Fri, Jun 11, 2010 at 11:07 AM, Colm Sloan colmsl...@gmail.com wrote:

  I'd like to see the girl from Portal as a new character in TF2.

 ___
 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] Source Engine 2!!!

You may be onto something there.

Perhaps just via a link to a place where we can learn more... just require us 
to agree to a nondisclosure agreement.

Why? Well--to allow the people of the list to take a much easier approach as 
early adopters of whatever is being unveiled.

I mean, even if it is only Portal 2--or even Portal Wii or Portal Linux (or 
Portal Atari like one person suggested--which would not really surprise me 
these days), this likely will mean an update to the API used for working with 
the games.

By letting the people on hlcoders mailing list see the stuff, allows for easier 
adoption of its use.

Oh--hey, I am taking away from my tinfoil boonie hat ranting time again... 
.'

~Katrina

On Friday, June 11, 2010 02:42:08 pm Harry Jeffery wrote:
 Swiftly going back on topic (see what I did there?)...
 
 I think as subscribers to the hlcoders mailing list we deserve a sneak
 peak. We promise not to leak it, if we do you can always punish us by
 breaking the SDK (again).
 
 :P
 
 On 11 June 2010 21:16, Katrina Payne fullmetalhar...@nimhlabs.com wrote:
  Nonsense.
 
  The institution reminds us that the companion cube does nothing to 
threaten
  our personal comfort and desires.
 
  In fact, the whole institute building the portal gun only has our greatest
  safety and peace of mind, when dealing with its associates.
 
  And! They have cake.
 
  Clearly, she was disfigured before she got to the institute--where they are
  giving her the best care.
 
  ~Katrina
 
  On Friday, June 11, 2010 10:56:40 am Spencer 'voogru' MacDonald wrote:
  She got disfigured in a portal mishap.
 
  -Original Message-
  From: hlcoders-boun...@list.valvesoftware.com
  [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of 1nsane
  Sent: Friday, June 11, 2010 11:45 AM
  To: Discussion of Half-Life Programming
  Subject: Re: [hlcoders] Source Engine 2!!!
 
  That was a girl? It seemed quite ugly. Very much so compared to the 
person
  they based it on.
 
  On Fri, Jun 11, 2010 at 11:07 AM, Colm Sloan colmsl...@gmail.com wrote:
 
   I'd like to see the girl from Portal as a new character in TF2. 

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Source Engine 2!!!

2010-06-11 Thread Adam Buckland

Talking of ports, does anyone have a rough release date for the Mac SDK?

On 11 June 2010 21:54, Katrina Payne fullmetalhar...@nimhlabs.com wrote:
 You may be onto something there.

 Perhaps just via a link to a place where we can learn more... just require us
 to agree to a nondisclosure agreement.

 Why? Well--to allow the people of the list to take a much easier approach as
 early adopters of whatever is being unveiled.

 I mean, even if it is only Portal 2--or even Portal Wii or Portal Linux (or
 Portal Atari like one person suggested--which would not really surprise me
 these days), this likely will mean an update to the API used for working with
 the games.

 By letting the people on hlcoders mailing list see the stuff, allows for 
 easier
 adoption of its use.

 Oh--hey, I am taking away from my tinfoil boonie hat ranting time again...
.'

 ~Katrina

 On Friday, June 11, 2010 02:42:08 pm Harry Jeffery wrote:
 Swiftly going back on topic (see what I did there?)...

 I think as subscribers to the hlcoders mailing list we deserve a sneak
 peak. We promise not to leak it, if we do you can always punish us by
 breaking the SDK (again).

 :P

 On 11 June 2010 21:16, Katrina Payne fullmetalhar...@nimhlabs.com wrote:
  Nonsense.
 
  The institution reminds us that the companion cube does nothing to
 threaten
  our personal comfort and desires.
 
  In fact, the whole institute building the portal gun only has our greatest
  safety and peace of mind, when dealing with its associates.
 
  And! They have cake.
 
  Clearly, she was disfigured before she got to the institute--where they are
  giving her the best care.
 
  ~Katrina
 
  On Friday, June 11, 2010 10:56:40 am Spencer 'voogru' MacDonald wrote:
  She got disfigured in a portal mishap.
 
  -Original Message-
  From: hlcoders-boun...@list.valvesoftware.com
  [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of 1nsane
  Sent: Friday, June 11, 2010 11:45 AM
  To: Discussion of Half-Life Programming
  Subject: Re: [hlcoders] Source Engine 2!!!
 
  That was a girl? It seemed quite ugly. Very much so compared to the
 person
  they based it on.
 
  On Fri, Jun 11, 2010 at 11:07 AM, Colm Sloan colmsl...@gmail.com wrote:
 
   I'd like to see the girl from Portal as a new character in TF2.

 ___
 To unsubscribe, edit your list preferences, or view the list archives, please 
 visit:
 http://list.valvesoftware.com/mailman/listinfo/hlcoders





-- 

Bucky

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Source Engine 2!!!

2010-06-11 Thread Byron Mallett

I've managed to get my course coordinator for my Digital media course quite
interested in the possibilities of Source modding as something to add to our
Mac lab. Now all we need is an SDK to play around with. :D

On Sat, Jun 12, 2010 at 10:41 AM, Adam Buckland adamjbuckl...@gmail.comwrote:

 Talking of ports, does anyone have a rough release date for the Mac SDK?

 On 11 June 2010 21:54, Katrina Payne fullmetalhar...@nimhlabs.com wrote:
  You may be onto something there.
 
  Perhaps just via a link to a place where we can learn more... just
 require us
  to agree to a nondisclosure agreement.
 
  Why? Well--to allow the people of the list to take a much easier approach
 as
  early adopters of whatever is being unveiled.
 
  I mean, even if it is only Portal 2--or even Portal Wii or Portal Linux
 (or
  Portal Atari like one person suggested--which would not really surprise
 me
  these days), this likely will mean an update to the API used for working
 with
  the games.
 
  By letting the people on hlcoders mailing list see the stuff, allows for
 easier
  adoption of its use.
 
  Oh--hey, I am taking away from my tinfoil boonie hat ranting time
 again...
 .'
 
  ~Katrina
 
  On Friday, June 11, 2010 02:42:08 pm Harry Jeffery wrote:
  Swiftly going back on topic (see what I did there?)...
 
  I think as subscribers to the hlcoders mailing list we deserve a sneak
  peak. We promise not to leak it, if we do you can always punish us by
  breaking the SDK (again).
 
  :P
 
  On 11 June 2010 21:16, Katrina Payne fullmetalhar...@nimhlabs.com
 wrote:
   Nonsense.
  
   The institution reminds us that the companion cube does nothing to
  threaten
   our personal comfort and desires.
  
   In fact, the whole institute building the portal gun only has our
 greatest
   safety and peace of mind, when dealing with its associates.
  
   And! They have cake.
  
   Clearly, she was disfigured before she got to the institute--where
 they are
   giving her the best care.
  
   ~Katrina
  
   On Friday, June 11, 2010 10:56:40 am Spencer 'voogru' MacDonald wrote:
   She got disfigured in a portal mishap.
  
   -Original Message-
   From: hlcoders-boun...@list.valvesoftware.com
   [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of 1nsane
   Sent: Friday, June 11, 2010 11:45 AM
   To: Discussion of Half-Life Programming
   Subject: Re: [hlcoders] Source Engine 2!!!
  
   That was a girl? It seemed quite ugly. Very much so compared to the
  person
   they based it on.
  
   On Fri, Jun 11, 2010 at 11:07 AM, Colm Sloan colmsl...@gmail.com
 wrote:
  
I'd like to see the girl from Portal as a new character in TF2.
 
  ___
  To unsubscribe, edit your list preferences, or view the list archives,
 please visit:
  http://list.valvesoftware.com/mailman/listinfo/hlcoders
 
 



 --

 Bucky

 ___
 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] Source Engine 2!!!

2010-06-11 Thread Keeper

Thinking about this ... how much development do people think will happen on
macs?  In the school/academic world, it makes sense because of the
availability to larger groups of macs.  In the real world, however, most
people who code don't use macs.  Is that trend changing?  I'm not a mac
hater, I just know in the business world they aren't generally used for
this.

As far as moving the steam platform to mac, that makes total sense.  Outside
of advertising/art departments macs are known as being home computers.

Just wondering if it makes sense from a developers standpoint.

Keeper

-Original Message-
From: Byron Mallett [mailto:byrona...@gmail.com] 
Sent: Friday, June 11, 2010 9:23 PM
To: Discussion of Half-Life Programming
Subject: Re: [hlcoders] Source Engine 2!!!

I've managed to get my course coordinator for my Digital media course quite
interested in the possibilities of Source modding as something to add to our
Mac lab. Now all we need is an SDK to play around with. :D


___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Source Engine 2!!!

2010-06-11 Thread Mark Chandler

A lot of indie coders use macs. So it will be popular with mod teams and 
such.

Mark

On 6/12/2010 10:16 AM, Keeper wrote:
 Thinking about this ... how much development do people think will happen on
 macs?  In the school/academic world, it makes sense because of the
 availability to larger groups of macs.  In the real world, however, most
 people who code don't use macs.  Is that trend changing?  I'm not a mac
 hater, I just know in the business world they aren't generally used for
 this.

 As far as moving the steam platform to mac, that makes total sense.  Outside
 of advertising/art departments macs are known as being home computers.

 Just wondering if it makes sense from a developers standpoint.

 Keeper

 -Original Message-
 From: Byron Mallett [mailto:byrona...@gmail.com]
 Sent: Friday, June 11, 2010 9:23 PM
 To: Discussion of Half-Life Programming
 Subject: Re: [hlcoders] Source Engine 2!!!

 I've managed to get my course coordinator for my Digital media course quite
 interested in the possibilities of Source modding as something to add to our
 Mac lab. Now all we need is an SDK to play around with. :D


 ___
 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] Source Engine 2!!!