How to make maptext not jump up?

ID:2033880
 
Feb 9 2016, 11:19 pm (Edited on Feb 9 2016, 11:37 pm)
(See the best response by Ishuri.)
http://www.twitch.tv/officialjabe/v/43053404?t=19s

I did a poor job explaining what the issue I'm having is but if you just look at the video you can see the behavior I'm trying to avoid.

Basically its that anytime a maptext reaches a new line instead of expanding downwards it pushes all the text up instead.

How can I get around this behavior?

I don't think there is any maptext variable or functions or events I can trigger off so I have no idea when its gonna jump to a new line because then I'd just push down the y by another 32pixels or so.

Code at the request of Zasif
#define TEXT_SPEED world.tick_lag
#define NAME_FONT "<span style='font-weight:bold;font-size:small;width:100%;font-color:yellow'>"
#define CHAT_FONT "<span style='font-size:x-small;width:100%;font-color:white;text-justify:inter-word'>"
client/New()
    ..()
    spawn(10)new/script(src,"Grandpa","Today is the day you inherit the clan. The responsibility to establish and maintain our clans LEGACY falls solely on you!")

script
    New(client/c,name,chat)
        //DYNAMIC creates an object that sets its variables to the arguments
        var/obj/black=DYNAMIC("icon"='turfs.dmi',"icon_state"="black","alpha"=200,"screen_loc"="WEST+2,SOUTH+5 to EAST-2,SOUTH+3","layer"=FLY_LAYER)
        var/obj/txt=DYNAMIC("maptext_x"=128,"maptext_y"=-16,"maptext_width"=320,"maptext_height"=96,"screen_loc"="WEST+2,SOUTH+5","layer"=FLY_LAYER+1)
        c.screen+=list(black,text)
        sleep(5)
        txt.maptext="[NAME_FONT][name]:</span><br>[CHAT_FONT]"
        sleep(5)
        var/list/L=split(chat," ")//Returns a list of words in a string
        spawn for(var/v in L)
            for(var/j=1 to length(v))
                sleep(TEXT_SPEED)
                txt.maptext+="[copytext(v,j,j+1)]"
            sleep(TEXT_SPEED*3)
            txt.maptext+=" "
Feb 9 2016, 11:27 pm
Maybe show the code thats handling your maptext?
Feb 10 2016, 8:53 am
COULDNT HURT
Feb 10 2016, 9:27 am
I don't think defining text speed like that dynamically changes it with world.tick_lag
Feb 10 2016, 9:28 am
Best response
Oh and to solve ur issue do valign=top as html under a font tag
Feb 10 2016, 9:31 am
In response to Ishuri
Ishuri wrote:
I don't think defining text speed like that dynamically changes it with world.tick_lag

Wut? It's just a simple define that points to world.tick_lag. Defines are faster than a variable because variables need to be looked up, whereas a define is just, a thing. Lol.

#define quicker world.tick_lag
sleep(quicker) //less cpu than
sleep(world.tick_lag) //more cpu
Feb 10 2016, 9:32 am
In response to Rushnut
Rushnut wrote:
Ishuri wrote:
I don't think defining text speed like that dynamically changes it with world.tick_lag

Wut? It's just a simple define that points to world.tick_lag. Defines are faster than a variable because variables need to be looked up, whereas a define is just, a thing. Lol.

#define quicker world.tick_lag
sleep(quicker) //less cpu than
sleep(world.tick_lag) //more cpu

Huh, did not know this, looks like I have some changes to make
Feb 10 2016, 9:40 am
In response to Rushnut
Rushnut wrote:
#define quicker world.tick_lag
sleep(quicker) //less cpu than
sleep(world.tick_lag) //more cpu

That's not true. Those are both exactly the same. #define macros replace the text before the actual compile even happens. That's why it's called the preprocessor.
Feb 10 2016, 10:00 am
In response to Multiverse7
Multiverse7 wrote:
That's not true. Those are both exactly the same. #define macros replace the text before the actual compile even happens. That's why it's called the preprocessor.

Maybe I'm not too accurate on the actual inner workings. But my statement is still very much true, maybe Ter13 could get in here and explain why.
Feb 10 2016, 10:04 am (Edited on Feb 10 2016, 10:13 am)
I believe it just replaces any instance of TEXT_SPEED to world.tick_lag upon compiling.

Originally it was just for testing to find out what a Just Right speed was.

That being said valign did not seem to work.

*Edit*

