Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Everything posted by JoshM

  1. I've always wanted to take something like this: http://www.soekris.com/net4826.htm And make a large cluster of them. Sounds like fun :) Of course afterwards I assume that I would discover it to be useless...
  2. This is more than you want to spend, but for a little more than what you've got so far ($299 + s/h) you could pick this up: Dimension 2400 Series Intel® Celeron® Processor (2.40GHz, 400 FSB) Operating System Microsoft® Windows® XP Home Edition Memory 256MB DDR SDRAM at 400MHz Keyboard and Mouse Bundles Dell Quietkey Keyboard and Dell 2-button Scroll Mouse Monitor 17 inch E773 (16 inch viewable) Conventional CRT Video Card Integrated Intel® Extreme Graphics Hard Drive 80GB Ultra ATA/100 7200RPM Hard Drive Network Interface Integrated 10/100 Ethernet Modem 56K PCI Data Fax Modem Adobe Software Adobe® Acrobat® Reader 6.0 CD or DVD Drive Single Drive: 48x CD-RW Drive Sound Card Integrated Audio Speakers Dell A215 Speakers Digital Music Musicmatch® Jukebox Basic Digital Photography Photo Album™ SE Basic Limited Warranty, Services and Support Options 90 Day Warranty, 90 Day At-Home Service, and 90 Days Technical Support Dell 720 Color Printer Qty 1 ree Dell Color Printer 720 Unit Price $0.00 Hardware Support Services 1Yr Ltd. Warranty- Advance Exchange TOTAL:$299.00
  3. JoshM

    Real? Or not...

    Quote:Original post by Ronamitri I think I don't have to say that one cube map of 4kx4k is huge. 384 MB. It's 128MB more than that consoles have. And if this is real-time, I don't want fps to be included, but spf (sec. per frame) :) Don't forget about texture compression, massive memory bandwidth, and lots of SIMD accelleration.
  4. JoshM

    good career?

    Quote:Original post by HairyTroll Actually, game programmers work for peanuts. They do. Here's how you work it out: -snip- If you work at a place like this you should QUIT. I make a decent wage, my company has a 401k with good matching, my insurance is rock solid, and I'm not required to work more than 40 hours/week except for a week or two a year. Don't get me wrong - every office has its ups and downs. But the workplace that you describe is a dying beast IMO.
  5. JoshM

    RTTI: Good or bad?

    RTTI using the compiler is nasty. If you do it yourself it's actually not that bad and can be very helpful. However, the overhead and complexity of it sort of demands a certain project size and need in order to be worth the trouble. The Doom3 engine uses this extensively, for example, as does the Tiki engine. Doom3 defines a class called idTypeInfo. That class has a pointer to a function of type "void idClass::Spawn()". This enables you to say, in script or when loading map data, "spawn BadGuy" (to spawn a monster) or "give BigGun" (to give youself a big gun) or "removeclass idWeapon" (to remove all weapons from the game). It also makes it possible to iterate the base classes when doing load/save. And it comes in very hand when combined with a messaging system - you can declare a std::map in the typeinfo that says "when you recieve a message called this, here is the function you call for this type".
  6. JoshM

    Programming Paralysis.

    We call it "analysis paralysis" around here. You're right in that the only way to get around it is to "just do it" (AFAIK). I've had the same problem for a while now, and I feel like I'm starting to get a grip on it finally. I'm finding it much more productive and rewarding to analyze code after it's been written and finished rather than before starting (pretty much what SiCrane is suggesting, though I wouldn't go as far as to say I'm practicing XP). Then next time I begin it's easier to know the practical uses of design patterns, structural idioms, etc... Basically, "An expert is someone who not only knows the right way to do something, but a thousand wrong ways." From experience :) Another thing that I've found very helpful is gamejam-style events. For example, ALGDS. EDIT: I like to think of it this way... at some point your problem stops being "how do I write a good WHATEVER" and becomes "how do I write ANYTHING". Luckily the second problem is easy to solve: just start typing :)
  7. JoshM

    No Branching Zone

    Quote:Many of them were based on assembly language details (especially addition and subtraction with carry) which cannot easily be translated to C. It practically never made the code any easier to read though.. I see. I'd like to explore ways that are more suited to C++. I suspect it can make the code easier to read and maintain, as in the state switch/virtual case. Unfortunately I don't have the patience to go off reading pages of asm looking for gems :)
  8. JoshM

    No Branching Zone

    Quote:Original post by twanvl For real development I would say it's useless, the branches are there for a reason. I know they exist for a reason. I'm not saying they should be outlawed or that they're useless. I've just gotten the impression lately that we might be better off considering other alternatives first. I'm still not getting my meaning across very well... First of all, I started thinking about this because some of the upcoming processors that games will be targeting may suffer a substantial stall penalty from mispredicted conditional branches. So I started thinking that a branch here and there isn't going to make any difference - you have to code from the beginning with the mindset that "branches can be expensive when used en mass". So then if I open up any random function in the codebase that has an "if" or "switch" in it, how can I rework that so that the if/switch is replaced with an unconditional branch or a simple fetch? I don't see this as premature optimization. I see this as coding with the hardware in mind. I'm not talking about tuning bits of code - I'm talking about using language constructs that generally favor faster code. I dunno, maybe it's pointless. Just a thought and an interesting problem imo :/
  9. JoshM

    No Branching Zone

    Quote:Original post by doynax Go read some optimized assembly code from the Pentium era instead. Huh? Instead of what? If I'm bothering you feel free to avoid my thread ;) Seriously, though, I'm not looking to write assembly code. Quote:I've seen code that goes to ridicilous lengths to avoid branching instructions. Well, ridiculous lengths may be too far. On the other hand - to implement multiple inheritence in ASM you'd have to go to ridiculous lengths. But in C++ it's a keyword or two.
  10. JoshM

    No Branching Zone

    Quote:Original post by twanvl You could use arrays of function pointers: *** Source Snippet Removed *** Yea, this is exactly the kind of thing I'm talking about! I'm really interested in how far this approach can be taken and how useful it is.
  11. JoshM

    No Branching Zone

    Quote:Of course I missed the most obvious answer. The word "game" generally implies success and failure conditions. Hmmm, I don't think about it that way - to me game implies only "conditions". Not necessarily only success and failure. There may be degrees of success and failure. Either way, let's say I have a guessing game where you have to guess my number. I could do it like this: const char* responseCorrect = "Correct!"; const char* responseWrong = "Wrong!"; int i; const char* responseTable[10]; for( i = 0; i < 10; ++i ) { responseTable = responseWrong; } responseTable[ randomNumberFrom0To9 ] = responseCorrect; int guessedNumber = getGuessedNumber(); cout << responseTable[ guessedNumber ]; Admittedly it's a lame and contrived example, but it's possible at least :)
  12. JoshM

    No Branching Zone

    Updated original question to reflect clarifications based on feedback so far :)
  13. JoshM

    No Branching Zone

    Quote:Original post by igni ferroque It would be impossible to do anything that requires a program to act on the outcome of a previous operation. It would be possible to implement certain things with number transformations rather than explicit branch instructions, but then you'd just be implementing branching on a more abstract level. That's not exactly true. For example, here's a branch: enum State{...} state; switch( state ) { case STATE_A: ProcessStateA(); break; case STATE_B: ProcessStateB(); break; etc... And here's a non-branch: State* state; ... state->Process(); I wouldn't say that the second example is "a more abstract branch." It's a different paradigm. And if Process is a virtual function, then what happens when you call state->Process() depends entirely on the concrete class that state points to and thus depends on the result of a previous operation (ostensibly, assignment).
  14. JoshM

    Thoughts on error handling?

    At first I really hated the way error handling in Win32 was done. Then I started doing Xbox development and actually "got it", and it's really not that bad. Also, from what I understand (correct me if I'm wrong), C++ exceptions are a bad idea on consoles because it can cause the compiler to add quite a bit of exception handling code at compile time. Anyway, many Win32 functions works like this: HRESULT hr = Win32Function(); ASSERT( FAILED(hr) || SUCCEEDED(hr) ); if( FAILED( hr ) ) { handle error; } etc... Technically an error is < 0, but it's not just some arbitrary value that varies from function to function. Sure, it's not perfect. But it's actually not bad at all IMO, having used it extensively. An HRESULT can be deciphered like this (from winerror.h) // // Values are 32 bit values layed out as follows: // // 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 // 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 // +---+-+-+-----------------------+-------------------------------+ // |Sev|C|R| Facility | Code | // +---+-+-+-----------------------+-------------------------------+ // // where // // Sev - is the severity code // // 00 - Success // 01 - Informational // 10 - Warning // 11 - Error // // C - is the Customer code flag // // R - is a reserved bit // // Facility - is the facility code // // Code - is the facility's status code And there are macros to compose/decompose HRESULTS (though I never actually have to use these): MAKE_HRESULT(sev,fac,code) HRESULT_SEVERITY(hr) HRESULT_FACILITY(hr) HRESULT_CODE(hr) If you're going for something more OO then return values are probably less useful.
  15. JoshM


    I've had various problems when not explicitly testing the high bit - sometimes the low bit would be set for a while when the high wasn't (i.e. the key gets "stuck" when it shouldn't). It may have been because I was debugging or something like that, but either way I recommend you just save yourself a potential headache and test the only useful bit. Your mileage may (and evidently does) vary :) Just speaking from my own personal experience. The code is easier to read when not testing the bits so if it works for you then go with it.
  16. JoshM

    Video Game Music Goes Mainstream

    Soundtrack for "Castlevania: Symphony of the Night" = teh win. Oh and any Blizzard game.
  17. JoshM


    Also, here is reference if you don't have it: MSDN: GetAsyncKeyState
  18. JoshM


    GetAsyncKeyState simply tells you whether a given key is pressed down at the instant you call the function. The return value can't be trusted or used as TDragon suggested, I believe, since it will return a value with the highest bit set if the key is down, and *sometimes* will return a value with the lowest bit set if the key was pressed after the previous call to GetAsyncKeyState. But you can't trust that lowest bit because of multitasking. I believe you should do: if( GetAsyncKeyState( VK_LEFT ) & 0x8000 ) To determine if a key is down at that instant. If you're trying to get typed input (like somebody typing in their name) then you shouldn't use GetAsyncKeyState.
  19. JoshM

    good career?

    I started programming out of pure interest about 15 years ago when I was a freshman in high school. Before that I'd toyed around with Atari BASIC and some games, and when Doom and Quake came out my interested turned to obsession. I never went to school for it because I didn't want to. As it turns out I was driven enough (i.e. I was compelled to do it because I loved it) that I didn't need to go to school. I've been getting a paycheck as a game programmer for about 7 years. The honeymoon is definitely over - sometimes I hate this job. But overall it's very good to me. I take great satisfaction in problem solving, and so I take great satisfaction from my work - somtimes. Other times I spend days on end screwing around with documents and emails and source control problems and blah blah blah. If I didn't still enjoy it overall I would quit and pursue photography or music. The thing that really makes this job worth it is the people you might meet in the process. I've been lucky enough to have personal and professional relationships with some wonderful people. Some are wicked-smart, others are just good people. A few are both. A few others just suck a lot :) My enjoyment of this CAREER is very separate from my enjoyment of this WORK. I always love programming. Sometimes I hate being a programmer. It all depends on where I work and who I work with - but not so much what I work on. My opinion, based on my experience and what I've learned from others in the past 7 years, is: If you really want to be a programmer and you love the idea of working on video games - then go for it! But don't force it because you will ultimately be disappointed and worse for the wear.
  20. JoshM

    time travel is not possible

    Quote:Original post by kingnosis Time travel is impossible because there's nowhere to go. The past and the future don't exist. We have memories of the past and expectations of the future, but the past and future don't exist as places you can go to. There is only right now, which we live in seldom enough. We fool ourselves into believing in a past and a future because we spend so much time thinking about them. But I wonder if it's possible to visit flatland and somehow turn the paper inside out or project it onto a wall so that space is distorted in a way that creates the effect of time travel? (pardon the horrible analogies)
  21. JoshM

    time travel is not possible

    Everybody knows that time travellers come from post-apocalyptic America and their goal is to spend a few weeks collecting old computers from the 70's but do it in the 90's and prognosticate about the future on internet forums while they're sitting around waiting for the flux capacitor to recharge :) John Titor said so!
  22. This is something I've wondered about also but I've never put fingers to keys on it. I'm pulling this off the top of my head, but how about something like this: class AbstractAttribute { public: int toInt() const = 0; string toString() const = 0; ... }; template< class TAttribyteType > class ConcreteAttribute : public AbstractAttribute { TAttributeType val; public: ... }; string ConcreteAttribute< int >::toString() const { return IntToString( val ); } etc And use list< AbstractAttribute* > to store them? Or create a NamedAttribute class and put it in a map?
  23. JoshM

    Eternal damnation.

    I consider myself agnostic because the proof that god does not exist is no more conclusive than the proof that god does exist. I abhor organized religion. That said, the Unitarian church is about the only religious establishment that I believe deserves a chance. http://en.wikipedia.org/wiki/Unitarianism As far as the original question goes... why would god send anyone to hell for eternity? So you'll be socially divisive and dedicated to the establishment while you're on earth, of course ;)
  24. JoshM

    Can we realy let everyone live?

    Quote:Original post by tstrimp I don't think HIV is killing nearly enough to effect the population on a global scale. Please someone correct me if I'm wrong. 3.1 million people died of HIV & AIDS in 2004. 39.4 million people were living with infection at end of 2004, up 4.9 million from the year before. 75% of worldwide HIV/AIDS related deaths happen in Sub-Saharan Africa, where the death rate increased 57% from 1997 to 2002. About 1 in 9 people in Africa have AIDS. And it's not slowing down. So, no - right now it's killing 3 mil a year. But give it time, it's just getting started. Just think about that for a second... 3.1 million is slightly more than the entire population of the state of Iowa. All those people died last year. 4.9 million is New Mexico + Mississippi. All of those people are going to die in 7-15 years. Until then they can spread it to anyone. 4.9 million new people got this fatal and communicable disease, and ZERO were cured.
  25. JoshM

    Metroid Prime Modelling Questions

    Quote:Original post by Kelly G Ah, but showing animation stored in a file is also "programatic," That's not what I meant. "Programatic animation" implies that the animation is created entirely from the code and doesn't use any hand-created assets. Quote:Which method is easier depends on what your model file and graphics library support. Just about any model/anim file and graphics library will support animation. Quote:If you were writing from scratch, I would think morphing would actually be easier to impliment. Possibly. I'm thinking about it this way (I'm a programmer btw)... here's the item on my task list for doing it with morphing: - Design and implement system for skeletal animation playback and blending that also supports arbitrary morph targets. And here's the item for doing it without morphing: - Design and implement system for skeletal animation playback and blending. Which sounds easier to you? Quote: The models having the same number of vertices would be easy to accomplish because the sensible thing to do would be to create the enlarged gun model directly from the regular gun model in your modeling app, using a scale tool or something. If you do this you will surely have the same number vertices listed in the same order. You can then just apply the simple math to get your results. Also, why would you want to create/store/load an entire copy of the mesh for the morph targets when you can just create/store/load a single animation that has a single scale keyframe? Seems a lot simpler to me. Anyway, you may be right - I don't know. But my experience has taught me that it's *always* easier to just do the simplest thing possible. In this case, it's much more simple for everyone involved to just make a short animation that scales the gun up. But of course that gets more complicated if you have to support all the fire animations when the gun is large and small. It's been a while since I played Prime (loved it, finished it) but I don't think that was the case.
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!