Im creating an android game and started using TextureAlias for game assets, creating it as: TextureAtlas(Gdx.files.internal("assets.atlas")) and getting AtlasRegions simply by atlas.findRegion("my_asset") then setting this region into a sprite. Everything works fine, textures are rendered properly but after I put my app into background (methods pause and hide are called) and then bring it back to front (show is called) my assets are broken, they are grayish, not totally black as they would appear after calling dispose on TextureAlias - what am I missing? Should I be recreating TextureAtlas each time show is called?
When you as an Android user leave an app, there are 2 things that could happen.
One thing definitely happens, and that's "actually pause", which means the app is still running but not active.
If Android needs the resources, it might "actually kill" your app even though you think it's running.
(You can search Android App Lifecycle for more info)
In the first case, nothing would happen, your GL context would still exist and everything should work.
In the second case, however, your original GL context won't exist anymore, which means the textures would be bust.
The correct solution is to put your TextureAtlas load functionality into the create() function of your Game, so it will be reloaded only if the app was killed and not if the user switched out and in again.
You will of course also need to reconstruct the screen so it uses the new textures.
Related
I'm creating an html5 banner using Google Web Designer. I've created the banner and published it. When I view the published version I noticed that it takes sometime to load.
Someone else on my team is also creating HTML5 banners. The banner that he creates loads instantly even though its a larger file size. We compared our files and other than the actual assets, the way the banner was created and published is the same.
Does anyone have any ideas why this might be happening?
GWD add this code at the end of the banner and animation show up immediately:
<script data-exports-type="dclk-quick-preview">studio.Enabler.setRushSimulatedLocalEvents(true);</script>
Which environment are you using?
When creating a new project in GWD you are able to select an environment. By default is DoubleClick.
This adds additional file (in the case of DoubleClick, the Enabler library).
If you open your Chrome console, while running the banner, you will see that the banner is not initialized until the enabler is available.
You will also see how much time it takes to load the enabler.
If your colleague is creating a banner without that library, or without correctly listening to the event Enabler.initialized, this may be the main reason for the discrepancy.
If you don't want to include this additional library (that is used to integrate your banner in DoubleClick Studio), just select Generic from the environments dropdown.
There is also another reason that may cause the delay, and is the PoliteLoader.
You can select to politeLoad the banner from the Publish menu.
If the PoliteLoader is selected this cause the banner to be initialized only after the page is fully loaded. This may cause delays compared to a non polite loaded ads.
This all seems not to be a bug, but a feature of enabler.js simulates a test environment, when not beeing uploaded to Adwords (guess it similar in Doubleclick). Uploading to Google Environments should change the situation
Look at the console and see:
There is a long delay in alle items loading after the enabler.js.
It is NOT because of a long loading time of enabler.js - thats all fine.
Looking at the Logs, the enabler waits a second and throws out:
[ 1.008s] [studio.sdk] Using default ad parameters in test environment. Simulating local events.
When uploading to Google Adwords (i assume that this all is similar to DC Studio) - the enabler throws out different logs and the delay disappears.
Hope this was helpful.
By chance, I found out a way to make the Enabler loading fast. Instead of using Publish, use Preview to generate the HTML.
For some reasons, Enabler.js in preview-generated HTML only takes 0.019s to load as compared to Enabler.js in publish-generated HTML taking 1.015s to load.
Studio Enabler SDK looks for "e" parameter in iframe URL containing Studio creative. It expects a number and uses that to set the creative environment.
Setting e=1 in your preview environment (query string parameter in the iframe url pointing at the index.html for your studio creative) will tell Enabler to use LIVE mode.
I assume there is a reason why Enabler has this functionality (avoid counting impressions or paying for impressions from test/qa environment)...so I wouldn't suggest using this as a permanent setting.
I've been running some tests here and I just want to confirm if someone could do something with this issue.
When I execute a notification action in background using new iOS8 notifications, the app starts in background and runs the delegate handleActionWithIdentifier after iOS initialization (I see how didFinishLaunchingWithOptions is called before).
But the AS3 is not called so I cannot handle any action in that end.
Anyone with the same problem? possible solutions?
Thanks
Finally I realized that I cannot reach AS3 execution if I use a mxml file for the AS3 app. But using AS3 files, I can reach the execution at least for the first main sprite initialization, so I can handle the notification response at that moment.
I have an http handler built and running on my website server. Code in flex generates a http request then navigates to the handler, which generates and streams back file information for the user to download.
Basically the request sends image data and the return result is a pptx stream with the image data in a powerpoint slide.
This worked fantastically this morning until about an hour ago. I have no idea what changed, but every swf I am building which attempts to access this handler is now giving me:
* Security Sandbox Violation *
Connection to https://g1.localhost/Turm/BounceBack.aspx halted - not permitted from https://g1.localhost/Turm/FlashApps/ImageAndExporting.swf?debug=true
I even fully qualified the BounceBack.aspx name (it was a relative url until just now) in case something was confusing the flash player, but as you can see, the url request and the swf are loaded from exactly the same domain (even the same virtual app in the web domain).
I have even added the physical filepath as a 'trusted folder' in my flash player security settings.
What gives? Anyone have any suggestions?
Using the Apache 4.9.1 SDK and latest version of flashplayer.
As mentioned, this worked all day yesterday and this morning. I cannot figure out what has changed, but am having no luck resolving the issue, source code has not changed.
Finally figured out what changed. I move the navigation to my ASPX handler into a seperate method that delays invoation till after a UI update. Becuase I use the same ui components for printing as well as exporting, I tested the updates with the print feature and that worked without error. About an our later, I noticed the handlers were failing. Since the url request is not handled inside a UI interaction event (Like MouseEvent.CLICK) the flash player was preventing the call. Once I moved the navigation back into the event handler, the sandbox violation went away.
If you ask me, not a very good error message due to the actual problem encountered, but ... you learn something every day.
I have a Flex 4 application that loads Flex 4 applications into it by using the mx.controls.SWFLoader component. I load the same swf-subapp several times as each subapp also runs standalone, and the content of the subapp is determined by a XML that I pass into it via the loader context.
This has worked until recently, but now, the second time I load the same swf (with a different xml) the loaded swf stops executing anything after the FlexEvent.INITIALIZE is triggered (I'm not doing anything in my initialized event handler). In other words, I don't get a CreationComplete event, which is where I start my code (and worse, no errors either).
As I've been working on a different part of my main application, I can't quite remember which change crashed my project, but what I do remember is that I updated my Flex SDK and I've hade similar silent errors in relation to a SDK upgrade earlier.
In my main application I do cleanup after myself before loading a new swf, so it shouldn't be garbage laying around.
Please help!
Solved it.
There was an enterframe handler that kept the first instance of the swf in memory, that in some way blocked the next one from loading (eventhough I used the removeAllElements on the parent container and hoped that would do the trick).
Now I use a NativeSignal and remove all listeners from that on onRemove handler (RobotLegs). Works like a charm.
I'm developing a plugin using FireBreath on Windows (for now) that among other things is displaying a webcam feed using OpenGL. I'm using a windowed plugin and I'm drawing from a separate thread. The code can be viewed here:
Header file
https://github.com/EvilTengil/kinect-at-home-plugin/blob/0007beecf136ff2e5e1aa50be94d4906447a8f43/Win/KinectAtHomeWin.h
Source file
https://github.com/EvilTengil/kinect-at-home-plugin/blob/0007beecf136ff2e5e1aa50be94d4906447a8f43/Win/KinectAtHomeWin.cpp
(Ignore the strange code in onWindowResized, it's just some testing that remained in the commit.)
The problem is that as soon as the browser window is re-sized so that the visible region of the plugin is changed or the the extension is somehow scrolled outside the visible area of the scroll box, the plugin crashes in Chrome. I haven't got Firefox installed but I'm guessing it's a NpApi thing, since it's working in Internet Explorer.
I believe what is happening is that Chrome releases and creates a new HDC whenever the visible dimensions of the plugin is changed. This probably results in that the Rendering Context is invalid, but it is still being used in the plugin and that causes the crash.
I've noticed NPP_SetWindow get's called when this happens, but those calls are ignored in NpapiPluginModule_NPP.cpp, so my there is no way of hooking in to this event.
I've Google for several hours now but without finding any help. Does anyone have any experience of this?
I have an idea that it could work if I created my own child window to the plugin window where I could handle my own DC. I did some quick testing that failed, which is probably because of my lame Win32 skills. But could this work with some more work? Another idea I have is to track the visible region somehow, but I haven't looked in to this yet.
Windows handles getting invalid should not cause a program to crash per so. But OpenGL, namely its extensions require some special precautions, especially if the host program makes use of OpenGL as well.
Any kind of plugin or DLL that makes use of OpenGL must take care, that is puts its required resources into a sane state before using them, and put them back once done. For OpenGL this means, everytime before you start using it you should rebind your context:
HDC hOldDC = wglGetCurrentDC();
HRC hOldContext = wglGetCurrentContext();
// first unbind old context/DC from current thread
wglMakeCurrent(NULL, NULL);
// then bind our context
wglMakeCurrent(hMyDC, hMyContext);
// this is essential, as in Windows the addresses of extensions
// may depend on the active context, so you must reinitialise
// extension function pointers!
reinitialize_extensions();
/* NOW USE OPENGL FUNCTION
// cleaning up once we're done:
wglMakeCurrent(NULL, NULL);
wglMakeCurrent(hOldDC, hOldRC);
// remember that we also need to reset extension
// function pointers to the other context
reinitialize_extensions();
Since in Window extension functions pointers depend on the context it makes sense to put them into a structure and call them through that one. This saves the whole extension reinitialisation thing. In C++ you could wrap the whole OpenGL context in a class for this.
Remember that you need to go through this setup/teardown everytime your plugin gets called through NP-API.