Jump to content

rainwarrior

Members
  • Posts

    33
  • Joined

  • Last visited

Everything posted by rainwarrior

  1. Whatever it is, X has become Y, the moon shines in the day, and all the water turns to blood. Also, we're up to: . T . X X I T Y
  2. I like the idea of . and X being vowels and consonants, but how do you justify the Y? The Y at the end of "eternity" is a vowel. Excepting the Y situation, "eternity" is the only word I could find that fits that vowel/consonant pattern. If you give up on that, though, there's a lot of fun possibilities. Here's a few: iniquity capacity chastity divinity biscuits ****pits infinity dynamite fatality gunsmith humanity recruits impunity mesquite vitality nobility rarebits totality urbanity velocity transits opposite debility atrocity circuits
  3. wut? Pretty much every FPS will eventually give me a headache and nausea. Some just take longer than others. I suppose if I suffered from Parkinsons disease, it could be from my mouse control, but it more likely has to do with my brain and vision. Every first person game deals with the problem that your monitor takes up a very narrow part of your actual field of view. If they rendered a field of view that matched that, it would be very hard to see the world around you effectively. Like, if you make a tube with your hand, and put it in front of your eye, you can probably see all of your monitor through it, but try to imagine going through your whole day only seeing this. So the field of view that is rendered is artificially expanded to help your awareness of the game world, but you end up with this disparity between the 3D field of view that is being simulated by your monitor and the actual field of view that your monitor takes up. This is problem inherent in the genre; it is not really something that better camera code can fix. It might be something that a bigger monitor can fix, though. The move to widescreen has helped this problem a lot, I think. It doesn't bother everyone, but it certainly does bother a lot of people.
  4. How do you challenge other people's brutes? http://bradyar.mybrute.com
  5. Why would you believe this?
  6. I loved Braid. I hadn't felt that satisfied by a puzzle game since Chip's Challenge. Is there new stuff in the PC version? I played it as an XBLA game.
  7. The letter
  8. Blackthorne turned out alright.
  9. I'm just a developer that really likes the PS3. I don't work exclusively on it. Though, I guess a lot of my posts here have been about the PS3. I'm really excited about Worms though. I used to play Worms 2 a lot in high school.
  10. My reasons were: 1. Emulate SNES games. 2. Have fun programming on the Cell.
  11. The "software emulation" version is only half-software. They still had to put the PS2's graphics chip in there. When they took that out of the more recent models to lower the cost a little, they gave up on backwards compatibility. I have one of the old 80gig half-software versions, and I'll actually say that the backwards compatibility is really good. I've played through a lot of PS2 games on it, and the only one it had a problem with was Rampage Total Destruction, and when I finally played that on a PS2 I realized it was trying to do me a favour. Noby Noby Boy is a lot more fun than it should be. I've spent a lot of hours on it, and I'm not sure why. Well worth $5. Has anyone mentioned Pixeljunk Monsters? That game was really, really addictive.
  12. 45Hz actually isn't a framerate unless your renderer is really weird. A monitor refreshes at 60Hz. There are no subdivisions of this, it just refreshes 60 times a second. Anything you render has to be displayed during a refresh, which means that any framerate must divide 60 by an integer. 60Hz, 30Hz, 20Hz, 15Hz, 12.5Hz, 10Hz... If something is displaying 45fps, that means that every two frames, one is a 30Hz frame and one is a 60Hz frame, which is wonky. It can happen under certain conditions, but it's probably not a sign of a healthy renderer. (Or the vertical retrace synch is turned off because you like higher FPS numbers more seeing half of the last frame and half of the next frame on your screen at the same time.) Anyhow, using alpha testing (1-bit alpha) instead of alpha blending gets you a big render savings (blending is slow) and also sorts properly automatically (because it can use a depth buffer). If you really want blended hair that doesn't look wonky from some angles you also have to break it up into little pieces and make sure the draw back to front (either via many draw calls, or with a dynamic vertex buffer). Alpha testing is just faster to render and easier to make for an artist.
  13. I'm not advocating BASIC as a good or bad starting point. It was just an example. I don't think starting language is a big factor in the long run.
  14. Well, it was kind of a late reply anyway. The whole comparison was kind of bogus, too. We could start with the fact that both languages can include external libraries. Just because Haskell has list primitives doesn't really make them any more useful than, say, STL templates. This isn't the biggest problem with the comparison though. C++ offers a tremendous ability to adapt the language to your own style. Far beyond C's preprocessor directives (which are quite powerful at transforming the look of the language, see the IOCCC for some silly examples), C++'s classes, templates and operator overloading can radically bend the language to your needs. This is one of C++'s great strengths, and is something that not many languages even come close to. I can't really speak to which language would be best to learn first. Personally, I started with BASIC. The reason I started with BASIC was because I found a really, really good series of books on it (made by Osborne) at my school library, perfectly suited for children. I don't think BASIC is a particularly great language, and it left me with several roadblocks when I finally came to learn C and assembly, but in the long run I don't think it mattered. I learned BASIC because it was what those books taught, and this was the right thing to do for me. If I had tried to learn C from a bad teacher instead of BASIC from a good one, I might have failed and given up. Learning to program is what matters, the starting language is such a small factor, I think, compared to the choice of teacher.
  15. Krezack, your cut and paste C++ quicksort is way longer than it should be. The entire "median finding" stuff (more than half the code there) was not present in either your Haskell or Python implementation. (Drop the "findMedianOfMedians" line, and the two functions below the main quicksort.) If you're going to make comparisons like this, at least make them remotely fair. That said, using the leftmost element as a pivot is a terrible implementation for a quicksort. Feed it an already sorted (or even mostly sorted) list and you'll get worst case complexity. This is tangential to the argument about which language is more elegant, or whatever, but it's an important thing to know that this canonical example of Haskell's concinnity is an awful quicksort.
  16. Nonsense. I could easily divide any of you.
  17. I got hired at the start of last year by Obsidian. Here's a rundown of my games programming career prior to getting the job: 0. At age 4 my family got an Atari ST, beginning my lifelong interest in video games. 1. I started learning BASIC pretty young, maybe 6 or 7 years old. It started when I found some kid-oriented BASIC programming books in my school's library. (There was a series, I think by Usborne, with cartoon monsters and stuff; I don't know if they're still around, but they were awesome.) When I brought it home, my dad found a disk that came with the computer that had ST BASIC on it, and I went to work. I learned by copying listings out of books and magazines, and playing around with them. 1. During my elementary school years I wrote 20 or so very simple games (stuff like text adventures, bowling, space invaders, etc...) on my Atari ST (in ST BASIC and the compilable GFA BASIC), and later a 286 IBM compatible in QBASIC. 2. At some point I came across the Squaresoft RPGs (FFIV, Secret of Mana, FFVI, etc.) and was inspired to want to make an RPG myself. I started trying to make a square-tile engine for an RPG in QBASIC. (This is around grade 8 or so). 3. A year or so later I discovered that there was no way to do a masked blit in QBASIC with any kind of speed, which seemed pretty important. I tried moving up to Visual Basic, but I couldn't figure out how to do sprite/tile graphics there either (I tried various things, like putting my sprites in image boxes and moving them around frame by frame, which didn't work too well). At that point I picked up a "learn C++ in 12 easy steps" book, and downloaded DJGPP. 4. From various tutorials I could find on the internet I learned about Mode 13h VGA programming, keyboard interrupts, and other things relevant to game programming, and put together a few simple VGA games (starting with pong), and even some very simple 3D graphics (i.e. points, lines and spheres) based on what I'd learned in high school algebra. 5. Once I had some of the basics down I went back to making an RPG engine, this time with 3/4 perspective tiles (i.e. Super Mario RPG style). Around the same time I discovered a freeware RPG engine effort called Verge, and became a part of that community. I made a character editor tool for Verge (which doubled as the character editor for my own engine). I worked on this project on and off for a long while, had made a working map editor, and had even learned enough assembly to rewrite all of the tile blitting code in pure assembly. 6. Eventually that project was abandoned, and when I finished high school I took a detour by going to university for music. While doing this I put my elective credits into a computer science degree. When I finished my music degree, I stayed on to finish a computer science degree as well. During this time I took a course in computer graphics and was really hooked. I put a whole lot of time into that course, and learned a ton. I also joined the competitive programming team (we competed in the ACM ICPC), and there I learned a lot about algorithms, coding on a team and under a deadline, and got a lot of good coding experience. 7. After graduating, I was looking for a job for about six months. During this time I tried to learn everything I could about graphics that I didn't know yet. I wrote simple raytracers, and many 3D graphics programs, put together some demo stuff I could use with my resume, and I started putting out applications everywhere I could. I probably sent out a few hundred resumes. I didn't get any responses for the first while, though over time having more and more to show in terms of demos I think, eventually I was getting to about one phone interview per week in response to the resumes I was sending out. Obsidian was about the 10th interview I had, I think. So, that's how I got into the industry. Lots and lots of practice over the years, and then lots and lots of resumes when I got out of university. I think having a demo or something to show really helps. Something I didn't realize while I was looking for a job; a lot of times not getting called back is more about what the company needs at the moment than the quality of your application. There were times where I felt that maybe I wasn't valuable enough to get the job I wanted, because I got no response at the time, but many times since I have been hired I have gotten calls and e-mails out of the blue, places wanting to interview me based on the resume I'd send them 6, 10, 15 months prior. Timing for the company is a huge deal, and you can't predict that. My advice, if you want to get into the industry, is to make stuff. Make little games. Make mods. Make graphics demos. Learn as much as you can, and if you read about something make sure to try it out. Write lots of simple programs; figure out the minimal workings of a game engine. Get experience working on a team by getting your friends involved.
×
×
  • Create New...