Desktop framedef bug

[Blacky]

I've done multiple testing, and if my last neuron isn't completely fried there's a bug with the drawing of the desktop:

This is my frame :



<framedef name="desktop">
<bitmap file="frames/desktop.png" />
<top rect="0,0,1500,150" />
<middle rect="0,300,500,500" />
<bottom rect="0,150,1500,150" />
<right rect="1400,300,100,1200" />
<decal rect="500,300,500,500" />
</framedef>


And to check, this is my (simplified, for testing purposes) bitmap (https://temp.dorem.info/fg2/desktop.png).

And the result (https://temp.dorem.info/screenshots/bscr-C53z.png). Check the right column, under the first three big icons, it should be pure yellow and not red&yellow.

PS: in case my ruleset was doing something nasty, I've check, the above is the only reference to the desktop.png file in the whole ruleset.

[Blacky]

I tried halving my bitmap (and everything in my framedef) because FG2 has a history of issues with non-microscopic bitmap, got the exact same bug.

After more testing, it seems like the y coordinate of the <right> element isn't handled properly (it even seems it isn't handled at all).

Edit: anyone know a ruleset with a <right> and a y coordinate (for the desktop) >0 around?

[Blacky]

It also (it's probably related in some way) would seem the desktop (the only one I've tested) can't handle a height >=788 pixels.

I tested with a 1000&#215;1000 bitmap, and a <middle> and <right> height from 1 to 787px everything is fine, but from 788px a transparent (on first draw) or black (after resizing the window and FG2 redrawing its content) line appear, like the bitmap is cut in some weird way.

See:

https://temp.dorem.info/screenshots/bscr-Mkrq.png

And the xml for that:

<framedef name="desktop">
<bitmap file="frames/desktop.png" />
<right rect="1000,0,100,787" />
<middle rect="0,0,1000,788" />
</framedef>


The <right> sprite is ok at 787, no transparent 1px line; but the dark <middle> has that 1px transparent line (it becomes black after redraw).

It should be easy to reproduce this yourself. And since it's very specific, I'm guessing not that hard to debug ?

Edit: well no, it would have been too simple. I tested the same bitmap resized at 787px, and the same thing is happening at 619/620px. So it's the ratio between the height of the bitmap, and the height of a section of the frame (the same here, ~79%). But I've seen ruleset with this kind of bitmap, so I'm losing my French here…

[Griogre]

Have you tried adding in the corners? It's been a very long time since I've messed with one of these. I don't have time to look up the documentation today but here is the last framedef I made for a PotSM skin.



<!-- Desktop (overrides graphics_frames.xml definition) -->
<framedef name="desktop">
<bitmap file="desktop_background.png" />
<topleft rect="23,10,95,100" />
<top rect="120,10,180,100"></top>
<topright rect="302,10,90,100" />
<left rect="23,105,95,300" />
<middle rect="120,110,175,290" />
<right rect="302,105,90,298" />
<bottomleft rect="23,410,95,100"/>
<bottom rect="120,410,180,100"></bottom>
<bottomright rect="302,410,90,100"/>
<decal rect="600,0,765,512" />
</framedef>


He's a screen of the skin here: https://www.fantasygrounds.com/forums/showthread.php?t=10639

[Blacky]

Have you tried adding in the corners?
Yup I tried complex fancy frame and had a whole bag of issues, so I simplified things a lot to be able to pinpoint either my mistake or the bug.

I just tried corners on the height ratio bug I have described last, changes nothing.


I don't have time to look up the documentation today
Thing is, the documentation is very very thin, especially on these things. To my knowledge I did read it (https://www.fantasygrounds.com/refdoc/framedef.xcp) but there's nothing special on desktop or limits of any kind.

However, I managed to make this ratio bug disappear by reducing the bitmap width from around 3000px to 2000px.

[Griogre]

Blacky, 1) I'm pretty sure there are some requirements that once you start using certain sections you have to use *all* the matching ones, so, because you used top and bottom you have to use the corners.

Here's the framedef for an unreleased Shaintar skin which did what I think you are doing just the middle and right:



<framedef name="desktop">
<bitmap file="frames/desktop.png" />
<middle rect="0,0,320,240" />
<right rect="320,0,290,400" />
<decal rect="615,0,1585,1000" />
</framedef>


https://www.fantasygrounds.com/forums/showthread.php?t=10620&highlight=Shaintar

2) Next on your proportional bitmap resizing issue. I'm pretty sure that the size of the desktop image is defined somewhere in the ruleset and if your image size doesn't match that definition size it gets scaled is strange ways - which might be another reason why you are having problems getting your desktop to work. I don't really see anything wrong with your coordinates but I don't think a 1500x1500 desktop was standard for any ruleset. What happens if you use the desktop image size that is default for that ruleset?

