1
News / Re: Stencyl 4 - Out Now! (4.0.1)
« on: March 05, 2019, 12:52:14 pm »
hell yeah
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.
2
Toolset Extensions / Re: Themes extension
« on: August 16, 2018, 11:54:17 pm »
version 1.2.2 supports extension blocks
3
Toolset Extensions / Re: Themes extension
« on: July 21, 2018, 08:03:30 pm »
version 1.2.1 adds Stencyl 3.4+ support, sorry about that!
4
Toolset Extensions / Re: Themes extension
« on: July 21, 2018, 03:52:58 pm »
Ok, 1.2.0 is out. same link points to it, or click here
A bunch of tweaks and fixes. support for new comment block, and backwards compatibility checks.
It also adds a default_grayBG theme for LIBERADO
aand most of the other sections have changes but i don't want to flood this with images
unfortunately, there is no way to make that top bar under "behavior" to be a flat color. internally it lightens the bottom. i can make the bottom darker to make it look flat after it gets lightened, but that makes a lot of areas non-flat everywhere else. I've opted to keep only the designer mode bar non-flat because that is the only area affected when keeping it this color, while everywhere else looks better.
A bunch of tweaks and fixes. support for new comment block, and backwards compatibility checks.
It also adds a default_grayBG theme for LIBERADO
aand most of the other sections have changes but i don't want to flood this with images
unfortunately, there is no way to make that top bar under "behavior" to be a flat color. internally it lightens the bottom. i can make the bottom darker to make it look flat after it gets lightened, but that makes a lot of areas non-flat everywhere else. I've opted to keep only the designer mode bar non-flat because that is the only area affected when keeping it this color, while everywhere else looks better.
5
Toolset Extensions / Themes extension
« on: July 21, 2018, 01:33:48 am »
hi i made a toolset extension that allows you to change Stencyl's theme
>> download it here <<
then place in [WORKSPACE]/extensions
it comes with two themes i made: DarkFlat and DarkNeon. they look like this:
DarkFlat
DarkNeon
the rest of Stencyl looks like this in both themes:
and you can choose a theme through the extension options:
<3
Eventually I'll add support for you to create your own themes!
For now if you have a theme you want me to add, you can reply and I'll put it in manually.
Versions
1.2.2
- support extension custom blocks
- support for Stencyl 3.4 (maybe earlier)
- new comment block color support
- compatibility support for builds without certain blocks
- tweaks to some colors
- added default_grayBG theme
1.1.0
- initial release
- added DarkFlat and DarkNeon themes
6
Journals / Re: Bunosphere! - LD38
« on: April 24, 2017, 09:12:39 pm »
@squeeb yep! I thought on it a lot and there was no good (fast) way to implement skewing, so any sprite that scales has to rotate towards the player (center), so that it scales parallel/perpendicular to the "camera". I originally planned for all sprites to scale, and therefore rotate, but i realized i could make spherical-looking objects and those don't have to rotate.
@merrak thank you! Yeah there were a ton more games similar to this visual than i expected, I hope mine stands out at least somewhat. I appreciate the compliments
@merrak thank you! Yeah there were a ton more games similar to this visual than i expected, I hope mine stands out at least somewhat. I appreciate the compliments
7
Journals / Re: Bunosphere! - LD38
« on: April 24, 2017, 07:09:56 pm »
oh man thanks for the nice words everyone!! I totally thought i had email notifications turned on. guess not!
@mdotedot ooh yeah good idea!! I have now submitted it
@squeeb the trees are actually composed of 2 sprites: one non-scalable leaves sprite, and one scalable trunk sprite.
@mdotedot ooh yeah good idea!! I have now submitted it
@squeeb the trees are actually composed of 2 sprites: one non-scalable leaves sprite, and one scalable trunk sprite.
8
Journals / Bunosphere! - LD38
« on: April 24, 2017, 10:51:59 am »
Hey! I made another game! Ludum Dare!
Solve puzzles and explore as a small bunny in this strange world. Who knows what you'll find?
Play it here:
https://ldjam.com/events/ludum-dare/38/bunosphere
https://torcado.itch.io/bunosphere
http://torcado.com/LD38/
Solve puzzles and explore as a small bunny in this strange world. Who knows what you'll find?
Play it here:
https://ldjam.com/events/ludum-dare/38/bunosphere
https://torcado.itch.io/bunosphere
http://torcado.com/LD38/
9
Journals / Re: Ghost Bird
« on: April 16, 2017, 04:23:00 pm »
whew boy, it's been a while!
As mentioned before, i've been prioritizing updates on tigsource but I'll still try to remember to update here
So to catch yall up,
I took a contracting job to make a mobile game (in stencyl) which took a long time and is the main reason for my absence on the game. That has been recently finished and released, and I have since started working on Ghost Bird again!
I began by deciding to remake the whole game.
I built off of the original LD build into what it is now, meaning theres a ton of left over crappy code and assets that i don't want. I'm basically going to be manually programming the most important parts (game scale stuff) and copy/pasting the complicated stuff (shaders and lighting)and probably just copy-paste all the other stuff while moving things around, etc.
I've even written a design doc exclusively on how i'm going to organize my code and assets (which i won't share because it is probably of no use to anyone else)
I've also made some cool things take a look:
now aint that neat.
this is mainly progress from rebuilding the game. the previous images were all on the previous build. This one is (and will be) a lot cleaner, but most of this is copied code so its not much faster, but that's fine.
I have finally gotten around to fleshing out the design for the world/story/etc. with the help of a friend or two. I've mapped out the base layout of the world, including zones and path progression. I've also figured out a general story and some branching paths/endings. Next will be to go into more detail, designing rooms and puzzles, etc.
and finallyy neW THINGS IM EXCITED ABOUT!
Check out these new and improved shrooms!!
Now, the mushrooms aren't the thing i'm so excited about, just a vessel of it:
I have finally figured out a way to draw on top of my lighting shader while still under the other shaders!*
*It's not actually drawn on top, as we will see in my explanation below
The thing I disliked most about my lighting, specifically the colored lights part, is that it washed out, flattened, and overpowered basically everything on screen in that area. I've spent the most time tweaking color values in such a way to minimize over-flooding necessary detail, while maximizing the prettiness of the lights, because the less opaque I make the lights, the less likely i'll get the colors to match up to the ones I want in my palette. for instance: the brightest blue in that latest gif needs to be fairly opaque in order to turn out that color, but because I couldn't draw beneath the shader, it would just make every pixel in that area that color, and I really hated it. You can tell in the older mushroom gif how low-intensity the lights are. That's the other end of the extreme, and neither looks that great in my eyes, or at least it's not perfect.
This is what they looked like before, and what they would've looked like if I didn't make the lights so dim. The light itself looks so much cooler, but it's totally useless if you can't see what's emitting it!
So, I basically needed a way to draw between the shaders.
For the longest time this has been the last thing i've considered impossible to do. I never thought I'd be able to do the original lighting, never thought i'd be able to turn it into a shader, never thought i'd optimize the lighting algorithm enough to use in the game, etc. etc. I've surpassed them all for the most part, except the one; drawing between shaders. I spent a long time thinking about this and basically regarded it as impossible to do in Stencyl. I needed to be able to split shaders into layers and draw between them, so I could have my pixel quantization, color palette, and screen warp shaders still in effect and the lighting shader overwritten. Before transitioning to shaders I could do this pretty well:
I have 2 different layers of lighting here: One in front of tiles, and one behind. and both are behind this beautiful ghost bird.
This was great because I could have high-intensity light on the background, while maintaining detail on the tiles and other stuff immediately behind the light.
(Also these gifs just made me realize I've forgotten to add the light-trail thing in the newer build. maybe it looks better without it? I don't know. Let me know what you think please thanks)
Anyway, here's how I did it.
Just like the dumb hacky way I'm currently sending the tile data and light color arrays to the shader (arrays of 10-digit integers, mod-ing/floor dividing to grab sections of digits as data), This "fix" is too, dumb and hacky.
Basically I'm doing another check in the lighting shader to see if it should draw onto the current pixel or not. The only data any pixel could have is 3 8bit RGB colors (and a useless constant alpha). So What I'm doing is i'm quantizing (boy I guess I love this word) each 255 integer to a multiple of 16, and checking if each R G and B value is a multiple of 16, and iff it is, don't draw on top of it.
Because this is terrible and hacky, this basically only works in the case that Ghost Bird is in currently. I'm restricting the game to a small color palette, so I can almost guarantee that none of the colors in the game will randomly create a false-positive for this check. Even the lighting that uses very much off-palette colors, which used to be drawn on screen normally, is being drawn within the same shader so there's no way these colors could accidentally create false positives either. Any other game and there would be random misplaced pixels.
Also I'm not too sure about the nitty-gritty details of shaders, but this extra check could possibly be saving GPU time. I've read that if-statements are not good because of divergence (maybe this specific check is ok though?), so that may attribute to a slower shader, but if it's not too much slower the check basically exits the whole shader code for that pixel, which has a ton of stuff like color blending, etc.
But yeah. There you go. Final annoyance solved. I have full control over what colors are drawn to the screen. I no longer have anything to whine about besides my own working speed.
Time to go make everything even more pretty!
As mentioned before, i've been prioritizing updates on tigsource but I'll still try to remember to update here
So to catch yall up,
I took a contracting job to make a mobile game (in stencyl) which took a long time and is the main reason for my absence on the game. That has been recently finished and released, and I have since started working on Ghost Bird again!
I began by deciding to remake the whole game.
I built off of the original LD build into what it is now, meaning theres a ton of left over crappy code and assets that i don't want. I'm basically going to be manually programming the most important parts (game scale stuff) and copy/pasting the complicated stuff (shaders and lighting)and probably just copy-paste all the other stuff while moving things around, etc.
I've even written a design doc exclusively on how i'm going to organize my code and assets (which i won't share because it is probably of no use to anyone else)
I've also made some cool things take a look:
now aint that neat.
this is mainly progress from rebuilding the game. the previous images were all on the previous build. This one is (and will be) a lot cleaner, but most of this is copied code so its not much faster, but that's fine.
I have finally gotten around to fleshing out the design for the world/story/etc. with the help of a friend or two. I've mapped out the base layout of the world, including zones and path progression. I've also figured out a general story and some branching paths/endings. Next will be to go into more detail, designing rooms and puzzles, etc.
and finallyy neW THINGS IM EXCITED ABOUT!
Check out these new and improved shrooms!!
Now, the mushrooms aren't the thing i'm so excited about, just a vessel of it:
I have finally figured out a way to draw on top of my lighting shader while still under the other shaders!*
*It's not actually drawn on top, as we will see in my explanation below
The thing I disliked most about my lighting, specifically the colored lights part, is that it washed out, flattened, and overpowered basically everything on screen in that area. I've spent the most time tweaking color values in such a way to minimize over-flooding necessary detail, while maximizing the prettiness of the lights, because the less opaque I make the lights, the less likely i'll get the colors to match up to the ones I want in my palette. for instance: the brightest blue in that latest gif needs to be fairly opaque in order to turn out that color, but because I couldn't draw beneath the shader, it would just make every pixel in that area that color, and I really hated it. You can tell in the older mushroom gif how low-intensity the lights are. That's the other end of the extreme, and neither looks that great in my eyes, or at least it's not perfect.
This is what they looked like before, and what they would've looked like if I didn't make the lights so dim. The light itself looks so much cooler, but it's totally useless if you can't see what's emitting it!
So, I basically needed a way to draw between the shaders.
For the longest time this has been the last thing i've considered impossible to do. I never thought I'd be able to do the original lighting, never thought i'd be able to turn it into a shader, never thought i'd optimize the lighting algorithm enough to use in the game, etc. etc. I've surpassed them all for the most part, except the one; drawing between shaders. I spent a long time thinking about this and basically regarded it as impossible to do in Stencyl. I needed to be able to split shaders into layers and draw between them, so I could have my pixel quantization, color palette, and screen warp shaders still in effect and the lighting shader overwritten. Before transitioning to shaders I could do this pretty well:
I have 2 different layers of lighting here: One in front of tiles, and one behind. and both are behind this beautiful ghost bird.
This was great because I could have high-intensity light on the background, while maintaining detail on the tiles and other stuff immediately behind the light.
(Also these gifs just made me realize I've forgotten to add the light-trail thing in the newer build. maybe it looks better without it? I don't know. Let me know what you think please thanks)
Anyway, here's how I did it.
Just like the dumb hacky way I'm currently sending the tile data and light color arrays to the shader (arrays of 10-digit integers, mod-ing/floor dividing to grab sections of digits as data), This "fix" is too, dumb and hacky.
Basically I'm doing another check in the lighting shader to see if it should draw onto the current pixel or not. The only data any pixel could have is 3 8bit RGB colors (and a useless constant alpha). So What I'm doing is i'm quantizing (boy I guess I love this word) each 255 integer to a multiple of 16, and checking if each R G and B value is a multiple of 16, and iff it is, don't draw on top of it.
Code: [Select]
vec4 origColor = texture2D(uImage0, vTexCoord);
if((colored) && (mod(floor(origColor.rgb * 255.0 + 0.5), 16.0) == vec3(0.0))){
gl_FragColor = origColor;
} else {
Because this is terrible and hacky, this basically only works in the case that Ghost Bird is in currently. I'm restricting the game to a small color palette, so I can almost guarantee that none of the colors in the game will randomly create a false-positive for this check. Even the lighting that uses very much off-palette colors, which used to be drawn on screen normally, is being drawn within the same shader so there's no way these colors could accidentally create false positives either. Any other game and there would be random misplaced pixels.
Also I'm not too sure about the nitty-gritty details of shaders, but this extra check could possibly be saving GPU time. I've read that if-statements are not good because of divergence (maybe this specific check is ok though?), so that may attribute to a slower shader, but if it's not too much slower the check basically exits the whole shader code for that pixel, which has a ton of stuff like color blending, etc.
But yeah. There you go. Final annoyance solved. I have full control over what colors are drawn to the screen. I no longer have anything to whine about besides my own working speed.
Time to go make everything even more pretty!
10
Ask a Question / draw above shaders / resize window
« on: April 04, 2017, 05:00:29 pm »
Seemingly unrelated questions but very much so in this weird issue I've found.
Basically this started from a need to be able to resize the game window. I am currently using Engine.stage.resize() and I have a shader that quantizes pixels to remove in-betweens, so i can scale up/down by integers perfectly
This has a strange side effect with the shaders, which is probably related to the issue ill describe in a bit:
The shaders will only ever be as big as the scale of the game when started. so not only do i need to start in x4 scale, but when I downsize, I need to write the shaders in a way that only uses a portion of the screen. So when i go down to x3 i need to work with a box in the lower left corner that's 3/4ths the size of the whole shader. I've figured all that out before and it works fine. I have realtime window scaling on 1x-4x integers.
Main issue:
I really need a way to be able to draw above my shaders to implement some ideas I have. There exists a "toggle shaders for HUD layer" function which I could theoretically use for this! Just draw whatever on the hud layer and it will be above my shaders. And in fact, this does work, except that anything drawn above the shader will always be at the base resolution of the game. So at 4x scale, it looks fine. Once I go down to 3x or lower, anything above the shader is bigger than it should be for that scale. And in fact, it is at the same size as the shader itself.
Also, I say "anything drawn above the shader" instead of "anything drawn on the HUD layer" because this doesn't just affect the HUD layer, if I use the layer.addChild() model for adding the shader to a specific layer, this scaling issue affects all layers above it.
(Pic for reference later)
Possible Solutions:
- Have 4 differently scaled sprites for everything I want drawn above the shaders and pick the correct one based on scale, and also change drawing locations based on scale. Should work, but would be very tedious.
- If there's a way to grab anything drawn to a shader, like how the [current screen as image] block works, I could resize the image and draw that instead.
- Find a different way to resize the game than Engine.stage.resize. I've looked into this more than all the other answers, nothing I've tried works.
- Don't let player resize game on runtime, instead only allow window size before game starts. This way shaders will be the correct size, and this would probably save CPU time on lower scales, since I'm not wasting shader screenspace. I'm not sure how I'd do this though. The only way I could think of doing it is by exporting 4 different builds, one per scale, and running the one the player wants. but that's annoying and such a waste of disk space.
Secondary issue:
There are many many cases in which I'd love to have something affected by some shaders but not others. In fact, I'd actually want this much more than any solution I proposed above, but I have a strong feeling this isn't coming any time soon. If anyone could prove me wrong and give me a little more hope, I'd be so happy.
Anyway, taking an example from the screenshot I posted above, there are 4 shaders in play here:
- Lighting triangles
- Screen warp
- Pixel quantization
- Color mapping
The lighting shader draws black on most of the screen. If i wanted the player to see something that's in the black areas, I'd need to draw it above that shader. But at this point everything else would go out of whack; the sprite would be positioned wrong because of the screen warp, the sprite may not be the right color, and the sprite may be drawn between pixels (ugly!).
The only conceivable solution that I've come up with is to use a specific color to draw the sprite, so that the shaders (specifically the lighting one) can detect that color and not draw black on top of it, and instead make it the correct color. The downside of this, of course, is that I can only have 1-color sprites drawn above the lighting.
otherwise I'd have to try to mimic the screen-warp and, somehow, the pixel quantization shaders using the image API or something like that.
Thanks if you read all of that. If anyone has any ideas about any of this, I'd love to hear them!
Basically this started from a need to be able to resize the game window. I am currently using Engine.stage.resize() and I have a shader that quantizes pixels to remove in-betweens, so i can scale up/down by integers perfectly
This has a strange side effect with the shaders, which is probably related to the issue ill describe in a bit:
The shaders will only ever be as big as the scale of the game when started. so not only do i need to start in x4 scale, but when I downsize, I need to write the shaders in a way that only uses a portion of the screen. So when i go down to x3 i need to work with a box in the lower left corner that's 3/4ths the size of the whole shader. I've figured all that out before and it works fine. I have realtime window scaling on 1x-4x integers.
Main issue:
I really need a way to be able to draw above my shaders to implement some ideas I have. There exists a "toggle shaders for HUD layer" function which I could theoretically use for this! Just draw whatever on the hud layer and it will be above my shaders. And in fact, this does work, except that anything drawn above the shader will always be at the base resolution of the game. So at 4x scale, it looks fine. Once I go down to 3x or lower, anything above the shader is bigger than it should be for that scale. And in fact, it is at the same size as the shader itself.
Also, I say "anything drawn above the shader" instead of "anything drawn on the HUD layer" because this doesn't just affect the HUD layer, if I use the layer.addChild() model for adding the shader to a specific layer, this scaling issue affects all layers above it.
(Pic for reference later)
Possible Solutions:
- Have 4 differently scaled sprites for everything I want drawn above the shaders and pick the correct one based on scale, and also change drawing locations based on scale. Should work, but would be very tedious.
- If there's a way to grab anything drawn to a shader, like how the [current screen as image] block works, I could resize the image and draw that instead.
- Find a different way to resize the game than Engine.stage.resize. I've looked into this more than all the other answers, nothing I've tried works.
- Don't let player resize game on runtime, instead only allow window size before game starts. This way shaders will be the correct size, and this would probably save CPU time on lower scales, since I'm not wasting shader screenspace. I'm not sure how I'd do this though. The only way I could think of doing it is by exporting 4 different builds, one per scale, and running the one the player wants. but that's annoying and such a waste of disk space.
Secondary issue:
There are many many cases in which I'd love to have something affected by some shaders but not others. In fact, I'd actually want this much more than any solution I proposed above, but I have a strong feeling this isn't coming any time soon. If anyone could prove me wrong and give me a little more hope, I'd be so happy.
Anyway, taking an example from the screenshot I posted above, there are 4 shaders in play here:
- Lighting triangles
- Screen warp
- Pixel quantization
- Color mapping
The lighting shader draws black on most of the screen. If i wanted the player to see something that's in the black areas, I'd need to draw it above that shader. But at this point everything else would go out of whack; the sprite would be positioned wrong because of the screen warp, the sprite may not be the right color, and the sprite may be drawn between pixels (ugly!).
The only conceivable solution that I've come up with is to use a specific color to draw the sprite, so that the shaders (specifically the lighting one) can detect that color and not draw black on top of it, and instead make it the correct color. The downside of this, of course, is that I can only have 1-color sprites drawn above the lighting.
otherwise I'd have to try to mimic the screen-warp and, somehow, the pixel quantization shaders using the image API or something like that.
Thanks if you read all of that. If anyone has any ideas about any of this, I'd love to hear them!
11
Ask a Question / Re: Shader Questions
« on: January 08, 2017, 08:16:15 pm »
oh I see. yeah either way works. I'm not sure which would be faster
12
Ask a Question / Re: Shader Questions
« on: January 08, 2017, 07:28:45 pm »
math operations may be faster to run in the shader, but I'm not sure.
the 0-1 number is called a float, and it's relationship to the texture coordinates is usually denoted as the 'uv'
what I do is just send the current scale to the shader.
I'm not sure why you would want to convert to a float outside of the shader anyway. That's only ever used to get the current fragment position inside the main shader body, which runs asynchronous to the game logic. unless I'm just missing something.
the 0-1 number is called a float, and it's relationship to the texture coordinates is usually denoted as the 'uv'
what I do is just send the current scale to the shader.
I'm not sure why you would want to convert to a float outside of the shader anyway. That's only ever used to get the current fragment position inside the main shader body, which runs asynchronous to the game logic. unless I'm just missing something.
13
Ask a Question / Re: Shader Questions
« on: January 08, 2017, 11:24:06 am »
yes you're right, you do need to use the texture for each individual shader.
as for enabling/disabling individual shaders, what I do is just save each shader to their own attribute, then when I want to use different shaders I just clear all shaders then apply a new one using the shader combine block with the shaders you want
what you could do from there is add each shader to an array, and apply the shaders based on that. that may require some code though, I haven't tried it
There is an undocumented(?) shader variable called uResolution, which is a vec2 and holds the base game resolution (I think)
if it is the base resolution and not the current resolution after scaling, you will have to do some weird math to get the right pixel coordinates.
as for enabling/disabling individual shaders, what I do is just save each shader to their own attribute, then when I want to use different shaders I just clear all shaders then apply a new one using the shader combine block with the shaders you want
what you could do from there is add each shader to an array, and apply the shaders based on that. that may require some code though, I haven't tried it
There is an undocumented(?) shader variable called uResolution, which is a vec2 and holds the base game resolution (I think)
if it is the base resolution and not the current resolution after scaling, you will have to do some weird math to get the right pixel coordinates.
14
Windows / Mac / Flash / HTML5 / Spell Bear
« on: December 11, 2016, 07:44:53 pm »
Hey here's my Ludum Dare 37 game!
http://ludumdare.com/compo/ludum-dare-37/?action=preview&uid=5839
Spell Bear!
You are practicing magic when suddenly, oh no! Everything goes wrong! Now the whole room is out to get you!
Use your awesome wizardry skills to stay alive and get cash money!
Upgrade your skills to become undefeatable!
CONTROLS:
Movement: WASD or ARROW KEYS
Attack: Hold LEFT MOUSE BUTTON
Aim: Move MOUSE
Thanks for playing!
http://ludumdare.com/compo/ludum-dare-37/?action=preview&uid=5839
Spell Bear!
You are practicing magic when suddenly, oh no! Everything goes wrong! Now the whole room is out to get you!
Use your awesome wizardry skills to stay alive and get cash money!
Upgrade your skills to become undefeatable!
CONTROLS:
Movement: WASD or ARROW KEYS
Attack: Hold LEFT MOUSE BUTTON
Aim: Move MOUSE
Thanks for playing!
15
Journals / Re: Ghost Bird
« on: November 19, 2016, 03:08:33 pm »
progress from stream number 4
progress from stream number 5 boo hoo nobody joined to watch this stream.also it was the stream i made the most progress on anything...
Here's the animation by itself
Also I bought a new microphone so stream quality will go waay up once that arrives
- New night theme for grass area. May still play around with colors and such
- Made a systems to get waterfalls working (shown below)
progress from stream number 5 boo hoo nobody joined to watch this stream.also it was the stream i made the most progress on anything...
- Waterfalls work completely.
- Sprite and animation for water source, a lion head
- New magic source, a crystal that turns on and off at intervals (or is always on)
- Waterfalls turn beam orbs when running atop them
- Player physics changed to account for spinning orb; player now moves with the rotation
- Beam orb physics changed; now they're a lot easier to point in the direction you want
Here's the animation by itself
Also I bought a new microphone so stream quality will go waay up once that arrives
