Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

Control Flow

2 (2.2%)

Arrays, Strings, Pointers, and References

8 (9%)

Functions

4 (4.5%)

Basic object-oriented programming

30 (33.7%)

A bit more advanced OOP (Composition, Operator overloading, Inheritance, Virtual Functions)

18 (20.2%)

Templates

8 (9%)

Other (Explain)

4 (4.5%)

Working with files?  (Streams)

15 (16.9%)

Total Members Voted: 89

[Siquo]

Well, it also depends on if you want to get shit done, or learn. I'm building (well, almost) everything from scratch (engine, gui, etc) in my current project, and although frustrating and slow, I'm learning a lot.

[Supermikhail]

I guess I'm learning a lot, too, although I don't get this lofty feeling like with other learning activities like learning a new language, or learning to play guitar. But I'm mainly concerned with getting shit done now. Or maybe always. Yeah, I've recently discovered that I care about the result, not the process, so as long as the product matches my vision, I'm happy, even if the code is riddled with gotos (if it were in C++)... No, that sounds wrong. I guess I want to get shit done competently, but I'm not going to try to get a PhD for it, because I get the kicks out of my vision transpiring in the code, and if it doesn't do it I'm just going to lose motivation.

[Blank Expression]

Finally, don't even bother with something like this, find an adequate third-party library and focus on the impostant part: YOUR code. It is likely that an existing physics library is highly optimized, and you will probably spend days debugging physics math before you can even approach a sufficient setup to do everything you want it to.

This is, ultimately, the best possible solution. Were I in your shoes I'd ignore everything else he says in his post, because frankly it's astonishingly scary and misleading and hearkens back to the days where, hey, 65K objects are all you'll ever need, but at the end of the day, doing it yourself is like pulling teeth.



Also, note: computing offsets from a 16-bit integer index will be slower than using pointers--you get nothing from said index, aside from an arbitrary 65K item limit. As I noted earlier in the thread a "short" is generally a system-width int with its top or bottom bits masked, and the pre-allocated memory space is wasteful and assumes more about the structure than can be reasonably extracted from a general case. This is something of an example of a programmer trying to get too cute and actually making his job harder than it needs to be. (That habit is somewhat endemic to C developers, though some individuals transcend it.)

[Virex]

Also, note: computing offsets from a 16-bit integer index will be slower than using pointers--you get nothing from said index, as I noted earlier in the thread a "short" is generally a system-width int with its top or bottom bits masked. This is an example of a C programmer trying to get too cute and actually making his job vastly harder than it needs to be. (That habit is somewhat endemic to the species, though some individuals transcend it.)

Doesn't that depend on the compiler and the underlying hardware? IIRC, on modern processors there's often an operation for accessing a memory address from a base address and an offset. In such a case, for speed considerations, it should matter little if you're using a direct address or a base address and an offset (true, you're using one more register that could be used for other calculations, but that's only valid if those calculations don't involve the index into the array in some way.) Note that in this case you might just as well use an integer type that matches the register size of your processor instead of using int16's. Or use pointers anyway if you don't need to know what index you're on.
Or don't worry about it in the first place and use whatever is easiest because there's a good chance that a.) setting your compiler to speed 3 makes it rewrite your loop into the best form for the case anyway and b.) your bottleneck isn't in the way you access your array anyway.


Also, int16's are very useful if a.) you're programming on a 16 bit microprocessor, b.) you're programming in assembler and need to squeeze another number into a register so you can avoid accessing the stack for some functions (pushing and popping a register is more expensive then bit-masking one), c.) you're trying to force an overflow at 65K for some reason or d.) you're going to be sending the raw data over a sequential line and the protocol doesn't support arbitrarily sized data (with an interrupt-based protocol you could just only send the bits that matter and omit the zero bits at the front), or e.) something someone who knows more about hand-optimized assembly then I do will point out to you. In any other case you're better off using an integer type that matches the machine word size of your target hardware (in case a. that'd be 16 bit, but it can be 8 bit for cheap microprocessors, 32 or 64 bit for most home computers and anything upwards of 64 bit for high performance hardware.)

[Blank Expression]

Also, note: computing offsets from a 16-bit integer index will be slower than using pointers--you get nothing from said index, as I noted earlier in the thread a "short" is generally a system-width int with its top or bottom bits masked. This is an example of a C programmer trying to get too cute and actually making his job vastly harder than it needs to be. (That habit is somewhat endemic to the species, though some individuals transcend it.)

