Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 27 Apr 2011
Offline Last Active Today, 01:13 AM

Posts I've Made

In Topic: Managing engine subsystem interactions

11 June 2015 - 10:18 AM

Seems you do know why then smile.png

I know globals are bad only because people say so, but I didn't fully understand why they are bad, especially the public access part. With your explanation now I know how they are bad for cache coherency.


I still have some questions regarding your engine structure.


Different features might have data the flow through the subsystems in different order, and might go through the same subsystem multiple times. For example, we might need to do several consecutive raycasts that depends on each others result. How do we ensure all the works are done before we finish a single frame? Do we start by raising a update event and loop through all the subsystems until there are no more works queued for this frame?


By batching jobs subsystems will operate on a command pattern. I once used a engine whose rendering system is done like this, but debugging it was quite a headache. With procedural methods, if we received a segfault or other exceptions, all the inputs and callers down until main() is probably still on the stack so it is easier to track where it went wrong. But with a command pattern the information of who gave us this garbage is lost, unless we do some excessive logging. For the footstep example, suppose one of the many sound effects played is wrong, how would you suggest to track down where went wrong?


Thanks a lot!

In Topic: Why didn't somebody tell me?

11 June 2015 - 02:51 AM

Learned English for more than 20 years but I recently found that:


"Expect" and "Except" are different words, spelled differently.


As a programmer they always come in the same place like "Runtime exception: foo expected after bar", and human brain only identify the first/last character and composition, so I assumed they were the same thing.

In Topic: 2D Platformer: Choosing a physics engine

29 May 2015 - 10:27 AM

Common platformer features can be implemented well with a physics engine, here's mine as an example using Box2D:


I'd admit it's quite a headache to bend a physic engine into the unrealistic nature of a platformer, but this path could be easier if you don't know how to write collision codes or many objects need realistic movements.


For engine selection, I don't think there are any competitors with Box2D. For a platformer you don't need to modify Box2D's source, but you do need a lot of extra code to make it fit the features you want.


Here are some tips:


For "non-floaty" movements, instead of applying force, calculate the impulse to reach the desired speed and then apply it. Don't directly set the speed, you'll get weird results while pushing objects.


For "one wayed platforms", those you can jump on from beneath but won't fall from above, Box2D has a contact listener that will let you disable collision on conditions. You'll need to remember the result for the whole duration of the contact. For example, if the contact began with the character coming from below, disable collision until the contact has ended.


For objects following a path, use a kinematic body. You can set its' position directly, but remember to adjust its' velocity according to the last frame or objects on it won't move with it.


I'm better with physics(majored in mechanical engineering) than physics engine (I don't understand what the hell Box2D is doing internally, and mathematically impaired to check simple collisions), so bending rules with supernatural forces at my command is easier than defining the rules of this new universe. Depending on your ability it could vary, but whichever you chose I think there are people that can help.

In Topic: inline virtual is a nonsense ?

15 April 2015 - 11:16 AM

It is well named for it's original purpose, pasting code instead of the cost of a function call. That's is IF your compiler respects your decision, and they probably don't. They think they are too good to use your kind advice. Now the only use is to avoid the one definition rule, and it became misleading.


I'm also perfectly fine while using it (C++ is my main language). I just think that teachers/books should alert you it is likely that actual inlining will be done regardless of this. This keyword has almost nothing to do with performance today.


I also googled around for inlining in C#, and they have this [MethodImpl(MethodImplOptions.AggressiveInlining)]. Funny thing is .NET also only regard it as an hint. Compilers this day are all like "write assembly yourself or don't tell me what how I do my job".

In Topic: inline virtual is a nonsense ?

15 April 2015 - 09:58 AM

It has a completely different and very sensible purpose. Try putting a simple function or operator in a header used in multiple CPP files without the 'inline'.


It is still a nonsense because we only use it for its' side effect and not the original purpose. It should be something like


allow_duplicated_definition_and_assume_they_are_all_same void foo(){};


Nothing is actually inlined, why call it "inline"? The name only trick people to think it will "optymize" things, waste half a second to type and 7 bytes of precious disk space.


Newer languages don't even need the side effect of inline. Today's compilers are perfectly capable of knowing two definitions means exactly the same thing or not. They also don't use copy-and-paste based include so nothing is duplicated just because every source file must know about some source file.


Although this is the burden of an old language. It kind of surprised me that they decided the original meaning of "auto" is too silly to live in C++ anymore, but I think "inline" was used too much, and we will be stuck with it.