Gideros 2022.9 Released

hgy29 · September 2022

I am happy to announce the (pre) release of Gideros 2022.9, maybe too soon but lets face it, I can't spend time doing in depth testing of each release so lets do it together. I am confident it should be at least backward compatible.

Major changes under the hood this time:
- LuaU engine have been upgraded to latest (or rather latest a few weeks ago!). It comes with performance improvements and a new form of litteral strings. More on this here: https://devforum.roblox.com/t/luau-recap-july-august-2022/1966965 and here: https://github.com/Roblox/luau/blob/master/rfcs/syntax-string-interpolation.md
- True parallel multithreading is now possible in Gideros, with limitations similar to those that come with multithreading in C++. Parallel threads are launched by Core.asyncThread instead of Core.asyncCall, and have a lot in common with those asynchronous threads. They share the same environment as the rest of your code, and can access anything... in theory! In practise care should be taken to avoid concurrent modifications, and most Gideros API isn't thread safe. A new table.share call has been added to make a lua table protected with mutexes. Such table accesses are slower, but thread safe.
- Gideros now supports on demand rendering: rather than updating the screen continously (the fps), when on demand rendering is enabled Gideros will refresh the screen only if it can figure out something has changed. This saves a lot of GPU/CPU power as well as battery life.
- Audio used to depend on various engines: XAudio2 on UWP and several versions of OpenAL. Now we use the same OpenAL-Soft version for every platform, providing a consistent API accross platforms and opening the way for future audio additions such as filters and effects.

This version is a big step forward, multithreading in particular should allow for more efficient 3D games, by allowing to run 3D collision engine in parallel with rendering, and on demand rendering being a big improvement for professionnal apps.

Hope you'll like it!

New features
[core] Implement on-demand rendering
[core] Support luau parallel threads
[core] Add signals for parallel threads, and improve yield api

Improvements
[luau] upgrade to latest
[core/layout] Improve shrink mode
[audio] Use latest OpenAL soft for most platforms (apple,android,qt,uwp,html)

Fixes
[android] Fix handling of numeric input
[io/win32] Convert filename to wchar_t for win32

Download it from here:
http://giderosmobile.com/download

MoKaLux · September 2022

great job sensei

Thank u for all the new features

SinisterSoft · September 2022

Fantastic update, amazing - well done.

SinisterSoft · September 2022

Just tested everything on it, and the only thing that didn't work right was ReportComplete (gideros version). Not this updates fault though, I think that's down to me not updating it in 12 months and imgui must have changed slightly - clicking stuff didn't work.

vitalitymobile · September 2022

Amazing! Thank you for your hard work!

rrraptor · September 2022

Oh, I love new string formating stuff

The only thing is missing is a highlighting

hgy29 · September 2022

rrraptor said:
Oh, I love new string formating stuff

The only thing is missing is a highlighting

Yes I didn’t want to change the highlighter too early, but I love this new syntax too

rrraptor · September 2022

@hgy29
Atleast we can have this:

Just mimic a normal string.

hgy29 · September 2022

Yes, that would be easy to add

rrraptor · September 2022

Something is not right )

I still have a messge after removing the variable

keszegh · September 2022

sounds great, thanks.
how does the on-demand-rendering work? i don't want of course the messy details, mostly i'm interested if i use the immediate mode imgui then does this new addition notice if the gui is the same and then have less gpu load or or not?

hgy29 · September 2022

keszegh said:
sounds great, thanks.
how does the on-demand-rendering work? i don't want of course the messy details, mostly i'm interested if i use the immediate mode imgui then does this new addition notice if the gui is the same and then have less gpu load or or not?

Well, I am sure sure it would work out of the box with imgui. Gideros tries to keep stage of graphics changes made through calls to Sprite functions: position, color, text, etc. Since Imgui is supposed to be immediate, I don't think it tracks changes itself.
I am not sure how we could possibly deal with imgui...

keszegh · September 2022

this version corrects my issues with reading files with hungarian accents. thanks a lot

rrraptor · September 2022

hgy29 said:
Well, I am sure sure it would work out of the box with imgui. Gideros tries to keep stage of graphics changes made through calls to Sprite functions: position, color, text, etc. Since Imgui is supposed to be immediate, I don't think it tracks changes itself.
I am not sure how we could possibly deal with imgui...

https://github.com/ocornut/imgui/issues/71
It is possible to track events, but how do you deal with things that is manually added to draw lists?
Perhabs: https://github.com/ocornut/imgui/issues/2268#issuecomment-486450272
but I'm not an expert in memory / complexity measurements expert

hgy29 · September 2022

rrraptor said:

https://github.com/ocornut/imgui/issues/71
It is possible to track events, but how do you deal with things that is manually added to draw lists?
Perhabs: https://github.com/ocornut/imgui/issues/2268#issuecomment-486450272
but I'm not an expert in memory / complexity measurements expert

If this is due to a programmatic change in the lists, I guess the developper could ensure redraw by setting something (position or anything) on the imgui sprite. Gideros would then know a refresh is needed, but I agree it would be tedious. Maybe comparing the vertex buffers and setting a flag in the end of frame call ?

rrraptor · September 2022

@hgy29 can you please share an example of using threads?)

hgy29 · September 2022

Yes, I’ll share my test cases when I am back at the office on Monday. Meanwhile here is a quick example:

