armigus

I think a lot of Game Maker's performance issues stem from its collision checking. Ordinary checking is an O(n^2) operation that scales very poorly with the number of objects. One means of addressing this issue is with spatial hashing.

What is it? Spatial hashing divides 2d/3d space into regions so that tests for vision, collision, etc. only take place within those regions or those adjacent to it. Generally you want relatively small regions but not to an extreme. Dividing a 1024x1024 room into 128x128 or 64x64 chunks is reasonable but 16x16 chunks is a bit too small. Each region has a collection of all objects fully or partially within it.

How does it work? Each corner of an object's bounding box (or the mask if applicable) is assigned a region. The object maintains a small collection of regions it lies within. When an object moves, it recalculates the regions it lies in. Regions entered are told to add the object and regions left are told to remove it. Any collision tests for an object will look only in the regions it is a part of.

Why should this matter? A room of size 1024x1024 divided into 128x128 chunks has 64 regions. The number of collision checks per object drops by at least 16 and in many cases is 64. Larger and more complex rooms will see even greater benefit. I have some 2560x2560 rooms that are nearly unplayable now that would see massive improvement using this algorithm.

Sgt. Conker has an excellent article on spatial hashing here. Please click on the link and read it yourself before asking for more detail here--he even has C# code for the algorithm. If I find other good articles on the topic I will post the links.

Sgt. Conker has an excellent article on spatial hashing.

What is it?  Spatial hashing divides 2d/3d space into regions so that tests for vision, collision, etc. only take place within those regions or those adjacent to it.

How does it work?  Each corner of an object's bounding box (or the mask if applicable) is assigned a region.  The object maintains a small collection of regions it lies within and each region maintains a collection of its objects.  When an object moves, it recalculates the regions it lies in.  Regions entered are told to add the object and regions left are told to remove it.

Why should this matter?  A room of size 1024x1024 divided into 128x128 chunks has 64 regions.  The number of collision checks per object drops by at least 16 and in many cases is 64.  Larger and more complex rooms will see even greater benefit.  I have some 2560x2560 rooms that are nearly unplayable now that would see massive improvement using this algorithm.

I have a set of objects whose sprite depends on other objects' sprites:

Draw_Mask()
var ms;
//ms = "Mask at ("+string(x)+","+string(y)+")"
draw_set_color(c_black)
draw_rectangle(0,0,view_wview[0],view_hview[0],false);
draw_set_color(c_white);
with (Liquid) {
  if (x-sprite_width*.5>other.x+view_wview[0]) continue
  if (x+sprite_width*.5<other.x) continue
  if (y-sprite_height*.5>other.y+view_hview[0]) continue
  if (y+sprite_height*.5<other.y) continue
  draw_sprite(mask_index,-1,x-other.x,y-other.y)
}
draw_rectangle(-1,view_hview[0]-1,1,view_hview[0]+1,false);
//show_message(ms)
return sprite_create_from_screen(0,0,view_wview[0],view_hview[0],1,1,0,0,0,0)

Mask_Builder()
var xp,yp,ob,ms;
// Screen code
xp = 0;
while (xp < room_width) {
  yp = 0;
  while (yp < room_height) {
    ob = instance_create(xp,yp,Land_Mask)
    with (ob) {
      sprite_index = Draw_Mask()
      mask_index = sprite_index
      if (global.testing) {
        visible = true
        image_alpha = 0.3
      }
    }
    yp += view_hview[0]
  }
  xp += view_wview[0]
}

Originally I executed Mask_Builder in the create event of my room controller object. This has occasionally resulted in the malformation of the sprites since the Liquid objects did not have their textures assigned yet. This is serious because the Land_Mask is responsible for keeping water objects like boats and frogmen from charging ashore.

Setting an alarm in the create or room start events was not an optimal solution, especially when screen drawing is synchronized. There was only one time when you knew that drawing was about to happen: the draw event. So the procedure is:

1. Set an initialization flag in the create event.
2. Check the flag in the draw event. Set the alarm to 1 and reset the flag if the latter is set.
3. Call Mask_Builder in the alarm event

That should guarantee the presence of the object textures for drawing custom sprites. Initial testing with the commented code active has been promising, but exhaustive testing is needed to confirm this beyond doubt. Faintly shadowing the covered regions via the global.testing variable was also helpful.

I have an extensive library of uniform polyhedron mesh2 objects in POV-Ray .inc format.
Unfortunately, POV-Ray cannot natively subdivide mesh2 and output the results to a file.

My shapes would make excellent primitives for a mesh modeling program but I want something rather unique: the ability to join my polyhedra together as if they were Legos.

So, I am looking for a mesh modeler with a readily extensible primitive library, a mesh subdivision function, and an object join/merge function that transforms one object so that one of its faces coincides with its partner's counterpart.

Does such a program exist?  Plug-ins are acceptable.

I am looking for a 3D mesh modeling program with these characteristics:

1. A readily extensible set of primitives.  I have a large library of uniform polyhedron meshes in POV-Ray (.inc) format that I can port if need be.

2. Primitive joins and merges.  Basically, you click on two faces on separate objects, and the join will transform the first object so that the both faces coincide.  It allows polyhedra to be joined like so many legos.  Merging the vertices, edges, and faces should be optional.

3. An XML-based mesh format that supports subdivision.

All three criteria are required.