Scrolling Game Development Kit Forum

Done. Although the topic would probably stay at the top for quite a while even without a pin these days .

Sorry for possibly misleading you on the visible sprite filtering. I know it was done in the C# code, but it appears that may not have carried over to the JS code in my hastiness to get things "done". This is the C# code that filters visible sprites in LayerBase.cs:

   public bool IsSpriteVisible(SpriteBase sprite)
   {
      return sprite.isActive && sprite.GetBounds().IntersectsWith(VisibleArea);
   }
   public void InjectSprites()
   {
      for (int i = 0; (i < m_nInjectStartIndex) && (i < m_Sprites.Count); i++)
      {
         SpriteBase sprite = m_Sprites[i];
         if (IsSpriteVisible(sprite))
            AppendFrames(sprite.PixelX, sprite.PixelY, sprite.GetCurrentFramesetFrames(), sprite.color, -1);
      }
      for (int i = m_nInjectStartIndex; (i < m_nAppendStartIndex) && (i < m_Sprites.Count); i++)
      {
         SpriteBase sprite = m_Sprites[i];
         if (IsSpriteVisible(sprite))
            InjectFrames(sprite.PixelX, sprite.PixelY, sprite.GetCurrentFramesetFrames(), sprite.color);
      }
      for (int i = m_nAppendStartIndex; (i < m_Sprites.Count); i++)
      {
         SpriteBase sprite = m_Sprites[i];
         if (IsSpriteVisible(sprite))
            AppendFrames(sprite.PixelX, sprite.PixelY, sprite.GetCurrentFramesetFrames(), sprite.color, 1);
      }
   }


I think you originally had the right idea. Your new idea is more confused than your initial understanding:

• Frames are for drawing graphics (from canvas or IMG source) that have not been transformed by a 2D transform.
• XFrames are for drawing graphics (from canvas or IMG source) that have been transformed by a 2D transform.
• Graphics that have been affected by color modulation are drawn from a canvas (as XFrame or Frame).
• Graphics that have not been affected by color modulation are drawn from an IMG source (as XFrame or Frame).

Therefore, if you want to force graphics to be drawn from a canvas, just touch the color modulation. This will not affect whether it is a Frame or an XFrame, but it will affect whether the image source of that Frame or XFrame is coming from a canvas or an IMG, which I think is your goal.

3. One idea for real time color modulation I had was to possibly copy the graphic onto an offscreen canvas, use FillRect a few times with different gCO modes, then copy back to the game canvas. Please let me know what you think, I don't understand these very well:

https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/globalCompositeOperation

I've played around with these, and gotten all of them to work, and I know that there's SOME combination which can be used for color modulation. I'm not sure which though. You probably can find out..

So far I've done fast color tinting, desaturation, brightening, darkening (burn), and light bloom.

I feel like multiply is pretty close to what I was doing, but hue looks pretty close to what I thought color modulation did, and what I was trying to accomplish (re-coloring existing graphics without affecting intensity etc).

5. I would never say that SGDK2 isn't ready for hardcore game development. It's all about HOW ITS USED.

Everything in your engine is perfect.

Perfect.

...
Please never stop working on SGDK2,

Such high praise -- and I very much appreciate it. Too bad it's after so much of SGDK2 has left my brain and been left in the past. I will keep your comments in mind as I consider where to invest efforts in the future, though. Perhaps I will yet find time to further develop SGDK2... like I did with lighting effects. There are at least a couple hangers-on (including you) giving me some motivation to keep it alive. Thank you.

Another thing I've mentioned earlier was a framerate issue...
...
Version 2.3 should probably use refreshAnimationFrame() rather than setInterval/setTimeout.

I'm confused how a different method of pushing animation could make much difference. If there's too much to do within 1/30th of a second (or whatever your frame rate is) there's not much you can do to save it. But I guess there could be some more subtle differences that would make requestAnimationFrame more consistent than setInterval. Again, I put less time (and experience) into the HTML5 code than into the C# code, but will try to remember this for future updates. Sounds like the right thing to do.

Finally, you should consider adding more exporters than the HTML5 exporter. An HTML5 project can be exported across multiple devices through the use of tools such as ionic and phonegap.

Did you notice the Mobile Device sample project, which is essentially an HTML5 project designed for a mobile device interface. Is that the kind of thing you're talking about?

If you un-check the box for embedding the images in the HTML, then you will get code like this:

<img id="CoolFont" style="display:none" src="CoolFont.png" />
<img id="FireFont" style="display:none" src="FireFont.png" />
<img id="Lettering" style="display:none" src="Lettering.png" />
<img id="SHFL32x32" style="display:none" src="SHFL32x32.png" />
<img id="SHFLPlatform" style="display:none" src="SHFLPlatform.png" />
<img id="SHFLSprites" style="display:none" src="SHFLSprites.png" />

instead of code like this:

<img id="CoolFont" style="display:none" src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAATgAAABICAYAAABiKukfAAAAAXNSR0IArs4c6QAAAARnQU1BAACx
...
GNkrX2VeTJAPAKoWmeL6TluKvyNTDzn1a+Lh7zkM/A/wbs0ciKuS5wAAAABJRU5ErkJggg==" />
<img id="FireFont" style="display:none" src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAATgAAABICAYAAABiKukfAAAAAXNSR0IArs4c6QAAAARnQU1BAACx
...

But I don't quite understand the concern over the performance of the initial load. That's something that shouldn't be happening that often, and the difference between different methods shouldn't be humanly noticeable if it's happening only occasionally, should it?

Of course, all the SGDK2 code is available if you want to change the generated code. The only way to change code not visible in the project tree is after it's generated or by changing the generator. Although you might be able to circumvent it with some JavaScript tricks that override inherited base behavior, I don't have any specific ideas there.

My jsperf tests on a Google Nexus 6P are:
image from URL: 7,897
image from base64 jpeg: 474
image from base64 png: 47
image from blob_url: 6,158
image from blob: 123

I also don't understand how you come to the conclusion that JPEGs are faster to draw. I thought we were talking about loading speed, not drawing speed. And once the image is loaded, there should be little memory of the original format of an image. The only impact on drawing speed I might expect would be based on whether there are translucent and transparent pixels in the data. Have you done any tests of JPG drawing vs PNG drawing? You should just be able to replace the PNG files generated by the HTML code generator with JPG files for a test.

Dynamically loading graphic sheets would slow things down wouldn't it? Is your project so large that you can't fit all the graphics in memory? Would it make sense to split the project into separate HTML files so when you reach a certain point, you navigate to another HTML file? Otherwise, I'm not sure how to unload graphics.

In general, I'm wondering what is driving this need to optimize. Are you sure the problems you're trying to solve are the problems causing your performance issues, assuming you are even observing performance issues? Have you used Chrome's performance profiling features to check where performance is an issue?

What is "~~"?

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

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?

I found a very straightforward means to clone a subversion repository to a GitHub git repository, so that's available now at https://github.com/bluemonkmn/sgdk2/tree/master. Do you want to take a look and see if you can fork it or whatever makes the most sense as far as getting in to edit code?