local results={}
table.share(results) — results table while hold thread results
— spawn a parallel thread
Core.asyncThread(function()
 — do some heavy task <img class="emoji" src="http://forum.giderosmobile.com/resources/emoji/smile.png" title=":)" alt=":)" height="20" />
 Core.yield(5) — wait 5 secs
 results.pos=vector(1,2)
end)
— spawn an async task to grab the result on main thread when available
Core.asyncCall(function()
 while not results.pos do Core.yield(true) end
 print(pos)
end)

MoKaLux · September 2022

FYI ~~I have this error with the Threads plugin~~.

-- edit my bad I was using an outdated code

EDIT2: quote from hgy29 below
"Threads plug-in is deprecated since luau move, and now you shouldn’t even need it since threads are built in"
--> can we remove the Threads plugin from Gideros? that would be less confusing!?

hgy29 · September 2022

Threads plug-in is deprecated since luau move, and now you shouldn’t even need it since threads are built in

rrraptor · September 2022

@hgy29 instead of this weird "Core.asyncCall" waiter, would it be better to add:

std::condition_variable::notify_one
callback to "std::condition_variable::wait" (Core.signal():wait()), so it can wait for some specific action (e.g. counter reaches 0)

Here is my version (array sorting):

local SEED = 123
 
local ITEMS = 1000 -- how many arrays to sort
local ELEMENTS = 1000 -- how many elements in each array
 
function prepareData()
	local data = {}
	math.randomseed(SEED)
 
	for i = 1, ITEMS do 
		local arr = {}
 
		for j = 1, ELEMENTS do 
			arr[j] = math.random()
		end
		data[i] = arr
	end
 
	return data
end
 
function sort(arr)
	--table.sort(arr)
 
	-- built-in table.sort is faster, so
	-- I slow down the process on purpose
 
	for i = 1, #arr do 
		for j = i + 1, #arr do 
			if arr[i] > arr[j] then
				arr[i], arr[j] = arr[j], arr[i]
			end
		end
	end
 
	arr.sorted = true
end
 
function testSync()
	local data = prepareData()
	local startTime = os.clock()
 
	for i = 1, #data do 
		sort(data[i]) 
	end
 
	print(`Sync: {os.clock() - startTime}`)
end
 
function testAsync()
	local data = prepareData()
	table.share(data)
 
	local startTime = os.clock()
 
	for i = 1, #data do 
		Core.asyncThread(sort, data[i])
	end
 
	Core.asyncThread(function()
		local sorted = 0
		local total = #data
 
		while total ~= sorted do 
			sorted = 0
 
			for i = 1, total do 
				if data[i].sorted then 
					sorted += 1
				end
			end
		end
 
		print(`Async: {os.clock() - startTime}`)
	end)
end
 
testAsync()
testSync()
 
--[[
on my pc:
 
Async: ~2 s.
Sync: ~13 s.
--]]

hgy29 · September 2022

It is already in, I just wrote a quick example

hgy29 · September 2022

But remember that main thread can’t wait!

hgy29 · September 2022

Thinking of it, if you want to pass the result of a thread back to main thread (for ui processing) then the easiest way is to fire and asyncCall at the end of the thread, that’s the cleanest way plus you can pass arguments to the call

rrraptor · September 2022

hgy29 said:
It is already in, I just wrote a quick example

I can only see:
https://github.com/gideros/gideros/blob/cde15d0ef1efd61054794b0202f89b8d456d41ac/luabinding/luaapplication.cpp#L412
https://github.com/gideros/gideros/blob/cde15d0ef1efd61054794b0202f89b8d456d41ac/luabinding/luaapplication.cpp#L401

I mean this:

local myVar = 12
local cv = Core.signal()
 
Core.asyncThread(function()
	print("Thread is waiting...")
	cv:wait(function() --<--
		return myVar == 0
	end)
	Core.yield(5)
	print("Done!")
end)
 
Timer.delayedCall(2000, function()
	myVar = 0
end)

hgy29 said:
But remember that main thread can’t wait!

Yes, I know

hgy29 · September 2022

Yes I implemented wait() and notify_all(), do you think more is needed ?

rrraptor · September 2022

hgy29 said:
Yes I implemented wait() and notify_all(), do you think more is needed ?

Im not an expert in thread, but why not?) If this is too complicated then not worth it, otherwise...?

hgy29 · September 2022

I can add notify one, but if required, but I never encountered a use case for this one myself

rrraptor · September 2022

hgy29 said:
I can add notify one, but if required, but I never encountered a use case for this one myself

What about "wait" with callback?

cv:wait(function() return myVar == 0 end)

resumes thread when myVar == 0

hgy29 · September 2022

Hmm I am not sure, resuming lua while in the wait loop, that could work, I’ll try…

MoKaLux · September 2022

When Live syntax checking option is checked, in gideros studio, it messes up completely the find/replace behavior

For example when enabled and you do a find, either you will have to scroll up to find the highlighted word or the word won't be highlighted at all.

Live syntax checking gives me weird warnings as well, for example: ax is never used within the scope..., but I don't even have an ax variable here

Thank you

EDIT: when disabled everything seems fine
EDIT2: nope, even with Live Syntax Checking and Type checking disabled, the find/replace functions are not working good

There is like an offset and I have to scroll up to see the actual word. Could be related to the file length (in my case 500+ loc)?

hgy29 · September 2022

I doubt it is related to file length, I use very big files myself and didn't have the problem so far. I can have a look if you can send me a way to reproduce

Howdy, Stranger!

Categories

In this Discussion

Top Posters

Gideros 2022.9 Released

Comments

Howdy, Stranger!

Quick Links

Categories

In this Discussion

Top Posters

Gideros 2022.9 Released

Comments