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 ... 184
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?

News and Announcements / Re: Version 2.3.0 Released
« on: 2017-09-25, 07:34:45 AM »
SourceForge already functions as the host for SGDK2 source control (using subversion) at I could try to replicate the tree on GitHub, and try to merge changes back to SourceForge, or try to convert the whole history to Git in place at SourceForge using instructions like those at Do you think the work to be done on SGDK2 warrants a source control conversion? I do like Git better than SVN, but I'm not sure SGDK2's source control needs will warrant the complexity of a migration, unless it's just a convenience measure, and the primary source control is still the one at SourceForge.

News and Announcements / Re: Version 2.3.0 Released
« on: 2017-09-22, 10:19:32 AM »
Since I don't get much time to work on SGDK2 these days, I wonder if you could accomplish some or all of the things you want by adding sprites and tiles to categories so that you can use the IDE to categorize most of what you want, then add custom code files in the SourceCode folder to use those categories to modify the behavior of everything in those categories. For example, can you update the draw function of every sprite in a category as the game initializes? Or update every frame included in every sprite of a particular category? Unfortunately I've forgotten much about what I learned about JavaScript's prototype inheritance since implementing HTML5 support, but is there a way to essentially re-assign an object to behave as an instance of a subclass of itself?

If you or anyone you know has more time to dedicate to SGDK2 coding, I would consider merging updates into SGDK2 code; maybe adding a developer to the project. You seem to be conscientious about what constitutes a clean design considering how hard you are being on your own "hacky" solutions. ;)
I would be happy to try to answer questions about the code, but I don't know that I have the time to tinker with new designs and solutions for a while.

Can you share a simple demo of the frame rate problem you are seeing? I tried updating the frame rate in the sample HTML5 project, and it seemed to maintain a consistently slower frame rate when using a lower limit parameter. (I dropped it from 80 to 30.) I'm testing in Chrome and IE11.

News and Announcements / Re: Version 2.3.0 Released
« on: 2017-09-19, 07:28:45 AM »
I don't have a full reply at the moment, but I do want to reply to your two edit comments:
  • Can you describe more what's wrong with LimitFrameRate? I haven't changed it since 2.2.10. Is it working in EXE builds, but not HTML5, or just not working in any environment? One thing you have to be careful of is not to call it more than once per frame.
  • I never implemented tile and sprite interleaving for HTML5 projects. That was only implemented for EXE builds. It was more complicated than I was prepared to deal with at the time in JavaScript. So it's kind of a designed limitation for the moment. The hard part is implementing the necessary code structures for sorting sprite frame output among tile frame output. It's probably not really hard, but will involve a good deal of additional code.

Oh, also on the topic of a custom matrix, is the ability to edit the matrix parameters directly in the frameset editor insufficient or not working?

News and Announcements / Re: Version 2.3.0 Released
« on: 2017-09-14, 07:13:34 PM »
I found that I had already implemented the SetTargetParameterFor and related functions in another HTML5 project at I extracted the essential bit (GeneralRulesCustom.js) into a simple Demo project attached to this post. I deleted all the standard source code to reduce the size of the file, but you can easily restore it after loading the project with the File Menu's "Reset Source Code" => "<Blank>" command. Then you should be able to build and run as HTML5 and see the Target Parameter functions working. Move the red ball to touch one of the blue bubbles, then press the Ctrl key repeatedly to move and change the direction of that bubble. Is this the functionality you were after?

News and Announcements / Re: Version 2.3.0 Released
« on: 2017-09-05, 12:43:03 PM »
Thanks for your input, maybe you can help me some more...

1. Can you switch the map/sprite editor of SGDK2 back to OpenGL 1.x? Please, or at least add modes to switch between.

The projects can maintain their OpenGL 3.x code (We would probably rewrite this myself for compatibility if needed) but forcing OpenGL 3.x support for the IDE itself removes so many users and forces people with commodity hardware to use older versions of SGDK2, which to my knowledge won't get the same HTML5 updates unless people copy over the newly generated HTML5 files and .cs rules into the project structure. I'm using a Thinkpad X61 with OpenGL 1.x capped support.

It doesn't really seem like a useful thing to force this version change since it doesn't matter whether map editors or sprite editors use OpenGL 1.x's immediate mode with quads or fancy OpenGL 3.x, they're doing simple things anyway! :)

I don't have a whole lot of OpenGL experience, and/or it's been a few months since did anything with OpenGL so my memory's getting fuzzy again; do you know what kinds of features are unique to post-1.x versions? I would have assumed the new lighting architecture (use of shaders) would be relying on something after OpenGL 1.x. So at a minimum, the map editor would not be able to show the effects of lighting.

Also, since you've dealt with it more recently, do you know when this requirement changed? How far back to users have to go to find a version they can use with OpenGL 1.x? Is there a hard version-based requirement that explicitly fails if the version is a problem, or do things just not work right and confusing errors occur? I wonder if it would be a simple matter of disabling a version check, or if I would have to back out the whole shader-based drawing architecture.

