readables xdata : images in text possible?

Fidcal · March 17, 2008

Am I right in thinking that you can't just insert an image into xdata text like you would in html or Word etc? So how would this be done? Create a custom gui for each page? In this example five rectangles one for the background parchment, rectangles for the text at the top, left, and bottom, and one for the image? But you couldn't flow text through the text rectangles?

**greebo** · March 18, 2008

No, you can't have that kind of flow control. The GUI code is cool, but it is definitely not a word processor.

Fidcal · March 18, 2008

I think I was concerned about variations between systems like in a web browser but in fact I suspect a gui page will look the same on every system except finer detail on higher res and smaller in a window etc. But the format is fixed for that page so... I'll try to set up a gui to look something like the above. We could use a few with the image at different points, some with a couple of images. Just so there is a reference for mappers to copy and easily modify.

I'm also assuming that gui code allows the small rectangle for the small image to be superimposed over the large rectangle with the background image. Fairly sure it can.

The only thing to be considered is when the mapper sets it up the text won't flow so he has to split his text to end sensibly at the end of each rectangle. Another way to do it would be one big text rectangle and the mapper inserts \n where the text is on the same line as the graphic. I might try both to see which is easier. When editing it might be easier to move the \n about rather than copy and paste text to and from one rectangle to another.

**greebo** · March 18, 2008

I'm also assuming that gui code allows the small rectangle for the small image to be superimposed over the large rectangle with the background image. Fairly sure it can.

You just need to nest another windowDef into the larger text windowDef:

windowDef textArea {
rect 100,100,500,300
text "<body>"
font "fonts/jd_hand"
forecolor 0,0,0,0

windowDef daImage {
	rect 450,100,50,50 // this is measured relatively to the parent windowDef
	background "guis/assets/hoarders/blah"
}
}

jdude · March 18, 2008

You could just open the piece of paper in photoshop and manually type in everything and format it and save it as a different image

**greebo** · March 18, 2008

You could just open the piece of paper in photoshop and manually type in everything and format it and save it as a different image

I was about to suggest something similar, but then you can say goodbye to any easy localisations.

Fidcal · March 18, 2008

One day in the future someone might write a gui readables tool. There is one via the console but it's a bit unreliable and inflexible as I recall. Now we can reload xdata in a mission it is not too bad to adjust in a plain text editor for the moment and review within seconds.

Fidcal · March 18, 2008

I can get the image in the book if I put it in the gui itself but I want to pass it from the xdata. If in the gui I do...

   windowDef Image1
{
	rect 0,0,50,50
	background "<pix1>"
}

then in the xdata I do...

	   "gui_page1"   : "guis/readables/book_stone_print_right_curl2.gui"
~~~~~~~
"page1_pix1" : "guis/assets/readables/squirrel.tga"

 "page1_title" : "Squirrels"

