Gideros Update 2015.07.15

ar2rsawseen

LuaSocket on WinRT player
WinRT Windows 10 support
Using correct temp directory on WinRT
Fixed using multiple parallel UrlLoaders on WinRT
Fixed problems with documents directory on Desktop exports
Fixed changing window sizes and autoscaling on Desktop exports
Preserving window dimensions and position on Desktop exports
Improved WinRT performance
Implemented Vertext Buffer Objects for performance increase for all platforms

https://github.com/gideros/gideros/releases/tag/2015.07.15

Thanks @tkhnoman for additions to desktop export.

And let us know if you feel any performance boost

cheers ~O)

totebo

Yay! Under what circumstances would "Vertext Buffer Objects" increase performance?

hgy29

@totebo, under most of them actually.

Actually VBO works by keeping vertices locations and textures coordinates in GPU memory, rather than uploading them to GPU before every draw call. So as long as those vertices and textures coords don't change, then they need not to be updated into GPU memory.

Moving a sprite through setPosition/Rotation and so on do not change vertices coordinates, only transform matrix is changed, so it turns out that those data almost never change.

Notable exceptions are: tilemaps (VBO not implemented on tilemaps), changing a Shape's content (clearing, adding other paths, etc), changing a bitmap's texture (texcoords may need to be recomputed), ...

SinisterSoft

Just to let everyone know, on tests I was getting an almost 2x speed increase on Windows Phone with this update. Great work @hgy29 on adding VBO.

SinisterSoft

Also, if you have submitted anything to the Microsoft store then please re-submit as the older version did not work on Windows 10, this one does.

totebo

That's fantastic! A good reason to update my games.

vitalitymobile

Wow wow ! Thank you all !

Xman

great job!

john26

Yes, the new graphics engine implemented by @hgy29 gives a huge speed boost to Windows Phone apps and I'd strongly recommend upgrading to this version. Other OS's get a speed boost too but it seems especially pronounced for systems using DirectX (Windows Phone and Windows Store). And it's Windows Phone where you really notice the difference as phones are less powerful than desktops/laptops.

billydb

Yep huge difference on windows rt. gone from unplayable to almost smooth on a low end device. Thanks all involved
Btw my game uses tilemaps and has a hexagonal plane mesh that gets aligned to a ring of box2d dynamic objects each frame to create the player character. Does this mean the vbo stuff wont help with these?

hgy29

Currently no gain for tilemaps (perhaps some support in a future release), but meshes will certainly benefit from VBO stuff.

keszegh

i still don't get how fullscreen works, when i set it to full-screen then the two sides of the screen remain gray. i guess that somehow even in full-screen the resolution ratio of the window size is forced in a letterbox-way.

so how can we set the app to 'really full' screen?

ar2rsawseen

@keszegh it's the same as with devices screens.
If you have a screen that you do not support in letterbox (that does not fit the ratio you have anticipated) it will show whitespaces

keszegh

@ar2rsawseen, i have it in noscaletopleft mode, windows size is 0,0 and e.g. logical size 640,640. and when i resize the exported desktop app to fullscreen then the app is square-shaped with gray left and right area instead of filling the whole screen.

unlike in the player it fills the whole screen, as i would like it to behave for the exported app too.

so what can i do so that full-screen covers the whole screen whatever the monitor screen size is?

i'm not sure i get what you mean by "fit the ratio you have anticipated".

john26

I think you should use stretch scaling to make it fill the whole screen when full screen is selected. No scale means it will always be logical dimensions whatever the window size. In full screen a window is created that fills the screen but should still be regarded as a window. If that window is bigger than logical dimensions it will only get filled if you use stretch letter box or one of the scaling options.

yubaro

Trouble in Mac Desktop export, the .app not working, quits unexpectedly when trying to start. This did not happen in the previous version, in the previous version works fine.

keszegh

