ID:2206615
 
Not a bug
BYOND Version:510
Operating System:Windows 10 Pro 64-bit
Web Browser:Chrome 55.0.2883.87
Applies to:Dream Seeker
Status: Not a bug

This is not a bug. It may be an incorrect use of syntax or a limitation in the software. For further discussion on the matter, please consult the BYOND forums.
Problem Summary:

When maptext variable is not altered in any way:


When maptext gets set to anything such as in the code example below:


Chat Box.dmi contains a 1pixel by 1 pixel color I'm stretching to make the chatbox.


Code Snippet (if applicable) to Reproduce Problem:
/*
The object that will be stretched and overlayed on the
client's screen.
*/


ChatBox
parent_type = /obj
icon = 'Chat Box.dmi'
icon_state = "Chat Box"

// By default (Pixel Values)
var
// Start at the lower left-hand corner
screen_x = 16
screen_y = 16

// Stretch across the screen
screen_width = 440
screen_height = 140

// OFFENDING LINE
maptext = "Testing 1 2 3 4 4 5 6 7"

New()
..()
Resize()

proc
Resize()
screen_loc = "1:[screen_x],1:[screen_y]"
var/matrix/myTransform = matrix()
myTransform.Translate(0.5,0.5)
myTransform.Scale(screen_width,screen_height)
transform = myTransform

maptext_width = screen_width
maptext_height = screen_height



/*
When the client connects add the chatbox to the screen
and save it for later reference.
*/

client
var
ChatBox/chatBox = new/ChatBox()

New()
..()
screen.Add(chatBox)

You should double check that this wasn't something fixed by id:2199924
In response to Nadrew
I've tried on both the latest stable and beta versions.

"Lummox JR resolved issue", so I would assume he's committed that fix already?
510 is not going to be very meaningful here because of recent fixes. However I would suggest if you see an issue in 511.1370, you post a demo project that shows the problem in action.
In response to Lummox JR
Thanks. I'll look at this tomorrow.
In response to Lummox JR
Cheers :-)
This isn't a bug!

Okay, so recently maptext was changed to respect matrix transformation.

So basically, your maptext area is set to 440x140. Your transform is set to scale by 440x140.

So your maptext is scaling up to 193600 x 19600 pixels. Since you are scaling the text up to MASSIVE sizes, the anti-aliasing for the text is causing the textarea to look all weird in the second picture.

Here's a quick fix:

/*
The object that will be stretched and overlayed on the
client's screen.
*/


ChatBox
parent_type = /obj
icon = 'Chat Box.dmi'
icon_state = "Chat Box"

// By default (Pixel Values)
var
// Start at the lower left-hand corner
screen_x = 16
screen_y = 16

// Stretch across the screen
screen_width = 440
screen_height = 140

obj/text = new/obj()

New()
..()
Resize()

proc
Resize()
text.screen_loc = screen_loc = "1:[screen_x],1:[screen_y]"
transform = matrix(screen_width,0,0.5,0,screen_height,0.5)
text.maptext_width = screen_width
text.maptext_height = screen_height

setText(content)
text.maptext = content


/*
When the client connects add the chatbox to the screen
and save it for later reference.
*/

client
var
ChatBox/chatBox = new/ChatBox()

New()
..()
screen.Add(chatBox,chatBox.text)
chatBox.setText("Herpyderpy")


Also it's good to see those lil' dudes and tiles again.
Thanks for saving me that time, Ter. I'll close this. :)
Lummox JR resolved issue (Not a bug)
In response to Ter13
Yeah haha, thanks for those tiles. Hardly doing them justice in that but it works for a demo.

I can't say I agree with that addition to the language but I don't really have the power to say what gets added.

All I can say is that it's far more common to never want your maptext resized with the object. That's an edge case not the main case and by forcing me to work around you're basically making an issue in the majority of cases.

Don't agree at all and I would like to at least express my interest in having that reversed as fast as possible before people start getting used to it.

In response to Zecronious
The problem with going back is, the alternative is never transforming maptext at all. Also, the old way did allow transforms to use the translation portion of the matrix, so it was a sort of hybrid.

All you need, though, is for the maptext to be part of an overlay or image with RESET_TRANSFORM. If KEEP_TOGETHER is in play you might need to add KEEP_APART for that. And for your chat box example, it's even easier because the maptext can be the main object and the transformed part can be an underlay or overlay.
An alternative would just be to have maptext_transform which would make a far more elegant solution than any of these work arounds.
In response to Zecronious
Zecronious wrote:
An alternative would just be to have maptext_transform which would make a far more elegant solution than any of these work arounds.

That really wouldn't be elegant at all. That ends up on a slippery slope where eventually many of the vars get replicated as maptext vars, and it's just not somewhere I want to go.

The best solution for your needs is the one I mentioned: Make your backdrop a transformed overlay/underlay of the maptext object.
In response to Lummox JR
That's a brutally ugly solution. 'slippery slope' towards more variables having their own transform doesn't sound like a bad thing at all.

Sounds like a slope I'm happy to slide down. It would be so much nicer.
Really though, maptext should have been a separate object from the start, along with object parenting as in most game engines these days.
In response to Kaiochao
Kaiochao wrote:
Really though, maptext should have been a separate object from the start, along with object parenting as in most game engines these days.

Exactly