Beyond_Repair

Members
  • Content count

    183
  • Joined

  • Last visited

Community Reputation

116 Neutral

About Beyond_Repair

  • Rank
    Member
  1. Minecraft Servers

    Yupp, it's easy to run a temporary Minecraft server for you and some friends while you're playing. Just be "democratic" and let the person with the best connection and computer of the group host it. ;-) To be sure, there are presumably way more servers than on the official list, being temporary private servers for the above purpose.
  2. Agree Windows could do with more logical categorization. It's not just the start menu and 3rd party software - it's also the default folders given by Microsoft such as C:\"really long path"\My Pictures (all in localized spelling), or just C:\Program Files without any further categorization.. Disclaimer: Did not use Win 7 yet.
  3. Minecraft Clone

    Hehe not much required to look better than Minecraft ^^ Though I suppose this statement may not be true some months from now when Minecraft creator has got his company up and running.
  4. extended ascii (, ,...)

    Like the_edd says, it depends entirely on the font/font library you're using. The first obvious thing to check is whether said font library and font claim to support extended ASCII, and if so if you've enabled it (have set the correspond character set or some such). I can't help with Win32 API specifics I'm afraid
  5. multiplayer card based game like hearts

    I suspect Hearts was developed with the Win32 API, which is unfortunately quite aged. On the other hand, it is a C API, so if you are a C programmer its concepts won't appear alien to you. The more modern tech would be to write a .NET application, regardless of selected language. If going that route, try downloading Visual C++/C# Express and mess around with it to see if you like it. Or, you can write something else than native Windows app by picking some GUI toolkit library (of which there are plenty for C).
  6. Stuxnet

    The scale of Stuxnet has been estimated to require national funding to accomplish. That said, national funding does not automatically imply CIA...
  7. Uh, depends who you are going to work for. C/C++ code bases are significant. Especially a factor in large, slow companies that in no way are going to say: "Let's rewrite our proven reliable C/C++ engine of X million lines of code to another [for that engine] unproven language". This is probably the biggest reason that C/C++ will continue to be huge game programming languages for many more years. Note that it means that if programming a game on your own the above is much less relevant, and then the technical details of C vs C++ vs C# vs Java become more of an actual factor to consider. Not going to elaborate on that though; there are a 1000 threads on the subject for you to look up. :-) If you want to finish a game, I'd recommend C# or Java. However, if you want to eventually know all four languages, I'd recommend C++ as it is the by far the most difficult of them, and with C++0x (the newest version) most programming paradigms and twists you'll see in the others are represented in C++. [Edited by - Beyond_Repair on November 26, 2010 7:02:21 AM]
  8. C++: switches -- O(1)?

    Quote:Original post by ravengangrel Quote:Original post by Element of Power It would speed up my code considerably if it did. Otherwise, I'd have to resort to making each "case" a function reference stored in an array that I access with the enum values... not too pretty... If I have understand correctly, you have a performance problem with a switch statement (inside a loop, I'd hope). Are you sure the problem is in the switch code? Why don't you try to tell us what's your real problem (what you try to fix making switch statemens a bit faster)? Quote:Original post by Beyond_Repair So what the did the compiler do? It generated the code ptr = &MAILBOX[i & 5]. If you look at it, it's in a sense more safe than the UB code I proposed, as it won't randomly corrupt data somewhere else than the array with out of bounds access. Wait, what? so, for i == 1, it made ptr = &MAILBOX[1]; then for i == 3 it made ptr = &MAILBOX[1] This seems quite wrong to me, maybe there's something I didn't understand... I'm dumb. I obviously meant 2^5 - 1 = 31 instead of 5... Thanks for proof reading. :)
  9. C++: switches -- O(1)?

    Oh compilers are pretty clever these days. For an embedded system I had the following code written: switch (i) case 0: ptr = &MAILBOX0; break; case 1: ptr = &MAILBOX1; break; .. case 31: ptr = &MAILBOX31; break; } MAILBOXn is a register (essentially a volatile global variable in a C context) for CAN bus communication on a certain TI DSP. Now, if it was guaranteed these registers were adjacent in memory it would be possible to index them like MAILBOX[i]. Now, there is no such guarantee from the hardware specification (although for this particular implementation it was true) so it would be undefined behavior to implement it like that. So what the did the compiler do? It generated the code ptr = &MAILBOX[i & 31]. If you look at it, it's in a sense more safe than the UB code I proposed, as it won't randomly corrupt data somewhere else than the array with out of bounds access. Bottom line is that it's redundant to manually prematurely optimize a switch statement; check what the compiler has done first. [Edited by - Beyond_Repair on November 1, 2010 5:08:41 AM]
  10. I'm stupid, are u too?

    Quote:Original post by Zahlman Quote:Original post by Beyond_Repair Quote:Original post by Talroth I also don't know if you can really say it improves readability to be able to throw a whole lot of things in a small space/fewer lines. That's why I added the "and program meaning hopefully improved - otherwise don't do it" disclaimer... What I mean in particular is clever for loops such as: for (int i = 0; f(i); ++i); That one is pretty readable IMO: f is evaluated for 0.. until f turns false. The semicolon indicates the interesting stuff happens in the header. However, the same semicolon is responsible for lots of bugs where people have no idea why nothing happens in their loops (with actual bodies). Of course, you could just write: for (int i = 0; f(i); ++i) {} :) That was my point. The form with the semicolon just causes needless trouble. But now since it's here in the syntax and won't go away we may as well use it if it's actually more readable (if slightly).
  11. I'm stupid, are u too?

    Quote:Original post by Talroth I also don't know if you can really say it improves readability to be able to throw a whole lot of things in a small space/fewer lines. That's why I added the "and program meaning hopefully improved - otherwise don't do it" disclaimer... What I mean in particular is clever for loops such as: for (int i = 0; f(i); ++i); That one is pretty readable IMO: f is evaluated for 0.. until f turns false. The semicolon indicates the interesting stuff happens in the header. However, the same semicolon is responsible for lots of bugs where people have no idea why nothing happens in their loops (with actual bodies).
  12. Storing floating point alpha values

    Of course, you can try 16 or 24 bits fixed point. Otherwise you'll need some sort of compression [I presume someone else will reply with this]. Although I'm not sure you're doing everything correctly, the sentence "Even worse with float values i need the uint8 also which results in a total of 175 mb memory usage." is quite weird.
  13. Unfamiliar C construct

    This is one thing I do like about C(99 only? can't recall if it's in C89) It leads to more readable header files and modular code.
  14. I'm stupid, are u too?

    The semicolon body and assignment instead of equality operator problems are quite common; in fact so common I think that if C/C++ language could be redesigned the possibility for that would be removed by modifying syntax or semantic constraints. Sure it's cool that 1 extra line of code can be removed (and program meaning hopefully improved - otherwise don't do it) by using such syntax, but the cost of fixing such bugs out weights reduced coding time/increased understanding. It's probably a good idea to have these things on a check list for mistakes to look for, when one rips his/her hair out searching for a (mistakenly looking) completely illogical bug.
  15. SDL using surface and pixel alpha?

    IIRC I considered this particular problem of surface alpha vs. pixel alpha 3-4 years ago and it wasn't possible at that time. I don't know if it's any different in SDL 1.3... Of course, you could manually manipulate surface pixel buffers but that's kinda wasteful and we have modern GPUs for a reason. So yes, I think using OGL under SDL is the way to go (it would also help in other cases).