Defold 1.7.0 Beta

[AGulev]

@ross.grams

Broken for 5 years and no one reported it, haha. I believe it. Fair enough.

It’s sounds worse than it is. Developers aren’t happy with messages in such places, the Defold team, either. That’s why we started to introduce callbacks and people happily moved to it. It’s not like functionality doesn’t exist. It was replaced.

Since you mention it and for you it looks suspicious, I’ll make extra checking one more time (what’s why we have beta, so our users can help us in cases we missed something).

@ross.grams

…It seems that the reports about it in last release’s thread were because it was still broken, not because it suddenly worked flawlessly. It is directly stated in the Sound manual that you can delete the game object that a sound component is on and it should still work fine.

It works fine, users just get an error that message can’t be delivered, which doesn’t break anything.

@ross.grams

At any rate, I have no objection to the “change”, I’m just concerned about the docs getting out of date.

As I said, I’ll recheck everything (esp old version etc), and if I don’t find anything suspicious I’ll fix documentation. Thank you.

[AGulev]

I tested in 1.2.163 (the change was in 1.2.162, but on GitHub in releases, I found only 1.2.163) no messages at all, only callback

So, I’ll fix the documentation to make sure everything explained clear.

[Mathias_Westerdahl]

Here is a small test case showcasing how to use a custom “mycolor” for coloring multiple sprites using vertex attributes, as opposed to using uniforms.
This will avoid breaking batches, which is a good thing.

This is a single draw call, using a single sprite, with different vertex attribute(s) for each sprite instance:

Here is the test project (Created with the 1.7.0 beta)
VertexAttributeColor.zip (10.0 KB)

[jhonny.goransson]

Sorry, I still can’t reproduce this issue, even on windows

[d954mas]

Device name LAPTOP-K0DFPU0P
Processor AMD Ryzen 5 5500U with Radeon Graphics 2.10 GHz
RAM 16.0 GB (available: 15.3 GB)
Device code 3BBEB675-7CC5-4A13-9E58-2B75005A27EF
Product code 00342-41452-59295-AAOEM
System type 64-bit operating system, x64 processor
Pen and touch input Pen and touch input are not available for this monitor

[d954mas]

Make small repro case.

go.property("data_texture", resource.texture("/assets/data.png"))


function init(self)
	self.data_texture_resource = self.data_texture
	self.data_texture_empty_params = {
		width = 1,
		height = 1,
		type = resource.TEXTURE_TYPE_2D,
		format = resource.TEXTURE_FORMAT_RGBA,
		num_mip_maps = 1
	}
	self.data_texture_empty_buffer = buffer.create(1, { { name = hash("rgba"), type = buffer.VALUE_TYPE_UINT8, count = 4 } })
	local stream = buffer.get_stream(self.data_texture_empty_buffer, hash("rgba"))
	stream[1], stream[2], stream[3], stream[4] = 0, 0, 0, 0
	
	timer.delay(0/60,true,function()
		resource.set_texture(self.data_texture_resource, self.data_texture_empty_params, self.data_texture_empty_buffer)
	end)
end

170b_set_texture_problem.zip (10.3 KB)

[AGulev]

@ross.grams

At any rate, I have no objection to the “change”, I’m just concerned about the docs getting out of date.

I spent some time rechecking everything and actually found one thing I had broken. I fixed it and added more information to the documentation to make things clearer. Thank you for bringing up this topic.

@Mathias_Westerdahl

