I've always felt that the eye's light adaptation should be simulated by the game. If you play in a well lit room, your eyes won't adapt to changing light levels in a computer game, so I wonder, why doesn't the game increase the lighting when the majority of the scene is dark? It would even be possible to create "blinding" effects when entering daylight from a dark room. It would also create the impression of an even higher dynamic range of light than what is actually possible on a monitor.
The classic Digger game with CGA graphics for the PC (ran on the 8086) went through this process by this guy: http://www.digger.org/
Amazing feat. It's completely rewritten in C to gain exactly the same functionality as the original code, with only the binary / dissassembled machine code to work with.
Dont underestimate 120 bits/s
on
Goodbye, Galileo
·
· Score: 2, Interesting
"maximum data transfer rate of ~120 bits/s"
Let see. 120 bits/sec for 8 years... thats about 28 gigabytes of data. Not that bad.
... The author has chosen to use Ruby as his working language. This is an interesting choice. Ruby is certainly a language that is inspiring a lot of admiration these days...., but with the majority of the code-generation examples being for Java-related technologies, I wonder why Java was not selected instead.
It all about choosing the right tool for the job. Arguing that you should use Java to generate Java is like asking a carpenter to use a board of wood as the only tool to make a table.
Using Ruby (or, Perl, etc.) makes the code generator a lot simpler.
Did any of the posters care to checkout the site, click the download link and get the source? This is NOT an aprils fool joke. This an (albeit esoteric) actual language with a parser, a VM, and example programs to go!
User friendliness is subjective and covers many more or less measurable properties usch as user experience, user efficiency, learning curve, etc.
Most new users of a product will get a bad experience from an interface with a steep learning curve. They want to be able to use only the most basic features, here and now. They will never care about the fancy features due to little interest in the technology.
Experienced users [geeks?] will get a bad experience from an overly simplified user interface. They will want to be efficient with the interface, know about and control every feature, and are willing to spend time learning new concepts to get there.
This conflict is solvable (only?) by having two or more versions of the user interface and let each user decide.
CUPS (Common Unix Printing System) has support for simple quotaing. You can limit number of pages per user per time interval (e.g. month) and so forth. You cannot however set quotas per user individually or per user group. THere is, however a page_log which logs who has print how many pages. This can be used to disable access to the printing server for those who print to much to your likings:)
When will there be a filter on slashdot to weed out all news from the trying-to-make-linux-look-like-windows dept.? For me, and for a lot of the people I study and work with, OutLook was never a serious alternative to the MUAs we use (such as Pine, VM, Gnus etc). What is the "news for nerds" in a OutLook-a-like MUA?. It's not stuff that matters:(
No. This fall into the category, "This feature [overlapping windows] is most of the time more annoying and confusing than helpful, so we are going to take it away".
I can't see any possible situation where it is helpfull to have windows overlap. I have been using the Ion window manager for a year now, and have never had a more tidy and clean desktop.
This is excellent. XMMS has always had a pretty poor decoder (the same as in mpg123), which does not handle VBR mp3's very good (lots of artifacts in the sound). FreeAmp has a better decoder (as does mpg321), but is overall quite buggy. I'm looking forward to this.
1) Refactor early! Refactor the code and API as soon as you been suspect that it isn't going to be scalable/maintainable in the future. The longer you wait, the more unmaintainable the code gets and the more users will depend on your API. If a part of the API was a design mistake from the beginning, change it asap! Both you AND your users will benefit from the change (even though some will complain)
2) Make it "reasonable" backwards compatible. I.e. there is no reason behind supporting gcc-2.7-series. C++ compilers are lacking behind the ISO standard, but most are cathing up. Don't avoid exceptions because "some compilers doesn't support it". Some compilers doesn't, but exceptions has been around for 10 years! Time to force your users into an upgrade, I say.
The analogy, "should hammer makers be responsible for murders-by-hammer" is wrong. It should be "should gun makers be responsible for murder-by-shot?".
A hammer is designed as a tool for practical purposes, but can be used to kill. A rootkit is designed to gain unauthorized access, not to as a tool for practical purposes. (But may have practical side effects, akin to a gun, which CAN be used to avoid getting shot, while that is not what it was designed for).
Besides from this probably being another April's Hack, this has already been done! And its called Ruby. Ruby takes all the good parts from Perl, Python, Java, and even Smalltalk and combine them in a genuine object oriented language which is suited for both quick hacks and larger projects. Read Thirty-seven reason I Love Ruby and What's Ruby.
XFree has two mouse speed. The default and the accelerated, when you move faster than some threshold. You can use xset to configure the multipler and divisor for the accelerated speed.
Unfortunaly, there is no smooth acceleration in X. By smooth I mean that the actual cursor speed moves by some function of the actual mouse speed, which is NOT linear. E.g. cursorspeed = mousespeed ^ 1.25. This gives polynomial speed, which MS OS has had since I do not know when.
In DOS, the mouse drivers provided by Logitech and other had this feature, also known as "ballistic" acceleration (if you did not know, Ballistic is a polynomial movement). The is also used in Windows today.
When I first used X11, I too had problem using the mouse, because of the lack of ballistic movement, but you get used to it! I can see the problems with trackballs though, where you have a harder time moving the longer distances.
Fortunately Quake3Arena for Linux has its own Mouse acceleration/ballistics which makes the controls right. But if you try running windows q3a through Wine, you can experience this problem. Q3A for Window depends on windows to do the ballistics, but they are not provided in Wine, so the controls are very bad. You can turn, but you cannot turn fast because the acceleration is linear (even when accelerated).
Beg the XFree86 project for ballistic mouse acceleration! It's not really a driver problem.
The fella need to steal the screen and keyboard in order to interact with them. VNC does not provide this on X. It merely allows you to get a (not the) desktop on the machine. The desktop is your own, running at it's own display it (e.g. DISPLAY=:1) and you cannot share it with others (unless you log our and let other use the VNC, but that would require all student to use VNC in the first place, and still wouldn't allow interaction).
VNC Screens are managed by Xvnc which is an X server in its own right, simply exporting the display over a compressed network connection. It's only the Window version which allow you to control a remote desktop.
If modern toolkits were written for Xt, they would have a much harder time porting it to other platforms. Both Gtk+ and Qt runs on Windows, and directly on framebuffers which make them a viable solution for embedded devices. You wouldn't want to run a full bloated X11 on your Palm, now, would you?
My guess at why Xt isn't so popular is the documentation. There is almost no good tutorials and reference for Xlib and Xt around the net. You need the books. Yes, there is the library reference, but it's a postscript file and very hard to find. The hypertext was invented after the documentation was written, and the docs hasn't been updated. Futhermore, this documentation and the man pages for the Xlib/Xt API are NOT very good. It assumes that you know the basics - and for that you need the books. A showstopper for many + making it hard to make a quick hack.
Another reason may be the structure of the API itself. It's rather complex. Not much is "default" until you choose otherwise, as in Gtk+. Instead you have to make all the decisions about the properties of a window before it can be displayed. Again, a showstopper for quick hacks.
GNU Pth is a portable non-preemptive threading library. All threads run in a single server OS process, so it can be a solution if you have resource concerns. (I know a few perverted people who enjoy programming with tens of thousands of threads, which Linux is incapable of handling).
A memory leak is a sign of bad design. If you have it, rewrite your code.
When you insert a malloc() in your code, be sure to make it clear to yourself "who" or "what module" is responsible for that memory, and be sure to hold it responsible for freeing it again. If you are object oriented, this is even easier.
Programmers that write programs that allocate memory, and then get back to them to insert free() statements when the programs are to be used in practice, should be fired ASAP.
Don't program by coincidence, Think!
While I still think it should be up to the companies to decide whether they want to make their games free [beer] or not, and not enforced by law, I don't understand why they wouldn't. At some point, the interest in some game is so low that reprints (e.g. "classic" editions) cannot bring revenue. Then why not release it to the community? It wouldn't hurt the brand if the copyrights are kept, but more likely help build up a community around real classic that would increase sales for updated version through branding by word-of-mouth.
Take for instance the Monkey Island classics from LucasArts - we are quite a few who spend long night adventuring through the Caribbean Waters as Guybrush-you-know-who-Threepwood. I would be fun play the first milk-out-your-nose-funny editions again. It would even increase my interest in the Monkey Island series in general and I would probably make a few other interested in the game while babling about how awesome the are, and we would all buy the just-released "Escape from Monkey Island".
Why be forgotten when you can promote yourself and be famous -- at no cost?!
You can't learn to program from a course. You can only learn to programming by solving practical problems using a computer and a programming language. Of course, you need to learn the fundementals of programming but that doesn't not make a programmer.
At my university [or what corresponds to college in USA], CS student are taught programming fundementals in Pascal (for the imperical part) and Java (for the OO stuff), but all also confronted with real problems for which they have to make a program in order to solve. This is by taking out nearly half the time of a term using on a dedicated project in which the students themselves have to find the problem and the theory needed to implement the solution. (Example projects range from `administrative computer system' and `expert systems' to `database query optimization').
Students that are not confronted with such practical implementation problem will have a hard task cathing up because they will need to use their spare time learning to program real and practical programs!
Slashdot Mirror
I've always felt that the eye's light adaptation should be simulated by the game. If you play in a well lit room, your eyes won't adapt to changing light levels in a computer game, so I wonder, why doesn't the game increase the lighting when the majority of the scene is dark? It would even be possible to create "blinding" effects when entering daylight from a dark room. It would also create the impression of an even higher dynamic range of light than what is actually possible on a monitor.
Amazing feat. It's completely rewritten in C to gain exactly the same functionality as the original code, with only the binary / dissassembled machine code to work with.
"maximum data transfer rate of ~120 bits/s"
Let see. 120 bits/sec for 8 years... thats about 28 gigabytes of data. Not that bad.
It all about choosing the right tool for the job. Arguing that you should use Java to generate Java is like asking a carpenter to use a board of wood as the only tool to make a table.
Using Ruby (or, Perl, etc.) makes the code generator a lot simpler.
Did any of the posters care to checkout the site, click the download link and get the source? This is NOT an aprils fool joke. This an (albeit esoteric) actual language with a parser, a VM, and example programs to go!
User friendliness is subjective and covers many more or less measurable properties usch as user experience, user efficiency, learning curve, etc.
Most new users of a product will get a bad experience from an interface with a steep learning curve. They want to be able to use only the most basic features, here and now. They will never care about the fancy features due to little interest in the technology.
Experienced users [geeks?] will get a bad experience from an overly simplified user interface. They will want to be efficient with the interface, know about and control every feature, and are willing to spend time learning new concepts to get there.
This conflict is solvable (only?) by having two or more versions of the user interface and let each user decide.
And some in german:
CUPS (Common Unix Printing System) has support for simple quotaing. You can limit number of pages per user per time interval (e.g. month) and so forth. You cannot however set quotas per user individually or per user group. THere is, however a page_log which logs who has print how many pages. This can be used to disable access to the printing server for those who print to much to your likings :)
When will there be a filter on slashdot to weed out all news from the trying-to-make-linux-look-like-windows dept.? For me, and for a lot of the people I study and work with, OutLook was never a serious alternative to the MUAs we use (such as Pine, VM, Gnus etc). What is the "news for nerds" in a OutLook-a-like MUA?. It's not stuff that matters :(
No. This fall into the category, "This feature [overlapping windows] is most of the time more annoying and confusing than helpful, so we are going to take it away".
I can't see any possible situation where it is helpfull to have windows overlap. I have been using the Ion window manager for a year now, and have never had a more tidy and clean desktop.
This is excellent. XMMS has always had a pretty poor decoder (the same as in mpg123), which does not handle VBR mp3's very good (lots of artifacts in the sound). FreeAmp has a better decoder (as does mpg321), but is overall quite buggy. I'm looking forward to this.
1) Refactor early! Refactor the code and API as soon as you been suspect that it isn't going to be scalable/maintainable in the future. The longer you wait, the more unmaintainable the code gets and the more users will depend on your API. If a part of the API was a design mistake from the beginning, change it asap! Both you AND your users will benefit from the change (even though some will complain)
2) Make it "reasonable" backwards compatible. I.e. there is no reason behind supporting gcc-2.7-series. C++ compilers are lacking behind the ISO standard, but most are cathing up. Don't avoid exceptions because "some compilers doesn't support it". Some compilers doesn't, but exceptions has been around for 10 years! Time to force your users into an upgrade, I say.
The analogy, "should hammer makers be responsible for murders-by-hammer" is wrong. It should be "should gun makers be responsible for murder-by-shot?".
A hammer is designed as a tool for practical purposes, but can be used to kill. A rootkit is designed to gain unauthorized access, not to as a tool for practical purposes. (But may have practical side effects, akin to a gun, which CAN be used to avoid getting shot, while that is not what it was designed for).
Basically, there are no good and easy solutions, but the article does give a few ways to go.
Besides from this probably being another April's Hack, this has already been done! And its called Ruby. Ruby takes all the good parts from Perl, Python, Java, and even Smalltalk and combine them in a genuine object oriented language which is suited for both quick hacks and larger projects. Read Thirty-seven reason I Love Ruby and What's Ruby.
But there are more iterators:
... prints "Hello, World!" 5 times
Unfortunaly, there is no smooth acceleration in X. By smooth I mean that the actual cursor speed moves by some function of the actual mouse speed, which is NOT linear. E.g. cursorspeed = mousespeed ^ 1.25. This gives polynomial speed, which MS OS has had since I do not know when.
In DOS, the mouse drivers provided by Logitech and other had this feature, also known as "ballistic" acceleration (if you did not know, Ballistic is a polynomial movement). The is also used in Windows today.
When I first used X11, I too had problem using the mouse, because of the lack of ballistic movement, but you get used to it! I can see the problems with trackballs though, where you have a harder time moving the longer distances.
Fortunately Quake3Arena for Linux has its own Mouse acceleration/ballistics which makes the controls right. But if you try running windows q3a through Wine, you can experience this problem. Q3A for Window depends on windows to do the ballistics, but they are not provided in Wine, so the controls are very bad. You can turn, but you cannot turn fast because the acceleration is linear (even when accelerated).
Beg the XFree86 project for ballistic mouse acceleration! It's not really a driver problem.
VNC Screens are managed by Xvnc which is an X server in its own right, simply exporting the display over a compressed network connection. It's only the Window version which allow you to control a remote desktop.
If modern toolkits were written for Xt, they would have a much harder time porting it to other platforms. Both Gtk+ and Qt runs on Windows, and directly on framebuffers which make them a viable solution for embedded devices. You wouldn't want to run a full bloated X11 on your Palm, now, would you?
Another reason may be the structure of the API itself. It's rather complex. Not much is "default" until you choose otherwise, as in Gtk+. Instead you have to make all the decisions about the properties of a window before it can be displayed. Again, a showstopper for quick hacks.
GNU Pth is a portable non-preemptive threading library. All threads run in a single server OS process, so it can be a solution if you have resource concerns. (I know a few perverted people who enjoy programming with tens of thousands of threads, which Linux is incapable of handling).
The tricorder for Palms is here.
Can't live without it. How else would I know if the people I meet are terrestrial or not?
When you insert a malloc() in your code, be sure to make it clear to yourself "who" or "what module" is responsible for that memory, and be sure to hold it responsible for freeing it again. If you are object oriented, this is even easier.
Programmers that write programs that allocate memory, and then get back to them to insert free() statements when the programs are to be used in practice, should be fired ASAP.
Don't program by coincidence, Think!
While I still think it should be up to the companies to decide whether they want to make their games free [beer] or not, and not enforced by law, I don't understand why they wouldn't. At some point, the interest in some game is so low that reprints (e.g. "classic" editions) cannot bring revenue. Then why not release it to the community? It wouldn't hurt the brand if the copyrights are kept, but more likely help build up a community around real classic that would increase sales for updated version through branding by word-of-mouth.
Take for instance the Monkey Island classics from LucasArts - we are quite a few who spend long night adventuring through the Caribbean Waters as Guybrush-you-know-who-Threepwood. I would be fun play the first milk-out-your-nose-funny editions again. It would even increase my interest in the Monkey Island series in general and I would probably make a few other interested in the game while babling about how awesome the are, and we would all buy the just-released "Escape from Monkey Island".
Why be forgotten when you can promote yourself and be famous -- at no cost?!
... only the fundementals of programming.
You can't learn to program from a course. You can only learn to programming by solving practical problems using a computer and a programming language. Of course, you need to learn the fundementals of programming but that doesn't not make a programmer.
At my university [or what corresponds to college in USA], CS student are taught programming fundementals in Pascal (for the imperical part) and Java (for the OO stuff), but all also confronted with real problems for which they have to make a program in order to solve. This is by taking out nearly half the time of a term using on a dedicated project in which the students themselves have to find the problem and the theory needed to implement the solution. (Example projects range from `administrative computer system' and `expert systems' to `database query optimization').
Students that are not confronted with such practical implementation problem will have a hard task cathing up because they will need to use their spare time learning to program real and practical programs!