Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Mumbles

Members
  • Content Count

    691
  • Joined

  • Last visited

Community Reputation

32 Excellent

About Mumbles

  • Rank
    Advanced Member
  • Birthday 11/26/1986

Profile Information

  • Gender
    Female
  • Location
    England
  • Interests
    No

Recent Profile Visitors

13,631 profile views
  1. Thanks! Will try this. And thanks, YouGroove, for originally suggesting it. Oh, I see what YouGroove was saying now. I thought he was saying to use Franck's code, but with three component vectors as the parameters. I feel a bit silly now...
  2. There's no point using a 3 component vector for 2D calculations because the Z will never be used. It's the same reason we don't usually use 4 component vectors for points in 3D space.
  3. Shame, I'd have loved to have played this by the looks of it... Especially if it had multiplayer in it... The lack of shadows -- trust me, it's not important, you don't really notice it
  4. So uh, doesn't actually provide any protection at all?
  5. Mumbles

    Dead PC

    Is it plugged into a surge protected outlet socket (or extension board), or do you have an inline surge protector between the power cable and the PSU's input socket? If you have any surge protectors, look for the indicator lights - what do they show? Fault or healthy? Given the green light inside your case, a surge sounds unlikely, which is good as this means you're more likely to be looking for a single (faulty) component rather than replacing the whole lot. Try power supply first, because it's cheaper and easier to replace. Was anyone else at home? Any power surges or spikes reported
  6. Thinking about it, it's probably a better idea to have the "big" function using a Vec16 instead. I assume Vec9 and Vec16 still exist? The only difference would be that if there are more than 4 elements you may wish to print an index number rather than a letter. Also, in case of a Vec9, you may want a new line every 3 elements, and for a Vec16, every 4 elements, just to make it more readable.
  7. Copying and pasting similar functions like this can lead to problems, particularly later when they are more complex. You'd do better to roll them all into a single function, particularly if you want to do more complicated things with your vectors later. This is a general programming thing //Header (Kept the same) std::string String(Leadwerks::Vec2 vector); std::string String(Leadwerks::Vec3 vector); std::string String(Leadwerks::Vec4 vector); //CPP (New function added at top. It's not declared in the header, so it's invisible outside this source file) std::string VectorT
  8. Why has he got a deformed uh... sausage, sticking out of his head?
  9. It's sounding quite impressive as it is. I can't wait to see this develop into something big. Glad to see that LE 2 isn't dead...
  10. Your intel HD 4000 is probably the problem. It should work on that (you may need to upgrade your drivers), but there may be a load of rendering bugs. Intel isn't that great when it comes to Open GL, which is what Leadwerks uses. The best intel can offer for graphics is almost as good as a load of doggy doo doo...
  11. Yeah, because C++ doesn't have like 100 million+ free libraries available to reuse... So is C++... Both languages are just methods of writing a very long sequence of events that you want the computer to perform. One uses lots of meaningful symbols to reduce how much you have to write, and the other prefers a more "verbal" style of writing that long list... The symbols are quick to learn, like when you learn numeracy at school, it's very quick to learn what the + sign means. Before long you know that 123+456 means 579. The symbols in C++ are the same, once you've seen them a
  12. I use winsock2. I'm happy with the performance but the lack of OO may turn some people away from using it. One thing I'm confident about is that it's built in to the Windows OS, so it's nothing third party and should work flawlessly. Wine handles it perfectly too, but if I wanted to port to native Linux, I'd have to adapt it to Berkeley Sockets and whilst Winsock is designed to mimic Berkeley's commands, some of winsock's commands work differently to Berkeley's and some are totally new. That would take a bit of learning to work out which functions work the same (like accept) and which work
  13. This should have no impact. In my setup I have 1000 physics updates per second, with 25, 40 or 50 "major updates" spaced evenly... It was just as smooth as when I was using 25, 40 or 50 steps per second, but it now produces the same results whatever the update rate is. My advice to anyone having trouble using the integrated physics engine is, provided you're using the C++ interface, ignore it and use any physics library of your choice. Seriously, the fact I could do it speaks volumes of how easy it is...
  14. You shouldn't need swept collision on the walls because they don't move, thus they can't move too fast fast for accurate collision. You should only enable swept collision on bodies that can reach high velocities (If it can move further than its own length in a single step). Swept collision should be enabled on as few bodies as possible because it really slows things down. Same goes for "autosleep" but I don't believe that functionality has been exposed to us... Edit: Actually no, that's badly written. Enabling swept collision on too many bodies severely degrades performance. Disab
Facebook Twitter Youtube Github Steam
×
×
  • Create New...