Doesn't that depend on the compiler and the underlying hardware? IIRC, on modern processors there's often an operation for accessing a memory address from a base address and an offset. In such a case, for speed considerations, it should matter little if you're using a direct address or a base address and an offset (true, you're using one more register that could be used for other calculations, but that's only valid if those calculations don't involve the index into the array in some way.) Note that in this case you might just as well use an integer type that matches the register size of your processor instead of using int16's. Or use pointers anyway if you don't need to know what index you're on.

Base+offset does exist, but in this case it's base+(index*array_offset=offset), which is at least an op slower than base+offset or direct addressing. For the kind of brain-melting perf that somebody who actually spends their time building this sort of weird setup is apparently going for, it's actually slower. I wouldn't build it this way to begin with because, as you note...

Or don't worry about it in the first place and use whatever is easiest because there's a good chance that a.) setting your compiler to speed 3 makes it rewrite your loop into the best form for the case anyway and b.) your bottleneck isn't in the way you access your array anyway.

Exactly. Your bottleneck certainly is not that, but his supposed architecture couples an arbitrary object limit with actually worse performance. The compiler is generally smarter than the programmers driving it, and this case is a perfect example of it.

Also, int16's are very useful if a.) you're programming on a 16 bit microprocessor, b.) you're programming in assembler and need to squeeze another number into a register so you can avoid accessing the stack for some functions (pushing and popping a register is more expensive then bit-masking one), c.) you're trying to force an overflow at 65K for some reason or d.) you're going to be sending the raw data over a sequential line and the protocol doesn't support arbitrarily sized data (with an interrupt-based protocol you could just only send the bits that matter and omit the zero bits at the front), or e.) something someone who knows more about hand-optimized assembly then I do will point out to you. In any other case you're better off using an integer type that matches the machine word size of your target hardware (in case a. that'd be 16 bit, but it can be 8 bit for cheap microprocessors, 32 or 64 bit for most home computers and anything upwards of 64 bit for high performance hardware.)

All completely true, but none of which is really applicable here. He's on a PC, which means word-size of 4 at the minimum. It's bit-twiddling for the sake of bit-twiddling.

[Supermikhail]

Oh. I'm still using shorts for periodic numbers. Did it lie to me then that the size of its shorts is 2 bytes?... Or maybe it wasn't it... Oh, yeah, it was C++. Then Java API, to my dismay, says that the maximum value its shorts can store is 2¹⁵-1. So, what does it make it? Er. That's 2 bytes it is. Nevermind.
...Hey, so it turns out Java has a type called byte! Joy. Is it an even bigger waste of space?

[Nadaka]

Oh. I'm still using shorts for periodic numbers. Did it lie to me then that the size of its shorts is 2 bytes?... Or maybe it wasn't it... Oh, yeah, it was C++. Then Java API, to my dismay, says that the maximum value its shorts can store is 2¹⁵-1. So, what does it make it? Er. That's 2 bytes it is. Nevermind.
...Hey, so it turns out Java has a type called byte! Joy. Is it an even bigger waste of space?

Yes... No... You can't control it.

The specification for the jvm does not specify how it packs data into memory. Different jvm's and different platforms may pack data more tightly or loosely than others. The the standard sun JVM does pack memory to 8bit boundaries. You can test this yourself by creating a simple program with a size million array of bytes and another with a size million array of integers and them measure the difference in the size of the vm. Blank Expression is wrong about memory usage, at least as it relates to the standard sun jvm.

[Blank Expression]

The specification for the jvm does not specify how it packs data into memory. Different jvm's and different platforms may pack data more tightly or loosely than others. The the standard sun JVM does pack memory to 8bit boundaries. You can test this yourself by creating a simple program with a size million array of bytes and another with a size million array of integers and them measure the difference in the size of the vm. Blank Expression is wrong about memory usage, at least as it relates to the standard sun jvm.

Note that replying to qwerty was in regards to his ill-advised C-based advice, not anything related to Java. Without (compiler-specific) pragmas and a decent bit of inefficient dicking around, every x86[_64] C/C++ compiler aligns to word boundaries (and doing otherwise is counterproductive). (If I had been referring to Java, it would have been a little odd to be talking about pointers, no?)

You are correct with respect to Java--if you use nothing but arrays (which are special-cased). Using any other collections, or operations where you must box the primitives, results in a loss of any space benefit. Some quick tests on the 6.0 JRE, with arrays of 1,000,000 elements (just getting total used memory from Runtime):