Hopefully there's some way to simply copy code from an older release and "switch" to it on user request, but your input might help me find the path of least resistance to doing so.

2. It would be nice if tile-categories could have their own separate drawing function. This would be very useful for the HTML5 projects. Because so many tiles on the screen are essentially 0 opacity, it wouldn't make sense to have to draw these each update, because the editor should know to skip these.

We could thus have a category for Invisible tiles.

Chrome and CEF are expensive for drawImage(), unlike many other browsers and related engines. Calling this function less times would lead to many good optimizations for the browser engine, namely speed. SGDK2 begins to lag around 3 or 4 layers!

Firstly I would point out that you can create a tile definition for any tile index that you don't want to draw, and delete the frame from it, which should prevent any drawing function from being called for that tile index. I'm not sure how well that fulfills your request, but if not entirely, I would ask why a drawing function would be associated with a tile category, and what's missing in the ability to control tile drawing via tile definitions. I would also point out that you can also use Tile definitions linked to a counter to control how tiles appear at run-time versus design-time. Frame 0 of the tile animation can be how the counter appears at design time, and frame 1 can be run-time. Then you just need a rule to increment the counter to 1 when the game starts. And frame 1 can have 0 frames in it if you want the tile to not be drawn at run-time. If you find that 0-frame tiles are being drawn at run-time, I think that's a bug.

*In addition with this, we could write custom draw functions that allowed us to access the frame data of tiles. I can think of some cool things that I would do with this already!*

I've already written the code but my project is messy and it's under a form of NDA, but it would be nice if this could be included in the mainstream SGDK, such as in the very next version.

I think you can already do a lot of cool things with animated tile definitions by fiddling with how the counter is updated instead of assuming that the counter always simply increments on every frame, and is shared by all animated tiles. Hopefully a lot of what you want can already be done.

3. SetTargetParameter for sprites could be a nice option to add to the HTML5 projects, though my approach is too hacky to be mainstream.

Do you assume that I can come up with a less-hacky version? :) I'll have to remember to look into it. I'm kind of surprised that it's not already implemented, but it shouldn't be hard because JavaScript especially is good at run-time reflection type stuff and should easily be able to identify and update properties by name at run-time. (I hate how my browser doesn't think runtime is a word so I keep hyphenating it :) ).

4. Real time color/alpha blending, as well as custom draw functions for sprites would be a nice option.

You mean you want the real-time color blending that is available in the EXE build to also be available in the HTML5 build? Do you know how to implement that in JavaScript /HTML5 code? Or if it's even possible?

5. Adding a nice music library for playing music could be a nice option, though I've written my own.

You mean for HTML5? Do you know of any good open source libraries? Or do you think yours would qualify?

6. Replace the color wheel with a custom graphic, which is useful for custom palettes

Do you mean to add an item to the menu to browse for a custom color wheel? Why replace the color wheel instead of replacing the default set of colors. The color wheel allows you to select all colors while the palette below allows you to select from a predefined set of colors. Alternatively, I think you can right-click on any pixel in the graphic sheet to pick its color if you want to store your palettes on the graphic sheets. Does that help?

Help, Errors, FAQ / Re: FAQ List
« on: 2017-08-29, 06:42:18 AM »
Whenever I have the choice I go with UTF-8 encoding, as, I believe, does .NET in general. So it's most likely UTF-8, which is usually 1 byte per character for English text. Changing the encoding should have little effect as long as JavaScript interprets its strings to have the same content at run-time. UTF-8 and ANSI should result in the same content for the kind of code generated by SGDK2.

Help, Errors, FAQ / Re: FAQ List
« on: 2017-08-12, 02:49:41 PM »
Byes per tile determines how much memory is consumed per tile in the compiled game *and* in RAM *and* in any saved game files generated while playing the game (with the SaveGame function). However the HTML representation may take more than 1 byte per tile in some cases. If you need more detail about that, I can explain, but you may be able to figure that out on your own by looking at the generated HTML. You can kind of see the maps in the code easily because I made a point of representing maps layers as JavaScript strings in a way you could kind of see in a text editor.

There must be some other factor in the error you are encountering. I created a simple demo project with a counter called Animation linked to an animated tile. See the attachment. (7-Zip required to extract content.)

Off-Topic / Re: What I've been doing since LoK:Revival
« on: 2017-06-08, 06:52:05 PM »
I have a new system and I've re-installed Unity and re-imported the data. Unity now supports directly importing from Sketchup, which I don't think it did before. So the data is a fraction of the size of the project I compiled a couple months ago. But my new system is too fast to get a good idea of how well this performs on low end systems. Can you determine how this new build compares to the recent build and the old build?

Pages: [1] 2 3 ... 184