[Blacky]

Blacky, 1) I'm pretty sure there are some requirements that once you start using certain sections you have to use *all* the matching ones, so, because you used top and bottom you have to use the corners.

I don't think so, here's the desktop framedef from the official D&D3.5 ruleset:


<framedef name="desktop">
<bitmap file="graphics/frames/desktop.png" />
<top rect="0,1,324,151" />
<middle rect="1,154,200,200" />
<right rect="450,0,106,144" />
<bottomright rect="450,0,106,144" />
<bottom rect="219,437,567,132" />
<decal rect="830,0,510,510" />
</framedef>

A <top> but no top corners, and no <bottomleft> corner.

Or is it ok in root 2.9 but not in root 2.0 (I'm asking because, as far as I can see, the documentation says nothing clear on <root> whatsoever).


Here's the framedef for an unreleased Shaintar skin which did what I think you are doing just the middle and right

Well, I'm just trying to reskin a ruleset, then translating it, then adapting it to my campaign&game&rules.

I might have done, I don't know, over a dozen desktop bitmap but encountered a lot of bugs and issues, some related to the bitmap size (I found another old thread here talking about bitmap frame size bug, confirmed by others people, but no dev took a serious look about it or corrected it).

So, each time, I simplify things, I reduce my bitmap, and lower my expectations. Right now I managed to work around the bugs and have something working, similar to your example, although it's pretty basic :mad:



2) Next on your proportional bitmap resizing issue. I'm pretty sure that the size of the desktop image is defined somewhere in the ruleset and if your image size doesn't match that definition size it gets scaled is strange ways - which might be another reason why you are having problems getting your desktop to work.
It's quite possible, I'm quite the ruleset newbie. But I never saw this anywhere, certainly not in the framedef's documentation, and in my original ruleset (the Dresden's one) there is no direct reference to the desktop bitmap size (it's 1100×500, and the string 1100 appear nowhere in the original ruleset).


I don't really see anything wrong with your coordinates but I don't think a 1500x1500 desktop was standard for any ruleset.
Yup, that's a shame. I would have thought 5760×1200 would have been the standard desktop bitmap size (makes the most sense to me, or something slightly bigger around 7K×1.2K), but the more I explore ruleset code, the more I see frames in the low hundreds pixels :confused:

[Moon Wizard]

The maximum bitmap size supported by FG is 2048x2048. If either dimension is greater than 2048, it will be rescaled to 2048. This is true for any graphic.

The corners and edges do not have to be contiguous, nor all defined. See the scrollbar frames and 3.5E frame as examples of non-contiguous frame definitions.

I did find a bug in the frame drawing code with the right edge calculation used for drawing. It only appears if the left and the right edge have different Y values. The default value for each edge is 0. It will be fixed in the v2.9.2 release. You can define a left edge with a Y value of 300, and a height of 0 for now to workaround.

Regards,
JPG

[Moon Wizard]

It looks like I will need to push this fix into the next big version (instead of the upcoming v2.9.2), so you will need to use the workaround for a while.

The issue is that there is a bug in the framedef definition in all the rulesets derived from the original D20 ruleset, which are most of the rulesets out there. By waiting I can use a compatibility flag to fix long term without causing issues in the short term.

Regards,
JPG

[Blacky]

Okay this this wayyy overdue, but I just realized I haven't thank you for the answer, and the future bugfix :eek:

So, here it is :)