> > Ah, this sounds quite usefull to hide the loading, allthough I'll have > to read up. > I assume this is how, say, GoogleMaps does it?
I think it's quite common where you want to have control over how images are handled yourself - as I say there are plenty of examples around of how to do the serlvet. > > "You are thinking of loading 20MB of images into the DHTML DOM of you > application" > > Am I? Does the DOM keep them there even when not displayed? > These images certainly wouldnt be displayed all at once. 1 or 2 at a > time at most. I'm not absolutely sure, but I think if you load an image it is basically attached to a document, whether the browser caches it or not, and whether it is currently visible of not. You don't control the browser cache, I mean I don't think you can tell it to conveniently download all your images and store them neatly on disk until you need to display them for example. It's also more than likely each browser does things differently. > > But the vaste majority of players should happily be able to load > 20-30MB onto their hard disk for the course of the game. That's my point: I don't think it works like that, I can see why it would be nice for you if it did. The browser probably does store images locally in some circumstances, but I believe this would be for virtual backing for the document it's loaded/displaying if required for memory management purposes. I.e. you've got a document of 20MB loaded which it must manipulate. I may be wrong, you'd need to investigate to be sure. > > "They > are deliberately designed to make downloading huge chunks of binary > data difficult, especially transparently, and they are not expecting > to have to display 20MB worth of images at once. " > > Again, not at once. > Surely a staggered download they wouldnt have a problem with? > Emulating, say, what it would expect from a user browseing DeviantArt? > yeah, the staggered download is basically the idea of the maze - each time you move to next location you've only got one locations worth of images to fetch. Or if it worked fast enough you could fetch all the required images for the adjoining locations so they would be ready to go instantly. It depends entirely on no of image bytes per location. Point is doing it this way old images are thrown away and can be garbage collected as you go, so you are not accumulating images in memory. It's stable. (assuming I'm right about the how this works of course). > "If you leave it to the browser, it makes one Http call per image and > you cannot guarantee the order they will be fetched. I" > > Yes, I noticed this already. Its interesting, as I expected it to be > in a first-come-first-served base's, but I guess theres some > optimisation within a timeframe. > I do wonder though what the limit of this is and if its the same per > browser. (I mean, if I loaded no more then 1 image every 10 seconds, > it would probably do it in the order I asked, but not if I asked for > one to be prefetched every 10ms) > This is more a curiousity though. > > ". The point of > the composite image strip is to fetch several images in one request > since they come in a single binary file. " > > Yes, I understand the point of them, and I think image bundles are a > great idea. > (In fact, online in general, theres probably a lot of wasted bandwidth > used on little UI elements on webpages..like 5kb gifs etc....) > In this specific case though they arnt approperate. > Not unless I got the server to dynamically splice the images together > and the client to cut them up. > But thats beyond the scope of the projects timeframe. This is exactly what the GWT ImageBundle does (and what has been best practice in web design for years). Annoyingly for you GWT only does this once per module because Bruce says they can't think of a single use case for needing separate ImageBundles! My bet is that if you just start loading all the images as you are suggesting, you will have to attach them to the DOM somewhere, so ultimately what you will be doing is building the entire game at the same time as the player is trying to play the first locations. So my betting is three to one on a) whilst this build is going on the game play will be badly affected at precisely the time you least want it to, and b) once you've loaded it all it will run like a dog anyway. I may well be wrong, but if I'm not, and you looked at the maze idea as plan B, then using image strips a la ImageBundle will make the game run much faster and smoother, so the effort might well be critical in the end. This is after all the heart of your technical challenge. This has been done so many times I expect you will find some javascript code that cuts them up (or maybe CSS stuff) to crib from somewhere and some server side tools to pack the image strips as well. > > On Feb 5, 3:27 pm, gregor <[email protected]> wrote: > > > I'm not sure I can be of much more help on this myself, since I have > > never written anything like this, and I have not come across any > > specific posts about it I can recall - maybe some members have, so you > > can hope.... > > > A few ideas/comments in-line: > > > On Feb 5, 11:42 am, darkflame <[email protected]> wrote: > > > > 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. > > > This question does come up quite a lot and has been answered including > > in the link I gave you (where it comes from the horses mouth). The > > fundamental issue is that the GWT compiler performs serious > > optimization at compile time to reduce javascript file size. To do > > that it produces a single js file at compile time and does not support > > the idea of loading the application in "chunks" unless you do the > > multiple module with separate entry point thing. You can read the > > thread and others for technical details. > > > > 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. > > > Another classic approach is the "maze" design (I think this is how > > trad text adventures where generally done). You have rooms with doors > > (or walls) connecting to other rooms. You have the maze defined in a > > data structure on the server, and when player gets to a room (i.e. a > > location), you download each of the rooms they can move to next which > > are specified as properties of the doors. Each room has its associated > > script file and images etc. I think this is fairly common and you will > > probably find ready made code examples around the web. The Gang of > > Four use it as example in introduction to creational patterns chapter > > in the famous book. > > > The big issue is how many separate images are required for each > > location. If its basically only one, its easy. You fetch the location > > scripts and data for each adjoining room over GWT RPC (very quick) > > which includes image ID's. Then you fetch the room image for the room > > they go to (again very quick if images are 100-200Kb etc). If several > > images, you have a multiple HTTP call problem which you really want to > > avoid. That's the idea behind the composite image strip. Much faster. > > It's what good image galleries do with thumbs for example. > > > > "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. > > > As I mentioned having the browser download the images via simple URL > > to image location is distracting for the player as the browser reports > > progress all the time. If you use your own file download servlet > > called repeatedly you avoid that problem, it does happen invisibly in > > background. Use standard HttpServlet and feed its URL + image ID param > > into Image object constructors. Lots of examples for this in group and > > around net. > > > > Is it a ram issue? A cpu one? I think in total we are only talking > > > about 20MB of images here, 30MB at most. > > > You are thinking of loading 20MB of images into the DHTML DOM of you > > application. The DOM is maintained by the browser, and it is not > > designed to deal with 20MB documents (big e.g. PDF's are downloaded > > into viewer plug-ins etc). Would you serve a single 20MB static HTML > > page? Most people consider a 1MB javacript file to be big. I'm not > > sure what the practical limits really are for the different browsers, > > and it probably also depends to some extent on what else they have > > running in other browser tabs. Personally I would avoid this approach, > > it doesn't feel right at all. > > > > 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. > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