Turns out that valign only works as an element attribute but not a css property/keyword.

i.e.

<span valign=top> Works

<span style='vertical-align:top'>Does not
Feb 10 2016, 10:07 am
In response to Tubutas
Tubutas wrote:
I believe it just replaces any instance of TEXT_SPEED to world.tick_lag upon compiling.

Originally it was just for testing to find out what a Just Right speed was.

That being said valign did not seem to work.

Yes, that is what #define does. Multiverse7 is correct.

Anyway, check this link out.

Feb 10 2016, 10:09 am
#define thing 10 is faster than var/const/thing = 10, but something like world.tick_lag is already defined as a built-in var, so using a #define to reference it makes absolutely no difference. However, if you are providing the option to redefine the #define as something else, which is not world.tick_lag, then yes, it is faster in that sense.
Feb 10 2016, 10:15 am
In response to Multiverse7
Multiverse7 wrote:
#define thing 10 is faster than var/const/thing = 10, but something like world.tick_lag is already defined as a built-in var, so using a #define to reference it makes absolutely no difference. However, if you are providing the option to redefine the #define as something else, which is not world.tick_lag, then yes, it is faster in that sense.

You're completely right, I'm retarded and was getting confused.

world/tick_lag = 0.5
#define TICK_LAG 0.5

That was what I meant is faster.
Feb 10 2016, 10:15 am
The trick is to define TICK_LAG or FPS as a constant.
#define FPS 60
#define TICK_LAG (10 / (FPS))
world/fps = FPS

// then...
sleep TICK_LAG

// is faster than
sleep world.tick_lag

// because there's no var lookup when you use a constant.
Feb 10 2016, 10:16 am
In response to Kaiochao
Go back to Insurgency you heathen.
Feb 10 2016, 10:27 am
In response to Kaiochao
Is that extra division operation really faster than the lookup, which has already been calculated?
Feb 10 2016, 10:39 am (Edited on Feb 10 2016, 10:45 am)
In response to Multiverse7
Arithmetic (and some other math functions like trig and log, see here) involving constants is evaluated at compile-time. ;)
Feb 10 2016, 10:42 am
In response to Kaiochao
Well, at least we hope so.
Feb 10 2016, 1:40 pm
/2 and *0.5 take the same amount of time to compute, so yes, it's evaluated at compile time.
Feb 10 2016, 2:08 pm
Rushnut wrote:
Maybe I'm not too accurate on the actual inner workings. But my statement is still very much true, maybe Ter13 could get in here and explain why.

You are a touch confused on this subject.

Basically, preprocessor macros are processed just before the code is compiled. They literally just replace the macro's name with the macro's value.

#define TICK_LAG world.tick_lag


sleep(TICK_LAG)

//compiles down to:

sleep(world.tick_lag)


A variable lookup is slower than supplying a constant value because the VM doesn't inherently know the value. The instructions would be something like:

ACCESS <world> (tick_lag) [PUSH]
SLEEP [POP]


On the other hand:

#define FPS 40
#define TICK_LAG (10/(FPS))


sleep(TICK_LAG)

//compiles down to:

sleep((10/(FPS))

//compiles down to:

sleep((10/(40)))

//simplifies to:

sleep((10/40))

//simplifies to:

sleep((0.25))

//simplifies to:

sleep(0.25)


The instructions for this would be:

PUSH 0.25
SLEEP [POP]


The overhead for a variable lookup in DM is larger than you would expect. That's because the variable lookup needs to:

1) Traverse scope

2) Get the object pointer

3) Look at the object's instance "touched" variable memory.

4) Look up the tree to the prototype's variable memory.

5) Get the variable pointer

6) Access the variable

7) Push the variable into the stack.

The only benefit to using world.tick_lag instead of a constant TICK_LAG definition is if your framerate can be altered. Alterable framerates are a good thing for games. Unfortunately, BYOND is engineered in such a way to make the benefit of a variable framerate less of a concern than the consequences.

A variable framerate in BYOND is just a bad idea at least until Lummox adds proper client-side frame separation and client side pixel movement gliding animations. However, even then, it's probably not a good idea because BYOND has to process input on the server side, and a game simply cannot afford to continuously muck with the responsiveness of controls because players require proper feedback and timing for just about every single genre of videogame. If you build your game in such a way that the input response times are variable for any unexpected reason other than network latency, it basically becomes unplayable for all but the most masochistic and/or Brazilian of audiences.