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.15Thanks
@tkhnoman for additions to desktop export.
And let us know if you feel any performance boost
cheers ~O)
Comments
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), ...
Likes: john26
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.
Likes: hgy29
https://deluxepixel.com
https://deluxepixel.com
Likes: john26, vitalitymobile, SinisterSoft
Likes: john26
Likes: john26
Likes: hgy29, SinisterSoft
https://github.com/gideros/gideros
https://www.youtube.com/c/JohnBlackburn1975
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?
Likes: john26, SinisterSoft
so how can we set the app to 'really full' screen?
Fragmenter - animated loop machine and IKONOMIKON - the memory game
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
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".
Fragmenter - animated loop machine and IKONOMIKON - the memory game
https://github.com/gideros/gideros
https://www.youtube.com/c/JohnBlackburn1975
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
Fragmenter - animated loop machine and IKONOMIKON - the memory game
"maintain aspect ratio when resizing"
Fragmenter - animated loop machine and IKONOMIKON - the memory game
https://github.com/gideros/gideros
https://www.youtube.com/c/JohnBlackburn1975
(btw previously resizing the window always maintained that the active area is square-shapes and the rest is gray letterboxed.)
Fragmenter - animated loop machine and IKONOMIKON - the memory game
https://github.com/gideros/gideros
https://www.youtube.com/c/JohnBlackburn1975
Fragmenter - animated loop machine and IKONOMIKON - the memory game
https://github.com/gideros/gideros
https://www.youtube.com/c/JohnBlackburn1975
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.
Could you check whether this fix the issue or not?
I found this in the error details:
https://github.com/gideros/gideros
https://www.youtube.com/c/JohnBlackburn1975
Likes: john26
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"
https://github.com/gideros/gideros
https://www.youtube.com/c/JohnBlackburn1975
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.
Likes: john26
Fragmenter - animated loop machine and IKONOMIKON - the memory game