Jump to content
  • Advertisement

JoshM

Member
  • Content Count

    64
  • Joined

  • Last visited

Community Reputation

128 Neutral

About JoshM

  • Rank
    Member
  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. I've really been wondering lately - imagine you are writing a game with C++ and you have no "if" or "?:" - or any other method of branching. What would be impossible, if anything? And what would be slower? I suspect some things will become faster and easier to understand... EDIT: Loops are allowed as long as you don't cheat and use it as an if, like: for( ; testCondition ; ) { if-branch } for( ; !testCondition ; ) {else-branch) EDIT part 2: Ok, let me simplify this - what if you can't use "if", "?:", "case", or any other kind of hackery that simulates those operations? EDIT part 3: My terminology was wrong - I mean "CONDITIONAL branch." (thanks doynax) From wikipedia: "A conditional branch is a basic logical structure. It resembles a fork in the road; there are at least two paths that may be taken and one must be chosen." A function call is not what I'm talking about because there is no logic to evalute in order to determine which function to call - even a virtual function is (I believe) just a lookup into the vtable, right? [Edited by - JoshM on August 11, 2005 7:59:05 PM]
  15. 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.
  • 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!