 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Raiford <"m[raiford]!at"@gmail.com> wrote:
> I think they implemented Quake in C++.net at one point.
Given that Quake was already implemented in C++, what would the .net
part bring to it?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Raiford wrote:
> I think they implemented Quake in C++.net at one point.
Since the original was in C, it was just a few hours porting it to C++ and
fixing the incompatibilities between C and C++, and then a couple hours
adding something (radar, IIRC) to prove it could be done.
C++.net is probably more compatible with straight C++ than C is.
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Given that Quake was already implemented in C++, what would the .net
> part bring to it?
Just to prove that quake could run under the .net platform.
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Raiford <"m[raiford]!at"@gmail.com> wrote:
> Warp wrote:
> > Given that Quake was already implemented in C++, what would the .net
> > part bring to it?
> Just to prove that quake could run under the .net platform.
I still fail to see the relevant difference.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> I still fail to see the relevant difference.
First, quake was C, not C++, so that had to be ported. Second, it means you
can interact with other .NET libraries to add stuff to the game.
http://www.codeproject.com/KB/mcpp/quake2.aspx
I think the exercise was more along the lines of "take a big C project and
port it to .NET C++ and see what the incompatibilities are and how to work
around them."
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] san rrcom> wrote:
> Warp wrote:
> > I still fail to see the relevant difference.
> First, quake was C, not C++, so that had to be ported.
There are only a few incompatibilities between C and C++, and it's really
rare for a C program to use something which would make it illegal C++
(although, admittedly, using a variable named eg. "class" in a C program
might not be unheard of, but I still think it's rare).
> Second, it means you
> can interact with other .NET libraries to add stuff to the game.
You *can*, but you don't *have to*. I fail to see how compiling a C (or
C++) program as a C++.net program would be difficult. Maybe the startup
routines (the main function, launching the main window...) might need to
be different, but it doesn't sound very drastic.
On the contrary: The *less* you add .net code to the program, the *easier*
it will be to compile as a C++.net program.
(One thing which I don't really understand is what's the point: If you
already have a working C/C++ program, why deliberately make it C++.net?
The only thing you will achieve is that you will be forcing people who
want to use the program to install the necessary .net libraries. And no,
they don't always come with Windows by default, especially if you use
a newer version of .net than 1.x.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> There are only a few incompatibilities between C and C++,
I think you'd need to read that link, where they list the incompatibilities.
> and it's really
> rare for a C program to use something which would make it illegal C++
> (although, admittedly, using a variable named eg. "class" in a C program
> might not be unheard of, but I still think it's rare).
Read the link. It's not long. There are a bunch of things about types that
changed.
>> Second, it means you
>> can interact with other .NET libraries to add stuff to the game.
>
> You *can*, but you don't *have to*. I fail to see how compiling a C (or
> C++) program as a C++.net program would be difficult.
It wasn't. That was the point. It took them about a week to port it, with
more than half the time being porting from C to C++.
> On the contrary: The *less* you add .net code to the program, the *easier*
> it will be to compile as a C++.net program.
Most likely true, yes.
> (One thing which I don't really understand is what's the point: If you
> already have a working C/C++ program, why deliberately make it C++.net?
I think it was done as an experiment, not as an end in itself. For one
thing, they were testing the difference in speed, as an example.
> The only thing you will achieve is that you will be forcing people who
> want to use the program to install the necessary .net libraries. And no,
> they don't always come with Windows by default, especially if you use
> a newer version of .net than 1.x.)
I don't think they envisioned the new version as an improvement over the old
version per se. Again, read the link.
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
>
> I don't think they envisioned the new version as an improvement over the
> old version per se. Again, read the link.
>
Right.
Warp, this wasn't a practical idea in and of itself. Just a "Lets do
this and see if it can be done" kind of thing. It gives no benefit,
except to say "See? The .NET runtime is fast enough to run Quake!"
That's all. :)
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Raiford escreveu:
> Invisible wrote:
>
>> Really? And what makes you think that? OpenGL with hardware
>> acceleration is equally fast if you call it from C or Haskell. :-P
>
> The original quake was not OpenGL... :) Though, they did release GLQuake.
>
> And, isn't Haskell like an order of magnitude slower than ... just about
> everything else?
No. Everything else means everything besides C/C++, and hardly any
language is able to go against it head-on.
see for yourself, against C++:
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=gpp&lang2=ghc&box=1
pretty much on par with OCaml against C++:
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=gpp&lang2=ocaml&box=1
which is pretty much like Pascal vs C++:
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=gpp&lang2=fpascal&box=1
compare then to hip but slow scripting language like Python, against C++:
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=gpp&lang2=python&box=1
or Lua (with JIT) against C++:
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=gpp&lang2=luajit&box=1
it's amusing to see C++ using so much more memory than higher level
languages in the mandelbrot benchmark BTW...
Fact is: GCH provides as solid and fast implementation for a very high
level language as possible, without getting down to low-level machinery.
3 times as slow as C++ at worse is not something to be ashamed of.
well, OTOH, there seems to be quite some "low-level tuning" in the
Haskell version of fannkuch:
http://shootout.alioth.debian.org/u32/benchmark.php?test=fannkuch&lang=ghc&id=5
the source is pretty much about as large and complicated as that of C++:
http://shootout.alioth.debian.org/u32/benchmark.php?test=fannkuch&lang=gpp&box=1
compare to the much cleaner, though much slower, Scheme version:
http://shootout.alioth.debian.org/u32/benchmark.php?test=fannkuch&lang=mzscheme&box=1
The GCC C++ fannkuch runs in 51.16 secs (1.092 KB of memory use),
Fortran Intel at 52.26 (408 KB) Pascal at 58.79 (48 KB!!), OCaml 61.40
(648 KB), java 6 -server 83.25 (11MB), Common Lisp SBCL 72.87 (4MB),
Haskell 153.13 secs (4MB) and Lua with JIT at 282.69 secs (952 KB).
The rest of the tests in the benchmark, including other, non-optimized
implementations in java, OCaml, Haskell and scripting languages, all go
above 9 minutes of runtime!! Including the clean code from Scheme I
mentioned... :P Ruby/Python/Perl take about 1 hour!
http://shootout.alioth.debian.org/u32/benchmark.php?test=fannkuch&lang=all
The slow version in Haskell is beautiful though:
http://shootout.alioth.debian.org/u32/benchmark.php?test=fannkuch&lang=ghc&id=3
This java version is horridly verbose and very slow:
http://shootout.alioth.debian.org/u32/benchmark.php?test=fannkuch&lang=javaxint&id=1
man, I love the shootout... ^_^
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Raiford <"m[raiford]!at"@gmail.com> wrote:
> Warp, this wasn't a practical idea in and of itself. Just a "Lets do
> this and see if it can be done" kind of thing.
If that was the goal, it's kind of a stupid goal. Of course it can be
done. Why couldn't it be done? Does C++.net impose some limitations that
would stop it from working?
AFAIK C++.net purely *adds* to the language. It doesn't remove anything.
So why couldn't it be done?
> It gives no benefit,
> except to say "See? The .NET runtime is fast enough to run Quake!"
It's not the .net runtime which is running the program. The program is
calling the .net runtime for some things (most artificially, without any
real good reason, for all I can see).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
