Faster than Image() ?

ID:162789
 
Nov 26 2007, 1:49 pm
Looking for a fast way to add overlays to an atom.

I am creating a dynamic meter system, which takes a "meter" graphic, and a "bar" graphic; and then based on the values you wish to display, it draws the bars on the meter accordingly.

I have coded this to work, using the Image proc to create each overlay per bar to add to the atom each time you wish to update the meter, but it proves to be too slow.

I coded a new system on the side to test if icon_states would be faster. It was indeed. But there are situations that would call for a dynamic meter instead of a static meter. The static meter can only display what the artist painted. A dynamic meter would be able to be of any size.

So does anyone know of a faster way to add an overlay to an atom?
Nov 26 2007, 1:58 pm
What situation would call for a dynamic bar?
Nov 26 2007, 2:37 pm
In response to Xooxer
Lets say I haven't thought of it yet, and I just want to learn how to up the speed on a design (dynamic meters) developed in DM.

Plus, who doesn't want to allow the artist to be lazy? Draw a meter, then draw a bar. Presto! Heck, you could even make meters out of objects in the game in real time, without having to create the art for each meter for every situation...
Nov 26 2007, 2:40 pm
In response to FIREking
Pre-rendered meters will always be the fastest method. Anything else will take time. You can aleviate this time delay by pre-rendering the most common meters when the game is launched and use them like icon_states, but the processing time would still be there.

~X
Nov 26 2007, 2:47 pm (Edited on Nov 26 2007, 3:05 pm)
In response to Xooxer
hmm..

It seems like it should be just as fast as icon_states tho.

All I am trying to do at runtime is take an icon_state in the meter icon file ("bar"), and draw it in different places in its overlay using pixel offsets.

Maybe Im searching for speeds not possible with byond in this manner, but it seems plausible to me...

The code is relatively small and computation is pretty basic. At least I assume...

for every bar required to draw
calculate its pixel offset
add it as an overlay to the meter

This simple process takes about a second for each update (regardless of number of bars seemingly). Lummox Jr's DMIFONT seems to be pretty quick, but I havent decrypted his code enough to understand why it's so fast. I assume its something to do with pixel blending methods on a black icon... which I am guessing is faster than trying to create overlays?

Nov 26 2007, 2:54 pm
In response to FIREking
Well by pre-rendered, I mean drawing all the possible states of the bar, and just altering it's icon_state depending on the variable being displayed.

When I do meters, I usually try and make about 10 bars. This way I can use a simple % calculation to figure out which icon_state to show.

So, I'll have about 11 different icon_states for 1 bar. The first, named 0 would show no bars, the next, named 1, would show 1 bar, and so on. No pixel offsets required, just a bit more work in the drawing department. And really, the work is mainly copy/paste.

When I mentioned pre-rendering the common meters, I meant creating an icon, or set of icons, at runtime that would all have these states. Then you'd just update the icon_state of the overlay, then remove and add it back to update it, like you would do for a normal overlay update.

I thought I had a demo that showed this method, but I can't seem to find it right now.

~X
Nov 26 2007, 3:01 pm
In response to Xooxer
Well I understand what you're saying but, I've already done this, and its fast. What I am trying to accomplish is doing it with less resources, but just as fast.

I have come up with two types of meters.

Static Meter
a static meter is basically a meter that has every possible state it will ever enter (and display) pre-drawn and saved into a file (icon file). So when you wish to display 40 percent of health, the proper iconstate is loaded to the atom/meter.

