53 replies to this topic

[Jobo]

Well, since this topic got brought back from hall of the dead anyway...

Once you become a good programmer it is easier to type in a variable/array than to create an object. It's tedious to create objects to store everything. Also plain stupid.

I say this to brett14, and all the other people who fight for the epicness of using arrays instead of objects; you're stupid.
Creating a buckload of arrays in the one object that is the only object in the game (thus always stays active) is like using nothing but global variables.
You can't ever release your variables when you don't need to use them anymore.

Local variables in objects are released when the object is deleted.
And since you only use 1 object with thousands of variables on it, you can't release anything you don't need to use anymore without ending the game.
This is plain stupid.

Never keep variables around that you don't need. They're locked in memory for absolutely no purpose.
It's slower than using objects.

[PlotClopper]

=/ who designs a game this way?

A lot of people. Anybody who cares about the speed of their game should try to optimize it wherever they can. Also structures are being implemented in GM8.1, which are basically the same thing as he's done, just a little bit easier to use.


It is just as easy to write

player[HP]=100;
player[DAMAGE]=2.5;
player[ARMOR]=4;

as creating an object, going to the create event and going

hp=100;
damage=2.5;
armor=4;

then having to access it with

object.hp;
object.damage;
object.armor;

You'll find it more organized if you keep all relevant variables clumped together in the script when you create it. It is easier to find where the values are (click on the script, or search and its there), and easier to edit because you don't have to go clicking through all the objects. Also, why have a huge overhead, take longer to code/fix errors, and be less organized? If you're storing variables use variables... There is a reason it's called a "varaible". Don't use objects for variables. It just doesn't make sense.

The only reasons, those make your method viable, are Game Maker doesn't currently support structs and Game Maker does everything possible to make its classes not act like classes. Your method barely approaches viability because of the faults of the alternatives. In any sane programming environment your method is irrefutably a needless reinventing of the wheel, that lacks flexibility, legibility, maintainability, stability, reliability and scalability.

OOP is the standard of modern programming and Game Maker is an absolutely abysmal implementation of it. The sheer number of hurdles, those I have to jump to get my Game Maker projects organized in a sane way, is absolutely maddening. Good organization is overly tedious and it tends to cause lower framerates, so ludicrous methods are being presented as legitimate solutions and I can't say they're 100% wrong, which I find absolutely abhorrent.

Edited by PlotClopper, 23 June 2012 - 11:50 AM.

[Follomania]

There are many cases where using arrays to replace objects can benefit the game. For example, say you're programming a 3D SimCity type game where you plan on having hundreds of individual buildings. If you make an individual object for each of those buildings you're going to have a game with an unplayable frame rate. Each of those objects will need to run "behind the scenes" calculations that will most likely be pointless. If you have a single object, you can loop through the array updating the coordinates only as needed.
Addressing memory, each object will also have to store it's own x, y, xprevious, yprevious, xstart, ystart, hspeed, vspeed, direction, speed, friction, gravity, gravity_direction, image_index, image_speed, image_xscale, image_yscale, image_blend, image_alpha, image_angle, persistent, depth, solid, and several others that I can't recall right now. Multiply that by a couple hundred, and I think you'll have more memory used than three or four arrays with that many indices.
Please, before you call people stupid, do some testing.

Back on the topic we should be discussing; this is a very clever idea. I'll have to work on some speed tests, but this should be quite a bit faster than ray-casting to find which joint I'm clicking on in an animation program. Great work!

[PlotClopper]

There are many cases where using arrays to replace objects can benefit the game. For example, say you're programming a 3D SimCity type game where you plan on having hundreds of individual buildings. If you make an individual object for each of those buildings you're going to have a game with an unplayable frame rate. Each of those objects will need to run "behind the scenes" calculations that will most likely be pointless. If you have a single object, you can loop through the array updating the coordinates only as needed.
Addressing memory, each object will also have to store it's own x, y, xprevious, yprevious, xstart, ystart, hspeed, vspeed, direction, speed, friction, gravity, gravity_direction, image_index, image_speed, image_xscale, image_yscale, image_blend, image_alpha, image_angle, persistent, depth, solid, and several others that I can't recall right now. Multiply that by a couple hundred, and I think you'll have more memory used than three or four arrays with that many indices.
Please, before you call people stupid, do some testing.

Those benefits do not exist in a sane programming environment, that does not needlessly shoehorn its classes as templates of physical, moveable objects. Using arrays to reimplement basic object functionality is a needless reinvention of the wheel, that is only made a necessity because of Game Maker's poor implementation of object functionality, that is basic.

Even still I would not reimplement basic object functionality in Game Maker with arrays because I correctly value legibility and maintainability over speed. I'll redesign my game to cope with technical limitations if that is necessary. I'll switch over to a different language if Game Maker is inadequate. I'll do anything except create an ill conceived, monstrous code base, that devours my time and sanity.