@john26, but stretch will ruin the 1:1 pixel ratio, won't it?
before (on android and in player) i was always happily using noscale top left and then with getdevicewidth/height i could get the actual size of the screen and using that i could modify my menu etc so that it looks good. so i think it would be possible that noscale topleft in fullscreen is really fullscreen (in the previous version it was like that) and i think this behaviour could be the one expected.

btw i tried to export with stretch mode just to see what happens (and windows size still 0,0) and in full-screen the screen is still not filled (has square-shape plus gray left and right areas), so it's not a good solution (and even if it would work stretching pixels is not something i want).

thanks for the help

keszegh

perhaps such a tickbox when exporting should exist:
"maintain aspect ratio when resizing"

john26

Could you try screen size 640x640 instead of 0x0 in stretch?

keszegh

it's also the same except that when not in full-screen then i cannot resize at all the window.
(btw previously resizing the window always maintained that the active area is square-shapes and the rest is gray letterboxed.)

john26

That definitely seems to be an error. I guess one option would be to find the screen resolution then set the window size to that. That should respect stretch etc.

keszegh

could work, what is the api for setting window size?

john26

application:setWindowSize

tkhnoman

@keszegh :
Did you mean you actually draw something outside of the box at the left and the right part of it?
I never think someone would use it like that.
In this version, it always try to maintain aspect ratio, because somehow when scaling a game, you could reach something like 100 x 1000, which for many games that scroll the camera, it destroy everything.

Sorry about that, I will try to add reading for Scale mode also. (but might imperfect at first)


@yubaro : Would try to recheck the MacOS version.

tkhnoman

@keszegh :
Could you check whether this fix the issue or not?

yubaro

@tkhnoman I use Yosemite 10.10.4
I found this in the error details:

Crashed Thread: 0 Dispatch queue: com.apple.main-thread   Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000   Application Specific Information: *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Error (1000) creating CGSWindow on line 281' terminating with uncaught exception of type NSException abort() called

john26

@tkhmona, what is the EXE you have sent? Is it a new Gideros Player?

tkhnoman

@john26 i just trying to detect scale Mode on Windows Desktop Export.

john26

Dear All,

I've been messing about with the desktop resize feature and indeed there are errors. Here's what I found works and what doesn't. These comments are for desktop Windows.

The good news is application:setFullScreen(true) and setFullScreen(false) definitely works and respects your scale mode "stretch" etc. So setFullScreen(true) accomplishes a genuine full screen BUT respects game logical coords aspect ratio. setFullScreen(false) returns the game window to logical dimensions. That's actually sufficient for many games so you can publish I think...

It's also possible for the end user to resize the window if you set screen size to (0,0) in "properties". This works well and maintains aspect ratio. However, it's dangerous because when the user chooses full screen, the chrome goes away and does not return when you press Escape so the user then can't move, resize or close the window!

You can prevent user resize by setting the Window size in properties. But this is a shame...

application:setWindowSize is broken. It resizes the window but does not resize the drawing area within it (ignores scaling mode) which is kind of useless.

Also, the window size you set in properties is broken. This game simply starts with logical coords. The only use of setting this to not (0,0) is to prevent user resizing.

So what I suggest is ONLY use setFullScreen(true/false) for now. That is still enough to produce a good product in many cases. I will ensure all this is fixed by next release.

Attached is the "Bird Animation" example showing how to use full screen. If you press F, W you can see how to switch between Fullscreen and Windowed -- and it respects "stretch". You can press A for (500,500) window but that does respect "stretch"

tkhnoman

Well, if people set screen size to (0,0) then it means they always need to be prepared with setFullScreen() button

I also think the maximize button need to be gone from windows too, (but i'm still wondering about this thing, so i didn't do anything about it) @john26 but make sure the maximize button still exist for mac, because Mac apps always have it.

keszegh

@john26, thanks for checking in detail, indeed for most apps maintaining the aspect ratio is good enough, but in long term e.g. in my animating/drawing app obviously i want/need to use all the screen area otherwise it looks lame, so it's good if you plan to fix this.