SGDK Version 2 > General Discussion

Version 2.3 Feature Suggestions

(1/5) > >>

Plush:
More suggestions to HTML5 (Which I'm implementing myself using hacky approaches):

Can you switch to typed arrays for maps? This is a fairly new addition to Javascript. Also use them for ImageData for ModulateColor tinting..?

Can you replace the TestCollisionRect function with one that only scans from a list of proximal sprites in a region (IE grid based sprite collisions that only search buckets, rather than entire maps. This is similar to spatial hashing collisions) such as TestCollisionProximal?

bluemonkmn:
I don't know how to iterate proximal sprites without spatial hashing, and spatial hashing seems like it would significantly complicate sprite collections. Spatial hashing could significantly increase the overall number of sprites that SGDK2 can handle in general, but having no experience in implementing it, it might take me quite a while to get it right. It might also introduce the desire for configurable values to indicate whether to exclude off-screen sprites from all processing. I expect more time would be spent on other processing of sprites besides just collision detection. This might be part of the reason I haven't implemented it -- I don't want to be penny wise and pound foolish on the optimizations.

I haven't encountered any SGDK2 games that require this degree of optimization, so it would be hard to make sure I'm optimizing appropriately. My hope was that dividing sprites into categories would be a sufficient optimization in this regard. By putting sprites into sufficiently narrow categories, you significantly limit the number of sprites you need to loop through when checking for collisions because each category is its own array. Is there any way you can use the existing sprite category constructs to sufficiently optimize your sprite interactions?

The same could be said for typed arrays. I haven't encountered anyone hitting any actual issues due to the internal format of the layer tile storage, so it's hard to know the real impact or value of this outside of theoretical calculations (and I tend to follow the principle of optimizing only when and where necessary). I can't remember if I was aware of JavaScript typed arrays when implementing HTML5 support, or maybe I wanted to support older browsers (was HTML5 introduced before typed arrays?), but the question does arise what the real trade-off would be in simplicity versus performance. Are you running out of memory?

bluemonkmn:
Can you implement typed array storage for your map layers by just replacing 2 lines in the MapLayer.js file in your SourceCode folder in your SGDK2 project? Replace

--- Code: ---var result = new Array();

--- End code ---
with this in decodeData1:

--- Code: ---var buf = new ArrayBuffer(data.length);
var result = new Uint8Array(buf);

--- End code ---
and this in decodeData2:

--- Code: ---var buf = new ArrayBuffer(data.length);
var result = new Uint16Array(buf);

--- End code ---

Plush:
Hello, bluemonkmn,

I shouldn't post my questions here in this thread. However, thank you for the support.

bluemonkmn:
I split the topic and moved it to an appropriate location to fix that.

Navigation

[0] Message Index

[#] Next page