GameMonkey Script

GameMonkey Script Forums
It is currently Mon Nov 20, 2017 3:32 pm

All times are UTC




Post new topic Reply to topic  [ 5 posts ] 
Author Message
PostPosted: Thu Nov 03, 2011 1:26 pm 
Offline

Joined: Thu Nov 03, 2011 1:00 am
Posts: 6
First of all, thank you for releasing Gamemonkey, it is indeed super neat and I am enjoying using it quite alot in my engine.

During each frame, my game requires alot of uses dynamic float3 and float2 types, causing tons of malloc allocations each frame, which slows down my system dramatically over time. To overcome this, I've decided to alter the gmVariable type to make it a union within my float3 and float2 types (which increases the sizeof(gmVariable) to 16 bytes.), which allows all these allocations to exist on the stack.

Code:
struct gmVec3
{
   float x,y,z;
};

struct gmVec2
{
   float x,y;
};

struct gmVariable
{
  static gmVariable s_null;

  gmType m_type;

  union
  {
   gmVec3 m_v3;
   gmVec2 m_v2;
    gmint m_int;
    gmfloat m_float;
    gmptr m_ref;
  } m_value;
...
}


After doing so, everything is working well, except my SETDOT operator. When I do something like this...

Code:
local test = vec3(1,1,1);
print(test.y); // "1"
test.y = 2.0f;
print(test.y); // "1"


My Y-value does not change. I do believe a new vec3 with the new y-value is being pushed on the stack and not altering the original "test" variable. My question is: is there any way I could make it change the actually y-value "test"?


My setdot operator is implemented like this:
Code:
void GM_CDECL gmVec2SetDot(gmThread * a_thread, gmVariable * a_operands)
{
   gmVec2 &VAL = a_operands[0].m_value.m_v2;
   const char* memberStr = (static_cast< gmStringObject*>(GM_OBJECT(a_operands[2].m_value.m_ref)))->GetString();

   // get float val
   float newVal = 0.0f;
   if(a_operands[1].m_type == GM_FLOAT) newVal = a_operands[1].m_value.m_float;
   else if(a_operands[1].m_type == GM_INT) newVal = (float)a_operands[1].m_value.m_int;
   else a_thread->GetMachine()->GetLog().LogEntry( "Setting v2 property '%s' as invalid type", memberStr );

   // set member
   if ( stricmp( memberStr, "x") == 0 ) thisVal.x = newVal;
   else if ( stricmp( memberStr, "y") == 0 ) thisVal.y = newVal;
   else a_thread->GetMachine()->GetLog().LogEntry( "Setting invalid property %s", memberStr );
}



Thanks a bunch for your help!!


Top
 Profile  
Reply with quote  
PostPosted: Thu Nov 03, 2011 9:53 pm 
Offline

Joined: Mon Dec 15, 2003 1:38 pm
Posts: 698
Welcome to the forum funkbot :) Might I suggest that you check out DrEvil's extended GM build, as he's already implemented a stack based Vector3, which should be functional and well tested: Game Monkey Script Ex(Extended) & gmBind2 This may help to fill-in-the-blanks for your modification, or you may like to switch to his build.


Top
 Profile  
Reply with quote  
PostPosted: Thu Nov 03, 2011 11:51 pm 
Offline

Joined: Thu Nov 03, 2011 1:00 am
Posts: 6
Hey Greg,

Thanks for your warm welcome and also for pointing me towards Gamemonkey EX project! Greatly appreciated.

I looked into his code, especially his gmVec3Stack implementation, and he does not have a working SETDOT implemented for his vec3 stack type.

I also saw Shawn's implementation and he does have some sort of SETDOT implemented, but the syntax is just way too unusable:
Code:
local vec = math.Vector(1, 2, 3);
vec = (4).x;



I am looking for a way to alter the data of the original vec3 variable that is calling the setdot operator, for example:
Code:
local test = vec3(1,1,1);
test.y = 2.0f;



Is it possible? Thanks again.


Top
 Profile  
Reply with quote  
PostPosted: Fri Nov 04, 2011 2:13 am 
Offline

Joined: Mon Dec 15, 2003 1:38 pm
Posts: 698
Funkbot, I understand what you are trying to achieve and I think it is not possible. It is an unfortunate by design limitation of the stack and variables. The alternative syntax vec = (4).x is indeed ugly. It would probably be clearer to just use syntax like vec = Vec3SetX(4) or vec = vec.SetX(4) (type bound). I think Shawn has already done the best he could. I'll investigate a bit further and let you know if there is a reasonable work around.


Top
 Profile  
Reply with quote  
PostPosted: Mon Dec 05, 2011 12:27 pm 
Offline

Joined: Fri Jun 19, 2009 12:39 pm
Posts: 31
Wouldn't a much simpler soultion to change the way that you allocate these smaller, more often used user-types?

Instead of relying on the standard new/delete or malloc/free which incurrs a lot of overhead in terms of memory and execution time; why not write something like a unit-heap allocator, which manages memory in fixed-size blocks?

After all, you get to define how an object is created in your type library function so it's up to you as to decided how it gets allocated. In fact, is there not already a class in gm that supports that sort of allocation strategy? I believe it's called gmMemFixed.

You still get some allocation overhead, but it's not *so* bad.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group