SGDK Version 2 > News and Announcements

Version 2.3.0 Released

(1/3) > >>

bluemonkmn:
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:
Very cool!  It looks terrific and I really like the fact that it opens up new possibilities for exploration games. 

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

bluemonkmn:
Thanks for your input, maybe you can help me some more...


--- Quote from: Plush on 2017-09-04, 02:25:00 AM ---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! :)

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


--- Quote from: Plush on 2017-09-04, 02:25:00 AM ---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!

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


--- Quote from: Plush on 2017-09-04, 02:25:00 AM ---*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.

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


--- Quote from: Plush on 2017-09-04, 02:25:00 AM ---3. SetTargetParameter for sprites could be a nice option to add to the HTML5 projects, though my approach is too hacky to be mainstream.

--- End quote ---

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


--- Quote from: Plush on 2017-09-04, 02:25:00 AM ---4. Real time color/alpha blending, as well as custom draw functions for sprites would be a nice option.

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


--- Quote from: Plush on 2017-09-04, 02:25:00 AM ---5. Adding a nice music library for playing music could be a nice option, though I've written my own.

--- End quote ---

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


--- Quote from: Plush on 2017-09-04, 02:25:00 AM ---6. Replace the color wheel with a custom graphic, which is useful for custom palettes

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

bluemonkmn:
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?

Navigation

[0] Message Index

[#] Next page