I currently have 6 animated models each between 5Mb and 8Mb each. When using each one individually it can take a little time to download them. I need to load these models up as and when I need them and not in the preloader of libGdx. All 6 models will take a long time to download in the preloader so I'm trying to bypass it.
I've used both GWT and libGdx many times but not together. This project is purely a html one and I'm familiar with classes that need to be serialised so data can be transferred back and forth using GWT's RPC methods.
So far I've come up with 2 ideas of doing this:
Transfer the model data and rebuild the mesh from scratch. This
would take a lot of time and just wouldn't work. Plus it's likely I'll lose such data like animations.
Using LibGdx's
ModelData class which would work perfect, but unfortunately non of
the main class and sub classes are serialised.
The current project has interfaces that bridge the platform specific from the 'core' to the 'html' which can then async the RPC calls. These work with libGdx just great.
Is there a way of skipping the preloader and loading the models on demand when they are needed?
If you need anymore information I'll be glad to add that in.
Take a look at the Dynamic Asset Loading with libGDX and GWT example by MonsterOfCookie: https://github.com/MonsterOfCookie/libGDXGwtHtmlExample
Disadvantage is that you have to compile your own libGDX fork because Monster's PR was not merged. (But for working seriously with libGDX' GWT backend you'll probably need your own fork anyway)
Related
I'm currently restructuring my LibGDX-Projekt to fit an ECS-Structure using Ashley.
At the moment I have the following System-Structure:
InputSystem (handles Player-Input)
PhysicSystem (applies velocity to entities, does collisiondetection and moves them)
CameraSystem (adjusts the camera to the camera-focus)
RenderingSystem (transforms the SpriteBatch with the camera-information and draws all entities)
Now I know that each System is supposed to contains all the logic it needs and is encapsuled to reduce complixity.
But I need the camera in the CameraSystem to adjust it, I need it in the RenderSystem to apply the camera-transformation and I need it in the InputSystem to see where the mouse is pointing at. How do you solve this with the ECS-Approach? Can Systems communicate with one another? Should I just use a Singleton called "SharedData" where I dump all the stuff that multiple systems need? Seems a little ugly to me.
Thanks in advance :)
Yes, using a singleton would defeat the purpose of using an ECS in the first place. In an ECS, the approach used is that all shared data is expressed using entities. It is perfectly fine to have an Entity type for which there will only be once instance of it during the lifetime of the game.
These could then be accessed directly from the Engine when the EntiySystem is added to it. An alternative approach could be to pass commonly accessed entities to the constructor of the systems if it is frequently accessed, in the past I have used this for passing a Box2D World entity.
I believe my code does a better job of explaining my reasoning so you can have a look at one of my previous games using Ashley. https://github.com/basimkhajwal/LSD
P.S - My project also includes an event queue for messaging between different entity systems (without passing data, all the data is still encapsulated in Entity classes) which I found to be extremely useful.
I'm starting a new project from scratch, and while I've also been creating and handling views and viewcontrollers programmatically so far (some some xibs from time to time, for some simple views), I'm now wondering if it's time to switch to Storyboards. It looks like Apple is pushing for them really hard, and maybe I shouldn't fight against them and embrace the new approach? (not really new, but maybe now mature?)
Pros:
You can really see your app and the connections between the app. If you have some UI that doesn't need logic (for example Terms Of Service with some static text and an Agree button that takes you to the next screen) you don't even need to create the controller part of that.
Cons:
If you're in a big team, storyboards can be really hard to merge when using version control.
Fore more info:
http://www.youtube.com/watch?v=XciUazpOfFU
Almost only cons. Here's is a list of their problems, copied from iraycd:
Storyboards fail at runtime, not at compile time: You have a typo in a segue name or connected it wrong in your storyboard? It will blow up at runtime. You use a custom UIViewController subclass that doesn't exist anymore in your storyboard? It will blow up at runtime. If you do such things in code, you will catch them early on, during compile time. Update: My new tool StoryboardLint mostly solves this problem.
Storyboards get confusing fast: As your project grows, your storyboard gets increasingly more difficult to navigate. Also, if multiple view controllers have multiple segues to multiple other view controllers, your storyboard quickly starts to look like a bowl of spaghetti and you'll find yourself zooming in and out and scrolling all over the place to find the view controller you are looking for and to find out what segue points where. Update: This problem can mostly be solved by splitting your Storyboard up into multiple Storyboards, as described in this article by Pilky and this article by Robert Brown.
Storyboards make working in a team harder: Because you usually only have one huge storyboard file for your project, having multiple developers regularly making changes to that one file can be a headache: Changes need to be merged and conflicts resolved. When a conflict occurs, it is hard to tell how to resolve it: Xcode generates the storyboard XML file and it was not really designed with the goal in mind that a human would have to read, let alone edit it.
Storyboards make code reviews hard or nearly impossible: Peer code reviews are a great thing to do on your team. However, when you make changes to a storyboard, it is almost impossible to review these changes with a different developer. All you can pull up is a diff of a huge XML file. Deciphering what really changed and if those changes are correct or if they broke something is really hard.
Storyboards hinder code reuse: In my iOS projects, I usually create a class that contains all the colors and fonts and margins and insets that I use throughout the app to give it a consistent look and feel: It's a one line change if I have to adjust any of those values for the whole app. If you set such values in the storyboard, you duplicate them and will need to find every single occurrence when you want to change them. Chances are high that you miss one, because there's no search and replace in storyboards.
Storyboards make you do everything twice: Are you building a universal app that runs both on iPad and on iPhone? When you use storyboards, you will usually have one storyboard for the iPad version and one for the iPhone version. Keeping both in sync requires you to do every UI or app-workflow change in two places. Yay. Update: In iOS 8 and Xcode 6, you can use a single Storyboard for iPhone and iPad.
Storyboards require constant context switches: I find myself working and navigating much faster in code than in storyboards. When your app uses storyboards, you constantly switch your context: "Oh, I want a tap on this table view cell to load a different view controller. I now have to open up the storyboard, find the right view controller, create a new segue to the other view controller (that I also have to find), give the segue a name, remember that name (I can't use constants or variables in storyboards), switch back to code and hope I don't mistype the name of that segue for my prepareForSegue method. How I wish I could just type those 3 lines of code right here where I am!" No, it's not fun. Switching between code and storyboard (and between keyboard and mouse) gets old fast and slows you down.
Storyboards are hard to refactor: When you refactor your code, you have to make sure it still matches what your storyboard expects. When you move things around in your storyboard, you will only find out at runtime if it still works with your code. It feels to me as if I have to keep two worlds in sync. It feels brittle and discourages change in my humble opinion.
Storyboards are not searchable: A project-wide search in Xcode is not really a project-wide search when you use storyboards. They are not included in the search. So when you remove a custom class from your code or rename it, you will have to manually go through the storyboard or look at its raw XML to make sure it is on par with your code changes. No sir, I don't like it. Update: Storyboards are searchable in Xcode 6.
Storyboards are less flexible: In code, you can basically do anything you want! With storyboards you are limited to a subset of what you can do in code. Especially when you want to do some advanced things with animations and transitions you will find yourself "fighting the storyboard" to get it to work.
Storyboards don't let you change the type of special view controllers: You want to change a UITableViewController into a UICollectionViewController? Or into a plain UIViewController? Not possible in a Storyboard. You have to delete the old view controller and create a new one and re-connect all the segues. It's much easier to do such a change in code.
Storyboards add two extra liabilities to your project: (1) The Storyboard Editor tool that generates the storyboard XML and (2) the runtime component that parses the XML and creates UI and controller objects from it. Both parts can have bugs that you can't fix.
Storyboards don't allow you to add a subview to a UIImageView: Who knows why.
Storyboards don't allow you to enable Auto Layout for individual View(-Controller)s: By checking/unchecking the Auto Layout option in a Storyboard, the change is applied to ALL controllers in the Storyboard. (Thanks to Sava Mazăre for this point!)
Storyboards have a higher risk of breaking backwards compatibility: Xcode sometimes changes the Storyboard file format and doesn't guarantee in any way that you will be able to open Storyboard files that you create today a few years or even months from now. (Thanks to thoughtadvances for this point. See the original comment)
It's McDonald's: To say it in Steve Jobs' words about Microsoft: It's McDonald's (video)!
One other Pro exclusive to UIStoryboards: Static table view cells. Per Apple, "With static content, the number of rows is a finite quantity that’s known at compile time. A table view that presents a detail view of an item is a good candidate for static content."
I'm developing a game with AS3 and AIR. I will have a large-ish quantity of images that I need to load for display elements. It would be nice not to embed all of the images that the game needs, thereby avoiding having them all in memory at once. That's okay in smaller projects, but doesn't make sense here.
I'm curious about strategies for loading images during run time. Since all of the files are quite small and local ( in my current project ) loading them on request might be the best solution, but I'd like to hear what ideas people have for managing this.
For bonus points, I'm also curious about solutions for loading images on-demand server-side as well.
a good idea would be, to create external SWFs, that embed images, that are likely to be used together, if that is possible at all ... something like projectiles.swf, obstacles.swf, enemies.swf, misc.swf .... i don't know ... something that makes sense ... maybe divide assets by levels, or something ... take a simple interface, that allows you to extract assets from an swf ... for example, let there always be a class Assets, with a static method getAll, which returns an Object, mapping string identifiers to corresponding classes, so you will get something like:
function onComplete(e:Event) {//this is the handler for the loading operation
var map:Object = (e.target as LoaderInfo).applicationDomain.getDefinition("Assets").getAll();//should return something like {"bullet1":Bullet1,"bullet2":Bullet2,...}
//do whatever you need to do with it
}
advantages:
images get compressed one against another, so overall filesize will be decreased ...
you drastically reduce request count on your server ...
you don't wind up with n-hundred files, following some name/path convention, or even not (also, you need to have a file index somewhere, to know, which files exist and which don't) ...
you can easily reskin your app by loading a different swf, instead of loading n-hundred images seperately ...
the ultimate advantage of this approach is, that you will have classes, that you can simply instantiate, instead of loading images over and over again ... the first operation is synchronous, the latter is not ... if you really need to do that, consider loading the image in binary form into a ByteArray using URLLoader, and then getting it on stage with Loader::loadBytes ...
you may want to generate the swfs on serverside using swfmill, to automate the process ...
greetz
back2dos
for you project
u can make solution using amfphp and mysql blob-storage.
in this link u can take understand how mysql blob-storage.
http://www.anyexample.com/programming/php/php_mysql_example__image_gallery_%28blob_storage%29.xml
and for amfphp please visit
http://www.amfphp.org/
and also please check this AMFPHP Live JPEG Encoder too,
http://www.bytearray.org/?p=90
The solution that I ended up settling on was to create a reusable singleton loading class which manages the loading and storage of data on-demand. It manages "jobs" which can be LOCAL or REMOTE which store references and the loaded data itself which is mapped in the manager class once it has fully loaded.
While I really like back2dos's suggestion, managing the (re-)creation of SWF's everytime an asset changes isn't optimal for my purposes.
I am developing a "dumb" front-end, it's an AIR application that interacts with a "smart" LiveCycle server. There are currently about 20 request & response pairs for the application. For many reasons (testing, developing outside the corporate network, etc), we have several XML files of fake data, and if a certain configuration flag is set, the files are loaded, a specific file is parsed and used to create a mock response. Each XML file is a set of responses for different situation, all internally consistent. We currently have about 10 XML files, each corresponding to different situation we can run into. This is probably going to grow to 30-50 XML files.
The current system was developed by me during one of those 90-hour-week release cycles, when we were under duress because LiveCycle was down again and we had a deadline to meet. Most of the minor crap has been cleaned up.
The fake data is in an object called FakeData, with properties like customerType1:XML, customerType2:XML, overdueCustomer1:XML, etc. Then in the FakeData constructor, all of the properties are set like this:
customerType1:XML = FileUtil.loadXML(File.applicationDirectory.resolvePath("fakeData/customerType1.xml");
And whenever you need some fake data (this happens in special FakeDelegates that extend the real LiveCycle Delegates), you get it from an instance of FakeData.
This is awful, for many reasons, but it works. One embarrassing part is that every time you create an instance of FakeData, it reloads all the XML files.
I'm trying to figure out if there's a design pattern that is not Singleton that can handle this more elegantly. The constraints are:
No global instances can be required (currently, all the code dealing with the fake data, including the fake delegates, is pulled out of production builds without any side-effects, and it needs to stay that way). This puts the Factory pattern out of the running.
It can handle multiple objects using the XML data without performance issues.
The XML files are read centrally so that the other code doesn't have to know where the XML files are, and so some preprocessing can be done (like creating a map of certain tag values and the associated XML file).
Design patterns, or other architecture suggestions, would be greatly appreciated.
Take a look at ASMock which was developed by a good friend of mine (and a member here Richard Szalay) and is based on .nets Rhino mocks. We've used it in several production environments now so i can vouch for it's stability.
should be able to get rid of any fake tests (more like integration tests) by using the mock object instead.
Wouldn't it make more sense to do traditional mocking with a mocking framework? Depending on your implementation, it might be possible to set up the Expects by reading the fake-data XML files.
Here is a Google Code project that offers mocking for ActionScript.
My website is entirely flash based, it moves around a 3D model which was given to me as chunks of video that I've converted to FLV files. I'm using the FLVPlayback component to control the video inside of my program. While running memory checks using System.totalMemory I've noticed that whenever a video is loaded, it will eat up a chunk of memory and even when I remove all the event listeners from it(they are all weakly referenced), remove the component from its parent, stop the video and null the component instance, it still will not give that memory back.
This has been bothering me since I started working on this project because of the huge amount of video a user can potentially instantiate and load. Currently every video is loaded into a new FLVPlayback instance whenever it is required, but I have read that perhaps the best way to go about this problem is to simply have a global FLVPlayback instance and just reload the new video into the old instance, that way there would only be one FLVPlayback component in the application's memory.
Has anyone else run into this problem as well? Have you found a better solution than using a global instance that you just re-use for every new video?
I've never really liked the components, they're a bit dodgy. This particular problem seems to be common, and the somewhat annoying solution is, as you're suggesting, to only have one FLVPlayback and reuse that.
Here's a blog post about it
You can't help the memory problems much until Flash adds destructors and explicit object deletion, unfortunately. See this thread:
Unloading a ByteArray in Actionscript 3
There's a limit to how much memory Flash applets can use; the GC seems to fire upon reaching that limit. I've seen my memory-easy applets use as much as ~200MB, just because they run for hours on end and the GC doesn't want to kick in.
Oh, and I don't think using a single instance is an elegant solution, either. Currently I just write a dispose() function for my custom classes, waiting for some day when it can be turned into a proper destructor.
From what I gather after a lot of testing is that flash dynamically loads in libraries and components as needed but never garbage collects that data. For instance, if I have a website or an Air app that uses the FLVPlayback component, the actual component and libraries associated with it aren't loaded until a new FLVPlayback() instance is created. It will then load in the library and component into memory but you will never get that space back until the program / website is closed. That specific instance with the video inside of it will get garbage collected and release some memory as long as you remove listeners from it, take it off the stage, and set it to null.
Also, if you are doing individual videos, the VideoPlayer is much lighter weight, and cleans up nicer.
Thanks for the responses, the links to the other blog questions were helpful as well, I had read all of Grant Skinner's info on garbage collection too, but searching through those links and going back and re-reading what he had originally said about GC helped refresh the old noggin. In addition to nulling and re-instantiating that single FLVPlayback component, I also realized that I wasn't correctly unloading and destroying my Loader instances either, so I got them cleaned up and now the program is running much more efficiently. I would say the memory usage has improved by around 90% for the site.
#aib I will admit the single instance solution isn't elegant, but because flash just won't let go of those FLV files, I'm kind of stuck with it.
#grapefrukt I detest the flash components, they typically cause more grief than time saved, however in this case I had a lot of cue points and navigation stuff going on with the video files and the FLVPlayback component was the best solution I found. Of course I'm still fairly new to the ActionScript world so perhaps I over-looked something.
Unfortuantely, thats just the way flash handles it. Not particularly smart, but it works for most people.