Re:Better Physical Modelling increases possibiliti
on
What is Next-Gen?
·
· Score: 1
Yes, I remember reading that the sequel kinda screwed the pooch. I've always wanted to play the first one though. Just not much time for games these days:( It's just so damn annoying that rocket launchers will not harm a flimsy wooden door in the slightest, nooooo, you have to find the right key or passcard or whatever. Bleh.
I've been programming for 20 years now, and I've worked in a variety of languages during that time on a lot of different things. And you know what? All of the code that I ever wrote before has pretty much zero value now, with a few exceptions. Especially at your phase of development as a coder, I think you'll find the value of code reuse after significant time has elapsed practically non-existant. Why? Well, because you'll find that your abilities grow substantially every couple years, and you're almost always better off to start with a clean slate rather than fooling around with your old code.
Now, there's a few caveats here. Another thing that happens over time is you learn to stop re-inventing the wheel and to use pre-existing libraries. Right now, you're just unaware of their existence, but you'll learn where to look if you make a little effort. In fact, you'll find that existing libraries tends to heavily influence choice of language to use. So it turns out that most things that are really worth reusing are already available, and you should use those solutions rather than maintaining your own. Sure, write your own for fun or education, but when you get a serious project, you've got no use for it. In some cases, you'll find that there's no library available, so you write something from scratch, but 3 years later, you find that somebody else has made a nice library that's much better than what you hacked together. Several times I have ported code from my own hacked together solution to a more mature library. It's a natural progression, and there are a thousand times more libraries freely available today versus 10 years ago.
Now, having said all that, there are still times where you want to make something that is generically reusable. The point is, though, you should really make an effort to make a library out of your code. I have done just this on a handful of occasions. Then, put it up on SourceForge or something similar dedicated to your language of choice. I have a few libraries up on SourceForge, some only a few hundred lines of code, but some other people have found them useful because I made the effort. Other people have suggested CVS or whatnot, and SourceForge will give you that.
Maybe the real gist of your question, though, was about making your code into a library? While the technical details of making a lib, dll, so, jar, pm, etc vary from language to language (sometimes compiler to compiler), here's a few pointers:
This is just good practice in general, but you have to make the code *independant*. It has to stand on it's own. You might have heard about encapsulation, this is what they're on about. Make sure your application code no longer has to make any assumptions about how the library works. Get rid of "magic numbers" and define well-named constants. Make some effort to make the libraries data protected so app code can't screw it up.
Make all of your functions meaningfully named. Make sure each function sanity checks it's inputs. Return meaningful errors anytime something goes wrong. This can be the hardest part. You have to check for and return errors *rigourously*.
Define error constants, and provide a function to get a meaningful error message as a string. Alternatively, if you're using exceptions, make sure the exceptions can provide a message as a string.
Provide appropriate initialization and cleanup/shutdown routines. Clearly define whether or not the library or the application "owns" any resources (memory, file handles, database connections, sockets, and so forth) so people know whether or not to release them.
Make an effort to decompose your functions to expose a fine-grained interface, and then write "convenience" functions that use the low level functions to implement common needs. For example, if you have something that opens a file and processes it, break that down into something that works on a memory buffer and provide a convenience function that opens a file and feeds it into the memory buf
Better Physical Modelling increases possibilities
on
What is Next-Gen?
·
· Score: 2, Interesting
I'm going to make a broad generalization here, so bear with me. There are basically two types of games:
1) Abstract, pattern, or board type games. Puzzle games, party games, and non-game-games. 2) Stylized simulations of various kinds. Simulated driving, sports, fighting/combat, and so forth. Even fantastical worlds have kind of implied rules that are being simulated.
For type #1, since there's no pseudo real world to simulate, designers are free to make up their own rules, and convincing physics or human-like AI aren't so important. Additionally, good graphics tend to be irrelevant to these types of games. As a result, there's almost no such thing as a "next-gen" puzzle game, because pretty much any puzzle game that gets made could have been done on previous-gen hardware. One exception might be TetriSphere.
However, for simulation type games, the drastic changes come from increases in the fidelity of the simulation. Since perfect simulation is impossible, we're stuck with a mixture of scripted/canned behaviors that cover a wide array of interactions along with actual simulation. So a primary driving force in making these games feel "next-gen" is migrating an entire category of functionality from scripts into simulation. Doing this requires more horsepower, thus next-gen hardware, and makes the game seem qualitatively different because player freedom has increased.
I think a basic development that has to happen soon is a move towards more realtime skeletal animation. I think it's practically criminal that new games being made today still have characters get hung up on the slightest corners of objects. Getting "stuck" on a crate is ridiculous, or a doorframe or a rock or anything. You need to appropriately account for momentum and have skeletal animation to realistically show the effect on the character, so you can stumble, bump, trip, twist etc. Deformable environments need to be common place, with decent collision/impact calculations (I've never played Red Faction, so I don't know how good of a job it did). Elements in the environment need to react properly to extreme heat or cold. You can come up with an almost endless laundry list of these things.
These types of things will give players more freedom and more convincingly immersive games. You could then make Sequel 127 and have it seem fresh and distinct, as the play experience will be unlike what came before. But then you'll need something else by the time you hit Sequel 130. But for right now, there are plenty of REALLY OBVIOUS things that need to be done, but don't seem to be chased very much. Of course, that's because these things are *hard* while improving graphics is easy...
Yeah, it'll be somewhat limited, but you could still use it for leaning/looking around corners and making your FOV a little more natural with slight scanning left/right/up/down. Sitting here typing this, I can gain maybe 45 degrees in any direction and still keep my eyes on the moniter without undue effort. It would take some getting used to and might be disorienting, but the fact that it's easy, natural, and kind of reflexive would be a huge advantage. Making looking and aiming independent has some advantages if you're not overloading the control complexity, so it'd be worth a shot to see how it plays. Particularly if you're using the main controller as a sword, and a second controlloer for a shield, you can't use your hand's to look around, so if you can make a head-tracking solution workable, it opens things up a little.
Also, as much as I ragged on the "gesture" approach in my earlier post, it's different with your head. In a Rainbow Six or other squad combat type of game, you could potentially issue orders with "head gestures." In other words, select a team mate by pointing at him (with the regular remote) and nod your head in the direction you want him to go. Voice commands are probably a better way to go for that, but it's worth thinking about the possibilities.
Not only does the controller appear to have a large number of degrees of freedom, all the ideas for having one player use multiple controllers magnifies this immensely. The genius is that it will be *intuitive* to use multiple controllers. One in each hand is the obvious bit, and the article suggested strapping one to a leg for kicking in a fighting game. One person suggested making a headset for "free-look" type uses. You could have a fighting game with one controller in each hand to punch/block, one on each leg for kicking/moving, and one on your head for ducking/dodging etc. 5 controllers all for one person might seem inane, but if they made alternate controllers that had no buttons but just the positioning detection with little velcro straps, you would no longer feel like an idiot strapping one to your ankle. Now, once you imagine this little "mini" controller sans buttons, there's all kinds of interesting new directions. I don't know how many of these can talk to the Revolution hardware simultaneously, but if you could get 12-16 going at once, you could have all kinds of fun with "home motion capture." Imagine a movie making "game" where you act out all the parts in motion capture. Imagine a totally new style of dancing game, where you *really* dance. Or imagine a dance instruction "game" for two people. You and your partner strap on ankle bracelts, wrist bracelets, and maybe something around the shoulders, and really dance. Add in a scoring mechanism for accuracy, toss in an online component for competition, and you're in a whole new world. Now you're really talking about a revolution.
However, this also illustrates the biggest challenge to be faced by Revo developers, IMHO. In all current games, your characters have canned animations to represent your moves. You press the A-button or whatever, and the sword swipe animation playes. It's pre-rendered, beginning to end. Revo games will have to do realtime skeletal animation, so that you can begin swiping your sword, check it mid-stroke, and block with your shield. If you use physical movement to trigger canned animations, it will feel surreal, and you'll quickly give it up because it won't be responsive. You'll start to swipe your sword, and the game won't respond for.5 sec while the animation finishes. In effect, now you're just talking about mouse gestures in 3D space. If the on-screen avatar doesn't track your movements accurately, smoothly, and convincingly, then you're just memorizing gestures to trigger a move--and that would be physically tiring with not much reward, and we'll go back to pressing buttons.
In my opinion, this is a good thing. For *years* what we've needed is better physical modelling, not better graphics. Better physics and better AI are really the key to better gaming. Graphics have been mostly "good enough" for 5 years, while physics and AI have only changed marginally since 3D games became ubiquitous. AI's a tougher nut to crack, but we have to have physics to make our virtual worlds interactive. So hopefully developers will target the older demographic that Nintendo is after. They don't really give a rip about better graphics (to a point), but make the controlls unresponsive, the physical simulation overly simplistic, or otherwise make the experience jarring, and you'll lose them in 5 minutes flat, never to return. Win them over, though, and I think you'll have a license to print money.
If anybody has the guts to try something really radical, there are interesting times ahead. We shall see...
If you're doing any web development (and let's be honest, if you're doing any develolpment, your organization is doing some web development somewhere), you *must * use 3 or 4 different languages. No way around it. If your organization isn't using some combination of HTML, XML, CSS, Javascript, XSLT, XPath, ActionScript (1, 2, or 3!), SVG, and other web languages, well, WTF?? Toss in a server side language, either Java, ASP.Net (any), PHP, Perl, Ruby, etc, and often you pick (or have only 1 choice of) a tag language to match (like JSP/JSF/etc with Java). Unless you're using some data abstraction layer, ORM type thingy, you'll probably have some SQL kicking around too.
Next, if you create an end-user application of some kind, in many many cases, you must use C/C++ due to end user requirements. Some of this is being eaten up by C#, but not everybody is willing to target the.Net runtime. Then, you probably have to write an installer, and this might be using InstallShield's scripting language or similar. Does your QA department do automated testing? The automated testing tools usually have their own scripting languages too (maybe these are moving to.Net languages now, I haven't looked in a while). And if you're a big dev team, you'll be doing automated builds, so'll have somebody who's actually hacking around with makefiles (potentially MS format NMAKE files).
If you're company is big enough to be worrying about this kind of problem, you'll have an IT infrastructure of some importance. Your IT team damn well better be using Bash scripting, Perl, Python, or some other Sys Admin language. Even Windows admins these days write scripts; there's even this new scripting framework scheduled (as an add on?) for Vista. How about your Apache config files? Your various mail/proxy/firewall configs (talking to UNIX folks here...)?
If you have a real IT division, I'll bet you have an accounting section. Remember why people have such trouble moving to OpenOffice.org? That's right, custom Excell/Acess solutions. What's that, VBScript you say? Moving into Fortune 1000 territory, how about R3? Well, that SAP system never actually did anything, but those consultants sure made a helluva lot of money. Manufacturing and assembly lines use all kinds of weird stuff. Got any telephony solutions running around? Are you targetting mobile devices? Use scientific/mathematical software? Rendering software? Various pre-press systems? Work in the medical/health care industry? A lawyer's office? All these verticals have lots of custom things running around that you sometimes can't avoid.
So in a nutshell, any reasonable corporation doing software development *should* be using 5-10 languages. If you were to pick only 1 language, the only choice you could possibly have is HTML. You could theoretically write a static HTML page with no CSS, no Javascript, no server side scripting, no SQL, and no Flash. You could run it off of one server, with no admins and no scripting. With no product to hawk, you don't need an accounting deptartment, and voila. Good luck with the whole money thing, though... What a stupid question. Use what you have to based on the requirements, and when you have a choice, do your best (maybe even bend over backwards) to avoid unnecessary proliferation.
The summary is messed up. The linked article states that 1 million DSs have been sold in the UK, vs 3.5 million in all of Europe (and 13 million worldwide). And apparently the PSP is much more popular in the UK than the rest of the world, resulting in more-or-less even sales with the DS. If I recall, the DS was outselling the PSP 3 or 4 to 1 in Japan until stores ran out of stock.
I also had one of those somebody's-copying-your-answers-so-you-get-them-wr ong-on-purpose episodes. In my case, the copier had flunked every single test so far, and after copying all of my answers, proudly went up to the professor and loudly stated that he had aced the test this time, getting everybody's attention. The professor says, "Oh really? Let me grade it right now." It was multiple choice, so lickity split he had the grade. Somehow he had gotten them all wrong! He would have been better off guessing. After changing my answers, I proceeded to turn mine in for a perfect score.
While not exactly an exam story, I didn't get along very well with this one CS Prof. In one course, for all of the programming assignments, he would include "hints" or general suggestions or starter code. Unfortunately, usually it was bad advice, error prone or poorly conceived or whatever. There was a small contigent of about 5 CS students that I tutored, and it rather annoyed the Prof that we tended to get perfect scores plus extra credit while completely ignoring his "hints" and not really attending class. In some cases we were the only ones, because the rest of the class would never get a working program following his direction. Since it was graded by student graders, though, he couldn't really interfere too much. Note, these students didn't copy my work, I actually tutored them so they could write the programs themselves. I'm sure it gave him much satisfaction to give me an A- when I overslept the day of the final, missed half the time, and only got a B. This despite having a better than perfect score on every project.
In my E&M class, there was a group of people, I guess started by some ROTC guys, who would stand up before a test, and in unison chant something witty, ending with, "Make it hurt professor, make it hurt! Huh!" at which point they would sit down and begin.
Again, not a test example, but in my algorithms class, there was a term that our professor defined slightly differently than the book. The guys that I worked on the projects with, we didn't go to class, so we of course used the book's definition. On one major project, we were stumped for a long time. We kept looking at each other saying, well, if only it were defined this way, it would be trivially easy... Well, we eventually worked it out, and then decided to go to class to see if anybody else had too. When the prof asked if anybody had a solution to this problem, we were happy to share ours. The prof looked at us funny, not really understanding what we were presenting, and said, "Couldn't you just do this?" and we were like, no, that would violate this condition. He's like, that's not how it's defined, and we kinda look at each other and go, that's what the book says! The prof kind of harrumphs and goes, hmmm, I'll have to look into that. Needless to say, we were a little miffed, but that episode has stayed with me because our version required real creativity and insight. It was sweet vindication, though, when I high-scored the midterm. FWIW, the problem had something to do with Omega notation of strictly monotically increasing functions or something like that, and proving that some kind of bounding function did or didn't exist. I forget. Anyway, the difficulty was not so much conceptualizing a solution (which wasn't easy) but coming up with a concrete function that actually displayed the behavior.
Perhaps you don't realize that they already have such tests and they work reasonably well, even though they don't use nanowires. These tests are easy, painless, relatively quick, but a bit too expensive for people to do them all the time "just in case." The way it works today, once you *suspect* cancer, then you fork over the money because the tests are a drop in the bucket compared to treatment (of any kind). Depending on the type of suspected cancer, there are a number of different tests that can be done, one of which is testing the blood for tumor markers (proteins). Accuracy is not the problem with the current marker tests, although if these new methods improve accuracy nobody's complaining, the problem is nobody wants to fork over a few hundred bucks every 3 months just to check for a small number of markers. It makes no sense. But if you can check for all the markers you are reasonably likely to encounter (given your gender/age/race) for $25, and it can be administered at the local pharmacy, then scores of people would get checked regularly just for peace of mind. That's *how* early detection will happen. So the point is, if this test cost $5000, nobody would care, because there's already much cheaper tests available. The only way a test increases early detection is by being run more often, and the current barrier to that is cost, not the tests themselves.
Currently, testing for tumor markers is not all that slow--it only takes a couple of hours if you have your blood drawn at the same location that runs the tests. However, each marker you want to test for requires that another vial of blood be taken and costs around $100. Getting the results back in 5 minutes is relatively unimportant, but being able to test for say 50 tumor markers with only 1 blood sample and one low price would be really valuable even if it took *longer* than current methods. That way, you would just check for all the most common markers for your gender/race every time you went in for a physical. Or if you were in an at-risk category, maybe more often.
What you *really* ought to thank me for is convincing my employer that OpenOffice.org was the answer, thus letting me work on it. Although, it has taken some dedication on my part or the project would have failed, so thanks:)
Also, I want to re-iterate that I'm hopeful things will improve after the 2.0 crunch. The Powers That Be are not unaware of what's going on, and some effort is being expended to improve things. But 2.0 is a monster that really needs to get out the door, and once that's done will be a good time to revisit some of this.
At any rate, I was one of the first non-Sun employees to contribute. This was before Novell, if I recall, about 3 years ago. I believe I'm still one of the few people outside Sun and Novell to hack on the C++ side.
So here's a little insight from the inside. I have had a *lot* of frustrations over the years working on OOo. I know why there aren't many other developers outside Sun working on it. Getting to the point where you can hack on stuff and do your edit/compiler/debug cycles requires dedication. If you aren't being forced into it, it'll never happen. I work on OOo at my job, or I'd never have made it either. It took 2 or 3 weeks to get the OOo 2.0 enivornment set up to where I could edit/compile/debug. Part of the problem is that they aren't distributing solvers for 2.0 snapshots due to resource limitations. The reason it takes so long is because I don't have a spare machine to compile on, so I let it build overnight. Of course, when there's an error, you don't see it until the next morning. If you're not comfortable editing makefiles (and non-standard makefiles, OOo uses dmake, not gnu-make), or working with CVS (some files had to be manually retrieved from the attic), working with a unix shell (I'm a bash guy, but they use tcsh which drives me nuts), etc, you stand no chance in hell. And yet, I am *thrilled* by the progress that's been made over the last few years. The build is a million times better/easier than it was. I'm pretty confident that these last few wrinkles will get ironed out, and when 2.0 final comes out, you'll be able to follow the instructions and it'll "just work."
Now, once you get to the point where you can hack, you'll run into the next problem. While the code may be open, the development process is only sort-of open. Since all the main coders work at Sun, you pretty much stand no chance in hell of doing work on core components, except bugfixing. So, for example, don't expect to sign up to the mailing lists and have any clue what people are working on. Don't expect to be informed of major changes coming down the line unless you have somebody on the inside to give you the scoop. Don't expect to get involved in design discussions, don't expect to have any input on scheduling, don't expect to be consulted about anything except when you're going to fix bugs in your code, don't expect to gain influence in the project over time as you become an established, respected developer. In short, don't expect anything that you would normally expect from an open source project. You will perpetually be an outsider, a non-employee, unpriviledged. Don't get me wrong, you'll gain respect and credibility over time--it's just that won't turn you into Sun management (duh), and Sun management makes decisions for the benefit of Sun (duh) without consulting Joe Random Developer (not too surprising). However, that said, if you want to work on peripheral things, plugins, extras, etc, and don't care much about when or if or how your stuff gets included in OOo official, the devs are really good about helping you out. Also, if you do this as your day job, you may be able to muster some more clout, especially if your company is going to make serious ongoing contributions.
So I'm hopeful that once OOo 2.0 comes out, more of a community will form as the build difficulties ease up. Will the community ever take control and set the direction of OOo, where Sun is just one player? Doubtful. Will the community fork OOo becuase of this? Maybe. Does it matter right now? No. Sun's doing a pretty good job, IMHO.
Well, ok, admittedly, I have not actually programmed the the graphics coprocessor. Yet. I've thought about it, though, and I will do more research into it. I probably stated things a little forcefully in my first message: I didn't mean you should *always* be programming the graphics coprocessor, just that if you're doing this level of optimization, you should be aware of that as a possibility.
Now, about spending hours doing inline assembly: if you read my post, you'd notice that it was the last thing in the list. Presumably, you've already A) optimized the algorithm, B) profiled, and C) taken the low hanging fruit. For whatever reason, it's still not good enough. At this point, you've already invested (likely) several days to "fixing" performance. You've studied the assembler that the compiler is generating. Now, you can either A) bend over backwards trying to get the compiler to apply better optimizations, or B) do it yourself. A) has the disadvantage that it's very compiler-specific sometimes, and somebody might innocently change the code, wrecking performance. B) has the disadvantage that it is processor family specific, but I see this as no worse than being compiler specific (in fact, it's often better). They both require a certain kind of expertise, double checking with the reference manuals, and maybe a little trial and error. Once again, I like the inline assembler because it doesn't change when a new compiler comes out. You don't have to worry until a new processor becomes common, and even then, only if you've carefully tweaked pipeline parallelism or cache behavior. And of course, you have this problem anyway, except you're depending on the *compiler* people to optimize for the new proc better.
Let me put it this way: the compiler optimzation is crucial for all the millions of lines of code that you're *not* going to look at. Once you've run the profiler, though, and found those 20 important lines, don't hesitate about taking things into your own hands. And if it wasn't worth it to spend a couple days on those 20 lines of code, you wouldn't have started this exercise in the first place.
Oh, and one last thing: inline assembler remains even in debug mode, when the compiler will obviously not be applying aggressive optimization. This can make debugging the rest of the application much more pleasant!
Aha, you sir, deserve a cookie:) You tried it one way, looked at the assembler, tried it the other way, looked at the assembler, and voila, make an educated decision. I've not optimized with GCC for a while; I've been a VC++ monkey lately. At any rate, it does seem to depend on specifically what you are doing with the array elements. I haven't figured out exactly what the compiler is doing; sometimes it can tell that the index hasn't changed between references, perhaps depending on the complexity of the expression. Sometimes it can't. I can tell you this, though: this kind of optimization has been the most common for me the last few years.
And yes, figuring out how to work around registry limitations is often the focus of further optimization. If GCC is being smart enough to set up segment selectors, that's great. You still only get 4 segment registers, though (unless you use the stack segment). At any rate, you make me want to go toy with the latest GCC.
Either way, if I look at the compiler output and think, "That's stupid," then I'll use inline assembler to tweak it and make the whole issue moot.
Thanks for your insightful response! (I'd mod you up, but alas, I already posted:)
I'm going to presume that you've *already* picked a reasonably effecient algorithm, 'cause otherwise there's no point. Second, I'm going to presume that you've already run the profiler, so you know which lines of code are important.
Here's my "guide to optimizing":
1) Are you disk I/O bound? You might need to switch to memory mapped files, or you might need to tweak the settings on the ones you have. You might need to use a lower level library to do your I/O. Many C++ iostreams implementations are slow, and many similar libraries involve lots of copying.
2) Are you socket I/O (or similar) bound? If so, you may need to rewrite with asynchronous I/O. This can be a PITA. Suck it up.
3) Are your threads spending all their time sitting in locks waiting for other threads? One, make sure you're using an appropriate number of worker threads optimized by the number of CPUs the host has. If you've already got the right number of threads, this can be a really tough decision. Presumably, the threads are helping your program readability, and trying to rework things into fewer threads is often a *bad idea*.
4) Are you spending all your time in malloc/new/constructor free/delete/deconstructor? Maybe you need to keep things on the stack, use a garbage collector, use reference counted objects, use pooled memory techniques, etc. In the right places, switching from some "string" library to const char* and stack buffers can give a huge benefit. Make sure, of course, that you use the "n" version of all standard string functions (the ones that take the size of the buffer as an argument) to avoid buffer overruns.
5) Are you spending all of your time in some system call? Like maybe some kind of WriteTextToScreen or FillRectangleWithPattern type of thing? For drawing code in general, try buffering things that are algorithmically generated in bitmaps, and only regenerate the parts that change. Then just blit together the pieces for your final output. Perhaps you need to rely on hardware transparency support for fast layer compositing. You might need fewer system level windows so you draw more in one function. Maybe you need to reduce your frame rate.
6) Are you using memcpy as appropriate?
If any of the previous items are true, you have no business worrying about the compiler. However, once you've gotten this far, you can start worrying about optimizing your code line by line.
7) Since you've gotten this far, the line(s) of code you're worried about are all inside some loop that gets run. A lot. They may be inside a function that's called from a loop too, of course. So, a few things to consider. A) You may need to use templates to get code that is optimized for the appropriate data type. B) You may need to split off a more focused version of the function from the general purpose function if it's also used in non-critical areas. This has negative maintainance ramifications. C) Do the bonehead obvious stuff like moving everything out of the loop that you can. D) Look at the assembly actually generated by your compiler. If you're not confortable with this, you have no business doing further optimization.
After looking at the assembler, then you'll know if the following are important. In my experience, they are.
1) Change array indexing logic to pointer logic:
MyType stuff[100];
for( int i = 0; i < sizeof(stuff) - 1; i++)
{
stuff[i] = abs(stuff[i+1]/PI);
if (stuff[i] < 0)
stuff[i] = 0;
else if (stuff[i] > maxval)
stuff[i] = maxval;
}
Last week I was poking around the web looking for good music theory/ear training software. Seems like a perfect thing for OSS, and in fact GNU Solfeg exists. The non-OSS competition is lots of shareware and crapware. But finding the OSS program was hard and the crapware was abundant.
This kind of stuff is perfect for OSS: it's pretty straightforward (no real innovation required), tends to be loosely coupled, benefits immensely from depth/thoroughness, and the competition doesn't tend to be super-slick. It's lots of the same reasons that WikiPedia is so successful.
Whoa boy, another flame war unto itself! I'm not a DB guy, but I like Postgres. I'm anxiously awaiting bugzillia 2.20 I think it is, with Postgres support. Then, when postgres 7.5 comes out with native Win32 support, life'll be grand. Not that that's what's holding me up, mind you, I have a couple linux servers running, but bugzilla's install looks intimidating and it's not pressing and I have a gazillion other jobs. It was enough for me to get Subversion running, and I failed getting samba configured properly. Now I'm waiting for all the tools (like IDEs especially) to have Subversion integration. Guess that's why I'm a coder and project manager, I'm a lousy admin! I know enough apache and tomcat to be dangerous, enough linux to get around, but diddley about sendmail, bind, and countless other programs. Hell, I can't get the ftp server configured to set permissions the way I want them (whatever the default ftp server is on FC1).
Fortunately Mono looks to have Postgres support. Now, if they would just ditch monodevelop and work on Netbeans, Eclipse, and KDevelop integration... I mean, competition is good and all, but I don't want to switch to monodevelop just to develop.Net stuff, you know? I want to stick with my IDE of choice, which right now means Netbeans or VC++.Net. BTW, I think VC++ 6 was an amazing product for its time, but I don't really like VC++.Net the IDE, although I do appreciate compiler advancements (better code and more standards compliant). Anyway, I intend to get around to playing with Mono sometime; I'm especially interested in the OSX version.
About choosing your battles, amen, that's why I do use Java--it's the right tool for the job in the places where I use it. Which has nothing to do with Java, but the fact that 3rd party products provide java libraries/interfaces. Perl would actually be better for what I'm doing, but toss in an obscure commercial database with only JDBC and a few java libraries, and poof, there you have it (the Netbeans angle helped a lot too, to be fair).
However, I really really like JSPs/Servlets. I *want* to like JSF, but but but... And EJBs are enought to make a grown man cry. I'm following the MyFaces list, and it looks like good things are coming. MyFaces will become an Apache project, and will integrate smoothly with Struts soon, and there's talk in the air about portlets. I figure that by next spring (march say), a lot of my frustrations with Java-land will be cleared up. Java 1.5 err I mean 5.0, Netbeans 4, hopefully a new JSF spec to clean up probs, and Struts-MyFaces harmony, all given some time to stabalize. Maybe even the commercial Java guys will get their acts together by then--I was dismayed to find that IBM's latest offering only supports old JSP/Servlets, BEA has their own proprietary nastiness, and Sun's proprietary versions of Netbeans (Java Studio Creator, I think) and Tomcat (Sun Web App Server?) are steaming piles of poo when I tried them a couple months ago. Granted, they were beta, but wtf??
I think PHP's previous simplicity and 'under-featuredness' with regards to OOP are actually what made it so popular
You know what, I can respect that. It's not for me, but that's cool. See, I'm primarily a C++ and Java coder. And while C++ is more complex, I find it's complexity *useful*, while Java's is just infuriating (J2EE is a nightmare). Now what I dream about is the day when you can use your choice of language on your choice of VM-Mono, JVM, or Parrot, including libraries etc. Being able to choose your libraries and language independantly would eliminate a lot of language wars, IMHO.
Well, I'm gonna mark you as friend since you seem level-headed and un-fanboyish:)
Now, admittedly, I'm *not* a PHP programmer. I only peruse annoucements like this periodically in case someday the choice of whether to use PHP or "technology X" lays before me. I don't use scripting languages much, using Perl when I do. But the things you mention as plusses *seem to me* to be pretty common amoungst the scripting languages (as you even say:). Seeing as how you're already a PHP developer, I expect these OOP features to be a great boon for your development. I guess I'm just hard pressed to see the long term PHP niche. Java's got most of the enterprise market and tool/vendor support, Perl 5's probably still got the most hacker/sysadmin users, while Perl 6 is just this side of vaporware they've at least mapped out a clear path to the future, and Ruby and Python have fancy shmancy language features and are pretty mature by now. So is the magic in the secret sauce or what?
Not to be flaimbait (really!), but after reading over the new features in PHP 5, my reaction is, "you mean you haven't had this all along?" Sure, all this is great for existing PHP users, but I don't think users of other languages will care much. New XML support? Now you can define constructors with __constructor() instead of the name of the class!!! Umm... Try/Catch? Overall, it seems they're just Java-fying PHP, in which case you might as well use Java, so it seems to me (unless, of course, you are already a PHP programmer). Perl programmers will just keep waiting for Perl 6, which makes these "new" features seem kinda like your 6 year old nephew threating to kick your ass. People who are looking for a new, hip, language all seem to be going for Ruby, and I can't blame them (heck, I would too if I had time for such things). Hey, can you hold on a sec... 1999 just called, they want their features back...
The ability to do generic programming ala Boost is a great feature. Higher level languages are all about better abstractions, and generic programming is the best abstraction mechanism we've seen in general use since OOP. While OOP lets you encapsulate behavior and abstract over interfaces, generic programming lets you abstract over *form*. The significance is in the coupling. Generic programming allows much looser coupling between the writer of the generic library and the user of the library. A nice example is a generic "find" function:
template <typename I, typename V> I find(I begin, I end, V val) {
for (I it = begin; it != end; ++it)
if (*it == val)
return it;
return end; }
And here, you have captured the essence of a linear search. To understand what's going on, first know that I and V are arbitrary types that are inferred (at compile time) from the values you pass when you actually call the find function. For the generic find function to work, there are only a couple of restrictions on these types:
1) I must be incrementable. 2) I must be dereferenceable. 3) You must get from begin to end in a finite number of steps. 4) The type you get when dereferencing I (I's value type) must be comparable to V.
Because of this, you can use the same find function to search through arrays, lists, vectors, maps, sets, strings, streams, and more, even though none of them inherit from each other or implement a common interface in the OOP sense.
Additionally, there's no complicated syntax for the user of the library:
int myarray[10] = {1, 1, 2, 3, 5, 8, 13, 21, 34, 55}; int* p = find(myarray, myarray + 10, 8); if (p == myarray + 10)
cout << "8 was not found." << endl; else
cout << "The value of p is " << *p << "." << endl;
The great thing about abstraction is that it avoids duplication. Avoiding duplication lets you test/debug/prove correct once for greater reliability. Once you wrap your head around this simple example, you'll be surprised how deep the rabbit hole goes.
A Brief History of Time, by Stephen Hawking The Principia, by Isaac Newton (find a good translation) Origin of Species, by Charles Darwin Six Easy Pieces and Six Not-so-Easy Pieces, by Richard Feynman (2 books) QED is also recommended. Also, an essay, "There's Plenty of Room at the Bottom." The Art of Computer Programming, by Donald Knuth Engines of Creation, by Eric Drexler Design Patterns, by Gamma et al
I seem to recall that one of Noam Chomsky's books on language is considered a classic, but I don't remember the name. I can't think of any "classic" AI books off the top of my head, and I've never seen a robotics book I liked.
I also recommend some Hard Sci-Fi, but it's a short list: Contact, by Carl Sagan Fountains of Paradise, by Arthur C. Clarke
Well, I've downloaded their freebie developer studio (note: I don't know what's different in the for-pay IDE). My company is currently trying to choose between ASP.Net and Java for our next website revision, so I'm looking into these things. As far as I can tell, this is some non-standard extension to Struts, and with the rest of the industry moving to JSF, I don't know if it's got a future or not. However, JSF is currently, uhh, beta shall we say (Sun's IDE is beta and acts like it). Even though I just got it, it seems as though BEA's stuff is a little more battle hardened. But as I've discovered just trying to port a simple test app from Sun's JS Creator to Netbeans/Tomcat, it's littered with non-standard extensions too. ARGH!
Just be confident knowing that most of your basic skills will transfer, and get a normal C++ book. Personally, I recommend Stroustroup's book, and Dietel and Dietel is an oft used text. Most of those "Learn C++ in 24 Hours!" types of books are a waste of trees. Like others have said, it's crucial that you get something that covers STL (both the ones I mentioned will). It's C++'s version of a class library. You'll find it a little thin after working in Java, and that's where platform specific stuff enters the picture. You'll find most of your time is learning a new widget set (presuming you need GUI programming), or socket APIs (if you need 'em), or platform specific threading/synchronization etc.
Overall, coming from Java, you won't expect or know how to use fancy language features. That's Ok. Write C++ like you would Java (mmm, careful about that memory leak though). This assumes you're doing app development where you can afford to make every function virtual, every object a reference, and have accessor functions for every member variable. If that's not what you're up to and you need write tight C++, well, forget Java while you learn C++. Make sure you get your memory models straight--stack vs heap, by value and by reference, pointers vs reference, iterators vs pointers, reference counted, and on and on. You have to get the now classic "Effective C++" books by Scott Meyers. That's the best way to avoid classic stupid C++ mistakes. You'll find it a bit heavy going at first, but until it makes sense to you, you're probably writing bad C++. Good luck.
Just wanted to point out that NetBeans also has this feature in the recently released 3.6. You don't have to wait until an "official" Eclipse release; you can use a stable NetBeans now. Obviously, I like NetBeans, and I think they've been making leaps and bounds of progress recently. I'm really looking forward to 4.0 with the Ant based project system. Then, you should be able to work in either NB or Eclipse, or Emacs or whatever floats your boat. Hooray for competition!
Also, for those saying this leads to bad coding style, I'm hoping that the forth-coming refactoring features in NB 4.0 will make this much less of an issue (don't know about Eclipse equivalent feature). Got a junior dev who likes to make really really long code blocks? Refactor into saner functions with a little help from your IDE. Since I'm about to get some junior devs dumped on me, I hope it does work out...
Slashdot Mirror
Yes, I remember reading that the sequel kinda screwed the pooch. I've always wanted to play the first one though. Just not much time for games these days :( It's just so damn annoying that rocket launchers will not harm a flimsy wooden door in the slightest, nooooo, you have to find the right key or passcard or whatever. Bleh.
Now, there's a few caveats here. Another thing that happens over time is you learn to stop re-inventing the wheel and to use pre-existing libraries. Right now, you're just unaware of their existence, but you'll learn where to look if you make a little effort. In fact, you'll find that existing libraries tends to heavily influence choice of language to use. So it turns out that most things that are really worth reusing are already available, and you should use those solutions rather than maintaining your own. Sure, write your own for fun or education, but when you get a serious project, you've got no use for it. In some cases, you'll find that there's no library available, so you write something from scratch, but 3 years later, you find that somebody else has made a nice library that's much better than what you hacked together. Several times I have ported code from my own hacked together solution to a more mature library. It's a natural progression, and there are a thousand times more libraries freely available today versus 10 years ago.
Now, having said all that, there are still times where you want to make something that is generically reusable. The point is, though, you should really make an effort to make a library out of your code. I have done just this on a handful of occasions. Then, put it up on SourceForge or something similar dedicated to your language of choice. I have a few libraries up on SourceForge, some only a few hundred lines of code, but some other people have found them useful because I made the effort. Other people have suggested CVS or whatnot, and SourceForge will give you that.
Maybe the real gist of your question, though, was about making your code into a library? While the technical details of making a lib, dll, so, jar, pm, etc vary from language to language (sometimes compiler to compiler), here's a few pointers:
I'm going to make a broad generalization here, so bear with me. There are basically two types of games:
1) Abstract, pattern, or board type games. Puzzle games, party games, and non-game-games.
2) Stylized simulations of various kinds. Simulated driving, sports, fighting/combat, and so forth. Even fantastical worlds have kind of implied rules that are being simulated.
For type #1, since there's no pseudo real world to simulate, designers are free to make up their own rules, and convincing physics or human-like AI aren't so important. Additionally, good graphics tend to be irrelevant to these types of games. As a result, there's almost no such thing as a "next-gen" puzzle game, because pretty much any puzzle game that gets made could have been done on previous-gen hardware. One exception might be TetriSphere.
However, for simulation type games, the drastic changes come from increases in the fidelity of the simulation. Since perfect simulation is impossible, we're stuck with a mixture of scripted/canned behaviors that cover a wide array of interactions along with actual simulation. So a primary driving force in making these games feel "next-gen" is migrating an entire category of functionality from scripts into simulation. Doing this requires more horsepower, thus next-gen hardware, and makes the game seem qualitatively different because player freedom has increased.
I think a basic development that has to happen soon is a move towards more realtime skeletal animation. I think it's practically criminal that new games being made today still have characters get hung up on the slightest corners of objects. Getting "stuck" on a crate is ridiculous, or a doorframe or a rock or anything. You need to appropriately account for momentum and have skeletal animation to realistically show the effect on the character, so you can stumble, bump, trip, twist etc. Deformable environments need to be common place, with decent collision/impact calculations (I've never played Red Faction, so I don't know how good of a job it did). Elements in the environment need to react properly to extreme heat or cold. You can come up with an almost endless laundry list of these things.
These types of things will give players more freedom and more convincingly immersive games. You could then make Sequel 127 and have it seem fresh and distinct, as the play experience will be unlike what came before. But then you'll need something else by the time you hit Sequel 130. But for right now, there are plenty of REALLY OBVIOUS things that need to be done, but don't seem to be chased very much. Of course, that's because these things are *hard* while improving graphics is easy...
Yeah, it'll be somewhat limited, but you could still use it for leaning/looking around corners and making your FOV a little more natural with slight scanning left/right/up/down. Sitting here typing this, I can gain maybe 45 degrees in any direction and still keep my eyes on the moniter without undue effort. It would take some getting used to and might be disorienting, but the fact that it's easy, natural, and kind of reflexive would be a huge advantage. Making looking and aiming independent has some advantages if you're not overloading the control complexity, so it'd be worth a shot to see how it plays. Particularly if you're using the main controller as a sword, and a second controlloer for a shield, you can't use your hand's to look around, so if you can make a head-tracking solution workable, it opens things up a little.
Also, as much as I ragged on the "gesture" approach in my earlier post, it's different with your head. In a Rainbow Six or other squad combat type of game, you could potentially issue orders with "head gestures." In other words, select a team mate by pointing at him (with the regular remote) and nod your head in the direction you want him to go. Voice commands are probably a better way to go for that, but it's worth thinking about the possibilities.
Not only does the controller appear to have a large number of degrees of freedom, all the ideas for having one player use multiple controllers magnifies this immensely. The genius is that it will be *intuitive* to use multiple controllers. One in each hand is the obvious bit, and the article suggested strapping one to a leg for kicking in a fighting game. One person suggested making a headset for "free-look" type uses. You could have a fighting game with one controller in each hand to punch/block, one on each leg for kicking/moving, and one on your head for ducking/dodging etc. 5 controllers all for one person might seem inane, but if they made alternate controllers that had no buttons but just the positioning detection with little velcro straps, you would no longer feel like an idiot strapping one to your ankle. Now, once you imagine this little "mini" controller sans buttons, there's all kinds of interesting new directions. I don't know how many of these can talk to the Revolution hardware simultaneously, but if you could get 12-16 going at once, you could have all kinds of fun with "home motion capture." Imagine a movie making "game" where you act out all the parts in motion capture. Imagine a totally new style of dancing game, where you *really* dance. Or imagine a dance instruction "game" for two people. You and your partner strap on ankle bracelts, wrist bracelets, and maybe something around the shoulders, and really dance. Add in a scoring mechanism for accuracy, toss in an online component for competition, and you're in a whole new world. Now you're really talking about a revolution.
.5 sec while the animation finishes. In effect, now you're just talking about mouse gestures in 3D space. If the on-screen avatar doesn't track your movements accurately, smoothly, and convincingly, then you're just memorizing gestures to trigger a move--and that would be physically tiring with not much reward, and we'll go back to pressing buttons.
However, this also illustrates the biggest challenge to be faced by Revo developers, IMHO. In all current games, your characters have canned animations to represent your moves. You press the A-button or whatever, and the sword swipe animation playes. It's pre-rendered, beginning to end. Revo games will have to do realtime skeletal animation, so that you can begin swiping your sword, check it mid-stroke, and block with your shield. If you use physical movement to trigger canned animations, it will feel surreal, and you'll quickly give it up because it won't be responsive. You'll start to swipe your sword, and the game won't respond for
In my opinion, this is a good thing. For *years* what we've needed is better physical modelling, not better graphics. Better physics and better AI are really the key to better gaming. Graphics have been mostly "good enough" for 5 years, while physics and AI have only changed marginally since 3D games became ubiquitous. AI's a tougher nut to crack, but we have to have physics to make our virtual worlds interactive. So hopefully developers will target the older demographic that Nintendo is after. They don't really give a rip about better graphics (to a point), but make the controlls unresponsive, the physical simulation overly simplistic, or otherwise make the experience jarring, and you'll lose them in 5 minutes flat, never to return. Win them over, though, and I think you'll have a license to print money.
If anybody has the guts to try something really radical, there are interesting times ahead. We shall see...
If you're doing any web development (and let's be honest, if you're doing any develolpment, your organization is doing some web development somewhere), you *must * use 3 or 4 different languages. No way around it. If your organization isn't using some combination of HTML, XML, CSS, Javascript, XSLT, XPath, ActionScript (1, 2, or 3!), SVG, and other web languages, well, WTF?? Toss in a server side language, either Java, ASP.Net (any), PHP, Perl, Ruby, etc, and often you pick (or have only 1 choice of) a tag language to match (like JSP/JSF/etc with Java). Unless you're using some data abstraction layer, ORM type thingy, you'll probably have some SQL kicking around too.
.Net runtime. Then, you probably have to write an installer, and this might be using InstallShield's scripting language or similar. Does your QA department do automated testing? The automated testing tools usually have their own scripting languages too (maybe these are moving to .Net languages now, I haven't looked in a while). And if you're a big dev team, you'll be doing automated builds, so'll have somebody who's actually hacking around with makefiles (potentially MS format NMAKE files).
Next, if you create an end-user application of some kind, in many many cases, you must use C/C++ due to end user requirements. Some of this is being eaten up by C#, but not everybody is willing to target the
If you're company is big enough to be worrying about this kind of problem, you'll have an IT infrastructure of some importance. Your IT team damn well better be using Bash scripting, Perl, Python, or some other Sys Admin language. Even Windows admins these days write scripts; there's even this new scripting framework scheduled (as an add on?) for Vista. How about your Apache config files? Your various mail/proxy/firewall configs (talking to UNIX folks here...)?
If you have a real IT division, I'll bet you have an accounting section. Remember why people have such trouble moving to OpenOffice.org? That's right, custom Excell/Acess solutions. What's that, VBScript you say? Moving into Fortune 1000 territory, how about R3? Well, that SAP system never actually did anything, but those consultants sure made a helluva lot of money. Manufacturing and assembly lines use all kinds of weird stuff. Got any telephony solutions running around? Are you targetting mobile devices? Use scientific/mathematical software? Rendering software? Various pre-press systems? Work in the medical/health care industry? A lawyer's office? All these verticals have lots of custom things running around that you sometimes can't avoid.
So in a nutshell, any reasonable corporation doing software development *should* be using 5-10 languages. If you were to pick only 1 language, the only choice you could possibly have is HTML. You could theoretically write a static HTML page with no CSS, no Javascript, no server side scripting, no SQL, and no Flash. You could run it off of one server, with no admins and no scripting. With no product to hawk, you don't need an accounting deptartment, and voila. Good luck with the whole money thing, though... What a stupid question. Use what you have to based on the requirements, and when you have a choice, do your best (maybe even bend over backwards) to avoid unnecessary proliferation.
The summary is messed up. The linked article states that 1 million DSs have been sold in the UK, vs 3.5 million in all of Europe (and 13 million worldwide). And apparently the PSP is much more popular in the UK than the rest of the world, resulting in more-or-less even sales with the DS. If I recall, the DS was outselling the PSP 3 or 4 to 1 in Japan until stores ran out of stock.
I also had one of those somebody's-copying-your-answers-so-you-get-them-wr ong-on-purpose episodes. In my case, the copier had flunked every single test so far, and after copying all of my answers, proudly went up to the professor and loudly stated that he had aced the test this time, getting everybody's attention. The professor says, "Oh really? Let me grade it right now." It was multiple choice, so lickity split he had the grade. Somehow he had gotten them all wrong! He would have been better off guessing. After changing my answers, I proceeded to turn mine in for a perfect score.
While not exactly an exam story, I didn't get along very well with this one CS Prof. In one course, for all of the programming assignments, he would include "hints" or general suggestions or starter code. Unfortunately, usually it was bad advice, error prone or poorly conceived or whatever. There was a small contigent of about 5 CS students that I tutored, and it rather annoyed the Prof that we tended to get perfect scores plus extra credit while completely ignoring his "hints" and not really attending class. In some cases we were the only ones, because the rest of the class would never get a working program following his direction. Since it was graded by student graders, though, he couldn't really interfere too much. Note, these students didn't copy my work, I actually tutored them so they could write the programs themselves. I'm sure it gave him much satisfaction to give me an A- when I overslept the day of the final, missed half the time, and only got a B. This despite having a better than perfect score on every project.
In my E&M class, there was a group of people, I guess started by some ROTC guys, who would stand up before a test, and in unison chant something witty, ending with, "Make it hurt professor, make it hurt! Huh!" at which point they would sit down and begin.
Again, not a test example, but in my algorithms class, there was a term that our professor defined slightly differently than the book. The guys that I worked on the projects with, we didn't go to class, so we of course used the book's definition. On one major project, we were stumped for a long time. We kept looking at each other saying, well, if only it were defined this way, it would be trivially easy... Well, we eventually worked it out, and then decided to go to class to see if anybody else had too. When the prof asked if anybody had a solution to this problem, we were happy to share ours. The prof looked at us funny, not really understanding what we were presenting, and said, "Couldn't you just do this?" and we were like, no, that would violate this condition. He's like, that's not how it's defined, and we kinda look at each other and go, that's what the book says! The prof kind of harrumphs and goes, hmmm, I'll have to look into that. Needless to say, we were a little miffed, but that episode has stayed with me because our version required real creativity and insight. It was sweet vindication, though, when I high-scored the midterm. FWIW, the problem had something to do with Omega notation of strictly monotically increasing functions or something like that, and proving that some kind of bounding function did or didn't exist. I forget. Anyway, the difficulty was not so much conceptualizing a solution (which wasn't easy) but coming up with a concrete function that actually displayed the behavior.
Perhaps you don't realize that they already have such tests and they work reasonably well, even though they don't use nanowires. These tests are easy, painless, relatively quick, but a bit too expensive for people to do them all the time "just in case." The way it works today, once you *suspect* cancer, then you fork over the money because the tests are a drop in the bucket compared to treatment (of any kind). Depending on the type of suspected cancer, there are a number of different tests that can be done, one of which is testing the blood for tumor markers (proteins). Accuracy is not the problem with the current marker tests, although if these new methods improve accuracy nobody's complaining, the problem is nobody wants to fork over a few hundred bucks every 3 months just to check for a small number of markers. It makes no sense. But if you can check for all the markers you are reasonably likely to encounter (given your gender/age/race) for $25, and it can be administered at the local pharmacy, then scores of people would get checked regularly just for peace of mind. That's *how* early detection will happen. So the point is, if this test cost $5000, nobody would care, because there's already much cheaper tests available. The only way a test increases early detection is by being run more often, and the current barrier to that is cost, not the tests themselves.
Currently, testing for tumor markers is not all that slow--it only takes a couple of hours if you have your blood drawn at the same location that runs the tests. However, each marker you want to test for requires that another vial of blood be taken and costs around $100. Getting the results back in 5 minutes is relatively unimportant, but being able to test for say 50 tumor markers with only 1 blood sample and one low price would be really valuable even if it took *longer* than current methods. That way, you would just check for all the most common markers for your gender/race every time you went in for a physical. Or if you were in an at-risk category, maybe more often.
What you *really* ought to thank me for is convincing my employer that OpenOffice.org was the answer, thus letting me work on it. Although, it has taken some dedication on my part or the project would have failed, so thanks :)
Also, I want to re-iterate that I'm hopeful things will improve after the 2.0 crunch. The Powers That Be are not unaware of what's going on, and some effort is being expended to improve things. But 2.0 is a monster that really needs to get out the door, and once that's done will be a good time to revisit some of this.
At any rate, I was one of the first non-Sun employees to contribute. This was before Novell, if I recall, about 3 years ago. I believe I'm still one of the few people outside Sun and Novell to hack on the C++ side.
So here's a little insight from the inside. I have had a *lot* of frustrations over the years working on OOo. I know why there aren't many other developers outside Sun working on it. Getting to the point where you can hack on stuff and do your edit/compiler/debug cycles requires dedication. If you aren't being forced into it, it'll never happen. I work on OOo at my job, or I'd never have made it either. It took 2 or 3 weeks to get the OOo 2.0 enivornment set up to where I could edit/compile/debug. Part of the problem is that they aren't distributing solvers for 2.0 snapshots due to resource limitations. The reason it takes so long is because I don't have a spare machine to compile on, so I let it build overnight. Of course, when there's an error, you don't see it until the next morning. If you're not comfortable editing makefiles (and non-standard makefiles, OOo uses dmake, not gnu-make), or working with CVS (some files had to be manually retrieved from the attic), working with a unix shell (I'm a bash guy, but they use tcsh which drives me nuts), etc, you stand no chance in hell. And yet, I am *thrilled* by the progress that's been made over the last few years. The build is a million times better/easier than it was. I'm pretty confident that these last few wrinkles will get ironed out, and when 2.0 final comes out, you'll be able to follow the instructions and it'll "just work."
Now, once you get to the point where you can hack, you'll run into the next problem. While the code may be open, the development process is only sort-of open. Since all the main coders work at Sun, you pretty much stand no chance in hell of doing work on core components, except bugfixing. So, for example, don't expect to sign up to the mailing lists and have any clue what people are working on. Don't expect to be informed of major changes coming down the line unless you have somebody on the inside to give you the scoop. Don't expect to get involved in design discussions, don't expect to have any input on scheduling, don't expect to be consulted about anything except when you're going to fix bugs in your code, don't expect to gain influence in the project over time as you become an established, respected developer. In short, don't expect anything that you would normally expect from an open source project. You will perpetually be an outsider, a non-employee, unpriviledged. Don't get me wrong, you'll gain respect and credibility over time--it's just that won't turn you into Sun management (duh), and Sun management makes decisions for the benefit of Sun (duh) without consulting Joe Random Developer (not too surprising). However, that said, if you want to work on peripheral things, plugins, extras, etc, and don't care much about when or if or how your stuff gets included in OOo official, the devs are really good about helping you out. Also, if you do this as your day job, you may be able to muster some more clout, especially if your company is going to make serious ongoing contributions.
So I'm hopeful that once OOo 2.0 comes out, more of a community will form as the build difficulties ease up. Will the community ever take control and set the direction of OOo, where Sun is just one player? Doubtful. Will the community fork OOo becuase of this? Maybe. Does it matter right now? No. Sun's doing a pretty good job, IMHO.
Well, ok, admittedly, I have not actually programmed the the graphics coprocessor. Yet. I've thought about it, though, and I will do more research into it. I probably stated things a little forcefully in my first message: I didn't mean you should *always* be programming the graphics coprocessor, just that if you're doing this level of optimization, you should be aware of that as a possibility.
Now, about spending hours doing inline assembly: if you read my post, you'd notice that it was the last thing in the list. Presumably, you've already A) optimized the algorithm, B) profiled, and C) taken the low hanging fruit. For whatever reason, it's still not good enough. At this point, you've already invested (likely) several days to "fixing" performance. You've studied the assembler that the compiler is generating. Now, you can either A) bend over backwards trying to get the compiler to apply better optimizations, or B) do it yourself. A) has the disadvantage that it's very compiler-specific sometimes, and somebody might innocently change the code, wrecking performance. B) has the disadvantage that it is processor family specific, but I see this as no worse than being compiler specific (in fact, it's often better). They both require a certain kind of expertise, double checking with the reference manuals, and maybe a little trial and error. Once again, I like the inline assembler because it doesn't change when a new compiler comes out. You don't have to worry until a new processor becomes common, and even then, only if you've carefully tweaked pipeline parallelism or cache behavior. And of course, you have this problem anyway, except you're depending on the *compiler* people to optimize for the new proc better.
Let me put it this way: the compiler optimzation is crucial for all the millions of lines of code that you're *not* going to look at. Once you've run the profiler, though, and found those 20 important lines, don't hesitate about taking things into your own hands. And if it wasn't worth it to spend a couple days on those 20 lines of code, you wouldn't have started this exercise in the first place.
Oh, and one last thing: inline assembler remains even in debug mode, when the compiler will obviously not be applying aggressive optimization. This can make debugging the rest of the application much more pleasant!
Aha, you sir, deserve a cookie :) You tried it one way, looked at the assembler, tried it the other way, looked at the assembler, and voila, make an educated decision. I've not optimized with GCC for a while; I've been a VC++ monkey lately. At any rate, it does seem to depend on specifically what you are doing with the array elements. I haven't figured out exactly what the compiler is doing; sometimes it can tell that the index hasn't changed between references, perhaps depending on the complexity of the expression. Sometimes it can't. I can tell you this, though: this kind of optimization has been the most common for me the last few years.
:)
And yes, figuring out how to work around registry limitations is often the focus of further optimization. If GCC is being smart enough to set up segment selectors, that's great. You still only get 4 segment registers, though (unless you use the stack segment). At any rate, you make me want to go toy with the latest GCC.
Either way, if I look at the compiler output and think, "That's stupid," then I'll use inline assembler to tweak it and make the whole issue moot.
Thanks for your insightful response! (I'd mod you up, but alas, I already posted
Here's my "guide to optimizing":
1) Are you disk I/O bound? You might need to switch to memory mapped files, or you might need to tweak the settings on the ones you have. You might need to use a lower level library to do your I/O. Many C++ iostreams implementations are slow, and many similar libraries involve lots of copying.
2) Are you socket I/O (or similar) bound? If so, you may need to rewrite with asynchronous I/O. This can be a PITA. Suck it up.
3) Are your threads spending all their time sitting in locks waiting for other threads? One, make sure you're using an appropriate number of worker threads optimized by the number of CPUs the host has. If you've already got the right number of threads, this can be a really tough decision. Presumably, the threads are helping your program readability, and trying to rework things into fewer threads is often a *bad idea*.
4) Are you spending all your time in malloc/new/constructor free/delete/deconstructor? Maybe you need to keep things on the stack, use a garbage collector, use reference counted objects, use pooled memory techniques, etc. In the right places, switching from some "string" library to const char* and stack buffers can give a huge benefit. Make sure, of course, that you use the "n" version of all standard string functions (the ones that take the size of the buffer as an argument) to avoid buffer overruns.
5) Are you spending all of your time in some system call? Like maybe some kind of WriteTextToScreen or FillRectangleWithPattern type of thing? For drawing code in general, try buffering things that are algorithmically generated in bitmaps, and only regenerate the parts that change. Then just blit together the pieces for your final output. Perhaps you need to rely on hardware transparency support for fast layer compositing. You might need fewer system level windows so you draw more in one function. Maybe you need to reduce your frame rate.
6) Are you using memcpy as appropriate?
If any of the previous items are true, you have no business worrying about the compiler. However, once you've gotten this far, you can start worrying about optimizing your code line by line.
7) Since you've gotten this far, the line(s) of code you're worried about are all inside some loop that gets run. A lot. They may be inside a function that's called from a loop too, of course. So, a few things to consider. A) You may need to use templates to get code that is optimized for the appropriate data type. B) You may need to split off a more focused version of the function from the general purpose function if it's also used in non-critical areas. This has negative maintainance ramifications. C) Do the bonehead obvious stuff like moving everything out of the loop that you can. D) Look at the assembly actually generated by your compiler. If you're not confortable with this, you have no business doing further optimization.
After looking at the assembler, then you'll know if the following are important. In my experience, they are.
1) Change array indexing logic to pointer logic:
can change to:
This eliminates lots of redundant addition. All of those stuff[i] = val type of statements tend to generate:
mov
Last week I was poking around the web looking for good music theory/ear training software. Seems like a perfect thing for OSS, and in fact GNU Solfeg exists. The non-OSS competition is lots of shareware and crapware. But finding the OSS program was hard and the crapware was abundant.
This kind of stuff is perfect for OSS: it's pretty straightforward (no real innovation required), tends to be loosely coupled, benefits immensely from depth/thoroughness, and the competition doesn't tend to be super-slick. It's lots of the same reasons that WikiPedia is so successful.
Whoa boy, another flame war unto itself! I'm not a DB guy, but I like Postgres. I'm anxiously awaiting bugzillia 2.20 I think it is, with Postgres support. Then, when postgres 7.5 comes out with native Win32 support, life'll be grand. Not that that's what's holding me up, mind you, I have a couple linux servers running, but bugzilla's install looks intimidating and it's not pressing and I have a gazillion other jobs. It was enough for me to get Subversion running, and I failed getting samba configured properly. Now I'm waiting for all the tools (like IDEs especially) to have Subversion integration. Guess that's why I'm a coder and project manager, I'm a lousy admin! I know enough apache and tomcat to be dangerous, enough linux to get around, but diddley about sendmail, bind, and countless other programs. Hell, I can't get the ftp server configured to set permissions the way I want them (whatever the default ftp server is on FC1).
.Net stuff, you know? I want to stick with my IDE of choice, which right now means Netbeans or VC++.Net. BTW, I think VC++ 6 was an amazing product for its time, but I don't really like VC++.Net the IDE, although I do appreciate compiler advancements (better code and more standards compliant). Anyway, I intend to get around to playing with Mono sometime; I'm especially interested in the OSX version.
Fortunately Mono looks to have Postgres support. Now, if they would just ditch monodevelop and work on Netbeans, Eclipse, and KDevelop integration... I mean, competition is good and all, but I don't want to switch to monodevelop just to develop
About choosing your battles, amen, that's why I do use Java--it's the right tool for the job in the places where I use it. Which has nothing to do with Java, but the fact that 3rd party products provide java libraries/interfaces. Perl would actually be better for what I'm doing, but toss in an obscure commercial database with only JDBC and a few java libraries, and poof, there you have it (the Netbeans angle helped a lot too, to be fair).
However, I really really like JSPs/Servlets. I *want* to like JSF, but but but... And EJBs are enought to make a grown man cry. I'm following the MyFaces list, and it looks like good things are coming. MyFaces will become an Apache project, and will integrate smoothly with Struts soon, and there's talk in the air about portlets. I figure that by next spring (march say), a lot of my frustrations with Java-land will be cleared up. Java 1.5 err I mean 5.0, Netbeans 4, hopefully a new JSF spec to clean up probs, and Struts-MyFaces harmony, all given some time to stabalize. Maybe even the commercial Java guys will get their acts together by then--I was dismayed to find that IBM's latest offering only supports old JSP/Servlets, BEA has their own proprietary nastiness, and Sun's proprietary versions of Netbeans (Java Studio Creator, I think) and Tomcat (Sun Web App Server?) are steaming piles of poo when I tried them a couple months ago. Granted, they were beta, but wtf??
Alright, enough chewing your ear off. Later.
I think PHP's previous simplicity and 'under-featuredness' with regards to OOP are actually what made it so popular
:)
You know what, I can respect that. It's not for me, but that's cool. See, I'm primarily a C++ and Java coder. And while C++ is more complex, I find it's complexity *useful*, while Java's is just infuriating (J2EE is a nightmare). Now what I dream about is the day when you can use your choice of language on your choice of VM-Mono, JVM, or Parrot, including libraries etc. Being able to choose your libraries and language independantly would eliminate a lot of language wars, IMHO.
Well, I'm gonna mark you as friend since you seem level-headed and un-fanboyish
Now, admittedly, I'm *not* a PHP programmer. I only peruse annoucements like this periodically in case someday the choice of whether to use PHP or "technology X" lays before me. I don't use scripting languages much, using Perl when I do. But the things you mention as plusses *seem to me* to be pretty common amoungst the scripting languages (as you even say :). Seeing as how you're already a PHP developer, I expect these OOP features to be a great boon for your development. I guess I'm just hard pressed to see the long term PHP niche. Java's got most of the enterprise market and tool/vendor support, Perl 5's probably still got the most hacker/sysadmin users, while Perl 6 is just this side of vaporware they've at least mapped out a clear path to the future, and Ruby and Python have fancy shmancy language features and are pretty mature by now. So is the magic in the secret sauce or what?
Not to be flaimbait (really!), but after reading over the new features in PHP 5, my reaction is, "you mean you haven't had this all along?" Sure, all this is great for existing PHP users, but I don't think users of other languages will care much. New XML support? Now you can define constructors with __constructor() instead of the name of the class!!! Umm... Try/Catch? Overall, it seems they're just Java-fying PHP, in which case you might as well use Java, so it seems to me (unless, of course, you are already a PHP programmer). Perl programmers will just keep waiting for Perl 6, which makes these "new" features seem kinda like your 6 year old nephew threating to kick your ass. People who are looking for a new, hip, language all seem to be going for Ruby, and I can't blame them (heck, I would too if I had time for such things). Hey, can you hold on a sec... 1999 just called, they want their features back...
1) I must be incrementable.
2) I must be dereferenceable.
3) You must get from begin to end in a finite number of steps.
4) The type you get when dereferencing I (I's value type) must be comparable to V.
Because of this, you can use the same find function to search through arrays, lists, vectors, maps, sets, strings, streams, and more, even though none of them inherit from each other or implement a common interface in the OOP sense.
Additionally, there's no complicated syntax for the user of the library:The great thing about abstraction is that it avoids duplication. Avoiding duplication lets you test/debug/prove correct once for greater reliability. Once you wrap your head around this simple example, you'll be surprised how deep the rabbit hole goes.
I'll reiterate GEB, and here's a couple more:
A Brief History of Time, by Stephen Hawking
The Principia, by Isaac Newton (find a good translation)
Origin of Species, by Charles Darwin
Six Easy Pieces and Six Not-so-Easy Pieces, by Richard Feynman (2 books) QED is also recommended. Also, an essay, "There's Plenty of Room at the Bottom."
The Art of Computer Programming, by Donald Knuth
Engines of Creation, by Eric Drexler
Design Patterns, by Gamma et al
I seem to recall that one of Noam Chomsky's books on language is considered a classic, but I don't remember the name. I can't think of any "classic" AI books off the top of my head, and I've never seen a robotics book I liked.
I also recommend some Hard Sci-Fi, but it's a short list:
Contact, by Carl Sagan
Fountains of Paradise, by Arthur C. Clarke
Well, I've downloaded their freebie developer studio (note: I don't know what's different in the for-pay IDE). My company is currently trying to choose between ASP.Net and Java for our next website revision, so I'm looking into these things. As far as I can tell, this is some non-standard extension to Struts, and with the rest of the industry moving to JSF, I don't know if it's got a future or not. However, JSF is currently, uhh, beta shall we say (Sun's IDE is beta and acts like it). Even though I just got it, it seems as though BEA's stuff is a little more battle hardened. But as I've discovered just trying to port a simple test app from Sun's JS Creator to Netbeans/Tomcat, it's littered with non-standard extensions too. ARGH!
Just be confident knowing that most of your basic skills will transfer, and get a normal C++ book. Personally, I recommend Stroustroup's book, and Dietel and Dietel is an oft used text. Most of those "Learn C++ in 24 Hours!" types of books are a waste of trees. Like others have said, it's crucial that you get something that covers STL (both the ones I mentioned will). It's C++'s version of a class library. You'll find it a little thin after working in Java, and that's where platform specific stuff enters the picture. You'll find most of your time is learning a new widget set (presuming you need GUI programming), or socket APIs (if you need 'em), or platform specific threading/synchronization etc.
Overall, coming from Java, you won't expect or know how to use fancy language features. That's Ok. Write C++ like you would Java (mmm, careful about that memory leak though). This assumes you're doing app development where you can afford to make every function virtual, every object a reference, and have accessor functions for every member variable. If that's not what you're up to and you need write tight C++, well, forget Java while you learn C++. Make sure you get your memory models straight--stack vs heap, by value and by reference, pointers vs reference, iterators vs pointers, reference counted, and on and on. You have to get the now classic "Effective C++" books by Scott Meyers. That's the best way to avoid classic stupid C++ mistakes. You'll find it a bit heavy going at first, but until it makes sense to you, you're probably writing bad C++. Good luck.
Just wanted to point out that NetBeans also has this feature in the recently released 3.6. You don't have to wait until an "official" Eclipse release; you can use a stable NetBeans now. Obviously, I like NetBeans, and I think they've been making leaps and bounds of progress recently. I'm really looking forward to 4.0 with the Ant based project system. Then, you should be able to work in either NB or Eclipse, or Emacs or whatever floats your boat. Hooray for competition!
Also, for those saying this leads to bad coding style, I'm hoping that the forth-coming refactoring features in NB 4.0 will make this much less of an issue (don't know about Eclipse equivalent feature). Got a junior dev who likes to make really really long code blocks? Refactor into saner functions with a little help from your IDE. Since I'm about to get some junior devs dumped on me, I hope it does work out...