Gideros 2016.4 published!

hgy29 · May 2016

@Ninjadoodle, did you try the latest beta version ? You can grab it at the same location as during the Kickstarter beta access. I am pretty sure I have fixed the hidpi screens handling issue I that one.

Ninjadoodle · May 2016

Hi @hgy29

Sorry, you're right ... I was downloading the wrong version.

- The retina works really well now! I still get the black screen tho, unless I raise the memory to 512mb, which make the mobile crash. If the memory is at 256mb, I get a black screen (even on desktop).

PS. I'm so fed up with mobile browsers.

Thank you!

hgy29 · May 2016

Yeah, cross browser compatibility is a real pain! I'd like to reduce HTML5 apps memory footprint. The main issues is that all assets are loaded in memory during initialisation, so they take memory even if not used.
A workaround would be to use UrlLoader to fetch assets asynchronously on demand, but the best would be to have gideros do this by itself under the hood, leveraging browser's cache.

Ninjadoodle · May 2016

Hi @hgy29 and @john26

"but the best would be to have gideros do this by itself under the hood, leveraging browser's cache"

Is this something you guys are planning in the future? I honestly think with this feature, the html5 export would be so much easier to manage and rival other engines.

I'm ok with redirecting mobile users to an app version of my game, but it would be really nice to be able to have this woking in the future

- I assume its pretty safe to have the memory at 512mb for desktop?

- Also, if all assets are loaded into memory on initialisation, I think this only allows for very small HTML5 games to be played on mobile, as anything slightly larger will most likely crash the device?

- How much work / funds would be needed to make Gideros (HTML5) load the atlases/images level by level, instead of all at once? - I'd be very happy to donate money towards this.

Xman · May 2016

It's really not a good experience when exporting the project,a white rectangle cover the screen and nothing else can do during that.Not sure from which release that happened,but all export process is done in the background is more acceptable!

hgy29 · May 2016

@Xman, I never saw what you are describing during an export. exports are done in foreground so that the user is not tempted to change file structure or content during export, but I agree that it would be better to have some information about export on going process than a somewhat frozen studio.

hgy29 · May 2016

@Ninjadoodle: I really can't tell about memory assumptions for either desktop or mobile devices, but I can tell you how I imagine on-the-fly loading of assets, instead of pre-loading in memory everything.

1. First we'll need to have an option to enable lazy dwnloading of assets either globally or on a file-by-file basis.
2. Files designed as lazy loaded will be put aside from the main GApp file, either in another file pack or on their own.
3. When gideros will need to open a lazy loaded file, gideros will trigger an asynchronous fetch of the file, because browsers don't like synchronous requests. This means that all 'open' calls wiithin Gideros must be converted to some asynchronous form, and this might be the biggest part of the work. Not sure this is even possible!
4. When the file is finally closed, memory used by the file is released.

I'll have a deeper look at how 3. can be done...

Ninjadoodle · May 2016

Hi @hgy29

Thank you for the answer, I appreciate the explanation.

I'm currently a bit worried that when my game has 20 or so levels (I have an atlas per level), the game won't even load at the start

I hope some sort of solution can be found.

PS. you talked about the option of using a urlLoader and doing this manually - is this sort of thing difficult? (I have no experience with it)

Xman · May 2016

@Xman, I never saw what you are describing during an export. exports are done in foreground so that the user is not tempted to change file structure or content during export, but I agree that it would be better to have some information about export on going process than a somewhat frozen studio.

Yes,it's necessary to freeze the gideros studio to prevent change,a small progress bar will not prevent us from doing something outside the studio during export.

NatWobble · May 2016

I sometimes have trouble launching the player at all, whether from Gideros or directly.

I think this is a dual monitor issue because sometimes in the GiderosPLayer config file (C:\Users\xxxxx\AppData\Roaming\GiderosMobile) the pos has a large x value: e.g pos=@Point(2400 143).

Changing it to pos=@Point(400 143) fixes the issue for me.

I'm not sure if this is the same issue that everyone else has been experiencing, but it might help a bit.

Xman · May 2016

tried the 2012 release,what the export processing did Is just perfect,any reason why this changed

hgy29 · May 2016

@Xman, there are multiple reasons why things changed, but I believe the most notable one is that gideros used to have duplicate code for exporting: one copy within gideros studio and the other with gdrexport command line tool.

We decided recently to strip export code from gideros studio and let it call gdrexport to do the job: easier to maintain, export code always up to date in gdrexport (we used to forget updating it).

So now gdrstudio spawn gdrexport as a background process, and wait for it to finish before printing "export successful". It works well as far as I can tell (I am using windows mostly, and I never saw the issues you get), but we could use gdrexport output stream to feed a progress dialog maybe.

