Do not worry this thread is not forever dead… after I finish the book I plan to continue posting more tips! I’ve been making many interesting discoveries and tricks that may not be immediately obvious and found some things which are usable but not documented at all!
Great. Please post any lacking documentation and we’ll fix that.
Demonstrating the various easing equations built in with how they work with go.animate
Working on this for the book. Run this example, and press up / down to go through the different easing equations. Then left click to animate the Defold logo to the new position. Ghosts of the Defold logo are created as it is repositioned by the animation to so the path clearly, and a white dot is left at the original position to more clearly show how some of the easing equations differ.
I plan to improve it, such as having a mode for the logo to move around randomly within the space after it completes each animation. Todo…
Web version: https://www.bookofdefold.com/examples/DefoldEasingEquations/
EasingEquations.zip (18.6 KB)
Nice! Thanks for sharing!
I just found this and it made my day - I’ve been trying to get the low-res font in Labyrinth to filter by nearest for a while and I put it on the back burner, now I can fix that!
f.lux will cause any Defold game (well, probably the entire screen) to stutter during the transition to “night shift”
Configuration settings retrieved with sys.get_config() are returned as string values; if you’re reading something that needs to be treated as a number (such as display height), use the Lua ‘tonumber’ function to convert the string into a number:
tonumber(sys.get_config("display.height"))
To get the size of a sprite that has been scaled, multiply the width/height by the sprite’s scale amount; for example:
local spriteWidth = go.get("#spriteAsteroid", "size.x") * go.get("#spriteAsteroid", "scale.x")
There are a few issues with this snippet of code:
- You call it spriteWidth but you base it on size.y. It should either be spriteHeight or you should base it on sprite.x
- You are ignoring the sprite scale. You need to also use
go.get("#spriteAsteroid", "scale.y")
- Sprites can be non uniformly scaled. I think you should multiply with
go.get_scale_vector().y
instead ofgo.get_scale()
I recently created an example of how to detect clicks on game objects with a sprite component and had to use to tale into account both scale of game object and of the sprite to get correct results.
Gosh darn it…sorry 'bout the typos, and thanks for the info in #3!
Correcting my original post now…
Bryan
@Pkeod, did you ever finish your supersampling vs multisampling in Defold investigation? Any results to share?
I should revisit again sometime soon and do new tests as I did leave things unfinished. I wasn’t happy with the results for a 3D project I was testing and gave up for the time being.
Defold has SSAA built in. This is the samples option in the game.project file. Other methods have to be setup manually as post processing shaders - I can publish examples later, it would be handy to be able to be able to drop the different methods in/out quickly.
For 2D projects, these features are not really useful. For 3D projects they can be used to reduce things like jagged edges / aliasing. As Defold’s 3D features improve, then they will be more relevant for more projects depending on the needs of an individual project. For now, it’s not a topic worth too much time.
If you do have a 2D game with jagged edges for example when rotating an object make sure you add enough inner padding to the sprites. If your image has image data near the edges of the image container then it’s more likely those edges will look bad when rotating.
Generally super sampling is better but more costly. The other methods are optimized approximations meant for specific situations with pros/cons each.
AA features are generally not appropriate for mobile games as they are costly. Unless you know you are only targeting devices such as the newest iPads then it’s safer to use. Defold doesn’t allow you to control the samples at runtime yet.
I have published my game code on GitHub - https://github.com/baturinsky/GlueTime
You can check it if you want to see how to
- Write parts of 2d physics that are missing in vanilla Defold, such is dynamically changing rigid bodies. See lib/rigid.lua and lib/collider.lua specifically.
- Scale time (set_time_step in lib/global.lua) and view (main/my.render_script, look for word “zoom”).
- And many other more trivial things that someone could find not quite trivial.
Speaking of physics, if someone is wanting to delve in it, two advices. First, read this http://chrishecker.com/images/e/e7/Gdmphys3.pdf for the basic math of it - it’s most to-the-point article I have found. Second - don’t apply changes to position, speed, rotation etc right when you calculate them. It can screw further calculations, especially one with the other body that is involved in same collision. Instead, accumulate changes and apply them after all collision calculations in current frame are done.
Enums
If you want to use enums instead of custom strings you can do this:
BLOCK_TYPES = {
red = 0,
blue = 1,
gold = 2
}
Using:
local new_block = ....
new_block.type = BLOCK_TYPES.red
Did a custom shader library ever get created? I am looking for either a glow or blur, possibly both.
No, I don’t think anyone created one I’m afraid…
Hi, I’m new to defold. I just want to ask how should I go about using the render script you outlined above but having it work on a non-square resolution.
So far, I modified the set_projection
call from
render.set_projection(vmath.matrix4_orthographic(0, RESOLUTION, 0, RESOLUTION, -1, 1))
to
render.set_projection(vmath.matrix4_orthographic(0, 160, 0, 284, -1, 1))
160x284 is my target render resolution (similar resolution to Downwell).
It seems to be working but the rendered image is “squished”, forcing it to be square. What should I modify to allow it to scale properly?
After much tinkering, I was able to find a solution. The solution was already there right in front of me: fixed_fit_projection
.
So I just used that instead of the default call to stretch_projection
. However there was still 1 problem, since the resolution that I wanted was 160x284, it means I have to set the display resolution to 160x284 in game.project to get the intended effect. That means the window looks very small.
I was able to get around that problem by replacing all calls to render.get_width()
and render.get_height()
with the base resolution that I want:
local WIDTH = 160
local HEIGHT = 284
--
-- projection that centers content with maintained aspect ratio and optional zoom
--
local function fixed_projection(near, far, zoom)
local projected_width = render.get_window_width() / (zoom or 1)
local projected_height = render.get_window_height() / (zoom or 1)
local xoffset = -(projected_width - WIDTH) / 2
local yoffset = -(projected_height - HEIGHT) / 2
return vmath.matrix4_orthographic(xoffset, xoffset + projected_width, yoffset, yoffset + projected_height, near, far)
end
--
-- projection that centers and fits content with maintained aspect ratio
--
local function fixed_fit_projection(near, far)
local width = WIDTH
local height = HEIGHT
local window_width = render.get_window_width()
local window_height = render.get_window_height()
local zoom = math.min(window_width / width, window_height / height)
return fixed_projection(near, far, zoom)
end
So now, I can set the display resolution to anything in game.project and it will just fit the contents to the window.
I hope this helps other people looking for solutions to the same problem.
Thank you for sharing your solution. Nowadays most Defold devs add a dependency to RenderCam or Defold-Orthographic and call it a day. Those extension do more or less what you did but nicely abstracted away and with more added benefits such as camera effects, camera follow, zoom and so on.