I've had my days of mucking through sloppy, malformed code. I will not endorse poor coding practices or allow other people's endorsements of poor coding practices.

[Rexhunter99]

There are many cases where using arrays to replace objects can benefit the game. For example, say you're programming a 3D SimCity type game where you plan on having hundreds of individual buildings. If you make an individual object for each of those buildings you're going to have a game with an unplayable frame rate. Each of those objects will need to run "behind the scenes" calculations that will most likely be pointless. If you have a single object, you can loop through the array updating the coordinates only as needed.
Addressing memory, each object will also have to store it's own x, y, xprevious, yprevious, xstart, ystart, hspeed, vspeed, direction, speed, friction, gravity, gravity_direction, image_index, image_speed, image_xscale, image_yscale, image_blend, image_alpha, image_angle, persistent, depth, solid, and several others that I can't recall right now. Multiply that by a couple hundred, and I think you'll have more memory used than three or four arrays with that many indices.
Please, before you call people stupid, do some testing.

Those benefits do not exist in a sane programming environment, that does not needlessly shoehorn its classes as templates of physical, moveable objects. Using arrays to reimplement basic object functionality is a needless reinvention of the wheel, that is only made a necessity because of Game Maker's poor implementation of object functionality, that is basic.

Even still I would not reimplement basic object functionality in Game Maker with arrays because I correctly value legibility and maintainability over speed. I'll redesign my game to cope with technical limitations if that is necessary. I'll switch over to a different language if Game Maker is inadequate. I'll do anything except create an ill conceived, monstrous code base, that devours my time and sanity.

I've had my days of mucking through sloppy, malformed code. I will not endorse poor coding practices or allow other people's endorsements of poor coding practices.

Excuse me but it's much faster for me to render 4000 scenery objects like trees from a small array than it is to create a class/object and then instantiate the object for every instance. Classes in any language, memory managed or not, compiled or interpreted, have overhead, it may be small but it's there, just like allocating dynamic memory in C++ applications uses more memory than you intend. For instance:

char *myString = new char[ 1024 ];

Does not necessarily allocate only 1024 bytes for my array, there is an overhead.

The thing about arrays vs classes/objects in any language is to know when to use them. I would not use arrays to represent players for instance, or any kind of animated character, but static data like scenery is far more efficient to run through arrays.
Just because OOP is the standard does not mean you MUST code everything using OOP, sometimes you gotta fall back to the good old C standards.

[PlotClopper]

There are many cases where using arrays to replace objects can benefit the game. For example, say you're programming a 3D SimCity type game where you plan on having hundreds of individual buildings. If you make an individual object for each of those buildings you're going to have a game with an unplayable frame rate. Each of those objects will need to run "behind the scenes" calculations that will most likely be pointless. If you have a single object, you can loop through the array updating the coordinates only as needed.
Addressing memory, each object will also have to store it's own x, y, xprevious, yprevious, xstart, ystart, hspeed, vspeed, direction, speed, friction, gravity, gravity_direction, image_index, image_speed, image_xscale, image_yscale, image_blend, image_alpha, image_angle, persistent, depth, solid, and several others that I can't recall right now. Multiply that by a couple hundred, and I think you'll have more memory used than three or four arrays with that many indices.
Please, before you call people stupid, do some testing.

Those benefits do not exist in a sane programming environment, that does not needlessly shoehorn its classes as templates of physical, moveable objects. Using arrays to reimplement basic object functionality is a needless reinvention of the wheel, that is only made a necessity because of Game Maker's poor implementation of object functionality, that is basic.

Even still I would not reimplement basic object functionality in Game Maker with arrays because I correctly value legibility and maintainability over speed. I'll redesign my game to cope with technical limitations if that is necessary. I'll switch over to a different language if Game Maker is inadequate. I'll do anything except create an ill conceived, monstrous code base, that devours my time and sanity.

I've had my days of mucking through sloppy, malformed code. I will not endorse poor coding practices or allow other people's endorsements of poor coding practices.

Excuse me but it's much faster for me to render 4000 scenery objects like trees from a small array than it is to create a class/object and then instantiate the object for every instance. Classes in any language, memory managed or not, compiled or interpreted, have overhead, it may be small but it's there, just like allocating dynamic memory in C++ applications uses more memory than you intend. For instance:

char *myString = new char[ 1024 ];

Does not necessarily allocate only 1024 bytes for my array, there is an overhead.

The thing about arrays vs classes/objects in any language is to know when to use them. I would not use arrays to represent players for instance, or any kind of animated character, but static data like scenery is far more efficient to run through arrays.
Just because OOP is the standard does not mean you MUST code everything using OOP, sometimes you gotta fall back to the good old C standards.

My point isn't arrays shouldn't be used. My point is arrays shouldn't be used to replicate object functionality. I have no objection to using an array to store coordinates for where trees should be rendered. I would have an objection to using an array instead of a class to define a tree "object."