short: 3419808
int: 5419808
Short: 9419808
Integer: 9419808

That said, memory use isn't the problem I was referring to. Memory is cheap. Inefficient data requesting, and essentially throwing away big whacks of every memory request, isn't. While I personally am of the opinion that it's better to use reasonably-domained data types, if you're going to be obsessive and "OCD" (his word, not mine), you benefit more from using ints wherever possible (and longs on x86_64). Using a non-machine-word sized value means you're making a word-size memory request and just masking off the rest of the bits. Mask-and-shift is not as cheap as just using the whole word. (There are special cases for using 4-byte words on x64, but that's getting into deep magic.)

Of course, this isn't important, which is what I was getting at. That these sorts of "optimizations" aren't, and are counterproductive in the long run. And the medium run. Also the short run, too, really. I don't think you and I actually disagree here.

[qwertyuiopas]

Because I was working with assumptions and vaguely recalled information before, I did some tests.

On plain ints, the pointer was noticably faster. Howerver, once it was structs of an int and a char, they both preformed equally.

With structs of an int and eight bytes, using a short as an index was slightly slower, but an interesting thing happened: -O1 they were equal, and -O2 and -O3 the index was *faster*.

Conclusion: The results are more complex than either of us know, more research is nessecary (perhaps larger data structures and trying an int as an index).


Bottom line, however, leave the physics engines to the triple-doctorate assembly language coders who could code both windows and linux from scratch in one 24-hour period and have fewer bugs and better performance, too.

[Supermikhail]

I wish I could get one for free. The library I've been talking about is this. And I'm not so sure it was made by any degree coders, judging by the amount of todo's, and the inclusion of elastic joints which "do something odd. Might be useful for something?" It's been last updated in 2008. I've looked and haven't found a better physics library, at least in Java. And for 2D...

So, I've toyed with an idea - as far as I can see, the heaviest stuff in physics engines goes into collision detection; so, as my game works on the micro level, maybe I should drop collisions completely and do everything with forces? Of course, that would involve creating a force object for every couple of bodies, but in the end I would still have to do it, or at least that's the only solution I can think of to make the game the way I want it. That is, I want it to do arrangement of atoms in a molecule. Like this says (but gradually), if anybody's interested.
Pros (if I haven't made myself look stupid yet): all lists have their required capacity known from the start; so far a force object consists only of two pointers and a float.
Cons: the required capacity of the force list will increase exponentially (or something like that) with the number of bodies; making a bounds object to keep all the bodies on the screen will require some ingenuity with this approach.

[Siquo]

Well, determining your level of abstraction should be the first thing on your agenda.
What is your game/program about? If I'm building an RPG, I'm not going to simulate quantum particle physics.

If you just want a box of colliding balls, that's just going to be CPU-heavy, whichever way you put it.

[Supermikhail]

Well, I'm simulating atom physics, but with some user interaction. But how I'm simulating them, I guess it's going to be a shifting thing for a while, that is until something moves on the screen. Bouncing balls could be it, but third-party libraries being made for macro-objects (and the whole collision physics, from what I've gathered in my research) doesn't help the usefulness of this approach.

[Siquo]

There's a shitload of physics to a single atom. Energy states, electron clouds and orbits, ions, isotopes, strong and weak electromagnetic force, ionic/hydrogen/(non)covalent/etc bonding, and even gravity matters. And all that in (at least) 4 dimensions.
So first, what are you going to simulate?

If just a brownian-motion-like-machine: Perfectly elastic non-rotating bouncing circles (atoms can be modeled like this) is doable (not I said circles, not balls), but anything more complex than that is going to get a LOT more complex. But if you limit yourself to just that, in 2D, you could easily make your own engine.

[Supermikhail]

Yeah yeah, exactly brownian-motion-like machine! I've written a portion of code, the hardest part is distributing functions and variables to the right classes, there's problems with that, and also deciding what to initialize variables to. I initially wrote a function to calculate the starting speed of an atom from the temperature. But that requires the physics engine to run on a microscale, as far as I can figure... And rendering might be complicated.

Oh. And I'm going to have bonds. Which are going to be all modeled as covalent... Or, I guess, with forces other kinds of bonds could be doable.

[Siquo]

Depends on how you represent the molecules. If they're just larger circles, it's ok, but if you've got connected circles, you've got rotation, mass distribution, rotational inertia, are your bonds elastic or not, etc etc. It's a whole new can 'o' worms.