Gideros 2018.10: Get it now.

totebo

Gideros 2018.9 described our vision for the future of game development. Today, we're extending that vision with significant advances across a number of areas:

• Debugging! Step code, inspect variables, enjoy life.
  
• Megacool plugin! A tool allowing sharing gameplay with animated GIFs. Check out the wiki.
  
• Threads! No more faking. These threads don't lie.
  

Gideros 2018.10. Our most advanced SDK yet. Download for free

New features

[studio] Add debugging options (breakpoints/stepping/inspect variables)
[plugin/Threads] Introduce true threads plugin
[plugin/megacool] Add megacool support (Android only)

Enhancements

[studio] Improve auto completion proposals with icons
[studio] Update icons for HiDPI
[studio] Add preferences dialog
[android] Use GL ES 3 if available
[plugin/lfs] Add a lfs.drives() call to get a list of possible drives (win essentially)
[plugin/controller] Allow to control deadzone (Controller.setDeadZone(float)
[plugin/ads] update unity and applovin

Fixes

[gfx] Avoid multiplying texture scale factor two times
[gfx] Fix TextureRegion:getRegion() parameter check
[plugin/ogg] Fix looping sound issue
[core] Fix Particles.setParticleSpeed

Download Gideros 2018.10 for free

vitalitymobile

Thank for update new feature!

Mac OS Mojave recently introduces the dark theme, I see some Gideros themes can not show text correctly in that theme.

keszegh

what a massive set of new features lately, thanks and grats

simwhi

A fantastic release. I'm looking forward to trying out the debugger!

keszegh

how does this debugging work? i add an arrow in a row and then run but it does not stop at the arrow as i'd expect (in general or more specifically, from zerobranestudio behaviour).

oleg

keszegh said:

how does this debugging work? i add an arrow in a row and then run but it does not stop at the arrow as i'd expect (in general or more specifically, from zerobranestudio behaviour).

keszegh

how do you add that blue dot? i can only add blue triangles.

oleg

@keszegh just click on the left of the line number

ps\\
triangles are the bookmarks for a quick transition (on the toolbar, yellow pentagrams)

keszegh

thanks @oleg, i've found the place, clicking close to the line number was not good, one has to click a bit farther.

otherwise i think the debugging feature is far from being as useful as in zbs, we obviously need watches and also to show tables in an informative way. i think it will be pretty cool though at the end.

SinisterSoft

@hgy29 has told me that he intends to improve the debugging feature.

One of the less talked about new additions is the new Megacool plugin, like the debugger it's still an early implementation but Megacool may help you get more people playing your games. Basically you set it recording and when you say stop the last 5 seconds are kept as an animated GIF. You can then share the animated GIF on whatever social networks you are connected to.

If someone click on the GIF then the app they run gets an event to say it was run from a Megacool link - so you can give them something like an extra coin or something, the person who shared the GIF also gets an event so you can also give them a coin. The actual system works brilliantly. Megacool gives you something like 50,000 free shares to get you started.

I'm sure more options will be coming to the Megacool plugin over the next few weeks also.

Note, a side effect of adding Megacool also meant that @hgy29 also had to add a way for OpenGL ES 3.0 to work. OpenGL ES 3.0 is backwards compatible with 2.0, but on some phones is actually faster - for reasons best left known only to the phone manufacturers.

Apollo14

guys I don't have words to express
this is hell of an update

hgy29

keszegh said:

i think the debugging feature is far from being as useful as in zbs

We don't want to drive people off ZBS, do we ? Well, seriously, all we do in that respect is aiming at providing a studio that as most of the features one could expect, so that most users don't feel the need to switch to another IDE. Debugger will be improved over time, but we had to start somewhere, and it is already better than what gideros studio had to offer until now.
Beside debugger, I am also looking into adding better integration of Gideros profiler into the studio, but one step at a time

vitalitymobile

"Integration of Gideros profiler into the studio" would be a killer feature for sure!
Thank so much for bringing many useful and awesome features into Gideros!

keszegh

about the threads plugin, if i do some file load/save operation in a separate thread, it won't pause now the app in main thread? (beforehand with fake threads i could not do this as an lfs operation was taken as 'one unit')

SinisterSoft

I think for the time being the extra threads can only be used for pure Lua stuff - like something that may take some time - eg generating a puzzle or something. I'm not sure though, @PaulR will know more.

PaulR

@keszegh : threads is pure Lua at the moment and are separate states so don't have access to modules loaded on the main Gideros state. Saving/loading on a non-realtime thread is a perfect use case for threads though so I'll need to see about loading lfs and luasocket, maybe optionally on creation.

keszegh

what happens if only one core is found?

is it safe to think that threads are always better than the fake threads from before (Except when an additional module/plugin is needed, at least for now)?
if yes, then perhaps threads could imitate the api of the fake threads to make the change easier.

SinisterSoft

They both have their uses. The fake threads time-slice the time between finishing drawing and the next draw frame. They can access all of the Gideros API and all the globals in your Lua program.

If no fake threads then those cycles are wasted, but you could look on it as battery power is saved.

If one fake thread then it gets all the time, unless you yield.

If two fake threads then the time is split between them both, and so on.

The real Threads will most likely use a different core, so they don't use any of the main core's cycles. The disadvantage is that they can't use the Gideros API or any of the variables in your program, API access may be available in the future though but it might be quite difficult to do.

If you have a single core phone (unlikely nowadays) then the real threads will be managed by the OS and it will operate more like a time-sliced system I'd guess.

You can use both at the same time, one or the other, or neither - it's up to you.

antix

Yay for drive getting in LFS!!! I'll give it a try if I ever get time on hokiday

keszegh

thanks for the clarification, realizing that even basic gideros api is not available in threads, i don't think it will be useful for me, nevertheless it is a nice addition.

SinisterSoft

It's 'early days' for real threads, they are still useful for generating levels, etc stuff you can do in Lua. You could even run a full game and have it send data to the main lua function for coordinate updates, etc...

keszegh

@SinisterSoft, indeed, actually what i'd want to use it for is to convert a table to json, compress it and save to a file. and also loading, the reverse direction.
so i do not need most of gideros api to work.

PaulR

@keszegh : I'm adding LFS, LuaSocket and JSON to Threads... if you want to test it please let me know.

keszegh

@PaulR, if zlib is also included (i hope so as it is in standard lua api) then this would be pretty useful to me, thanks a lot.
i won't be able to test soon though as i'm overwhelmed with other non-gideros tasks.

PaulR

No worries, I am looking into including that at the moment. Being able to do most of the utility operations on different threads will hopefully allow us to free up the main thread and be able to plan/design more efficiently in places.

SinisterSoft

What is needed I think is a fake 'memory' device.

So you copy a file in the thread called "|d|myimage.png" to "|m|myimage.png", for this a new command could be added to the Lua 'os' library:
os.copy("|d|myimage.png","|m|myimage.png")

The main thread code then can be changed from:
myTexture=Texture.new("|d|myimage.png")

to:
myTexture=Texture.new("|m|myimage.png")

If it never needs to load the texture again then it could then:
os.remove("|m|myimage.png")

Gideros has a file redirection system, so this could fit in perfectly - but it would have to be made multithreaded.

In the future a second fake device for a URL could be added, |u|
os.copy("|u|myimage.png","|m|myimage.png") -- loads from the internet url local to the player, eg for facebook instants, html5

and:
os.copy("|u|https://mydomain.com/images/myimage.png","|m|myimage.png")

pie

Hi,
does the Help buttons
> Documentation
and
> API Documentation

do something for you in 2018.10?

They don't open anything on my laptop
Thanks

hgy29

No they don't, as they used to open local documentation, which is no longer bundled with gideros. It has been fixed in 2018.11, those menu items will open online doc instead

pie

If I may, the offline docs would still be useful

talis

@pie offline docs are difficult to keep track of i guess. New Wiki docs are really good indeed. Always something added, something changing, translations etc. Maybe there is some plugin on WikiDocs to export all docs to offline somehow, but any case as i wrote it can be problematic to keep track of if it is up-to date information.

SinisterSoft

@talis yes, and with the wiki docs it's easy for anyone to fix or add more docs they feel are needed - they just have to contact myself or @hgy29 for a username.