It looks like you're new here. If you want to get involved, click one of these buttons!
html {
background: [img[club.jpg]] fixed;
background-size: cover;
min-height: 100%;
height:100%;
}
body {
color: #111;
font-family: Georgia;
font-size: 16px;
background-color: transparent;
}
#ui-bar, #ui-body {
background-color: #222;
color: #e6e6e6;
background: hidden;
background-attachment: fixed;
background-color: transparent;
border-color: transparent;
}
This results in a body and ui bar that are completely see-through, leaving only the basic background and passage styling on top. Which is cool, but means I can't change the background image mid-story.
Comments
1. I am using a class of street to show the street.jpg background image, you can name the class and image whatever you like. Remember to add the following CSS later in your stylesheet than your existing html selector. 2. Add the following addclass macro to the first passage you want to start showing the new background image: 3. Because people can use the browser back button to travel backwards through your story you will need to also add a removeclass macro to all passages that directly lead to the passage you added the addclass macro to in point 2.
Not in my story they can't!!!
Thanks for the reply
Could I possibly do something silly like adding the <addclass>> macro with the images to the StoryInit passage or simply using the [img[image.jpg]] entry in StoryInit so that they're loaded in before game start, then remove them at the Start passage?
That might work, yes, though since
StoryInit
produces no output (technically, it discards all created output), there would be nothing to remove. The only possible snags I foresee is that the created<img>
elements may not live long enough to get theirsrc
cached or, if it takes a while to come across these images, they could be removed from the cache prematurely (those are both browser implementation details). Regardless, I'd give it a try, since it's a simple solution (and I may be worrying over nothing).If that doesn't work for you, then programmatically creating
<img>
elements and simply not attaching them to the DOM (nor discarding them) would probably work. For example: (preferably in your Story JavaScript) n.b. I'd recommend only doing this for large and/or long lived images, however, as doing this for every image would be overkill.This seems to work on my machine, with the interesting side effect that the screen just goes blank white and doesn't show any loading bar as the storyinit passage loads. Once it's finished loading the images, I get the load bar very briefly as it moves to load the first passage.
Because of this I don't want to use it for too many images.
I'm getting an error when I put this code into my story. I put it after the sound macros in my story java area and it results in the story refusing to recognise the sound macros.
Ah, I believe I know what's going on there. Something I'll have to publish a new release to address.
The code has been tested. You likely broke something on copy or when populating the
sources
array.No, the
<link>
element is not legal outside of the<head>
element (and you shouldn't be using the starting passage as an initialization dumping ground anyway). That said, adding<link>
elements to the document head during startup isn't terribly difficult.For example:
To get it to run smoothly on the first time the image is seen, I actually have to create a separate start passage for each image and go:
<<addclass "html" "club">>
<<timedcontinue 1s>>
<<goto "Loading 3">>
And that continues through to Loading 1, each "loading" passage adding a new image to the background, and when all 4 loading passages are cycled, the game switches to the proper start passage.
So not ideal, but better than a weird hitch during the first image load. I could always try to make the images transparent maybe during this loading sequence so players don't get a brief preview of each image.
Please, tell me you tried all three together only as a last resort.
Just how large are these background images (in size and dimensions)? Does this happen in all browsers or just one? Are you using a WebKit/Blink-based browser? Live example?
I'm developing offline with chrome atm, and was originally using images 2mb each, but since optimised them down to about 300kb each. Images are 2560 x 1440.
Still same issue, which is that the very first time you encounter the transition, there's a slight pause before the game activates the transition (I don't just switch upbuptly, but have a 1s fade between each image).
But I don't actually mind my latest solution. It creates an interesting loading sequence of images so will probably just keep it on aesthetic grounds alone.
The emphasized parts are your real problems.
Raw file size matters during the loading of an image. Once that's been accomplished, the next hurdle are the pixel dimensions. To render an image onscreen, a bitmap must be created for it. A 25601440 pixel bitmap takes a bit of processing (and memory), thus the delay you're noticing as the bitmap is initially created for the image.
Common tricks, as we've been trying, are aimed mostly at caching the original image (I suppose that's my fault for not asking questions to begin with). To solve the (let's call it) bitmap latency, you need to have the browser not only load the original image, but also create the onscreen bitmap for it. In Firefox and IE, you could simply have the images rendered offscreen someplace (e.g. with a
<div>
, containing the images, fixed at a position far offscreen) or possibly even onscreen but invisible (e.g. same setup as before, but with hidden visibility or zero opacity, etc). WebKit/Blink-based browsers make this more a pain than it should be, however, because they require the image to be both onscreen and visible before they'll create the bitmap. Neither behavior is right/wrong, one is simply more of a pain in the neck.So, to resolve the bitmap latency for all browsers, you're going to need to have them rendered onscreen sometime before they're actually needed. Your current monstrosity does that, so if you like it you could simply stick with it.
Alternatively, you could do something like the following:
JavaScript: CSS: How it works: After the very first passage is rendered onscreen, the script creates a very small
<div>
(2px), layers the images inside it with fixed dimensions (1px), and then adds it to the page in a fixed position in the top left corner underneath the UI bar. While the images are extremely tiny and hidden from player view (by being underneath the UI bar), they are actually completely visible, so WebKit/Blink will render the image bitmaps.Also, let me readdress something from earlier:
The reason you're seeing the "blank white" bit is because of how Twine 2 spawns Play/Debug versions of your story. For a published file (i.e. under normal use), you should only see the load screen.
I'm aware that having such large images can give problems, but there are only 5 of them in my whole game, and it's not such a big deal to avoid having ones that look so good.
I take it there's now no need for any of the other preloader methods?