Thanks for your help. I know this isnt an issue many would come accross, allthough I thought there might be general methods for sensible progressive loading of large content.
I should have been a bit more specific with the way the app works, however, as it really does completely rule-out using image bundles for these images. This app is effectively like a game-engine, taking script-files, html and images from directorys on the sever. I'm not constructing the game myself, but rather the method used to create it. The upside of this is its very reusable, the downside is that all images have to be changable on the fly by other people in the team with no-codeing knowledge. Cutting and pasteing images together and clipping them on the client isnt really workable for this. Heck, I really dont have much to do with the game story/puzzle side.....I dont speak dutch! :P I guess in some case you could almost picture the game as a gallery application, with the images in a sequence and the goal is for the user to look/comment at one picture while the others are loading. Its not quite the case that the game is so dividable into levels. While it does have "chapters" which require specific images, theres other images that load at different times, and to some extent the game can be non-liner. Its perfectly possible to make a traditional text-adventure game in this engine, for instance. I have created, however, a "master list" of images and the most likely order they are needed in. "I would have thought the best approach might be to download the images as required for each level as the player advances through the game, and I would think displaying a "Loading area..." type message after they have completed a level is a traditional approach for games, especially giving them something to read whilst they are waiting." hmz.. Whats wrong with just loading it in the background as they are playing? By the time they done the first few puzzles, really thats enough time for the whole game to have downloaded. Surely todays machines are easily powerfull enough to handel downloading in the background while other stuff is going on? My goal is really to have waiting down to nearly zero, aside from a few seconds at the start. Is it a ram issue? A cpu one? I think in total we are only talking about 20MB of images here, 30MB at most. I'm thinking there should be a way to load continiously in the background, but not to burden the browser with too many call's at once. Cheers, Darkflame On Feb 4, 7:51 pm, gregor <greg.power...@googlemail.com> wrote: > I'm not sure this a "best practice" issue as such - I think you may > have more of an "edge case" here. I've tried your game (although I > can't understand what to do after first screen), but what happens is > that the browser is slogging away downloading data (presumably your > images) which gives gutter messages and hour glasses etc. This is very > distracting, but if you had to wait for the whole lot to download > before the game started you'd probably get bored and go somewhere > else. > > I would have thought the best approach might be to download the images > as required for each level as the player advances through the game, > and I would think displaying a "Loading area..." type message after > they have completed a level is a traditional approach for games, > especially giving them something to read whilst they are waiting. > > This approach is not so well served by GWT because AFAIK you can only > have one ImageBundle per module and in any case it is downloaded on > initial page load. You may find this thread interesting: > > http://groups.google.com/group/Google-Web-Toolkit/browse_thread/threa... > > In it Bruce Johnson comments: > > 4) History is the answer to apps that are "too big". If you combine > the > points from #2 and #3 above, hopefully it makes sense that whenever > you fear > your app is becoming "too big" for a single page, all you need to do > is > split it into multiple pages such that each page has a unique module > with a > unique entry point. History smooths all the page junction points, and > the > compiler is smart enough to eliminate code you don't use from each > page's > entry point(s). > > Which would appear to answer the one ImageBundle per module issue and > provide convenient inter-level load points. However I would also read > what Reinier has to say about it as he also knows what he's talking > about. It would certainly complicate your program. > > Failing that, you could consider handling image strips yourself. You > assemble a single composite image manually of all images required for > a single level in some convenient extraction grid. Then you use an > Image object for this composite image, but before you give it the URL, > you attach a LoadListener to it - this is so can tell when its > finished loading in your code and control the loading message and the > UI during level load procedure and kick off extracting the individual > image parts etc. > > It's a bit tricky to extract bits of one image to create several > others in your own code. I did it once for an experiment, it looked > like this: > > Image sampleImage = new Image(someURL) > ..... > ..... > HTML box = new HTML(); > Node imageClone = sampleImage.getElement().cloneNode(false); > box.getElement().appendChild(imageClone); > grid.setWidget(i, j, box); > Image part = Image.wrap((Element)imageClone); > part.setVisibleRect(7,7,10,10); > > The problem I found is that you can use an <img> Element to make a new > Image object (which you can then clip), but it must be attached to the > DOM already, hence the messing about. This works, but I make no claim > that it is the most, or even a reasonably, efficient way to do it. > There may be a much better way to do this in GWT, or you may find that > you can do it better in javascript and use a JSNI interface. It might > be worth searching the javascript forums for some ideas, as I'm sure > this has been done before. > > regards > gregor > > On Feb 4, 1:37 pm, darkflame <darkfl...@gmail.com> wrote: > > > > > No, this is a large number of very large images, bundles are not > > approporate as that would mean they would all be loaded at once, and > > the user would have to effectively preload the whole game. > > This is not about icons, but actual images. (as it, 640x480 or in some > > case's much larger). > > > On Feb 4, 10:42 am, doopa <niallhas...@googlemail.com> wrote: > > > > Hi, > > > > The key is to use ImageBundles or use one large image that contains > > > all the icons you want to use and then draw only parts of them when > > > you want it displayed. > > > >http://code.google.com/p/google-web-toolkit/wiki/ImageBundleDesign > > > > How that helps. > > > > On Feb 3, 5:50 pm, darkflame <darkfl...@gmail.com> wrote: > > > > > I have quite a large app being developed, and requires various large > > > > images to be displayed at certain times. > > > > > As the app (rather, a educational game) has a login screen, it makes > > > > sense to start loading the images while the user is login in, and in > > > > the order of the images appearance. > > > > > I thought I handled this ok with a while loop, going over a list of > > > > images and using ; > > > > Image.prefetch(URL); > > > > To get the images ready. > > > > > However, from what I can tell, this is slowing down some systems (CPU > > > > wise). I think this is because I'm effectively telling all the images > > > > to load at once without a pause. > > > > Whats the best practice for loading a large number of images in a set > > > > order? > > > > > You can actualy see the game > > > > here;http://www.cuyperscode.com/CuypersCode2/CCIIstart.html > > > > But its in Dutch. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
