Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - bluemonkmn

Pages: [1] 2 3 ... 185
General Discussion / Re: All Tile Shapes
« on: 2018-03-27, 06:57:42 AM »
Done. Although the topic would probably stay at the top for quite a while even without a pin these days ;).

General Discussion / All Tile Shapes
« on: 2018-03-25, 04:41:38 PM »
If anyone has ever wished that there were more tile shapes, here's your answer. The basic set has been expanded symmetrically to fill in the missing steep hill shapes, gradually sloped ceiling and steeply sloped ceilings for both C# and JavaScript (HTML5) projects. The attached project has all the customized content to do this without requiring a new release of SGDK2. Load the project, reset the source code to get all the standard code merged in, and you're set to go.

General Discussion / Re: Version 2.3 Feature Suggestions
« on: 2018-01-02, 12:41:22 PM »
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:

Code: [Select]
   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);

General Discussion / Re: Version 2.3 Feature Suggestions
« on: 2018-01-02, 07:58:57 AM »
The game seems a tad slower overall (With the added scope lookup time) but each frame seems to be less variable in timing. I'd much rather have a slower speed overall than a fast but insanely variable speed, especially when I have more being drawn on screen.

Consistent speed was my reason for using a method like setInterval to draw frames instead of requestAnimationFrame. Did you consider comparing the result against the stock SGDK2 behavior with a constant (low) frame rate limit set. Of course if you set the limit too high, it won't be hit, but if you set it appropriately low, it should be relatively consistent.

Are you also aware that you can pre-create most sprite instances and use "ActivateSprite" instead of add sprite so that you're not creating and deleting objects?

Is this code also drawing sprites which aren't on screen?
Maybe some browsers are smart enough to know that something is being drawn offscreen but is this something I can always rely on?

I believe the SGDK2 code is smart enough not to draw sprites that don't intersect the visible view on the screen. You shouldn't have to rely on the browser's smarts for that.

General Discussion / Re: Version 2.3 Feature Suggestions
« on: 2017-12-28, 05:24:53 PM »
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.

General Discussion / Re: Version 2.3 Feature Suggestions
« on: 2017-12-27, 08:13:29 PM »
I don't understand your reasoning behind XFrame performance being related to drawImage from a particular kind of source. XFrame and Frame both use drawImage, and both come from a graphic sheet image. However XFrame and Frame can both come from modulated images on a canvas or original images directly in the the IMG element. Is it possible the performance is related to modulated frames (from a canvas) and not to XFrame versus Frame? The only difference with XFrame is that they can have 2D transforms applied at runtime. Color modulations are not 2D transforms, and can apply to XFrames or Frames.

General Discussion / Re: Version 2.3 Feature Suggestions
« on: 2017-12-26, 09:16:41 PM »
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:

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.


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?

General Discussion / Re: Version 2.3 Feature Suggestions
« on: 2017-12-24, 08:51:04 PM »
I think the performance issue with drawImage would only affect sprites because I think tiles are already drawn at integral positions. But if you have a lot of sprites, I suppose that could be an issue. I think my thought at the time was that slow-moving sprites could actually benefit visually from drawing at non-integral positions.

Unfortunately, SGDK2 wasn't designed for heavy-duty game development. Or you have to be pretty smart about how you use it if you're going to seriously load it down with a huge project. As you've seen, color modulation is a big problem if you're trying to modulate a lot of graphics to a lot of colors in an HTML5 project since HTML5 doesn't appear to support real-time color modulation.

Glad you still find it somewhat useful, though.

General Discussion / Re: Version 2.3 Feature Suggestions
« on: 2017-12-21, 06:03:35 PM »
If you un-check the box for embedding the images in the HTML, then you will get code like this:

Code: [Select]
<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:

Code: [Select]
<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 "~~"?

News and Announcements / Re: Version 2.3.0 Released
« on: 2017-10-30, 07:33:21 AM »
Further discussion of features moved here.

General Discussion / Re: Version 2.3 Feature Suggestions
« on: 2017-10-30, 07:31:28 AM »
I split the topic and moved it to an appropriate location to fix that.

General Discussion / Re: Version 2.3 Feature Suggestions
« on: 2017-10-28, 06:42:02 PM »
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: [Select]
var result = new Array();
with this in decodeData1:
Code: [Select]
var buf = new ArrayBuffer(data.length);
var result = new Uint8Array(buf);
and this in decodeData2:
Code: [Select]
var buf = new ArrayBuffer(data.length);
var result = new Uint16Array(buf);

General Discussion / Re: Version 2.3 Feature Suggestions
« on: 2017-10-28, 06:24:13 PM »
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?

News and Announcements / Source Code Migrated to Git
« on: 2017-10-01, 08:31:34 AM »
The source code repository for Scrolling Game Development Kit 2 has been a Subversion (SVN) repository up until yesterday, at which point I decided to migrate it to Git with the help of GitHub's import utility. All the source code history is now available in a Git repository which is hosted at both GitHub and SourceForge. This will make it easier for anyone wishing to participate in future coding of SGDK2 to fork the repository and submit their changes via pull requests. My intent is to keep the two repositories in sync (although I don't have much experience with Git yet, so it remains to be seen whether this synchronization is as easy as it looks). SourceForge is SGDK2's home, but GitHub is designed specifically for Git. I suspect future development will begin at GitHub, and we'll use GitHub's methods for issue tracking if we track issues. But SourceForge will still be where releases are posted, and should be kept up-to-date.

The Subversion repository continues to exist at SourceForge, but will not be maintained for any future updates. It may be deleted at some point to avoid confusion.

Come join the fun by making your own fork of SGDK2 at GitHub, and make your own improvements, and if they're worth sharing, request they be considered for inclusion in the original!

News and Announcements / Re: Version 2.3.0 Released
« on: 2017-09-30, 10:50:52 AM »
I found a very straightforward means to clone a subversion repository to a GitHub git repository, so that's available now at 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?

Pages: [1] 2 3 ... 185