GMS2 View Compatibility Script Insanely Slow

[obscene]

To optimize a graphics effect, I only apply it to instances in the view. In GMS1.4, I did this...

            with (par_prop)
                {         
                if (image_alpha==1 && sprite_index && bbox_right>view_xview && bbox_left<view_xview+1920
                && bbox_bottom > view_yview && bbox_top < view_yview+804)
                    {
                    // do stuff

Lots of math, but it has never been slow.

After importing it into GMS2, it became this...

            with (par_prop)
                {         
                if (image_alpha==1 && sprite_index && bbox_right>__view_get( e__VW.XView, 0 ) && bbox_left<__view_get( e__VW.XView, 0 )+1920
                && bbox_bottom > __view_get( e__VW.YView, 0 ) && bbox_top < __view_get( e__VW.YView, 0 )+804)
                    {
                    // do stuff

In one room with a particularly large amount of instances, it became evident this is extremely slow.




__view_get() is a compatibility script generated by GMS.

var __prop = argument0;
var __index = argument1;
var __res = -1;
switch(__prop)
{
case e__VW.XView: var __cam = view_get_camera(__index); __res = camera_get_view_x(__cam); break;
case e__VW.YView: var __cam = view_get_camera(__index); __res = camera_get_view_y(__cam); break;
case e__VW.WView: var __cam = view_get_camera(__index); __res = camera_get_view_width(__cam); break;
case e__VW.HView: var __cam = view_get_camera(__index); __res = camera_get_view_height(__cam); break;
case e__VW.Angle: var __cam = view_get_camera(__index); __res = camera_get_view_angle(__cam); break;
case e__VW.HBorder: var __cam = view_get_camera(__index); __res = camera_get_view_border_x(__cam); break;
case e__VW.VBorder: var __cam = view_get_camera(__index); __res = camera_get_view_border_y(__cam); break;
case e__VW.HSpeed: var __cam = view_get_camera(__index); __res = camera_get_view_speed_x(__cam); break;
case e__VW.VSpeed: var __cam = view_get_camera(__index); __res = camera_get_view_speed_y(__cam); break;
case e__VW.Object: var __cam = view_get_camera(__index); __res = camera_get_view_target(__cam); break;
case e__VW.Visible: __res = view_get_visible(__index); break;
case e__VW.XPort: __res = view_get_xport(__index); break;
case e__VW.YPort: __res = view_get_yport(__index); break;
case e__VW.WPort: __res = view_get_wport(__index); break;
case e__VW.HPort: __res = view_get_hport(__index); break;
case e__VW.Camera: __res = view_get_camera(__index); break;
case e__VW.SurfaceID: __res = view_get_surface_id(__index); break;
default: break;
};
return __res;

Can anyone elaborate on what is going on exactly and how to make a clean conversion? I've read/watched a little bit on cameras but I'm confused as to what GMS2 may have already created in my project and how to work with that/remove that. (Do I already have cameras? One? One for each room? ID? Do I need to make a global one so all the billion things in my game that use view_xview / view_yview can access them?)

 

[ph101]

Yeah I was in a similar situation and actually have left well alone for now! Sorry I cant help except to say that surely yes you would need to code a new camera system and implement it across the project and remove the old code..

I know you didn't quite ask this but is it really more optimal to have many instances check if they are on screen like this, using a with? Out of interest is that in the draw event? Also I may be wrong don't objects off screen not draw anyway? Or is it cpu use you want to limit that the effect somehow uses?

 

[YellowAfterlife]

See if changing them to camera_get_view_y(view_camera[0]) and alike fares better. If so, you can make a backup/commit of your project and just find-replace all of them

 

[obscene]

See if changing them to camera_get_view_y(view_camera[0]) and alike fares better. If so, you can make a backup/commit of your project and just find-replace all of them

OK, a strange thing happened. I was going to implement your idea using the old obsolete variables just to make it readable and familiar. So I did this...

var view_xview=camera_get_view_x(view_camera[0]);
var view_yview=camera_get_view_y(view_camera[0]);

GM spit an error back to me, "cannot redeclare builtin variable."

So, I tested the code using view_xview and view_yview as I did in GMS 1.4. And it worked! So why in the world did GMS2 remove all those variables and insert all these scripts if they work properly as they were???

@php101
Yes, objects outside the view aren't drawn, but code in the draw events is still executed. In this particular effect, I use alot of other functions like point_distance and point_direction to get vectors between instances and lights, and so it's beneficial to cull as many of those calls out as possible by seeing if they are in the view first. I would probably be better to put this in an alarm however and just keep an array of instances in the view, just never got around to it.

 

[ph101]

So, I tested the code using view_xview and view_yview as I did in GMS 1.4. And it worked! So why in the world did GMS2 remove all those variables and insert all these scripts if they work properly as they were???

Hmm that is bizarre. How does the performance stack up...?

 

[obscene]

Silky smooth. obj_highlights went from 17k ms to 2k.

 

[obscene]

Update: Turns out that view_xview and view_yview are there, they just return 0. But, they appear to be global, so it only takes one object somewhere writing the camera view position to them to correct them for the entire game.

 

[ph101]

Ah right. Well yeah I guess just perfoming camera_get_view once per step and setting to global var to compare per object is a good idea anyway (so it probably is still slower than 1.4 you just only need to do it once anyway if I understand correctly anyway)