Ok so as the title suggests, and how do I get rid of them. I don't know what I did wrong but every time I try highlighting (mouse script) over a command in the menu (especially the status scene) it lags like hell. I'm guessing because of all the sprites I'm using (not using any windows) or just faulty coding. If anyone wants to look at see why I can send you a PM of my games cms.
Are you calling the refresh method constantly? That might be the problem.
If you mean the update method, as I barely use refresh, then possible yes. I'll get back to you guys if I don't get it.
He means is the update method constantly refreshing, as in redrawing a bitmap every frame. That is the most likely cause.
Then yes that would be where I need help fixing.
Edit...
Well I think the help sprite class I created on the main menu is causing the problem but I seem to be having an issue fixing it.
Ok so I've have done everything I can think of and still can't figure out how to remove the lag from the menu. Have no clue what to do next.
Disable stuff and calls within the script just to get an idea where the lag happens.
So there's nothing in your Mouse script under, say, Window_Selectable that says anything like "redraw the contents of the window again"?
You really need to learn how to use print statements effectively. That is literally what I have always used whenever you asked for help for your previous scripts.
Looks like everyone else said it already, so yeah... Make sure you're not going super intensive on anything that will redraw to the screen. Keep in mind that you have to consider not only your scripts, but also everything going on with all the default scripts. It's very possible that you're redrawing even more than you realize if the system default scripts are redrawing things as well as your scripts.
Okay so I figured out why the main menu is freezing. As I stated before the help sprite is causing it to lag every time I highlight over a command. So after going to Sprite_Help, and started commenting things off to see where the issue is. I notice that it was coming from the Bitmap method gradient_draw_text. Because when I comment off this method the lag disappears. If I go even further in this part of the method causes the most lag:
w.times do |x2|
h.times do |y2|
alpha_txt = text_bmp.get_pixel(x2, y2).alpha
if alpha_txt > 0
c = gradient_bmp.get_pixel(x2, y2)
c.alpha = alpha_txt
text_bmp.set_pixel(x2, y2, c)
end
end
end
Removing this from the gradient_draw_text method removes the lag (at least the main menu, as the status still lags for another reason), but causes all the gradient color disappear. Mostly due to the fact that this part of the method adds the gradient to the text. Printing it to the console causes a long list of numbers to appear due to the for loops.
Gradient text... Yeah, that explains a lot. xD
I think rewriting this into a .dll file is the only way to get this to run faster. :<_<:
Or use a bitmap text renderer. Just keep in mind that you will probably have a much more limited number of characters available.
is that either way as I am using a couple of foreign characters so that's going to be a problem.
there is another option. pre render the text. as in render the text one to a second bitmap and then just blit the renderd bitmap into your window. that way you only have to draw the gradiant once per text change. and it the text is meant to change often then there should be at-lest one part that doesn't change. prerender the text in parts according to it's update frequency and put it back together with blits
optimization isn't hard you just have to think a bit :P
When you say 'lags like hell' do you mean your game's FPS drops to like 1 or there's this super long pause that lasts for a few seconds but the game runs normally afterwards?
If the first, you should still look for why you are calling that 'gradient_draw_text' so many times. Why would you even need to call it multiple times anyways? Just draw it once and be done with it.
If the second, which must mean you are drawing something to an insanely large bitmap, I would probably do something along the lines of what Ryex suggested for my game.
FPS doesn't drop at all so it has to be the second one.
Edit: One question, Why is Bitmap's Set_Pixel and Get_Pixel so heavy?
Textures are usually in the VRAM of the GPU so getting a certain pixel value disrupts the entire pipeline flow of how things are rendered. Everything has to be suspended, then the texture has to be downloaded from the graphics card back into RAM where finally the pixel value is obtained. Setting the pixel does the same thing, then changes the value and loads the texture back onto the VRAM of the GPU. It's a very expensive process. Usually something like this is optimized by knowing in advance that you are going to modify a texture so you create a local copy in the RAM which you then modify and keep uploading in a one-way pipeline onto the GPU which is much, much faster. But RMXP lacks this kind of functionality.
Well Bizz, I belive this leaves just one question. does ARC posses this functionality? (no seriously, I haven't looked at hot you implemented the bitmap get and set pixel methods)
Yes. It will be refined in the next refactor of April, but in general ARC already does that.
When I rewrote the XRXS Battle System, it started off very laggy because of the Gradient Bars.
The Gradient Bars were being drawn each and every frame, not when they changed. The method I came up with to fix it wasnt great, but was part of a learning process. What I did was only allow the bars to refresh or redraw if the Bars had changed at all. That was done in the update method. Check for any changes to the bars and refresh only as needed and as infrequently as possible.
General advice: Same thing goes with sprites in every scene. Put a print inside the Refresh method right around contents.clear to see how frequently Refresh is being called. Every frame, or only when a change is made? print "Refreshing ", @event_id Its annoying to be "Refresh Messaged", but gives a better idea where the engine is struggling.
There is no reason a bitmap should ever be redrawn unless it has changed, anything else is wasted performance.
Convention is to use "update" to check if it needs changed, and if it does, it will cause call the "refresh" method that actually performs the drawing.
def update
if @time.second != Time.now.second
refresh_time
@time = Time.now
end
end
def refresh_time
draw_some_stuff
end
You could of course choose to do whatever you like, but that is the logical manner that is traditionally followed.