New functions!

[Shaltif]

[SILL]
And the cycle continues.  Chronic was working on a project using Sill when he noticed there was no 'easy' way to get an instance id given a position (such as under the mouse cursor).  After some brainstorming, I began working on a instance_nearest() type function (similar to Game Maker's setup)...While making this nearest function I thought it would be nice to have an alternate option to return an entire list of instances sorted in order of nearest to a point.  Then I realized that some users may want to be able to obtain lists for the other type of resources.  So after a lot of modification on how stuff is internally stored, I developed the following functions:

sill_resource_list(SILL_RESOURCE *list, SILL_UINT *size, SILL_UINT max, SILL_UINT offset, SILL_UINT type);
sill_resource_list_size(SILL_UINT *size, SILL_UINT type);

The type parameter in the above function uses a new set of constants (which I'll need to add to the manual) which specify which type of resource you want to get a list of:

///Resource Constants
SILL_RESOURCE_TEXTURE
SILL_RESOURCE_SPRITE
SILL_RESOURCE_FONT
SILL_RESOURCE_OBJECT
SILL_RESOURCE_INSTANCE
SILL_RESOURCE_COLLIDER
SILL_RESOURCE_FILE
SILL_RESOURCE_DIRECTORY
SILL_RESOURCE_RENDERBUFFER
SILL_RESOURCE_VIEW
SILL_RESOURCE_JOYSTICK
SILL_RESOURCE_SOCKET
SILL_RESOURCE_NETWORK
SILL_RESOURCE_SOUND

Note that the lists are pulled directly from the internal storage lists, so in some cases the returned results are a bit misleading.  For example, lets say you create 10 textures, 2 sprites and 4 fonts.  Then use the resource_list_size function to get the number of texture resources loaded.  It would result in 16, not 10 as you would probably expect.  Why?  Because each sprite and font internally makes a texture resource for use.  Interestingly, if you pulled the entire texture resource handle list (which would be 16 in our example), you would have access to the internal texture handles for the sprites and fonts, which you can pass to the texture functions for manipulation purpose (assign the sprite's or font's texture to a renderbuffer and you've basically created a way to draw directly to those resources...you could even delete the internal textures...but that would crash Sill the moment you tried to use the sprite/fonts that use those textures, so don't do that ;P).

Other resources that work like the example above are SOCKETS and NETWORK (each network can create multiple socket resources), and RENDERBUFFERS, TEXTURES and VIEWS (each view creates a texture and renderbuffer).  I just realized that means you can do some serious view trickery by messing with the renderbuffer assigned to a view...interesting.


In addition to the above resource listing (which I may expand with sorting and other features), I have created the instance_proximity subset for dealing with getting instances in proximity to a given point.

(the name of these functions and their listed parameters are still subject to change)

sill_instance_proximity(SILL_RESOURCE *result, SILL_REAL x, SILL_REAL y, SILL_UINT pos);
sill_instance_proximity_object(SILL_RESOURCE *result, SILL_REAL x, SILL_REAL y, SILL_UINT pos, SILL_RESOURCE object);
sill_instance_proximity_list(SILL_RESOURCE *result, SILL_RESOURCE *list, SILL_UINT size, SILL_REAL x, SILL_REAL y, SILL_UINT pos);
sill_instance_proximity_list_alt(SILL_RESOURCE *list, SILL_UINT size, SILL_REAL x, SILL_REAL y);

sill_instance_region(SILL_RESOURCE *list, SILL_UINT size, SILL_REAL x, SILL_REAL y, SILL_REAL width, SILL_REAL height);
sill_instance_region_size(SILL_UINT *size, SILL_REAL x, SILL_REAL y, SILL_REAL width, SILL_REAL height);

These deal with obtaining and sorting instance id's based on their position to a given point.  For the latter two proximity functions, you can supply them with a custom list of instances, in which it will spit out results accordingly.

The region functions result in the number of instances in a given rectangular area and can even produce a list of all instance id's inside the given area (by position, not collision mask).


...and I'm running out of time, heading into work early.   So I'm still working hard on Sill, just kinda detoured from the documentation angle.

~Brandon