I get a black square in the book. I suspect I need something in the onTime section, eg, set something or other...

	onTime 0 {
~~~~~~~~~ 
   set "title::text" "$gui::title";
	set "rightBody::text" "$gui::right_body";
set "leftBody::text" "$gui::left_body";

**greebo** · March 18, 2008

Hm, try this:

in the windowDef, set the background to:

background "<pix1>" // an empty string should work as well

in the onTime section, add an entry to set the background on demand:

set "Image1::background" "$gui::pix1";

and in the xdata file, add this (you already have that covered):

"page1_pix1" : "guis/assets/readables/squirrel.tga"

Fidcal · March 18, 2008

Hey! thanks! Works great - alpha channel too so we can illustrations, sketches, marks, stains, anything right on the page.

This is what I'm now thinking. We create default guis with one full page text body rectangle which starts lower if there is a title. One text title rectangle. Then say six rectangle for images, say pix1,2,3,4,5,6. The mapper just leaves them blank normally. If an image is needed say centre left he adds the path image to the pix3 line. Then he has to space out his text to go round it - not too difficult. If a larger image is needed, say centre right and bottom right then split the image in two and put the top part in pix4 and the bottom part in pix6. A full page can be 6 images. For a one-off it could be a custom gui but with the default you could have say a 4 page book with one small illustration on page 1, full page image on page 2, 2 images on page 3, etc. all from the same default.

And the images don't need to fill the rectangles - one image could be half the size and transparent alpha round it so then just format the text closer. It should be very flexible.

An alternative is one full page image being a composite of any sub-images - but probably not as I don't think tga compresses does it? So the blank alpha parts would use as much as the detail.

One downside - there does seem to be a delay both displaying and removing - even though I have precache at the start of the xdata.

**greebo** · March 18, 2008

One downside - there does seem to be a delay both displaying and removing - even though I have precache at the start of the xdata.

That's expectable, because the GUI render code doesn't know about the image when it loads the .gui file. The image path gets filled in later, and it has to be loaded right away from the disk.

Fidcal · March 18, 2008

So it would be faster if put in the gui itself? Quick test. Yes, I can see it does. What a pity. So it looks like custom guis. Maybe some templates with comments for mappers so they can copy the gui and insert their own image names. Or jdude's idea but possibly with just the background and images - the text added later so it can be translated.

Another idea for font selection and/or some degree of font size would be a gui with say two text body rectangles - one with font a and one using font b. The mapper leaves one empty and just uses the required font. It probably would not need more than 3 fonts for each type of background commonly plus 3 font sizes - that's 9 rectangles all covering the same area. The mapper leaves 8 empty and uses say body_jd_hand_42. But could also use several at once and space out his text.

**greebo** · March 18, 2008

Another idea for font selection and/or some degree of font size would be a gui with say two text body rectangles - one with font a and one using font b. The mapper leaves one empty and just uses the required font. It probably would not need more than 3 fonts for each type of background commonly plus 3 font sizes - that's 9 rectangles all covering the same area. The mapper leaves 8 empty and uses say body_jd_hand_42. But could also use several at once and space out his text.

I'm fairly sure that we can make the font style and size is also adjustable via xdata. Have you tried to make the font a variable?

Add this to the onTime 0 event:

set "body::font" "$gui::font";

And add the spawnarg page1_font set to some value, let's say "fonts/bamberg". Does this work?

Fidcal · March 18, 2008

No, text doesn't display when frobbed. In the console is...

WARNING: script\darkmod_readables.script(198): Thread 'darkmod_readable_mobile

::inventoryUse': Non-existant GUI handle: 0

Checked it over a few times now and don't think I've mistyped anything.

**greebo** · March 19, 2008

Hm, maybe we're running into a GUI limitation here (that fonts must be defined at GUI load time), but I'll have to check it myself some time.

**Springheel** · June 22, 2008

That's expectable, because the GUI render code doesn't know about the image when it loads the .gui file. The image path gets filled in later, and it has to be loaded right away from the disk.

Would it make any difference if the image was used in a secret room somewhere, and was thus already loaded?

Fidcal · June 22, 2008

Maybe worth a try. Might need to be not in a secret room but rendered out of sight - even one unit by one unit.

@greebo : BTW this makes me think the gui cannot know about the title content from the xdata and so that other idea for varying the body top position probably cannot work. Still have Plan B

Dram · June 22, 2008

Hm, maybe we're running into a GUI limitation here (that fonts must be defined at GUI load time), but I'll have to check it myself some time.

Isn't that what "precache" is for? Or am I mis-understanding something here?

Fidcal · June 22, 2008

I did use precache. I think the lag is simply the delay in putting the image in from memory. It's not so bad if it takes half a second for the readable to appear on screen but it looks odd if the readable appears then an image is pasted on to it half a second later. We're used to that in web pages but not in some ancient tome down in the crypts - sort of immersion breaking I found.

Dram · June 22, 2008

Hmm...yes that is annoying

**greebo** · June 22, 2008

@greebo : BTW this makes me think the gui cannot know about the title content from the xdata and so that other idea for varying the body top position probably cannot work. Still have Plan B

What do you mean by "cannot know about the title content"? Do you mean that the code cannot know about the length or whether there is a title at all?

Fidcal · June 22, 2008

What do you mean by "cannot know about the title content"? Do you mean that the code cannot know about the length or whether there is a title at all?

Hopefully I'm wrong but I was going on what you said earlier in this thread "the GUI render code doesn't know about the image when it loads the .gui file." and since I tried every variation in the conditional statement to test for an empty title string I could think of and it didn't respond, I began to wonder if it actually had that value at the time of the test. (see bugtracker 0000849)

**greebo** · June 22, 2008

Hm, I would need to look into that more closely. Do we need this for release, i.e. has this some priority?

Fidcal · June 22, 2008

Ideally, but not absolutely essentially. That is, I am in the middle of creating readables prefabs for jdude to put text in later. If some message won't for example quite fit on a parchment then the gui can be changed but well, there quite a few readables in there I think so it might mean adjusting them later.

But no, it is not top priority.

**Springheel** · June 23, 2008

I think the lag is simply the delay in putting the image in from memory. It's not so bad if it takes half a second for the readable to appear on screen but it looks odd if the readable appears then an image is pasted on to it half a second later.

Hmm. I wonder if there is any way to force the gui to display all the graphics at the same time? So that if there is any kind of delay it's a delay for the whole readable (which I agree would be acceptable). Although it seems odd that a small image file would take long enough to load from memory that it's noticeable.

readables xdata : images in text possible?

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation

Recent Status Updates