As you say, it's just how
scene works. And yes, it's happening in all those other games too.
The difference I suspect is that you've noticed it in your game and not noticed it in others. A bit like that cobweb in the corner of your room... it's probably been there for months, but now you've seen it... you'll be looking at it at least once a night.
The other thing is that you have one image followed by one line of text. With more dialogue (which is what all those other games have), it'll be less noticable.
I personally would also add
with fade when moving between locations and
with dissolve when changing images within the same location. But neither affect the thing you're describing.
Yes, it can cause issues if you code it like that.
Firstly though... You don't need to declare the images explicitly like that.
As part of it's start up processing (or maybe it's during the build process), RenPy scans the
/images/ folder and creates
image statements automatically for every valid image it finds there and any sub directories.
The only kink is that the generated
image displayables are named in lowercase. (So it's generally a good idea for files to be also named all in lowercase for your sanity).
/images/image01.png ->
image image01 = "image01.png"
/images/faces/image99.png ->
image image99 = "/faces/image01.png"
/images/DUMB01.png ->
image dumb01 = "DUMB01.png"
/images/this_file_01.jpg -> image this_file_01 = "this_file_01.jpg"
/images/this file 01.jpg ->
image this file 01 = "this file 01.jpg" (note the spaces in the filename).
This behavior is configurable, but I'll come back to that later.
Anyway, my point is that you rarely need to write your own
image statements.
Back on topic...
First the hard way...
Python:
label start:
scene black with fade # black background when no other image is shown over it.
# not strictly needed, you could do scene image01
show image01 with fade
mc "text 01"
show image02 with dissolve
hide image01
mc "test 02"
# effectively hiding the previous image by name each time a new one is shown. Memory issues... solved. Typing nightmare begins.
I hope you can see how painful that will become very quickly.
However, the way RenPy was original designed was to use full screen (background) images with foreground (character) sprites overlaid on top.
For this reason, RenPy has an image tagging system. Each displayable is tagged with the first part of it's
image id preceding any spaces.
Now in most recent RenPy AVN games, there aren't any spaces in the
image identifiers. (Mainly because they aren't using the sprite system).
So...
image this_file_01 = "/images/this_file_01.jpg" would be tagged as "this_file_01".
However, if your image statements include spaces - things change.
image this file 01 = "this file 01.jpg" would be tagged as "this" only.
The critical part of this is that only
one displayable tag can be displayed on screen at any time. Any previous ones are removed.
The way this is designed is for things like this:
Python:
define e = Character("Eileen", color="#04B486")
image eileen neutral = "eileen_neutral.png"
image eileen smiling = "eileen_smiling.png"
image eileen sad = "eileen_sad.png"
image bg myroom01 = "bg_myroom01.jpg"
image bg myroom02 = "bg_myroom02.jpg"
label start:
scene bg myroom01 with fade
show eileen neutral with dissolve
e "Hi, my name is [e]."
show eileen smiling at left with dissolve
e "Today I'm happy."
show eileen sad at right with dissolve
e "Tomorrow I might be sad."
scene bg myroom01 with dissolve
"Some more dialogue."
"Whatever."
"*** THE END***"
return
In this case, each image tagged
eileen automatically removes the previous
eileen tagged displayable.
Then the
scene statement means not having to remove that final
eileen sad image.
Note that I've had to add the
image statements manually, because the tagging system needs those spaces, but my imaginary filenames use underscores (which is pretty common).
Now think beyond just
eileen. The same system would work for the background images tagged as
bg.
As long as the first element (the tag) is unique, only one can be displayed at once.
So...
show bg myroom01 followed later by
show bg myroom02 would replace one
bg displayable with another.
Doing so would avoid the problem of the dialogue box fading out and in again. However, you might now need to add a
hide eileen with dissolve to hide the "eileen sad" image, since there would no longer be a
scene statement to do it.
Now... you're probably thinking about renaming your image files to use spaces rather than underscores. That way, you don't need to manually add all those extra
image statements. It's a pain in the arse. Better to stick to underscores, which is what applications like Daz3D will want to use anyway.
RenPy already has you covered.
Add this line into your
options.rpy file...
define config.automatic_images = [' ','_','-','/']
This will strip any of those characters out of the filename and create an
image statement using the removed characters as separators for the tagging system.
Because of the "/" in the list, that also means any subdirectory names are also processed too.
You can make use of this by picking directory names to aid the tagging system.
/images/bg/myroom01.jpg ->
image bg myroom01 = "/bg/myroom01.jpg"
/images/bg/myroom02.jpg ->
image bg myroom02 = "/bg/myroom01.jpg"
/images/eileen/smiling.png ->
image eileen smiling = "/eileen/smiling.png"
/images/eileen/neutral.png ->
image eileen neutral = "/eileen/neutral.png"
/images/eileen/sad.png ->
image eileen sad = "/eileen/sad.png"
All of which is a very long way to say that if you name your files correctly and use that options override, you can use
show rather than
scene without running into those potential memory issues in order to not have the dialogue box disappear and reappear.
All that explained... honestly, I'd stick to using
scene statements like every other game. Most RenPy devs know nothing of this displayable tagging system - and they just do things like
scene myroom2 with fade without all that tagging. Which is fine, because most of them aren't using foreground sprites any more either.
Edit: The "best" way is to use [icode]scene[/icode].
The rest of the post is just explaining a way to do it how you want. It really isn't as complicated as it sounds to implement - but it's fixing a problem almost everyone thinks is normal behavior. So take the path of least resistance and keep things simple.