Dynamic Meter
a dynamic meter is one that consists of two graphics. The first graphic being the meter its self, and the second graphic being the smallest bar possible to display in the meter (or something else like an object in the game to go across meters, like a picture of gold or a sword someone created that has a unique image at runtime meaning the resource for its image does not already exist in the game's resources). When you wish to display some information on this meter, the amount of bars necessary is calculated and then drawn in a repeating fashion. Currently I have accomplished this using the Image proc, but its slower than showing pre-rendered states of a static meter.

My "deal" is that I am complaining this should be just as fast, but it is currently beyond my current knowledge of DM on how to make it just as fast.

Maybe I am going about it wrong, is what I am saying. I am asking if anyone can help me think of a better way. The basic concept is a bar or group of bars already exists, and now we need to draw an atom or an icon_state over this bar just as quick as switching icon_states...
Nov 26 2007, 3:09 pm
In response to FIREking
Well, I'm saying pre-render them at runtime once, and then just use that dynamic icon you just created like you would the static icon you drew by hand.

What I mean to say is, create a small snippet that draws the icon for you, using the dynamic content you want. You then use this computer-rendered icon just like your static icon. The only difference would be that the dynamic icon wouldn't exist in the rsc file like your static one. You'd create it at runtime, then use it like any other icon.

I think that's how Lummox gets his icons to display so fast. He creates all the possible positions before any displaying is done. (Can't be held to that, I haven't looked into this source in years). Spuzzum's old s_damage library did this, and it worked pretty nicely long before pixel_x and pixel_y were introduced.

If this isn't really what you want, I'll try and do some testing later and find the quickest dynamic solution available, if someone doesn't answer your question before then.

~X
Nov 26 2007, 3:15 pm
In response to Xooxer
That is a good idea actually. I wonder if the server would take a hit when its being created...

In the meantime, I am moving on to GUI object creation via the map editor.

Thanks for the help.
Nov 26 2007, 3:21 pm
In response to FIREking
No problem. Yeah, the server will take a hit, but you can try running the process in the background to reduce the lag it causes the other procs running. sleep(-1) within your loop would do it. It's all basically a trade-off between runtime processing and rsc downloading. I don't think a small function like this would cause much intereference. You can always sleep a bit more to allow other procs to execute, and give the player a "Processing..." heads-up so they know it's working to build thier meter.

~X
Nov 26 2007, 3:32 pm
Depending on the kind of meters you're talking about - if you want HUD meters, use Shadowdarke's HUDmeter library. For adding and removing overlays, I recommend my handy add/remove overlay procs: [link]
Nov 26 2007, 3:48 pm
In response to Foomer
i'll give it a try

we'll see if its any faster!
Nov 26 2007, 3:54 pm
In response to Foomer
nope, just as slow

show() takes about two seconds to complete, no matter how many bars you have to draw.
var/atom/movable/overlay_obj=new()
atom/proc/overlay(icon,state,x,y,layer)
    overlay_obj.icon=icon
    overlay_obj.icon_state=state
    overlay_obj.pixel_x=x
    overlay_obj.pixel_y=y
    overlay_obj.layer=layer
    overlays+=overlay_obj
    return
    
hudobj/meter
    layer=FLY_LAYER
    var/statnum
    var/last_statnum
    var/maxstatnum
    var/last_maxstatnum

    var/bar_icon_state="bar"
    var/bar_layer=FLY_LAYER+1
    var/bar_start=2
    var/bar_size=2
    var/max_bars=15

    proc
        SetStat(var/n,var/mn)
            statnum=n
            maxstatnum=mn
            last_statnum=statnum
            last_maxstatnum=maxstatnum
            show()

        Update(var/n,var/mn)
            if(n!=last_statnum || mn!=last_maxstatnum)
                SetStat(n,mn)
        show()
            overlays=list()
            var/num_bars=round(round(statnum/maxstatnum,0.005)*max_bars)
            var/i = 0
            while(i<num_bars)
                draw_bar((bar_start-1)+(i*bar_size))
                i++
        draw_bar(var/px)
            //var/image/i=image(src.icon,icon_state=bar_icon_state,layer=bar_layer)
            //i.pixel_x=px
            //overlays+=i
            overlay(src.icon,bar_icon_state,px,0,layer)
Nov 26 2007, 4:08 pm
In response to FIREking
At you by chance using these overlays on an object that's displayed on client.screen?
Nov 26 2007, 4:18 pm
In response to Foomer
yes
Nov 26 2007, 4:26 pm
In response to FIREking
FIREking wrote:
nope, just as slow

show() takes about two seconds to complete, no matter how many bars you have to draw.

Two seconds? Ouch!

You could optimize that code quite a bit. All the proc calls add extra overhead and your overlay proc is performing a lot of assignments that you could do once before the loop and not have to repeat. I doubt if that's the reason for the extreme lag though.

> var/atom/movable/overlay_obj=new()
> hudobj/meter
>   layer=FLY_LAYER
>   var/statnum
>   var/last_statnum
>   var/maxstatnum
>   var/last_maxstatnum
> 
>   var/bar_icon_state="bar"
>   var/bar_layer=FLY_LAYER+1
>   var/bar_start=2
>   var/bar_size=2
>   var/max_bars=15
> 
>   proc
>       SetStat(var/n,var/mn)
>           statnum=n
>           maxstatnum=mn
>           last_statnum=statnum
>           last_maxstatnum=maxstatnum
>           show()
> 
>       Update(var/n,var/mn)
>           if(n!=last_statnum || mn!=last_maxstatnum)
>               SetStat(n,mn)
>       show()
>           overlays=list()
>           var/num_bars=round(round(statnum/maxstatnum,0.005)*max_bars)
            overlay_obj.icon=icon
            overlay_obj.icon_state=bar_icon_state
            overlay_obj.pixel_y=0
            overlay_obj.layer=layer
>           var/i = 0
>           while(i<num_bars)
                overlay_obj.pixel_x=(bar_start-1)+(i*bar_size)
                overlays+=overlay_obj

>               i++
>


You should also be aware that even with overlays that are just a pixel wide, the more overlays you have on screen at once the slower BYOND will render the map, especially with pixel offsets involved. With that code, you're showing up to 15 overlays per status meter. If you have a lot of meters visible at once that could cause some pretty extreme lag. It may even cause a lot of bandwidth issues, since a full load of information about each overlay has to be transmitted to each client.

Prerendering may seem like a hassle, but it will vastly improve performance. If you want a dynamic system you can render a new icon once and cache it, reusing it later as needed.
Nov 26 2007, 4:29 pm
In response to Shadowdarke
I think pre-rendering is going to be the way to go...

I could just write a library that creates stat bars and saves them into dmi files that you could just load into the environment... but I think i'll just stick with static meters now and draw them my self!
Nov 26 2007, 6:19 pm
In response to FIREking
Well if you find a solution for it let me know because I had the same problem overlaying numbers for when you get more than one of the same key in The Gauntlet. I think its a BYOND issue, personally, because I can do overlays on the map the same way and they're pretty much instantaneous.
Nov 26 2007, 6:20 pm
In response to Foomer
Will do.