but clearly Microsoft is betting on the trend of higher levels of abstraction become ever more important in the future of computing. Let's look at a brief history of computer programming.
In th beginning programs were most assembly/machine code. No abstraction. Ultimate flexibility and power to control the system, very little help in doing mundane or repetetive coding tasks.
Then came the early higher level languages. Whether procedural or functionally based (or some other paradigm), these gave programmers powerful tools to create more complex programs with only marginal loss in flexibility and power. Later methods such as OOP seekd to improve the levels of abstraction.
More recently, "scripting" languages have started to come into being as able to prototype and in some cases fully develop complete applications. Python and Perl, have less pure control and usually lower performance than languages like C or Fortran, but are much faster to develop in and are usually much easier to debug due to less code needed to solve the same problems.
The question is: what is the next level? Some day I think we'll get to have Star Trek like interfaces to our computers. Ask a question in natural language, which would then presumably be processed into an Ultra-High Level language description the computer can process directly. Obviously this is way off in the future, but I think that the trend is clear: as computers get more powerful we will use ever increasingly high level interfaces to get tasks done, relying on processing power to make up for less efficient algorith representations and a rich set of existing APIs to solve the majority of the problems that any application has to solve.
Microsoft thinks that the next level is a visual development environment. I think this is probably wrong, visual layout is inherently difficult and constraining, source code divided into distinct modules is not limited by spatial dimensions an facilitates searches and queries much more readily.
I think that the Open Source community is currently and a much better route, though through evolutionary rather than revolutionary means. Open source languages like Python (and probably Ruby, which I do not know but a lot of people seem to like) are very high level, easy to learn, and expose a huge number of APIs coded in higher performance languages like C. These APIs solve most of the common problems, and HLLs bring them together to form applictions. When more power or flexibility is neededdevelopers can drop into the lower level languages and develop their own modules which are linked into the HLL. If necessary, this can be done all the way down to the bare metal. A Python application could use C code for certain computationally intensive sections, which may in turn use assembly to take advantage of special instructions on the target architecture.
An even higher level language could be built that uses Python as a lower language when necessary, whihc in turn could use C, etc. The trick is developing a language that makes a significant proportion of tasks significantly easier than Python, or a language like. This will be done I feel, though it may require even richer and more powerful APIs than are currently available.
This progression to increasingly high level textual descriptions certainly meshes better with the Start Trek goal, and does not impose any of the restrictions of a visual environment upon the developer at any stage along the way. it will be interesting to see which method is more successful in the future.
Re:Here is what needs to be done
on
CSS for the LDP?
·
· Score: 1
By using proper XHTML (or HTML 4.0) and sticking to valid tags (heading tags, emphasis, lists) the page will automatically degrade nicely and be viewable in ALL BROWSERS
This is not always the case. Not that many people use it anymore, but 4.x versions of Netscape will seriously mangle some pages using valid and correct X/HTML and CSS.
I hate seeing market share go to IE, but the old Netscape fading into the past is probably one of the best things to happen for the future of good web design.
Re:Here is what needs to be done
on
CSS for the LDP?
·
· Score: 1
Dude, now it's score is "-1, Insightful"!
That's gotta be worth a cool +10,000,000 points by your scale.
Gtk# is a language binding for the GTK+ toolkit in the C# language. Qt is a toolkit. The two cannot be compared directly.
Now my experience developing with Qt is limited and with GTK+ almost non-existent, but if you want a fair comparison of toolkit bindings maybe try Gtk# vs. PyQt (Python bindings for Qt). PyQt is what I'm currently using to teach myself Qt, and I can tell you it eliminates the most frequent complaint developers, especially C coders, raise about Qt: the MOC. It isn't necessary with PyQt. Python also removes the need for the sometimes cumbersome creation of a C++ object hierarchy.
Now I'm not trying to bash Gtk#, I'm guessing it's a great combo, but I know that Qt is a great GUI toolkit (I do have experience with other toolkits, so I feel valid in my evaluation despite limited experience, much due to how fast I'm picking it up), so lets keep the comparisons real, okay?
I agree that it's important for consistent notaion to be used throughout a project, but as long as someone declares the conventions for the project and enforces them, there shouldn't be a problem.
The two developers you mention shound like they just needed a manager or project leader to slap them both down, delare that THIS is the way our variables will be named, and tell them to stop wasting their time on petty games. This kind of thing could happen any time certain coding conventions are used that are not actually enforced either way by the language, and is not a problem with Hungarian notation.
Qt is good. Also, the above poster should try an actuall HLL like perl or python. These definitely fit the mold of "a couple hours of programming [can] get something nice out".
I've done my share of Win32/MFC programming, and will attest that it's not a lot of fun. Look to some of the modern languages and toolkits, and you may find a happy merger of the productivity of C64 programming and the polished results expected of modern software.
This is true if you explicitly append a character for the type of every variable. However, there are other uses of Hungarian notation that imply more intent than explicit types.
In my C++ code I tend to use the following conventions:
m_ = member variable sm_ = static member variable g_ = global
These will not change unless the variable is moved to an entirely new scope.
Actual type annotations:
p = pointer (not likely to change unless all code using it changes) n = integer counter (usually int, but long or char could work also) str = string (not always used, and I know MFC/Win32 uses sz, but pretty clear)
Combine these, and I know that m_pObject is a pointer to a object of some sort which is a member of the current class.
That's basically it. A few characters that help convey intent, which is I believe the purpose of a good variable name. These examples are invariant to minor changes in type, such as switching float to double.
I would agree there are bad emples of Hungarian notion, notably by Microsoft. I really hate the lp* notation. Only microsoft would feel the need to declare a whole new type that is simply a pointer to another type.
Actually none, if you know (or are willing to learn) a little Python.
I've just recently started dabbling in Python, and I decided that I would like to learn more. I have also wanted to teach myself Qt for quite a while. After recently putting together a new PC that could handle modern versions of Qt (my old box ran Mandrake 8.0 and didn't have the HD space for updated libs) I decided to learn Python and Qt together.
I would definetely recommend this strategy. Python's dynamic typing makes it much faster to put together new objects. Qt signals and slots (for message passing/event handling) are actually simpler in Python than in C++, with no requirement of running the MOC (meta-object compiler) which is needed for certain C++ Qt macros. Qt Designer, the standard Qt GUI designer, produces interfaces in XML format. Normally a utility called uic is used to compile this UI to C++ code. A utility called pyuic compiles the same interfaces to Python.
If you're comfortable in C++, by all means try out Qt with the standard C++ bindings. But if you're interested in trying out new things rapidly, a little investment in Python may actually accelerate your learning process.
Disclaimer: C++ is actually my strongest language, but in learning a new API I think that a more rapid development language will be more fruitful. Also, Qt knowledge learned in C++ or Python translates extremely well in either direction.
The standard C API on Windows is the Win32 API. It works, but basically blows compared to APIs for more modern graphical toolkits like Qt. It has been available for a long time though.
In many ways it is actually superior to Microsoft's C++ APi from before the whole.NET thing, which is MFC (Ficrosoft Foundation Classes). MFC is basically a bunch of objects which wrap the Win32 C API, and as such offer only small benefits over it compared to what a true, from the ground up object oriented API would offer, and in some cases makes it harder to get things done..
Maybe someone who's actually done.NET programming can comment, but I would guess that a lot of.NET functionality is implemented through hooks to the standard Win32 API.
Re:The multi million dollar question...
on
In Google We Trust
·
· Score: 1
In almost all of these cases, the software being quickly adopted is something that MS does not offer anything close to, or did not at the time.
MS has (practically) always had a media player, but Napster really put MP3s and file sharing on the map. MS will probably never offer a P2P file sharing app, and at the time MP3s were largely unkown. It was the ability to download almost any song that made MP3s a big deal.
Similar story for most other examples. MSN messenger was late to the IM game, and did not exist when AIM et. al. came around. Lots of file sharing apps have been produced, but in this case MS is simply not willing to offer something that many PC users want, so users have to go out on their own.
With web browsers, things are a bit different. IE has been around for quite a while, people are used to it. Most people are accustomed to popups as part of the web experience. Even when shown the alternatives, popup-blocking and tabbed browsing alone are not nearly as big of a jump from the capabilities of IE as something like KaZaa is from no P2P app at all.
Good open source apps are making inroads, but slowly. Only when an app is revolutionary in what it does (open or closed source) will lots of users actively seek it out.
witehouse.com shouldn't have a problem, if I understand things correctly.
The guy in the story got in trouble for redirecting from typo domains to real porn sites and making money off of the referals, scamming the porn site out of referal money. The guy that runs whitehouse.com runs his own legitimate porn site. While many people are surely caught off guard by the site's contents, no one is being scammed out of any money in this case.
Ah yes, you're quite right. It was actually Raindrop Geomgic, a 3D polygonal mesh modeling and NURBS surface creation package that uses Qt. I use this a lot more (I only have limited CAD experience myself).
A quick look for evidence of Geomagic on Solaris does nto turn up anything other than version 3 (current is 5), which is disappointing if true. It does still use Qt though.
Hopefully Solidworks at least will be released for Linux sometime in the near future. It is built around the Qt toolkit (look at the lewer left corner of the splash screen on startup), and I believe their website says that Solidworks is available on Solaris, so Linux would not be too big of a jump.
The type of light source is not the issue at all. A true, pure ray tracer will follow a path from the eye, bouncing off of all reflective surfaces (to calculate specular reflected light) and adding it to the diffuse color seen directly by the viewer.
The scene would have looked much cooler if the walls were reflective, the normal type of surface that ray tracing used used for, because it would give really intricate reflections. Radiosity would not be able to calculate these reflections. Ray tracing cannot handle soft light effects, and with non-specular surfaces gives the boring result in the picture. Any "ray tracer" that gives other results is doing a lot more that just ray tracing, and probably incorporates radiosity effects.
That's the thing. Ray tracing handles mirror-like reflections, radiosity handles soft lighting and shadows. Some scenes look good using one technique, but most realistic scenes require a little of both.
It's a 3D modeling program. Takes point data acquired from 3D scanning devices, generates polygon meshes, can be used to detect and refine features, and finally can generate NURBS surfaces for export.
Hmmm, I was actually planning on inserting the diagrams into the middles of pages, surrounded by text. I'm not sure if I will really need any captions for this project, just to have the images placed sensibly.
I'm thinking of inserting images in PDF format because quite a few posts in other threads recommend the use of pdflatex for generating PDF output directly from LaTeX source. I've never used pdflatex but it sounds quite good, but cannot handle EPS directly, it must first be converted to PDF. It doesn't sound like this should be a problem though, as pdflatex is specifically designed to handle this sort of thing.
I don't really want to go the LaTeX -> DVI -> PS -> PDF because it is somewhat cumbersome and the DVI -> Postscript conversion has the problem of rasterizing the fonts is special care is not taken. It was this problem that made me find dvipdfm for conversion of DVI to PDF while skipping the PS step. Pdflatex sounds like it's one better, doing the conversion directly.
Just want to say that I spent part of today learning the basics of Postscript and writing (E)PS. All my images really need are high quality stroked lines/paths, triangles, and ellipses, and I've learned enough to all of this in a few hours.
The tricky part will be maximizung efficiency, because I will have a couple hundred of these images. Because they will be generated in software I don't need to define any Postscript functions if I choose, though there may be cases where simple functions will reduce the size of the file.
I have also converted the output to pdf using epstopdf, which works great. Now I just need to try out pdflatex and I should be good to go.
For anyone else who's interested in projects like this, here are some useful links I've found:
Generating postscript directly sounds like a great idea. I had thought I could use Xfig as an intermediary because I think I read somewhere that it is fairly scriptable, and since it's open source the file format should be easy to learn.
However, because I will be generating all of my diagrams through software, going directly to postscript will save time and cut an unnecessary step out of my toolchain.
From another thread, it sounds like pdflatex may be a better choice than dvipdfm for my needs, and a little reading tells me I can easily convert PS files to PDF for use with pdflatex using epstopdf. Which does lead to one more question: is there anything tricky about converting PS directly to EPS? Obviously there are plenty of apps that can do this, but it would be nice to do this directly in code or script this action to streamline things as much as possible.
I'm not sure if I have ever tried using pdflatex, though the fact that it's on my system makes me think I must have at some point. Is it better than dvipdfm? Can it easily handle both raster images (probably in PNG) and more importantly vector image formats (of which I've currently only used postscript/eps)? Finally, does it use nice fonts (can't remember at the moment which are Type 1 and which are Type 3)?
I know I've tried using dvipdf and ps2pdf at one point but had problems with them. I can't remember if the specific problem was using embedded EPS images, which I see from the pdflatex website that pdflatex cannot handle, or if it was problems with getting good fonts in the final PDF output.
Dvipdfm can handle EPS, though it had problems for me with some especially large EPS files. This was during my first LaTeX project in which I was actually using large, bitmap images stored in EPS files because I did not yet know how to include other image formats in LaTeX, and because postscript/EPS shows up in DVI while most other image formats are invisible in DVI and only show up for real in the final PDF output (at least this has been my experience). I ended up converting my large bitmap images to PNG and only using eps for vector images produced by Xfig. It would be nice to use pdflatex if it can handle vector formats exportable by xfig or some other free vector graphics program though, because dvipdfm require a bit of command line wizardry running through piped ghostscript to unclude EPS images.
Tecmo Bowl was a lot of fun, but there were a few things that bothered me about it.
The biggest thing was calling defenses. It would have been nice to have a few real defense, rather than just trying to guess what the offense picks, and if successful being able to automatically overwhelm them. Also it would have been nice to have a few more plays to pick from. I can't remember it you got 4 or 8 choices (I think it must have been 8? Up, down, left or right plus A or B on Nintendo?) but it was awfully limited.
Still, it was a great game to just pick up and play.
The differences sound intersting. I was still curious, so I looked at some review sites, and there were a few surprises. One of the sites had some opposite views from you, saying that NFL2K3 was slightly more arcady and emphasized the pass more, while having a superior franchise style mode. Other sites had still different views.
Also I wonder if the people who don't translate Madden skills to NFL2K3 successfully play on the tougher modes very much. I play on All Madden currently, and against the CPU it seems that very good discipline and understanding of fundamental schemes is required for success.
I'm guessing that this just means that the differences between the games are quite subtle. I'd really like to try NFL2K3 (or 2K4 when it comes out), but apparently it is not available on Gamecube. Guess I'll just stick to Madden.
I'm curious (especially as a later thread says something similar about NFL2K). I've never played any of the NFL2K series. In what ways would you say it's significantly better than Madden?
I'm genuinely curious, Madden seems very tightly put together to me. The AI seems quite realistic, the CPU knows how to manage the clock and the game situation quite well, the physics seem quite well developed, DBs will actually make interceptions regularly if you throw right to them (unlike many older football games), running works well and realistically both inside and outside the tackles, and the custom playbook feature gave me the one thing I felt was lacking in Madden 2002.
Most of my problems with it are pretty small. It's hard to defend passes whil controlling a DB, receivers don't make extra effort to keep feet in bounds along the sidelines and don't catch the ball in stride as often as they should. Things like that.
Are these features better in NFL2K, or is it just generally more refined and well tuned?
22 person live games would be cool, but I'm not sure how well they'd work out. Football requires a lot of coordination, discipline and timing between its players. This is usually only achieved with a lot of practice and experience.
I think that, except for really hard core expert teams, much in the way of play calling would end up going out the window, as routes that require precision would not be run reliably. On defense it would be easy to blow coverage, and hard to coordinate things like line shifts or coverage audibles to adapt to the offensive formation. Maybe I'm wrong, but it all seems very complicated to execute.
Slashdot Mirror
Under KDE 3.1 it's under
Control Center -> Desktop -> Window Behavior -> Focus (first tab)
Options are Click to Focus, Focus Follows Mouse, Focus Under Mouse, and Focus Strictly Under Mouse.
Haven't tested each setting (default is Click to Focus, which I like just fine for the most part), but there are your options.
but clearly Microsoft is betting on the trend of higher levels of abstraction become ever more important in the future of computing. Let's look at a brief history of computer programming.
In th beginning programs were most assembly/machine code. No abstraction. Ultimate flexibility and power to control the system, very little help in doing mundane or repetetive coding tasks.
Then came the early higher level languages. Whether procedural or functionally based (or some other paradigm), these gave programmers powerful tools to create more complex programs with only marginal loss in flexibility and power. Later methods such as OOP seekd to improve the levels of abstraction.
More recently, "scripting" languages have started to come into being as able to prototype and in some cases fully develop complete applications. Python and Perl, have less pure control and usually lower performance than languages like C or Fortran, but are much faster to develop in and are usually much easier to debug due to less code needed to solve the same problems.
The question is: what is the next level? Some day I think we'll get to have Star Trek like interfaces to our computers. Ask a question in natural language, which would then presumably be processed into an Ultra-High Level language description the computer can process directly. Obviously this is way off in the future, but I think that the trend is clear: as computers get more powerful we will use ever increasingly high level interfaces to get tasks done, relying on processing power to make up for less efficient algorith representations and a rich set of existing APIs to solve the majority of the problems that any application has to solve.
Microsoft thinks that the next level is a visual development environment. I think this is probably wrong, visual layout is inherently difficult and constraining, source code divided into distinct modules is not limited by spatial dimensions an facilitates searches and queries much more readily.
I think that the Open Source community is currently and a much better route, though through evolutionary rather than revolutionary means. Open source languages like Python (and probably Ruby, which I do not know but a lot of people seem to like) are very high level, easy to learn, and expose a huge number of APIs coded in higher performance languages like C. These APIs solve most of the common problems, and HLLs bring them together to form applictions. When more power or flexibility is neededdevelopers can drop into the lower level languages and develop their own modules which are linked into the HLL. If necessary, this can be done all the way down to the bare metal. A Python application could use C code for certain computationally intensive sections, which may in turn use assembly to take advantage of special instructions on the target architecture.
An even higher level language could be built that uses Python as a lower language when necessary, whihc in turn could use C, etc. The trick is developing a language that makes a significant proportion of tasks significantly easier than Python, or a language like. This will be done I feel, though it may require even richer and more powerful APIs than are currently available.
This progression to increasingly high level textual descriptions certainly meshes better with the Start Trek goal, and does not impose any of the restrictions of a visual environment upon the developer at any stage along the way. it will be interesting to see which method is more successful in the future.
This is not always the case. Not that many people use it anymore, but 4.x versions of Netscape will seriously mangle some pages using valid and correct X/HTML and CSS.
I hate seeing market share go to IE, but the old Netscape fading into the past is probably one of the best things to happen for the future of good web design.
Dude, now it's score is "-1, Insightful"!
That's gotta be worth a cool +10,000,000 points by your scale.
Gtk# is a language binding for the GTK+ toolkit in the C# language. Qt is a toolkit. The two cannot be compared directly.
Now my experience developing with Qt is limited and with GTK+ almost non-existent, but if you want a fair comparison of toolkit bindings maybe try Gtk# vs. PyQt (Python bindings for Qt). PyQt is what I'm currently using to teach myself Qt, and I can tell you it eliminates the most frequent complaint developers, especially C coders, raise about Qt: the MOC. It isn't necessary with PyQt. Python also removes the need for the sometimes cumbersome creation of a C++ object hierarchy.
Now I'm not trying to bash Gtk#, I'm guessing it's a great combo, but I know that Qt is a great GUI toolkit (I do have experience with other toolkits, so I feel valid in my evaluation despite limited experience, much due to how fast I'm picking it up), so lets keep the comparisons real, okay?
I agree that it's important for consistent notaion to be used throughout a project, but as long as someone declares the conventions for the project and enforces them, there shouldn't be a problem.
The two developers you mention shound like they just needed a manager or project leader to slap them both down, delare that THIS is the way our variables will be named, and tell them to stop wasting their time on petty games. This kind of thing could happen any time certain coding conventions are used that are not actually enforced either way by the language, and is not a problem with Hungarian notation.
Qt is good. Also, the above poster should try an actuall HLL like perl or python. These definitely fit the mold of "a couple hours of programming [can] get something nice out".
I've done my share of Win32/MFC programming, and will attest that it's not a lot of fun. Look to some of the modern languages and toolkits, and you may find a happy merger of the productivity of C64 programming and the polished results expected of modern software.
This is true if you explicitly append a character for the type of every variable. However, there are other uses of Hungarian notation that imply more intent than explicit types.
In my C++ code I tend to use the following conventions:
m_ = member variable
sm_ = static member variable
g_ = global
These will not change unless the variable is moved to an entirely new scope.
Actual type annotations:
p = pointer (not likely to change unless all code using it changes)
n = integer counter (usually int, but long or char could work also)
str = string (not always used, and I know MFC/Win32 uses sz, but pretty clear)
Combine these, and I know that m_pObject is a pointer to a object of some sort which is a member of the current class.
That's basically it. A few characters that help convey intent, which is I believe the purpose of a good variable name. These examples are invariant to minor changes in type, such as switching float to double.
I would agree there are bad emples of Hungarian notion, notably by Microsoft. I really hate the lp* notation. Only microsoft would feel the need to declare a whole new type that is simply a pointer to another type.
Actually none, if you know (or are willing to learn) a little Python.
I've just recently started dabbling in Python, and I decided that I would like to learn more. I have also wanted to teach myself Qt for quite a while. After recently putting together a new PC that could handle modern versions of Qt (my old box ran Mandrake 8.0 and didn't have the HD space for updated libs) I decided to learn Python and Qt together.
I would definetely recommend this strategy. Python's dynamic typing makes it much faster to put together new objects. Qt signals and slots (for message passing/event handling) are actually simpler in Python than in C++, with no requirement of running the MOC (meta-object compiler) which is needed for certain C++ Qt macros. Qt Designer, the standard Qt GUI designer, produces interfaces in XML format. Normally a utility called uic is used to compile this UI to C++ code. A utility called pyuic compiles the same interfaces to Python.
If you're comfortable in C++, by all means try out Qt with the standard C++ bindings. But if you're interested in trying out new things rapidly, a little investment in Python may actually accelerate your learning process.
Disclaimer: C++ is actually my strongest language, but in learning a new API I think that a more rapid development language will be more fruitful. Also, Qt knowledge learned in C++ or Python translates extremely well in either direction.
The standard C API on Windows is the Win32 API. It works, but basically blows compared to APIs for more modern graphical toolkits like Qt. It has been available for a long time though.
.NET thing, which is MFC (Ficrosoft Foundation Classes). MFC is basically a bunch of objects which wrap the Win32 C API, and as such offer only small benefits over it compared to what a true, from the ground up object oriented API would offer, and in some cases makes it harder to get things done..
.NET programming can comment, but I would guess that a lot of .NET functionality is implemented through hooks to the standard Win32 API.
In many ways it is actually superior to Microsoft's C++ APi from before the whole
Maybe someone who's actually done
In almost all of these cases, the software being quickly adopted is something that MS does not offer anything close to, or did not at the time.
MS has (practically) always had a media player, but Napster really put MP3s and file sharing on the map. MS will probably never offer a P2P file sharing app, and at the time MP3s were largely unkown. It was the ability to download almost any song that made MP3s a big deal.
Similar story for most other examples. MSN messenger was late to the IM game, and did not exist when AIM et. al. came around. Lots of file sharing apps have been produced, but in this case MS is simply not willing to offer something that many PC users want, so users have to go out on their own.
With web browsers, things are a bit different. IE has been around for quite a while, people are used to it. Most people are accustomed to popups as part of the web experience. Even when shown the alternatives, popup-blocking and tabbed browsing alone are not nearly as big of a jump from the capabilities of IE as something like KaZaa is from no P2P app at all.
Good open source apps are making inroads, but slowly. Only when an app is revolutionary in what it does (open or closed source) will lots of users actively seek it out.
The guy in the story got in trouble for redirecting from typo domains to real porn sites and making money off of the referals, scamming the porn site out of referal money. The guy that runs whitehouse.com runs his own legitimate porn site. While many people are surely caught off guard by the site's contents, no one is being scammed out of any money in this case.
Ah yes, you're quite right. It was actually Raindrop Geomgic, a 3D polygonal mesh modeling and NURBS surface creation package that uses Qt. I use this a lot more (I only have limited CAD experience myself).
A quick look for evidence of Geomagic on Solaris does nto turn up anything other than version 3 (current is 5), which is disappointing if true. It does still use Qt though.
Hopefully Solidworks at least will be released for Linux sometime in the near future. It is built around the Qt toolkit (look at the lewer left corner of the splash screen on startup), and I believe their website says that Solidworks is available on Solaris, so Linux would not be too big of a jump.
The type of light source is not the issue at all. A true, pure ray tracer will follow a path from the eye, bouncing off of all reflective surfaces (to calculate specular reflected light) and adding it to the diffuse color seen directly by the viewer.
The scene would have looked much cooler if the walls were reflective, the normal type of surface that ray tracing used used for, because it would give really intricate reflections. Radiosity would not be able to calculate these reflections. Ray tracing cannot handle soft light effects, and with non-specular surfaces gives the boring result in the picture. Any "ray tracer" that gives other results is doing a lot more that just ray tracing, and probably incorporates radiosity effects.
That's the thing. Ray tracing handles mirror-like reflections, radiosity handles soft lighting and shadows. Some scenes look good using one technique, but most realistic scenes require a little of both.
Raindrop Geomagic.
It's a 3D modeling program. Takes point data acquired from 3D scanning devices, generates polygon meshes, can be used to detect and refine features, and finally can generate NURBS surfaces for export.
Read the actual linked news. Linux kernel 2.6 did NOT have SE Linux merged into it, SE Linux was updated to run the new 2.6 prerelease kernels.
Hmmm, I was actually planning on inserting the diagrams into the middles of pages, surrounded by text. I'm not sure if I will really need any captions for this project, just to have the images placed sensibly.
I'm thinking of inserting images in PDF format because quite a few posts in other threads recommend the use of pdflatex for generating PDF output directly from LaTeX source. I've never used pdflatex but it sounds quite good, but cannot handle EPS directly, it must first be converted to PDF. It doesn't sound like this should be a problem though, as pdflatex is specifically designed to handle this sort of thing.
I don't really want to go the LaTeX -> DVI -> PS -> PDF because it is somewhat cumbersome and the DVI -> Postscript conversion has the problem of rasterizing the fonts is special care is not taken. It was this problem that made me find dvipdfm for conversion of DVI to PDF while skipping the PS step. Pdflatex sounds like it's one better, doing the conversion directly.
The tricky part will be maximizung efficiency, because I will have a couple hundred of these images. Because they will be generated in software I don't need to define any Postscript functions if I choose, though there may be cases where simple functions will reduce the size of the file.
I have also converted the output to pdf using epstopdf, which works great. Now I just need to try out pdflatex and I should be good to go.
For anyone else who's interested in projects like this, here are some useful links I've found:
A nice introductory tutorial to Postscript
The Postscript FAQ
The Postscript Language Tutorial and Cookbook (The Bluebook) in PDF format (quite comprehensive)
Generating postscript directly sounds like a great idea. I had thought I could use Xfig as an intermediary because I think I read somewhere that it is fairly scriptable, and since it's open source the file format should be easy to learn.
However, because I will be generating all of my diagrams through software, going directly to postscript will save time and cut an unnecessary step out of my toolchain.
From another thread, it sounds like pdflatex may be a better choice than dvipdfm for my needs, and a little reading tells me I can easily convert PS files to PDF for use with pdflatex using epstopdf. Which does lead to one more question: is there anything tricky about converting PS directly to EPS? Obviously there are plenty of apps that can do this, but it would be nice to do this directly in code or script this action to streamline things as much as possible.
I'm not sure if I have ever tried using pdflatex, though the fact that it's on my system makes me think I must have at some point. Is it better than dvipdfm? Can it easily handle both raster images (probably in PNG) and more importantly vector image formats (of which I've currently only used postscript/eps)? Finally, does it use nice fonts (can't remember at the moment which are Type 1 and which are Type 3)?
I know I've tried using dvipdf and ps2pdf at one point but had problems with them. I can't remember if the specific problem was using embedded EPS images, which I see from the pdflatex website that pdflatex cannot handle, or if it was problems with getting good fonts in the final PDF output.
Dvipdfm can handle EPS, though it had problems for me with some especially large EPS files. This was during my first LaTeX project in which I was actually using large, bitmap images stored in EPS files because I did not yet know how to include other image formats in LaTeX, and because postscript/EPS shows up in DVI while most other image formats are invisible in DVI and only show up for real in the final PDF output (at least this has been my experience). I ended up converting my large bitmap images to PNG and only using eps for vector images produced by Xfig. It would be nice to use pdflatex if it can handle vector formats exportable by xfig or some other free vector graphics program though, because dvipdfm require a bit of command line wizardry running through piped ghostscript to unclude EPS images.
Tecmo Bowl was a lot of fun, but there were a few things that bothered me about it.
The biggest thing was calling defenses. It would have been nice to have a few real defense, rather than just trying to guess what the offense picks, and if successful being able to automatically overwhelm them. Also it would have been nice to have a few more plays to pick from. I can't remember it you got 4 or 8 choices (I think it must have been 8? Up, down, left or right plus A or B on Nintendo?) but it was awfully limited.
Still, it was a great game to just pick up and play.
The differences sound intersting. I was still curious, so I looked at some review sites, and there were a few surprises. One of the sites had some opposite views from you, saying that NFL2K3 was slightly more arcady and emphasized the pass more, while having a superior franchise style mode. Other sites had still different views.
Also I wonder if the people who don't translate Madden skills to NFL2K3 successfully play on the tougher modes very much. I play on All Madden currently, and against the CPU it seems that very good discipline and understanding of fundamental schemes is required for success.
I'm guessing that this just means that the differences between the games are quite subtle. I'd really like to try NFL2K3 (or 2K4 when it comes out), but apparently it is not available on Gamecube. Guess I'll just stick to Madden.
I'm curious (especially as a later thread says something similar about NFL2K). I've never played any of the NFL2K series. In what ways would you say it's significantly better than Madden?
I'm genuinely curious, Madden seems very tightly put together to me. The AI seems quite realistic, the CPU knows how to manage the clock and the game situation quite well, the physics seem quite well developed, DBs will actually make interceptions regularly if you throw right to them (unlike many older football games), running works well and realistically both inside and outside the tackles, and the custom playbook feature gave me the one thing I felt was lacking in Madden 2002.
Most of my problems with it are pretty small. It's hard to defend passes whil controlling a DB, receivers don't make extra effort to keep feet in bounds along the sidelines and don't catch the ball in stride as often as they should. Things like that.
Are these features better in NFL2K, or is it just generally more refined and well tuned?
22 person live games would be cool, but I'm not sure how well they'd work out. Football requires a lot of coordination, discipline and timing between its players. This is usually only achieved with a lot of practice and experience.
I think that, except for really hard core expert teams, much in the way of play calling would end up going out the window, as routes that require precision would not be run reliably. On defense it would be easy to blow coverage, and hard to coordinate things like line shifts or coverage audibles to adapt to the offensive formation. Maybe I'm wrong, but it all seems very complicated to execute.