Legibility and maintainability matter more than speed. A project can often be scaled back or adjusted to compensate for technical issues. A project can't always be maintained and completed if it's poorly written.

Edited by PlotClopper, 27 June 2012 - 04:38 AM.

[THE_GAME_EDITOR]

Bam! You most likely ended the discussion.

[PlotClopper]

I suspect if this thread is not forgotten someone else will post to defend inappropriate array use. People, who hold bad coding practices, have a way of justifying their designs.

[filulilus]

Back on the topic we should be discussing; this is a very clever idea. I'll have to work on some speed tests, but this should be quite a bit faster than ray-casting to find which joint I'm clicking on in an animation program. Great work!

Thank you for bringing back the topic! (even tho I enjoyd the discussion)
yeah, it's main focus is targeting stuff (such as in a animation program or a RTS)

[torey0]

I've recreated the engine and I'm trying to find out how you make the 3d draw onto a surface (in 8.1)...

If there are a lot of things to draw (I have an 85*85 grid) the slower fps ends up flickering the colors onto the screen. Would the surface prevent that?

This just ends up drawing my tiles in 2d onto the screen. Going over the wiki I'm not sure what 3d settings I need to change to make the surface 3d? It does draw the grid fine otherwise.

Part of the draw event:

// Check for mouse
if(mouse_check_button_pressed(mb_any)) {
    surface_set_target(color_surface);
    draw_clear(c_black);
    for(i = 0; i < global.tile_count; i += 1) {
        draw_set_color(global.tile_color[i]);
        d3d_draw_floor(global.tile_x[i]-5,global.tile_y[i]-5,global.tile_z[i],global.tile_x[i]+5,global.tile_y[i]+5,global.tile_z[i],-1,true,true);
    }
    color_mouse = surface_getpixel(color_surface,mouse_x,mouse_y);
    for(i = 0; i < global.tile_count; i += 1) {
        if(color_mouse == global.tile_color[i]) {
            global.tiles[i] = 0;
            break;
        }
    }
    surface_reset_target();
}

// Draw our tiles
for(i = 0; i < global.tile_count; i += 1) {
    if(global.tiles[i] == 1) {
        d3d_draw_floor(global.tile_x[i]-5,global.tile_y[i]-5,global.tile_z[i],global.tile_x[i]+5,global.tile_y[i]+5,global.tile_z[i],background0,true,true);
    }
}

[Follomania]

I've recreated the engine and I'm trying to find out how you make the 3d draw onto a surface (in 8.1)...

If there are a lot of things to draw (I have an 85*85 grid) the slower fps ends up flickering the colors onto the screen. Would the surface prevent that?

This just ends up drawing my tiles in 2d onto the screen. Going over the wiki I'm not sure what 3d settings I need to change to make the surface 3d? It does draw the grid fine otherwise.

If you draw to a surface, you won't have it show up on the screen. But it's usually best to draw to the surface in the step event rather than the draw event.

To draw to the surface, you only need to set the projection with d3d_set_projection() right after you set the surface as the target:

surface_set_target(surface)
d3d_set_projection(xf,yf,zf,xt,yt,zt,xup,yup,zup)
draw_clear_alpha(color, alpha)
//...

Edited by Follomania, 15 July 2012 - 08:08 PM.

[torey0]

I remember reading somewhere that the surface drawing can go in the draw event now, but at the same time the older posts say step event...

I'm going to give a go working with setting 3d for the surface in the step event. I tried it briefly with the original example and it would just stop drawing anything whenever I clicked, so I was missing something.

Edit: Not sure what I did when I first tried it, but it is working fine now in the step event. No steady fps difference but the flickering is totally gone.

Moved the mouse check to the step event, rest is unchanged.

// Check for mouse
if(mouse_check_button_pressed(mb_any)) {
    surface_set_target(color_surface);
    d3d_set_projection_ext(50,50,30,100,100,28,false,false,true,60,1.6,1,32000);
    draw_clear(c_black);
    for(i = 0; i < global.tile_count; i += 1) {
        draw_set_color(global.tile_color[i]);
        d3d_draw_floor(global.tile_x[i]-5,global.tile_y[i]-5,global.tile_z[i],global.tile_x[i]+5,global.tile_y[i]+5,global.tile_z[i],-1,true,true);
    }
    color_mouse = surface_getpixel(color_surface,mouse_x,mouse_y);
    for(i = 0; i < global.tile_count; i += 1) {
        if(color_mouse == global.tile_color[i]) {
            global.tiles[i] = 0;
            break;
        }
    }
    surface_reset_target();
}

Edited by torey0, 16 July 2012 - 12:44 AM.

[Venomous]

You can use a target area larger than the real model without using surfaces.
Simply do the targeting first then call draw_clear() using the background color. After that draw the real scene.

[Coga19000]

Well, I have made a question above. Is GM able of using models?