Jump to content

  • Log In with Google      Sign In   
  • Create Account

gamedev199191

Member Since 14 Jan 2009
Offline Last Active Private

Posts I've Made

In Topic: [solved] OpenGL GLSL shader tutorial example translated, but not working

04 March 2012 - 05:32 PM

Aha, got it. I assumed the float ordering in the matrices was row after row, rather than column after column. Changing that fixes it :-)

In Topic: To Extend or to Embed

02 June 2009 - 07:46 AM

Quote:
Original post by ddn3The difficult part is to find a good demarcation between what to put in script and what to keep in c++. You'll have to weight the factors of performance, stability, flexibility and security. If you put too much in scripts you'll find that they become a bottleneck in performance, too little and you won't be harnessing the full power of the system you've built.


I've done a lot of game programming in scripting languages, and when the need arises, moving the script-based logic into C++. I find most of the work is in determining the best way to implement whatever system I might be working on, and this work exists in whatever language I might be using, high-level or low-level. Once this is done in the scripting language, moving it into C++ is an almost mechanical endeavor.

In my experience, the straightforward approach of writing in script when you can and profiling and moving what needs to be moved into a lower level language when the need arises, has worked well.

In Topic: Syncing Deterministic Events

16 March 2009 - 01:35 PM

Quote:
Original post by CadetUmfer
Well I'm trying to avoid sending even slower projectiles over the net. Since each projectile can only ever interact with the environment once (to explode or die), I was hoping to get away with it. Something like grenades that bounce around would be synced. Managing updates for 100 players is one thing...when they can each have a dozen projectiles in the world at once...


If projectiles don't interact with the environment does this mean that their fate is predetermined? That you can know at launch, whether they will explode or die?

Why not just send this with the projectile state when it launches, and just do it when the time comes? Or is it not that simple?

In Topic: Script loops vs callbacks [ANSWERED]

16 March 2009 - 01:28 PM

Quote:
Original post by WitchLordI prefer using event handlers with FSM. I feel it is easier to debug the code that way, and also to serialize the game state when saving/loading. It probably uses less memory overall too, since you don't need to keep a stack for each scripted entity.

But as mentioned above, it all comes down to personal preference and what fits best with the rest of the game engine. Both ways have their advantages and disadvantages, but I can't think of anything that can't be implemented in either of the ways.

The choice of script library may also be influenced by this or, or it may influence your decision depending on which is more important to you. Script libraries may be better at one of the design patterns than the other.


Absolutely.

Regarding stack usage. I just wrote a function with a loop in it and then started it up until it blocked. The amount of memory the microthread's stack is taking up is 48 bytes. In my language of choice, they are a lightweight tool where the programmer doesn't need to be concerned about their impact on resource usage.

In Topic: Script loops vs callbacks [ANSWERED]

14 March 2009 - 10:13 AM

I could rewrite my entity loops to be periodic callbacks without too much effort. There are still callbacks coming in for events anyway, even if actions are primarily managed by the loop.

Some clarity is gained from being able to write logic in a looping function, but a degree of it is lost from all the relevance checks that have to be made after each time the looping function blocks for any reason.

Then again, even with the diluted clarity of the relevance checks, a loop still seems preferable to the loss of ability to gauge visual flow that comes with more callback driven approaches.

I think it comes down to personal preference on programming style.

PARTNERS