OP here, let me see if I can address common comments I see here:
"why another language?" - because I can? I can't wrap my head around the thinking that creating new languages is somehow a problem for our development ecosystem. Noone forces you to use them. And like others have so kindly already mentioned, this one will probably die in obscurity, solving your problem before it even started.
"what's the point when it's not a major innovation?" - Better mainstream languages is an evolutionary process of designs building on eachother and making small incremental improvements. We will never arrive at the next big thing without tons of experimentation that teaches us what works. And if you want innovation, academia is full of programming language ideas that make Haskell feel like Basic in comparison, but they are very far off being usable. In contrast, Lobster is useful right here, right now, for a popular class of applications (games).
"significant whitespace, bzzzt" - hey, Python proves not everyone agrees with you. Would you have preferred a hypothetical world where Python and other significant whitespace languages had never existed? Oh, and in Lobster it is actually a compile error if two adjacent lines do not have the same whitespace prefix (sequence of tabs and/or spaces), meaning that it is *impossible* for code to visually look like its doing something different from what it actually does, even if people mix tabs and spaces and have different tab settings. The official Lobster syntax guidelines mandate spaces instead of tabs btw (like Python), but you are free to ignore that.
"why is this hobby project on the front page of/.?" - shouldn't you be spending your time moderating the firehose, or complaining that the moderation system doesn't work? I submitted it and it was promoted to the front page by others, why should I feel bad about that?:) I've been making compilers for.. ooh, 24 years now, and while this project is definitely more of a hobby project than past ones, it has been in the making for 3+ years, and has had quite a little bit more thought behind it than the average result of a college compiler class (I should know, I taught one for years:)
"isn't an interpreted, dynamically typed language too slow for game development?" - you may have a point there. There are no reasons why it couldn't be a lot faster with some type inference and JIT and/or static compilation.
"why did you change the OpenGL interface?" just because functions start with gl_ doesn't mean it's meant to be a direct mapping to OpenGL. It uses OpenGL 2 and OpenGL ES 2 under the hood, which require you to write and compile your own shaders and fiddle with matrices and many other things just to get a triangle on screen. Lobster's graphics interface shields you from that and is much more high level.
The packages currently available for ubuntu are the old 32bit binaries, which you can't see if you're on 64bit. You can either use the 32bit version (you'll also need a 32bit gtk installed) or wait for ubuntu to supply the new version for both.
Look at engines that actually get used for game projects in the commercial world: they are GAME engines, with a proven game for it, and a toolchain. Nobody ever licenses a naked engine, as in just a set of APIs. For a modern game, something that can render flashy graphics is only a small fraction of all the code involved.
Don't get me wrong, stack machines are certainly the simplest and arguably the most elegant & compact format, and certainly nice to use if you final target is mostly JIT/native code.
If you are interpreting, your primary concern is _speed_. Speed in an interpreter on modern architectures (especially the P4!) is determined by almost constant branch mispredictions for every interpreted instruction (assuming a for(;;) switch(..) {..}; central interpreting loop, which sadly is still the fastest portable way of doing things). So your goal is to have the minimum amount of instructions generated for any particular language construct.
Generating code for a register machine can be just as easy as for a stack machine if you have the right infrastructure (assuming you don't work with a bounded set of registers, which you have no need to in an interpreter).
Register machines do much better here than stack machines, I would estimate about 1.5 times less instructions overal. Don't worry so much about the amount of work inside an instruction, aim to do as much as possible at once without branching as your VM design.
It may be even be worth it to integrate struct field and array indirection as part of your opcode, as once you switch to a register machine, "getfield" type instructions will become your most frequent ones. So having say an "add" instruction that can directly address struct fields for its 3 arguments is going to be a big win (i.e. compile a.b = c.d + e.f into a single instruction). By having a pointer in your stack frame that points to itself, you can even do this for single variables in the same instruction.
This article is right on the money, and funnily enough addresses exactly the same topics as David Gelernter (/. NYT article a few days ago) tries to address with Lifestreams and related systems.
Filesystems are the biggest bottleneck to improving the OS ui, they singlehandedly are responsible for most of the problems these people mention. An ideal OS is persistent from the bottom up, and doesn't require you to think about load/save, start/stop, and storage locations.
How would this work? The user would just deal with documents, or objects, or however you'd want to call them. If he wants to view or edit them he just does so, he is not concerned with loading (there document is there, why does it require an intermediate action to make it even more available than it is?), he is not concerned with starting applications (maybe the document requires some code to make the editing possible, but why should the user care?).
But maybe most importantly he doesn't care about storage locations. Documents just exist, and don't have a particular location. So how does one "organize"? by queries (much like what we know from databases, just with a greatly simplified UI), or rather "persistent dynamic queries": persistent because they are always instantly viewable like directories, and dynamic because they refresh themselves automatically depending or new or changed objects. Want to see all emails from a certain sender? create a query and new emails from that sender automatically end up there. This allows people to create any amount of organisation in their document soup when they need it, not when they create documents.
Some posters complained that automatic persistence would not give you any control over throwing away unwanted changes... that's why a good OS should automatically keep track of a version history or persistent undo. Some others complained that not exiting applications would clog memory... that's why a good OS should be able to track down which code components are no longer needed for current documents being accessed, and act accordingly.
You were so busy to talk about your favourite feature that you forgot to actually look at the page I guess. Quite a few languages of mine do TI, for example the "Bla" one (read the doc and/ or source code) has quite extensive TI.
Yes TI is great. But it is not without issues outside of the world of functional programming (though most have sensible solutions).
In terms of cheating with the source, I don't believe that the game that comes with this engine is really supposed to be that big of a deal - it's more of a showcase for the engine itself.
Sorry, wrong assumption. One of my goals was to keep the engine ultra-simplistic, so I would actually manage to spend time on the parts I find interesting, such as the in-game editing and the multiplayer & single player gameplay.
Yes, cheating is a problem, especially for cube since a lot of the gameplay code runs (authoratively) client side. There is a lot that can be done in terms of checking though, but I fear that if someone builds a multiplayer oriented game off this with a significant community, it will have to be closed source again.
I know that is the way to go. Just right now I don't want the hassle of arguing with lots of people why I won't accept their 3 megabyte lensflare patches. Not a lot of point running an open source project if you are going to reject almost all patches anyway. When this goes open source, forking will be the only option for people that want to add changes.
The reason it reminds you of Quake 2 is that a lot of the textures he used in his sample levels actually are borrowed Quake 2 textures
bzzzt... all textures that are part of cube are 100% non commercial, made by authors like Sock and Iikka Keranen. Some of them may look similar to the "base" style of quake2, but they're not copied.
I guess its hard for both open & closed source fanatics to understand what I am doing with cube w.r.t. to the source.
No, I am not trying to sell it (cube is a fun little engine, but it lacks 101 features to be commercially viable).
No, I am not an Evil Closed Source Person. If you look at my homepage you'll see all my other projects come with source code (mostly GPL). If you read the cube docs, you'd see there is a plan to release the sources (BSD/ZLIB).
and no, the code doesn't require major restructuring / cleanup before it can be released. The exe size on win32 with "mimimize code size" is 80k or so, I am sure everyone will agree that given the feature set there is not a lot of fat to trim.
My motivation for not releasing the source yet is that cube is purely programming fun, and I have very particular coding/design ideas (minimalism) which I don't trust others to follow (yes, very arrogant, but its my code, deal with it).
Why clean up one unlogical system (time units) but stick with another (base-10) ?
When you go through the trouble of redesigning time units, you might as well try and get it completely right and use a power of two scale.
Most people subdivide the day in 5 minute units, hardly anyone makes an appointment for something smaller than that. As it happens, there are 288 5-minute units in the day, so one could subdivide the day in 256 units, and we'd have the added advantage of just having 1 unit needed for almost all practical purposes instead of 2 (minutes+hours). We could use an additional 256 units for the 256 slices of those 5.625 minutes, each of which lasts about 1.32 seconds, which is close enough to our current seconds. You could continue with 256 units for the new "milliseconds" etc.
You would probably want to use hexadecimal notation for time then (much superior to decimal anyway): "honey, lets have dinner at C4" (20 past 6 pm).
Maybe once this is instantiated we can start working on replacing other measures by power of two scales / hexadecimal as well.
"Unbelievable! Another great surprise from Id Software!"
How so? this is _public_ source code, the one you make _mods_ with. It has been standard practice since quake (1) to release this freely and soon after the game has come out. No suprise whatsoever.
Which is very different from id software releasing the _engine_ code to a game (as it has done for doom/quake/quake2), which would have been truely suprising in the case of rtcw:)
What always suprised me with these kinds of developments, is how easily people skip step 2, i.e.:
1. Someone starts doing X (where X = passport, p2p, XML,...)
2. ?
3. everyone sees X as a necessity, and is trying hard to not be left out.
So, we are already assuming we won't be able to live without these authentication networks, but noone along the line ever asked why? Am I the only one who finds this funny (or sad, your pick)?
Is it THIS easy to make a whole planet go along with a phenomenon without using basic brain functions?
"users" are irrelevant to licensing issues
on
Freedom or Power Redux
·
· Score: 4, Interesting
this is one issue that I have never understood about open source advocacy: the talk about "users".
(pure) users can't program thus their "freedom" is a 1:1 coupling to the freedom of the programmer that is their "supplier".
The only freedoms that thus matter are those of programmers (and "users that can program", if you must). But an easier metric to compare licenses would be "Nth level recipient", i.e.:
zero level: the original programmer and licensor
1st level: the programmer that builds on the original code
2nd level and onward: programmer that wants to build on the N-1 level base.
The GPL gives "most freedom" to levels 0 and 2 onwards (the more "selfish" license), whereas the BSD license gives "most freedom" to level 1 (a license giving "most freedom" to all of them can't exist, it will always be a fundamental choice). As soon as a level is occupied by a "user", there won't be any N+1 levels after it, so "freedom" becomes irrelevant.
The only downside to it is that it would require a massive effort on the part of web sites, standards bodies, and/or ISPs to switch over
Doh! Anyono should know by now that any idea that requires centralized rule to switch over (if only everyone would...) is guaranteed to fail. Change can generally only come about emergently, i.e. plant a good idea and hope so many people will pick it up to gain critical mass.
should "Is X art"? always be a yes/no question? To me, obviously not. Debating wether something is "art" by definition is pretty pointless.
Like classical "art", is there enough in video games that arouses your interest, makes you think, is aesthetically pleasing, original, or creative? most definitively.
Um, read what it says. That was for quake 1.01 linux, which was, um, "going around the net" WAY before the GPL quake source was officially released. I used that to code fisheye quake for my personal enjoyment, and ported it over to the GPL release later.
Re:Playing Quake like this causing health problems
on
PanQuake
·
· Score: 1
There's two different kind of dizzyness / motion sickness you can get from quake: immersion and camera motion.
You can get sick from "immersion" by playing on big screens (the more they cover the FOV of your eyes the better) coupled with *high* game FOVs, where fisheye projection helps to immerse you even more (because it gives less perspective distortion). I personally crave this kind of immersion and am used to it, but its not for everyone.
Alternatively you can get sick from "camera motion", which happens with either *low* game FOVs and/or low fps. It stops your eyes being able to smoothly track movement, high FOVs give you more context. It's like trying to run around in real life while looking through a zoomlens, you'll get very dizzy. Personally I suffer from this, I can't play games that don't allow FOV being changed from the default 90 (been used to 120 for 5 years now).
As a nice anecdote of how people don't understand what FOV does to you, I took part in a test as part of a psychology research from an unnamed university, where they investigated motion sickness and stability (how well you stand on your feet). In the test you had to stand in a black box, with in front of you a tv screen showing a video of someone running around with a handheld camera, meant to induce motion sickness. They had however shot the whole movie *using a zoomlens* giving a FOV of 20 or so. So their whole research was moot, as all motion sickness was induced by FOV rather than the actual movement. They weren't happy when I told them I think.
How likely is it that Intel will have used Quake 3 as a benchmark internally, and actually optimised their design for it?
Think about it, it's not completely unlikely, as the percentage of people and websites out there that rates Quake 3 as the most important benchmark is very high (I was one of them until the P4 came out), so it would make more sense commercially than to optimize for SPEC as they do traditionally.
Most reviews explain the "Quake 3 discrepancy" by its large hunger for memory bandwidth, which certainly is true. However within the large range of benchmarks I saw (for wide selection see the one on Ace's for example) there were plenty more memory-bound benchmarks, all of which the Athlon did equally well or better on.
Also, Quake 3 is VERY hungry for float performance, which the P4 appearently hasn't got. Does Quake3 use SSE2, either itself or in nvidea drivers which would allow them to mask this? Maybe it would be fun to test Quake 3 on a P4 with a video card that doesn't have T&L (to reduce the floating point load) and has no SSE2 optimisations (voodoo5 maybe?).
What people haven't mention sofar is _control lag_, which is independant from any input sampling method: the fact that if your frames stutter past you at 20 fps you have a harder time aiming, because how people aim is a kind of feedback loop between what they see and the adjustment they make with the mouse. Control lag can easily give as much or more lag in aiming than a slow connection does, I've included a very good explanation of this (taken from a messageboard that doesn't exist anymore) below.
Couple this with what other people have mentioned (primarily that MINIMUM fps is all that matters: difference between a normal timedemo and an intense fight can be as much as 5x to 10x, try getting 72fps minimum for that!) and the fact that the physics of all quake derived games are biased towards high fps, and 200 fps is actually kinda low. This is of course if you want to play "competively", if all you want is a relaxing frag for half an hour after work, 50 fps average will do you fine.
The post:
from: Menace (matthewv@best.com):
That Penstar link is interesting, but gets a lot of things wrong and misses all the most
important points.
Here goes.
Visually, the eye can distinguish between separate "flickers" at a varying rate depending on
such factors as brightness (brighter requires higher refresh rate--movies can get away with 48
flickers/sec becuase they are actually quite DIM--contrary to what that website says), field of
view (peripheral vision is more sensitive to flicker than straight-ahead vision), age of the
viewer, etc. The specific rate is known as the "critical flicker frequency."
So if you have a tiny, very dim point of light which is only slightly brighter than the
background and which just gets a little brighter and dimmer, and look at it directly, it can
flicker very slowly and still appear to be a steady point of light (you might not see the flicker
even if it's flashing at under 10Hz, or even slower), but a bright full-view image (such as a
bright strobe light in a dark room) may need to refresh at 200Hz or more to appear
completely steady and continuous.
It's less clear how much the eye/brain can integrate and distinguish motion, but my opinion is
that we CAN distinguish smoother/more detailed motion up to nearly the flicker frequency
limit. It may not always be noticeable, since often successive images differ little from the
preceeding one (which is a critical factor in motion video compression), but when the whole
image moves quickly or fast dramatic action occurs, you can see the difference.
Anyway, the 24fps (24 frames, each projected twice for 48 "flickers" per second) of film is
clearly NOT enough--I can see the lack of motion discrimination in movies quite easily,
though you tend to get used to it within the first couple of minutes. The 20-25fps range often
quoted as "all the eye can see" is really the MINIMUM limit below which most people have a
hard time fooling their brains into thinking they are seeing continuous motion, as opposed to
a series of distinct still images in succession. But that doesn't at all mean that increasing the
framerate doesn't result in dramatic improvements. The one serious effort I know of to study
this in regards to film was done by Douglas Trumbull, who concluded that 60fps was the
desirable minimum for smooth and accurate motion reproduction--and appearantly such film
looks startlingly more realistic than normal film.
HOWEVER, all this talk of "what the eye can see" blah blah blah doesn't even begin to address
the biggest problem in terms of computer games. We seem to be forgetting that instead of
just passively WATCHING our computer games, we INTERACT with them. So now you have
to think a little about what "framerate" means in these terms--if the game can render a certain
number of frames per second, that means that each frame takes a certain amount of time to
render. So from the point that the game has accepted all input, it takes that much time before
you can see it on screen. In addition, if you give input while it's in the middle of the previous
screen, it has to wait additional time until that screen is finished before it even begins on the
next one.
What this means is that there is an inverse relatoinship between framerate and what I call
"control latency." The amount of latency can be pretty shocking--at 10fps, your control latency
(the time between, say, moving the mouse and seeing the image on screen move as a result)
is actually 100-200ms! This is even wose than having a 100-200ms ping (a LOT worse) since it
effects aiming and all other client-side actions. At 25fps, the delay is 40-80ms, which is still
pretty significant. In order to keep that delay under 20ms at all times you need to have a
framerate which never drops below 100fps!
This helps explain the feeling of sudden lag that can occur during intense battles--in addition
to likely ping spikes from too much data saturating your lowly modem connection, if your
framerate plummets at the same time (which it probably will), it's quite possible you would
literaly experience a brief increase in total latency approaching a full second!
On top of this of course you have to consider the maximum possible number of angles you
can aim it in a given period of time. At 10fps, in the half second you typically have to aim,
there are only 5 possible angles you can aim at, and it will jump from one to the next, instead
of moving smoothly between them. Combined with the latency (100-200ms) this makes it
VERY difficult to aim. Compare this to 100fps where there would be 50 distinct angles to
cycle through in that half second, and only 10-20ms delay--it's MUCH easier to aim precisely,
and to make quick adjustments if necessary.
On top of all that of course is the fact that what we should be concerned with is our MINIMUM
framerates under the worst possible conditions, since the average framerate in a particular
situation is usually as much as double the minimum, and an intense situation is usually far
more demanding than your average "timedemo." (Compare bigass1.dem to Quake's built-in
demos, or crusher.dm2 to Q2's demo1.dm2 for instance, then spend some time watching
your "average" "minimum" and "maximum" numbers in Unreal Tournament with the timedemo
utility enabled. Based on the variation, take a guess what your minimum framerate in bigass1
or crusher would be, then compare that to the average reported score for demo1...) The
point being that even if all we want is a bare minimum of 30fps at all times, we may need to
get 50-100fps as the average score in a standard timedemo. And that's assuming that 30fps is
"enough," which, based on the information above, I contend is not the case--while a "casual"
gamer may not find it worthwhile to spend the money or sacrifice the visual quality for
improved framerate, there clearly IS a benefit to it. Certainly there's a limit--I doubt going
above 100fps or so does any additional good, but again, to ensure that fps ALL THE TIME
may take a timedemo score approaching 200fps...
In the form of the new Amiga. It uses Tao's Elate technology, which is exactly what you ask for: a portable cpu/assembly abstraction, with no more language bias than any other cpu (i.e. C mostly) coupled with a nice lightweight OS providing all common functionality. Comes with a very clean assembler, gcc, and a very fast Java JIT. It has already been ported to god knows how many architectures and is (albeit a bit "raw") available now.
Slashdot Mirror
You'll need robust iOS/Android support before you can dream of challenging SDL.
OP here, let me see if I can address common comments I see here:
"why another language?" - because I can? I can't wrap my head around the thinking that creating new languages is somehow a problem for our development ecosystem. Noone forces you to use them. And like others have so kindly already mentioned, this one will probably die in obscurity, solving your problem before it even started.
"what's the point when it's not a major innovation?" - Better mainstream languages is an evolutionary process of designs building on eachother and making small incremental improvements. We will never arrive at the next big thing without tons of experimentation that teaches us what works. And if you want innovation, academia is full of programming language ideas that make Haskell feel like Basic in comparison, but they are very far off being usable. In contrast, Lobster is useful right here, right now, for a popular class of applications (games).
"significant whitespace, bzzzt" - hey, Python proves not everyone agrees with you. Would you have preferred a hypothetical world where Python and other significant whitespace languages had never existed? Oh, and in Lobster it is actually a compile error if two adjacent lines do not have the same whitespace prefix (sequence of tabs and/or spaces), meaning that it is *impossible* for code to visually look like its doing something different from what it actually does, even if people mix tabs and spaces and have different tab settings. The official Lobster syntax guidelines mandate spaces instead of tabs btw (like Python), but you are free to ignore that.
"why is this hobby project on the front page of /.?" - shouldn't you be spending your time moderating the firehose, or complaining that the moderation system doesn't work? I submitted it and it was promoted to the front page by others, why should I feel bad about that? :) :)
I've been making compilers for.. ooh, 24 years now, and while this project is definitely more of a hobby project than past ones, it has been in the making for 3+ years, and has had quite a little bit more thought behind it than the average result of a college compiler class (I should know, I taught one for years
"isn't an interpreted, dynamically typed language too slow for game development?" - you may have a point there. There are no reasons why it couldn't be a lot faster with some type inference and JIT and/or static compilation.
"why did you change the OpenGL interface?" just because functions start with gl_ doesn't mean it's meant to be a direct mapping to OpenGL. It uses OpenGL 2 and OpenGL ES 2 under the hood, which require you to write and compile your own shaders and fiddle with matrices and many other things just to get a triangle on screen. Lobster's graphics interface shields you from that and is much more high level.
The packages currently available for ubuntu are the old 32bit binaries, which you can't see if you're on 64bit. You can either use the 32bit version (you'll also need a 32bit gtk installed) or wait for ubuntu to supply the new version for both.
Look at engines that actually get used for game projects in the commercial world: they are GAME engines, with a proven game for it, and a toolchain. Nobody ever licenses a naked engine, as in just a set of APIs. For a modern game, something that can render flashy graphics is only a small fraction of all the code involved.
You are asking the wrong question.
Don't get me wrong, stack machines are certainly the simplest and arguably the most elegant & compact format, and certainly nice to use if you final target is mostly JIT/native code.
If you are interpreting, your primary concern is _speed_. Speed in an interpreter on modern architectures (especially the P4!) is determined by almost constant branch mispredictions for every interpreted instruction (assuming a for(;;) switch(..) {..}; central interpreting loop, which sadly is still the fastest portable way of doing things). So your goal is to have the minimum amount of instructions generated for any particular language construct.
Generating code for a register machine can be just as easy as for a stack machine if you have the right infrastructure (assuming you don't work with a bounded set of registers, which you have no need to in an interpreter).
Register machines do much better here than stack machines, I would estimate about 1.5 times less instructions overal. Don't worry so much about the amount of work inside an instruction, aim to do as much as possible at once without branching as your VM design.
It may be even be worth it to integrate struct field and array indirection as part of your opcode, as once you switch to a register machine, "getfield" type instructions will become your most frequent ones. So having say an "add" instruction that can directly address struct fields for its 3 arguments is going to be a big win (i.e. compile a.b = c.d + e.f into a single instruction). By having a pointer in your stack frame that points to itself, you can even do this for single variables in the same instruction.
This article is right on the money, and funnily enough addresses exactly the same topics as David Gelernter (/. NYT article a few days ago) tries to address with Lifestreams and related systems.
Filesystems are the biggest bottleneck to improving the OS ui, they singlehandedly are responsible for most of the problems these people mention. An ideal OS is persistent from the bottom up, and doesn't require you to think about load/save, start/stop, and storage locations.
How would this work? The user would just deal with documents, or objects, or however you'd want to call them. If he wants to view or edit them he just does so, he is not concerned with loading (there document is there, why does it require an intermediate action to make it even more available than it is?), he is not concerned with starting applications (maybe the document requires some code to make the editing possible, but why should the user care?).
But maybe most importantly he doesn't care about storage locations. Documents just exist, and don't have a particular location. So how does one "organize"? by queries (much like what we know from databases, just with a greatly simplified UI), or rather "persistent dynamic queries": persistent because they are always instantly viewable like directories, and dynamic because they refresh themselves automatically depending or new or changed objects. Want to see all emails from a certain sender? create a query and new emails from that sender automatically end up there. This allows people to create any amount of organisation in their document soup when they need it, not when they create documents.
Some posters complained that automatic persistence would not give you any control over throwing away unwanted changes... that's why a good OS should automatically keep track of a version history or persistent undo. Some others complained that not exiting applications would clog memory... that's why a good OS should be able to track down which code components are no longer needed for current documents being accessed, and act accordingly.
You were so busy to talk about your favourite feature that you forgot to actually look at the page I guess. Quite a few languages of mine do TI, for example the "Bla" one (read the doc and/ or source code) has quite extensive TI.
Yes TI is great. But it is not without issues outside of the world of functional programming (though most have sensible solutions).
Sorry, wrong assumption. One of my goals was to keep the engine ultra-simplistic, so I would actually manage to spend time on the parts I find interesting, such as the in-game editing and the multiplayer & single player gameplay. Yes, cheating is a problem, especially for cube since a lot of the gameplay code runs (authoratively) client side. There is a lot that can be done in terms of checking though, but I fear that if someone builds a multiplayer oriented game off this with a significant community, it will have to be closed source again.
I know that is the way to go. Just right now I don't want the hassle of arguing with lots of people why I won't accept their 3 megabyte lensflare patches. Not a lot of point running an open source project if you are going to reject almost all patches anyway. When this goes open source, forking will be the only option for people that want to add changes.
bzzzt... all textures that are part of cube are 100% non commercial, made by authors like Sock and Iikka Keranen. Some of them may look similar to the "base" style of quake2, but they're not copied.
I guess its hard for both open & closed source fanatics to understand what I am doing with cube w.r.t. to the source.
No, I am not trying to sell it (cube is a fun little engine, but it lacks 101 features to be commercially viable).
No, I am not an Evil Closed Source Person. If you look at my homepage you'll see all my other projects come with source code (mostly GPL). If you read the cube docs, you'd see there is a plan to release the sources (BSD/ZLIB).
and no, the code doesn't require major restructuring / cleanup before it can be released. The exe size on win32 with "mimimize code size" is 80k or so, I am sure everyone will agree that given the feature set there is not a lot of fat to trim.
My motivation for not releasing the source yet is that cube is purely programming fun, and I have very particular coding/design ideas (minimalism) which I don't trust others to follow (yes, very arrogant, but its my code, deal with it).
Why clean up one unlogical system (time units) but stick with another (base-10) ?
When you go through the trouble of redesigning time units, you might as well try and get it completely right and use a power of two scale.
Most people subdivide the day in 5 minute units, hardly anyone makes an appointment for something smaller than that. As it happens, there are 288 5-minute units in the day, so one could subdivide the day in 256 units, and we'd have the added advantage of just having 1 unit needed for almost all practical purposes instead of 2 (minutes+hours). We could use an additional 256 units for the 256 slices of those 5.625 minutes, each of which lasts about 1.32 seconds, which is close enough to our current seconds. You could continue with 256 units for the new "milliseconds" etc.
You would probably want to use hexadecimal notation for time then (much superior to decimal anyway): "honey, lets have dinner at C4" (20 past 6 pm).
Maybe once this is instantiated we can start working on replacing other measures by power of two scales / hexadecimal as well.
"Unbelievable! Another great surprise from Id Software!"
:)
How so? this is _public_ source code, the one you make _mods_ with. It has been standard practice since quake (1) to release this freely and soon after the game has come out. No suprise whatsoever.
Which is very different from id software releasing the _engine_ code to a game (as it has done for doom/quake/quake2), which would have been truely suprising in the case of rtcw
http://wouter.fov120.com/panq2.jpg
;)
Slackers win the north european "smackdown" quakeworld competition over L, with a 3-1 win.
http://www.challenge-eu.com/smackdown/north/
What always suprised me with these kinds of developments, is how easily people skip step 2, i.e.:
...)
1. Someone starts doing X (where X = passport, p2p, XML,
2. ?
3. everyone sees X as a necessity, and is trying hard to not be left out.
So, we are already assuming we won't be able to live without these authentication networks, but noone along the line ever asked why? Am I the only one who finds this funny (or sad, your pick)?
Is it THIS easy to make a whole planet go along with a phenomenon without using basic brain functions?
this is one issue that I have never understood about open source advocacy: the talk about "users".
(pure) users can't program thus their "freedom" is a 1:1 coupling to the freedom of the programmer that is their "supplier".
The only freedoms that thus matter are those of programmers (and "users that can program", if you must). But an easier metric to compare licenses would be "Nth level recipient", i.e.:
zero level: the original programmer and licensor
1st level: the programmer that builds on the original code
2nd level and onward: programmer that wants to build on the N-1 level base.
The GPL gives "most freedom" to levels 0 and 2 onwards (the more "selfish" license), whereas the BSD license gives "most freedom" to level 1 (a license giving "most freedom" to all of them can't exist, it will always be a fundamental choice). As soon as a level is occupied by a "user", there won't be any N+1 levels after it, so "freedom" becomes irrelevant.
Doh! Anyono should know by now that any idea that requires centralized rule to switch over (if only everyone would...) is guaranteed to fail. Change can generally only come about emergently, i.e. plant a good idea and hope so many people will pick it up to gain critical mass.
should "Is X art"? always be a yes/no question? To me, obviously not. Debating wether something is "art" by definition is pretty pointless.
Like classical "art", is there enough in video games that arouses your interest, makes you think, is aesthetically pleasing, original, or creative? most definitively.
Sorry, I guess I wasn't clear. This is based on the original sources id software GPL-ed. It is not based on any of the source ports out there.
You should be able to just plug the sources in an build for linux glquake (haven't got opengl working on my linux setup, so couldn't test).
Um, read what it says. That was for quake 1.01 linux, which was, um, "going around the net" WAY before the GPL quake source was officially released. I used that to code fisheye quake for my personal enjoyment, and ported it over to the GPL release later.
There's two different kind of dizzyness / motion sickness you can get from quake: immersion and camera motion.
You can get sick from "immersion" by playing on big screens (the more they cover the FOV of your eyes the better) coupled with *high* game FOVs, where fisheye projection helps to immerse you even more (because it gives less perspective distortion). I personally crave this kind of immersion and am used to it, but its not for everyone.
Alternatively you can get sick from "camera motion", which happens with either *low* game FOVs and/or low fps. It stops your eyes being able to smoothly track movement, high FOVs give you more context. It's like trying to run around in real life while looking through a zoomlens, you'll get very dizzy. Personally I suffer from this, I can't play games that don't allow FOV being changed from the default 90 (been used to 120 for 5 years now).
As a nice anecdote of how people don't understand what FOV does to you, I took part in a test as part of a psychology research from an unnamed university, where they investigated motion sickness and stability (how well you stand on your feet). In the test you had to stand in a black box, with in front of you a tv screen showing a video of someone running around with a handheld camera, meant to induce motion sickness. They had however shot the whole movie *using a zoomlens* giving a FOV of 20 or so. So their whole research was moot, as all motion sickness was induced by FOV rather than the actual movement. They weren't happy when I told them I think.
How likely is it that Intel will have used Quake 3 as a benchmark internally, and actually optimised their design for it?
Think about it, it's not completely unlikely, as the percentage of people and websites out there that rates Quake 3 as the most important benchmark is very high (I was one of them until the P4 came out), so it would make more sense commercially than to optimize for SPEC as they do traditionally.
Most reviews explain the "Quake 3 discrepancy" by its large hunger for memory bandwidth, which certainly is true. However within the large range of benchmarks I saw (for wide selection see the one on Ace's for example) there were plenty more memory-bound benchmarks, all of which the Athlon did equally well or better on.
Also, Quake 3 is VERY hungry for float performance, which the P4 appearently hasn't got. Does Quake3 use SSE2, either itself or in nvidea drivers which would allow them to mask this? Maybe it would be fun to test Quake 3 on a P4 with a video card that doesn't have T&L (to reduce the floating point load) and has no SSE2 optimisations (voodoo5 maybe?).
Couple this with what other people have mentioned (primarily that MINIMUM fps is all that matters: difference between a normal timedemo and an intense fight can be as much as 5x to 10x, try getting 72fps minimum for that!) and the fact that the physics of all quake derived games are biased towards high fps, and 200 fps is actually kinda low. This is of course if you want to play "competively", if all you want is a relaxing frag for half an hour after work, 50 fps average will do you fine.
The post:
In the form of the new Amiga. It uses Tao's Elate technology, which is exactly what you ask for: a portable cpu/assembly abstraction, with no more language bias than any other cpu (i.e. C mostly) coupled with a nice lightweight OS providing all common functionality. Comes with a very clean assembler, gcc, and a very fast Java JIT. It has already been ported to god knows how many architectures and is (albeit a bit "raw") available now.