Author Topic: Version 2.3.0 Released  (Read 639 times)

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2752
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Version 2.3.0 Released
« on: 2017-02-20, 09:53:54 PM »
This version represents a relatively significant SGDK2 release, primarily introducing some real-time lighting features. Although there is no flashy demo included in the release, there is a new "Lighting Patterns" template that will help people get started with the new features, as well as a new tutorial to manually walk through each feature related to lighting from scratch. I've posted a video walking through and taking a look at the features available in the Lighting Patterns template project: https://youtu.be/XGWmeh3uUcM. See a full list of what's new in SGDK 2.3.0 at the what's new page in the online documentation.


Vincent

  • SGDK2 Addict
  • Expert
  • Fanatic
  • *****
  • Posts: 610
  • Legacy of Kain: Revival is completed!!!
    • View Profile
    • Chivalrous Games
    • Email
Re: Version 2.3.0 Released
« Reply #1 on: 2017-02-21, 07:07:34 AM »
Very cool!  It looks terrific and I really like the fact that it opens up new possibilities for exploration games. 
Legacy of Kain: Revival completed!
http://lokrevival.webs.com

See also my company website:
http://chivalrousgames.com

Plush

  • Visitor
  • *
  • Posts: 13
    • View Profile
    • Email
Re: Version 2.3.0 Released
« Reply #2 on: 2017-09-04, 02:25:00 AM »
I love SGDK2 for rapidly prototyping HTML5 code that I can modify later. You've always been good at adding things based on user feedback, like the folder structures in the project tree. Let me ask some questions:

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! :)

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!

*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.

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

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

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

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

Thanks!
« Last Edit: 2017-09-05, 01:03:32 AM by Plush »

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2752
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: Version 2.3.0 Released
« Reply #3 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?

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2752
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: Version 2.3.0 Released
« Reply #4 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 http://iotabuildit.sourceforge.net/. 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?

Plush

  • Visitor
  • *
  • Posts: 13
    • View Profile
    • Email
Re: Version 2.3.0 Released
« Reply #5 on: 2017-09-16, 12:06:58 PM »
Quote
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.

Version 2.2.10 is the version I currently use.

Quote
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.

I am very sorry for this. This is an amazing feature that I did not know existed after nearly 12 years of using this program.

Quote
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.

You have support for linear transformations (Through matrix elements) to resize and shear frames. For my application, I find myself doing complex things such as plotting each scanline of a frame to a position on a sine-wave and then modifying the argument of the sine wave to simulate wavy light-diffraction for a water-based level.

Things like these currently cannot be done with Framesets unless you go out of your way to have a frame for each scanline and stack the frames on each other. I've originally used this complicated method and other methods. Eventually I was forced to write my own custom draw function and heavily modify SGDK2's source code.

However, I'd REALLY love if we could have custom draw functions for each tile category! It would make things so much easier!

*It would be nice if you allowed us to apply our own custom linear transformation with a custom matrix to the frame in the Frameset editor like the shear matrix and scaling matrices that you use to resize, shear, and rotate the frame. (Though this wouldn't be intuitive to the non-mathy user), which would be similar in power to having a custom draw function. ******(But I feel letting us write our own custom draw function for each tile type would work just as well and be easier to implement)

Quote
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?

As of yet I haven't found any practical real-time way to perform this. getImageData() and putImageData() technically work but are very slow in real-time.

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

I'm using Sound.js, but I had to go a little further than the average SGDK2 user to get it to work.

Quote
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?

I'm silly. You're a genius. Sorry ^_^

EDIT

LimitFrameRate doesn't limit the Framerate to the correct speed in my version of SGDK2, you may have fixed this in a later version.

In my current version priorities don't work correctly between layer priorities and sprite priorities in the HTML5 version, for instance, try having a layer priority of 0 and test this.
« Last Edit: 2017-09-17, 08:22:44 AM by Plush »

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2752
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: Version 2.3.0 Released
« Reply #6 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?
« Last Edit: 2017-09-19, 07:33:46 AM by bluemonkmn »

Plush

  • Visitor
  • *
  • Posts: 13
    • View Profile
    • Email
Re: Version 2.3.0 Released
« Reply #7 on: 2017-09-21, 03:34:00 AM »
Quote
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.

If I set the framerate to a value, it's still usually much faster than that value. I'm trying to synchronize the FPS of my game as such using Date() rather than setInterval()

Quote
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?

It's great so far. I guess my usecase is very unusual for the average user.

I see that in the C# projects, one can use a custom class other than SpriteBase for sprites, will this ever be functionality in the JS equivalent?

I'm interested in having a separate class for sprites that need to be synchronized over a network in Javascript, called NetSprites.

I'd also be interested in having a custom draw function for categories of sprites as well!

I'll likely have to implement much of this using hacky approaches
 

Here's a modification I made to Frame.prototype.draw() to handle other color modes (In this case, multiply) and to disable to "ugly" smooting that happens when you transform a frame.

Code: [Select]
Frame.prototype.draw = function(ctx, x, y) {
   if (this.imageSource == null) return;
   ctx.imageSmoothingEnabled = false;
   ctx.globalCompositeOperation = "screen";



   ctx.drawImage(this.imageSource, (this.cellIndex % this.graphicSheet.columns) * this.graphicSheet.cellWidth,
   Math.floor(this.cellIndex / this.graphicSheet.columns) * this.graphicSheet.cellHeight,
   this.graphicSheet.cellWidth, this.graphicSheet.cellHeight, x, y, this.graphicSheet.cellWidth, this.graphicSheet.cellHeight);
   context.globalCompositeOperation = "source-over";
};

It would be nice if the Frameset editor had another option underneath the modulate RGB/Alpha area to select the color blending mode in HTML5 for a single frame. Things like multiply could be used for smoke, and things like screen could be used for the brightness of say, fire. This would be a very easy modification to make and would make for beautiful particle effects by blending tiles and sprites with the layers before them. This would be per frame so you could have really beautiful lighting-type effects.

More information on HTML5's color blending modes:
https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/globalCompositeOperation

It would also be cool if I could use a custom Frameset matrix in the framset editor to multiply the RGB values of a pixel, (x,y) by a transform matrix, in order to make say, an RGB -> YUV transform generated before runtime, where I could then discard the U and V and get a monochrome version of the frame. The current modulate color blending parameters can't do this in the frameset editor, they only tint the entire image.
« Last Edit: 2017-09-21, 07:30:23 AM by Plush »

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2752
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: Version 2.3.0 Released
« Reply #8 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.

Plush

  • Visitor
  • *
  • Posts: 13
    • View Profile
    • Email
Re: Version 2.3.0 Released
« Reply #9 on: 2017-09-24, 02:56:29 PM »
I'd be honored to help as a developer of SGDK2. I've seen so much done to this program over the years and I can't believe you'd invite me to work with it.

Thanks for the offer!

Will you upload this project to github?

As for a demo of the framerate problem, I'm just testing the LimitFrameRate call on Chrome. I'm not sure why it's happening.

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2752
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: Version 2.3.0 Released
« Reply #10 on: 2017-09-25, 07:34:45 AM »
SourceForge already functions as the host for SGDK2 source control (using subversion) at https://sourceforge.net/p/sgdk2/code/HEAD/tree/. 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 https://danielpocock.com/migrating-a-sourceforge-project-from-subversion-to-git. 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.

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2752
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: Version 2.3.0 Released
« Reply #11 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 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?

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2752
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: Version 2.3.0 Released
« Reply #12 on: 2017-10-30, 07:33:21 AM »
Further discussion of features moved here.