FIX: (#8544 ) Send sound_done or sound_stopped messages only if the sound is played using msg.post with the play_id parameter.
The sound component will send sound_done and sound_stopped messages only if msg.post() is used with the play_id parameter, as in msg.post("#sound", "play_sound", {play_id = 1}).

[MasterMind]

I believe I have found a bug where the attribute values are set to 0’s when they shouldn’t be.

Steps are:

1. Animate values using go.animate

2. Use go.cancel_animations and reset values back to 1 using go.set or any method.

3. Start a new animation using go.animate

At step 3 the attribute values will be replaced with ( 0, 0, 0, 0 )

Repro:
VertexAtrributte_colors_BUG.zip (11.1 KB)

[Mathias_Westerdahl]

I can’t seem to reproduce this issue?
We did fix an animation issue yesterday, and perhaps that solved it?
I’m using version 64a4731e9242a8884afeafcd72f22b3d3fd39ce5

[MasterMind]

I am using

• Defold version: 64a4731e9242a8884afeafcd72f22b3d3fd39ce5
• Platform: Win10

The results I am seeing are as follows. At step 3 mycolor values are vector4(1, 1, 1, 1) then a new animation is set to animate from: vector4(1, 1, 1, 1) to: vector4(5, 1, 1, 1) . Then the next 2 update frames the values drop to : vmath.vector4(0.16970998048782, 0.033941995352507, 0.033941995352507, 0.033941995352507) Then animates from: vector4(0, 0, 0, 0) > vector4(5, 1, 1, 1)

Debug prints show this:

DEBUG:SCRIPT:
: Step 2 After: mycolor:vmath.vector4(1, 1, 1, 1)
: Update mycolor: vmath.vector4(1, 1, 1, 1)
: Step 3 Before animation start: mycolor:vmath.vector4(1, 1, 1, 1)
: Step 3 after animation start: mycolor:vmath.vector4(1, 1, 1, 1)
: Update mycolor: vmath.vector4(1, 1, 1, 1) <---- First frame update after new animation started is correct then drops to zeros.
: Update mycolor: vmath.vector4(0.16970998048782, 0.033941995352507, 0.033941995352507, 0.033941995352507)
: Update mycolor: vmath.vector4(0.32912001013756, 0.065824002027512, 0.065824002027512, 0.065824002027512)
: Update mycolor: vmath.vector4(0.49871999025345, 0.099743999540806, 0.099743999540806, 0.099743999540806)
: Update mycolor: vmath.vector4(0.66815006732941, 0.13363000750542, 0.13363000750542, 0.13363000750542)
: Update mycolor: vmath.vector4(0.83765000104904, 0.16753000020981, 0.16753000020981, 0.16753000020981)
: Update mycolor: vmath.vector4(0.99723994731903, 0.19944798946381, 0.19944798946381, 0.19944798946381)

Originally I had applied the vertex attributes in another project and noticed every sprite I applied them to started blinking and found the values had dropped to 0’s so made the small repro where I get the same results.

[Mathias_Westerdahl]

Thanks, we found another issue and have a fix coming up. I think this will fox you issue as well?

[jhonny.goransson]

Pushed a fix to beta that should remedy this

[sergeysinyavsky]

I found a small bug when using image.load_buffer.
Buffer returns sting with wrong length when using buffer.get_bytes(data.buffer, hash("data")).
This happens because after the changes the count parameter in the stream has been changed, but the size of the array remains the same.

Image: 100x100 RGB

With this code I get an error: ERROR:GUI: Invalid image buffer size. Expected 30000, got 90000

local img_data = image.load_buffer(png_data, {flip_vertically = true})
local data = buffer.get_bytes(img_data.buffer, hash("data"))
gui.new_texture("any", img_data.width, img_data.height, img_data.type, data, true)

Buffer details:

{ --[[00000211656F4F10]]
  width = 100,
  type = "rgb",
  buffer = buffer.buffer(count = 30000, version = 0, handle = 131073, { hash("data"), buffer.VALUE_TYPE_UINT8, 3 }),
  height = 100
}

As you can see, the buffer has a size of 30000 and a count value of 3 in the stream.
It should be:

1. size = width * height and count = 3
2. size = width * height * 3 and count = 1

Moreover, if I cut the string myself, then everything will work.

string.sub(data, 1, 30000)

[sergeysinyavsky]

I also found a “blinking” issue.
As I understand it, this is related to the problem above with resource.set_texture
I update the texture as I paint on it and this is what it looks like:

It’s interesting that on my screen it doesn’t look like blinking, but as if I’m drawing with transparent alpha. And also the black circle is a sprite, which for some reason is also rendered strangely

UPDATE

Everything works fine in the html build.
My video card: AMD RX 580

[Mathias_Westerdahl]

I believe we have a fix coming for that as well.

[MasterMind]

@jhonny.goransson & @Mathias_Westerdahl The fix is working well. Cheers

[jhonny.goransson]

Pushed a fix for this to beta, please try again and see if it’s resolved

[sergeysinyavsky]

The “blinking” issue has been solved. Thank you

[neralion]

Hello, I’ve found an issue: if multiple vertex attributes are used in the material for a sprite, setting a value to one attribute causes the others to become 0. Is this normal behavior?

[AGulev]

The issue has been fixed.