Of course, by 'objects that are near you appear larger than objects in front of you', I meant 'objects to the side look larger than objects straight ahead':P
This effect is especially distracting when a game uses dense fog - the engine deems objects to the side to be closer to you (since they're not as far *straight ahead* of you, but they ignore distance in the other dimensions), and thereby not as fogged. Sometimes you won't be able to see a wall if you're looking straight at it, but if you turn a bit it'll appear!
There seems to be quite a bit of misunderstanding on this subject, as I can't even find mention in the 3D Projection wikipedia article of the fact that linear projection isn't entirely realistic (well, it mimics a pinhole camera realistically, but if you're trying to simulate a regular camera lens, or a person's eyeball, the fisheye projection is really what you want - linear projection is only an approximation that happens to work well for low FOV values).
If you want some first-hand experience with the fisheye projection, go stand in a long straight hallway and look directly at the wall. Of course, the corners along the floor and ceiling won't appear to be perpendicular (as they do in most FPSes, even with the FOV turned way up) - they will appear to curve towards points at the outer edge of your vision. The world would be a very strange place if this weren't true!
Most 3D games won't let you set the FOV to 180 degrees, since it's impossible using flat (pinhole?) projection that most of them use. This choice of projection is also why things look so distorted at the edges of the screen with a high FOV, and is why objects that are near you appear larger than objects in front of you, even when they're the same distance away, among other visual quirks. In order to show such a wide angle (approaching 180 degrees or above), you'd need to use a projection that's not limited to showing objects on one side of a plane, such as fisheye projection. This isn't normally done because it's technically simpler to do 3D rendering when straight lines in the world correspond to straight lines on the screen (that's the simplified explaination).
I think the guy who did this deserves more credit than you give him, if only because re-implementing all the processing functions and parsing the language is a relatively large undertaking for anyone who doesn't have mountains of free time on their hands, and the fact that it works at all is good sign that this guy isn't completely incompetent.
All that said, I agree that a 'SpinArm' extending a 'Spin' isn't the best example of inheritance. I also realize that seemingly small things like this can be very frustrating to read for people who are well-versed in the subject. But it was my understanding that he threw out that 'this is an example of inheritance' line just to show processing syntax (and assuming the reader already knows what inheritance is and that that's not a very good example of its use), and I'm guessing that most of his code is more sensible - if his entire project was written that sloppily it doesn't seem likely that he would have gotten as far with it as he did.
It looks to me like the big accomplishment here is that he parses processing language code and API calls and converts it to JavaScript that uses a canvas. It's pretty cool that it's possible to do that (similar to the Java -> JavaScript converter or the Ruby VM in JavaScript mentioned a few days ago), but the end product doesn't seem that useful to me, as the processing language isn't significantly better than JavaScript for this kind of thing, anyway. I'd be more interested if this guy had found a way to make processing perform better (translated to JS or otherwise), or if he came up with an entirely new language that made certain graphics really simple to express (certainfractalgenerators come to mind). Though it feels likely that proofs-of-concept such as this will inspire something really great in the near future.
The 100 new languages we get each year tend to be the same C++ style language with a few pieces of syntactic sugar on top.
Syntactic sugar and (as you said) a lack of libraries.
It frustrates me to no end that I can't just pick a language for a project and use the mountains of java|ruby|perl libraries that I'm already familiar with. By now most languages ought to be able to compile themselves or be interpreted on one or 2 mainstream runtimes, or at least have a convenient method of calling each other's libraries.
I know there are several languages that run on the JVM, and that the intenion of Parrot is to address just this issue, but JVM is huge, slow to start, and not generally very well adjusted for running small scripts or CGI programs (the kind of programs I tend to write a lot), and Parrot's been in development at least since 2002, with only a few languages working on it, most of them incomplete.
Huh? Did upgrading to 64-bit addesses magically multiply our RAM by 4 billion? Until you just about double the amount of actual, available memory (I say 'just about' because not _all_ memory is going to be used for pointers and 64-bit ints), doubling the size of all your pointers would do more harm than good.
Re:Bet there still isn't a decent "Stop!" button
on
HTML V5 and XHTML V2
·
· Score: 1
If you look closely at the code he proposed, you'll see that he wasn't suggesting that.
> Just like you can not run Fedora 6 in a GUI on a computer with 64mb of ram and 800mhz. > Maybe Fedora should optimize their code?
I ran Windows 98 on such a machine for a long time with no problems. Sounds to me not like an 'optimisation' problem, but maybe Fedora could do less fancy and unnecessarry processor-eating computations. -_o
C-like syntax (not that there's anything wrong with c cyntax, but Ruby does so much better in so many areas), inconsistent and confusing naming conventions, inconsistenies between versions, MAGIC QUOTES (that are on by default on most web hosts)... That's some of the stuff that made me dislike PHP.
I know exactly what you mean. Yesterday my sister backed the car over our garden hose and now it leaks all over the driveway whenever she goes to water the flowers!
> as a side note, is it just me or to games that try > to look "real" just end up looking more fake because > the technology just can't compete with reality by a > longshot yet?
Agreed. This is one of the beefs I had with Final Fantasy 8. In FF7 your characters were made (as I recall) of a bunch of flat-shaded spheres. It didn't look real, but it looked good. In FF8, in attempt to use the same models for all parts of the game, you became a vaguely human-shaped bunch of polygons with highly pixelated textures. It looked really bad, IMO.
And on Windows, it doesn't use the regular windows dialog. Instead, it uses the GIMP-specific one which treats root directories (c:/, d:/, etc) very strangely. Click on c:, and you end up in c:/program files/somethingtotallyunrelatedtothepictureiwanted toedit and have to click '..' 5 times. >:#
Firefox sucks. I type in http://togos/ (togos being in my hosts file), and if it can't connect to the server for whatever reason, it takes me to togosspeedlunch or some dumb crap. It's extremely annoying and I have found no way to turn this behavior off. So I stick with Mozilla:P
I suppose the new genre is that of training characters to do something, rather than doing it yourself or directly telling your population what to do. A war simulation is the most obvious application, but it could be applied to all sorts of genres of a different dimension. Like an ant colony simulator...
Probably not; as another poster pointed out they'll be too busy worrying about embryos. OTOH, some of us lefties that actually realize what's going on might tell you that trapping a mind in a box like that is a bad idea to start with. Not that this IBM project actually does that. At least not yet.
> they make it so friggin hard to install any other > program that doesn't come with the OS
This is how it goes:
Bob: OK, so we need to make a windows distribution and a linux distribution of this program.
Joe: OK, we'd better statically link all the required libraries for the windows version, since, you know, Windows users don't want to, you know, have unresolved dependencies.
Bob: But Linux users *love* unresolved dependencies! Let's just tell them they need to have librfaries X, Y, Z, W, XYZZY, QXKDT, and FARTBUTT3.2 (but not FARTBUTT3.3) and they'll make a day of it.
I suppose the difference at the root of all this is that if someone's running Windows, you can be fairly sure that they're on an x86 box and are using the Microsoft(R)(TM)(copyrite) distribution. OTOH, you've no idea what the Linux user's have, and therefore trust that they know how to install needed libraries better than you do. In fact, the way these libraries want to be installed (in/usr/local/lib and 10 other places), it can be hard to distribute them in a clean way with your app, compounding the problem.
Slashdot Mirror
Of course, by 'objects that are near you appear larger than objects in front of you', I meant 'objects to the side look larger than objects straight ahead' :P
This effect is especially distracting when a game uses dense fog - the engine deems objects to the side to be closer to you (since they're not as far *straight ahead* of you, but they ignore distance in the other dimensions), and thereby not as fogged. Sometimes you won't be able to see a wall if you're looking straight at it, but if you turn a bit it'll appear!
There seems to be quite a bit of misunderstanding on this subject, as I can't even find mention in the 3D Projection wikipedia article of the fact that linear projection isn't entirely realistic (well, it mimics a pinhole camera realistically, but if you're trying to simulate a regular camera lens, or a person's eyeball, the fisheye projection is really what you want - linear projection is only an approximation that happens to work well for low FOV values).
If you want some first-hand experience with the fisheye projection, go stand in a long straight hallway and look directly at the wall. Of course, the corners along the floor and ceiling won't appear to be perpendicular (as they do in most FPSes, even with the FOV turned way up) - they will appear to curve towards points at the outer edge of your vision. The world would be a very strange place if this weren't true!
Most 3D games won't let you set the FOV to 180 degrees, since it's impossible using flat (pinhole?) projection that most of them use. This choice of projection is also why things look so distorted at the edges of the screen with a high FOV, and is why objects that are near you appear larger than objects in front of you, even when they're the same distance away, among other visual quirks. In order to show such a wide angle (approaching 180 degrees or above), you'd need to use a projection that's not limited to showing objects on one side of a plane, such as fisheye projection. This isn't normally done because it's technically simpler to do 3D rendering when straight lines in the world correspond to straight lines on the screen (that's the simplified explaination).
See this page for a visual comparison.
I think the guy who did this deserves more credit than you give him, if only because re-implementing all the processing functions and parsing the language is a relatively large undertaking for anyone who doesn't have mountains of free time on their hands, and the fact that it works at all is good sign that this guy isn't completely incompetent.
All that said, I agree that a 'SpinArm' extending a 'Spin' isn't the best example of inheritance. I also realize that seemingly small things like this can be very frustrating to read for people who are well-versed in the subject. But it was my understanding that he threw out that 'this is an example of inheritance' line just to show processing syntax (and assuming the reader already knows what inheritance is and that that's not a very good example of its use), and I'm guessing that most of his code is more sensible - if his entire project was written that sloppily it doesn't seem likely that he would have gotten as far with it as he did.
It looks to me like the big accomplishment here is that he parses processing language code and API calls and converts it to JavaScript that uses a canvas. It's pretty cool that it's possible to do that (similar to the Java -> JavaScript converter or the Ruby VM in JavaScript mentioned a few days ago), but the end product doesn't seem that useful to me, as the processing language isn't significantly better than JavaScript for this kind of thing, anyway. I'd be more interested if this guy had found a way to make processing perform better (translated to JS or otherwise), or if he came up with an entirely new language that made certain graphics really simple to express (certain fractal generators come to mind). Though it feels likely that proofs-of-concept such as this will inspire something really great in the near future.
Hah, my 5$ download all but stopped, now I'm downloading from 27 peers at 30kB/s. They should just put the .torrent link on the 'thanx 4 ca$h' page!
Here it is, by the way: http://thepiratebay.org/tor/4059246/Nine_Inch_Nails_-_Ghosts_I-IV_2008_320kbps_And_Extras
(Sorry if that link's already been posted - I didn't see it anywhere in the comments)
Syntactic sugar and (as you said) a lack of libraries.
It frustrates me to no end that I can't just pick a language for a project and use the mountains of java|ruby|perl libraries that I'm already familiar with. By now most languages ought to be able to compile themselves or be interpreted on one or 2 mainstream runtimes, or at least have a convenient method of calling each other's libraries.
I know there are several languages that run on the JVM, and that the intenion of Parrot is to address just this issue, but JVM is huge, slow to start, and not generally very well adjusted for running small scripts or CGI programs (the kind of programs I tend to write a lot), and Parrot's been in development at least since 2002, with only a few languages working on it, most of them incomplete.
I thought this guy had some interesting ideas on the subject: http://www.equi4.com/moam/nuts
Huh? Did upgrading to 64-bit addesses magically multiply our RAM by 4 billion? Until you just about double the amount of actual, available memory (I say 'just about' because not _all_ memory is going to be used for pointers and 64-bit ints), doubling the size of all your pointers would do more harm than good.
If you look closely at the code he proposed, you'll see that he wasn't suggesting that.
> Just like you can not run Fedora 6 in a GUI on a computer with 64mb of ram and 800mhz.
> Maybe Fedora should optimize their code?
I ran Windows 98 on such a machine for a long time with no problems.
Sounds to me not like an 'optimisation' problem, but maybe Fedora could do less fancy and unnecessarry processor-eating computations. -_o
C-like syntax (not that there's anything wrong with c cyntax, but Ruby does so much better in so many areas), inconsistent and confusing naming conventions, inconsistenies between versions, MAGIC QUOTES (that are on by default on most web hosts)... That's some of the stuff that made me dislike PHP.
I know exactly what you mean. Yesterday my sister backed the car over our garden hose and now it leaks all over the driveway whenever she goes to water the flowers!
> as a side note, is it just me or to games that try
> to look "real" just end up looking more fake because
> the technology just can't compete with reality by a
> longshot yet?
Agreed. This is one of the beefs I had with Final Fantasy 8. In FF7 your characters were made (as I recall) of a bunch of flat-shaded spheres. It didn't look real, but it looked good. In FF8, in attempt to use the same models for all parts of the game, you became a vaguely human-shaped bunch of polygons with highly pixelated textures. It looked really bad, IMO.
>'m sorry, but exec's should show a "bit" more professionalism than this crap
Explain, plz. I never understood this 'professionalism' business.
By that logic, Common Lisp itself is the most ad hoc implementation of Common Lisp there is.
And on Windows, it doesn't use the regular windows dialog. Instead, it uses the GIMP-specific one which treats root directories (c:/, d:/, etc) very strangely. Click on c:, and you end up in c:/program files/somethingtotallyunrelatedtothepictureiwanted toedit and have to click '..' 5 times. >:#
Firefox sucks. I type in http://togos/ (togos being in my hosts file), and if it can't connect to the server for whatever reason, it takes me to togosspeedlunch or some dumb crap. It's extremely annoying and I have found no way to turn this behavior off. So I stick with Mozilla :P
Meh. I've been using the end of the couch for 2 years. It works great with an optical mouse. :)
I suppose the new genre is that of training characters to do something, rather than doing it yourself or directly telling your population what to do. A war simulation is the most obvious application, but it could be applied to all sorts of genres of a different dimension. Like an ant colony simulator...
Probably not; as another poster pointed out they'll be too busy worrying about embryos. OTOH, some of us lefties that actually realize what's going on might tell you that trapping a mind in a box like that is a bad idea to start with. Not that this IBM project actually does that. At least not yet.
Any kid who's gone to school lately could have told you that. And they had to go and do a study. Dumb.
> It would take a serious series of credentials
;)
> for your generalization to have any value or
> weight.
Like, uhhh... Having BEEN a kid?
Not that it means kids never have nightmares. I know I did when I was around 3 to 5, but you do seem to be overlooking something
Hey, this is pretty catchy. I like it!
That is a good point, but at least this guy is doing something cool with his money instead of just buying 50 swimming pools.
Heh. Until it started talking about so and so happened in 2010, I didn't know it was fiction.
> they make it so friggin hard to install any other
/usr/local/lib and 10 other places), it can be hard to distribute them in a clean way with your app, compounding the problem.
> program that doesn't come with the OS
This is how it goes:
Bob: OK, so we need to make a windows distribution and a linux distribution of this program.
Joe: OK, we'd better statically link all the required libraries for the windows version, since, you know, Windows users don't want to, you know, have unresolved dependencies.
Bob: But Linux users *love* unresolved dependencies! Let's just tell them they need to have librfaries X, Y, Z, W, XYZZY, QXKDT, and FARTBUTT3.2 (but not FARTBUTT3.3) and they'll make a day of it.
I suppose the difference at the root of all this is that if someone's running Windows, you can be fairly sure that they're on an x86 box and are using the Microsoft(R)(TM)(copyrite) distribution. OTOH, you've no idea what the Linux user's have, and therefore trust that they know how to install needed libraries better than you do. In fact, the way these libraries want to be installed (in