Xman · May 2016

hi，@hgy29
Just as you said, on Windows,when the open button is clicked on the open directory dialog, the dialog disappeared, it's just OK,We can do something else outside the gideros studio app.
However, on mac，the dialog become a white rectangle and stay on the the most top of the screen during the whole export .

just like the screencast show.

Xman · May 2016

Another time consuming bug:
1. setting the Bird Animation example Autorotation For iPhone iPad / Android.
2.launch the game on the player on a iOS device
3.rotate the device
4.relaunch the game
then half of the screen will not update.
here is a screencast

hgy29 · May 2016

@Ninjadoodle and others,

I am trying to add support for async tasks in gideros: this will allow you to run a function on gideros spare time, that is gideros will make is best to run it without interfering with rendering and framerate.

The main benefit will be to allow loading assets in background while displaying some animated loading screen to the user.
Some gideros functions could also become interruptible when called from an async task, which would help a lot for loading assets from HTML5 website...

totebo · June 2016

@hgy29, that sounds like an amazing feature. I have a method that merges static graphics into a single texture (to save sprites). This takes to long to do in game, but maybe with async I'd be able to queue it so it happens when it can? For me that would be magical and allow a lot more sprites on screen as a result.

hgy29 · June 2016

@totebo, yes thats the idea.
I am preparing a specific gideros version with this feature inside right now, @SinisterSoft will do some 'real-life' tests on it today if he can.

john26 · June 2016

coroutines (which is the underlying technology) will also allow sequential animations to be written in a way that is much more readable. Much better than using ENTER_FRAME callbacks or GTween with onComplete. That can lead to spaghetti code! Coroutines allow encapsulation of functionality and support OOP (for animations)

SinisterSoft · June 2016

I've tested it (on windows only at present) and it's great so far - just a couple of slight bugs for @hgy29 to squash.

It also seems to work on LuaJIT.

With it you could start a completely traditional procedural game in the coroutine - that is a game that works from top to bottom and loops forever- not an event driven style that has things happen as events occur. The events can then be used to do things like update sprites, etc...

@hgy29 managed to get auto-yield to work so you don't have to worry about any of that.

SinisterSoft · June 2016

@hgy29 's fakethreads are amazing! They work really well, all problems squashed now.

Should be in the next version of Gideros.

Ninjadoodle · June 2016

Nice, this is awesome guys

SinisterSoft · June 2016

Can someone who has an x86 Android machine please test this out?

It's the new LuaJIT that has been patched with the extra call needed for fake threads.

It should work on the current version of Gideros, I've tested both Arm versions but have no x86 Android machine to hand.

http://sinistersoft.com/downloads/luajit_patch.zip

Just make a player with it (export a blank project, delete the assets in the export), copy it to your machine - using dropbox or something? Send something to it, see if it works, debug messages, etc.

If you have this line then it will tell you about the jit optimisations:
print(jit:status())

Once this has been tested we are a stage nearer to releasing the next version of Gideros.

antix · June 2016

sounds all good. I hope the fix will be in the next version to address the issue where RenderTarget:clear() does not function correctly. That is a great way to create layered graphics but it's useless with the clear() bug.

SinisterSoft · June 2016

Clear bug?

SinisterSoft · June 2016

I've chatted with Nico and it looks like it's been fixed for a while, I think an install update is needed asap...

hgy29 · June 2016

Yes, it was fixed two month ago, we really need a new release very soon!

totebo · June 2016

@antix, could you please explain what you mean by "layered graphics" and when it would be used?

antix · June 2016

@totebo, Okay so really you are just compositing things. Lets say you have several atlases, one for the naked player, one for armour, and one for weapons. You first make a RenderTarget and copy the naked player into it. Then overlay the armour layer, and finally the weapon layer. Then you use the RenderTarget as the players atlas.

All this stuff takes place in an inventory UI so once the player has changed their equipment, you just keep the RenderTarget and discard the rest. You won't need to load those other graphics until the next time the player opens the inventory UI so there's no issue with slowdown there. RAM use is also moot because you are only temporarily using RAM while the player is actually in the inventory UI.

I suppose it's a bit more complex sometimes but that's a basic scenario.

antix · June 2016

Oh and +1 for a new release so I can start experimenting with RenderTargets more

>-

SinisterSoft · June 2016

@antix - I used this type of system in Superhero (Amiga) back in '91/'92....

Howdy, Stranger!

Categories

In this Discussion

Top Posters

Gideros 2016.4 published!

Comments

Howdy, Stranger!

Quick Links

Categories

In this Discussion

Top Posters

Gideros 2016.4 published!

Comments