Pages: 1
  Print  
Author Topic: draw_set_color  (Read 1189 times)
Offline (Male) Goombert
Posted on: October 29, 2013, 03:18:02 AM

Developer
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 3107

View Profile
Yah just a heads up everybody, Studio removed the draw_set_color function, well, the way it used to be anyway. I recently readded it the Game Maker 8.1 way with Direct3D where you can call it to change the color of a model or the alpha, but listen here is the funny thing. YoYoGames decided to store current color for every vertice, making their code redundant one would assume, and making it run slower and also making it less flexible to use, eg. drawing transparent models, when they simply could have replaced the blend operation in the FFP with HLSL. But never the less ENIGMA will continue the old expected draw_set_color behavior because it is rather useful to draw transparent models and the likes.

Code: [Select]
void draw_set_color(int col)
{
enigma::currentcolor[0] = __GETR(col);
enigma::currentcolor[1] = __GETG(col);
enigma::currentcolor[2] = __GETB(col);
    D3DCOLOR D3DColor = D3DCOLOR_RGBA(__GETR(col), __GETG(col), __GETB(col), 155);
d3ddev->SetRenderState(D3DRS_BLENDOP, D3DBLENDOP_ADD);
    d3ddev->SetRenderState(D3DRS_SRCBLEND, D3DBLEND_BLENDFACTOR);
    d3ddev->SetRenderState(D3DRS_DESTBLEND, D3DBLEND_INVSRCALPHA);
    d3ddev->SetRenderState(D3DRS_BLENDFACTOR, D3DColor);
d3ddev->SetRenderState(D3DRS_TEXTUREFACTOR, D3DCOLOR_RGBA(155, 155, 155, 155));
}

Also, this means that stupid cubes demo of their's won't work right out of the box. And listen how dumb this is, here is why...
Code: [Select]
       draw_set_color(c_red);
       d3d_set_lighting(true);
       d3d_light_define_direction(0, 0.5,0,1, c_white);
       d3d_light_enable(0,true);
       
       d3d_transform_set_rotation_z( d3d.x );
       d3d_transform_add_rotation_y( d3d.x/2 );

       if( global.cube>=0 ) d3d_model_draw(global.cube, 0,0,0, -1);
       
       d3d_set_lighting(false);
       d3d_model_draw(global.wirecube,  0,0,0,  -1 );

They put draw_set_color(c_red); directly before drawing the cubes. Which doesn't even change anything in Studio since set color was stored in the model but yet it does work in ENIGMA. Which makes me wonder why the fuck that code is even their in there demo, if they were just testing it or testing if it was removed or what. But at any rate, ENIGMA will keep the easy to use expected behavior and sprite batching will render on the state change since it is simply a blend op.
« Last Edit: October 29, 2013, 03:19:54 AM by Robert B Colton » Logged
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.

Offline (Unknown gender) TheExDeus
Reply #1 Posted on: October 29, 2013, 06:51:39 AM

Developer
Joined: Apr 2008
Posts: 1872

View Profile
This was partly discussed here http://enigma-dev.org/forums/index.php?topic=1375.msg13778#msg13778 3 months ago. I also mentioned how it makes more sense to include color for all vertexes (and it was partly the only way to do it), so I guess that is what they now did. So it is possible to change color on the fly via shaders, but if we are talking about batching vertex data (VBO's), then it's better to include vertex color as well so you don't rely on fixed function pipeline.

The most correct way would be to do this:
Add color to vertices.
Blend this color in a shader with the bound color.
But that would not only be incompatible with GM/GM:S, but also with the way we draw sprites. It would actually make sense if draw_sprite() also used bound color, but as the default bound color is c_black, then sprites by default also would be black. We can make default color c_white though. Then draw_text() would draw white text by default. So we should decide.
Logged
Offline (Male) Goombert
Reply #2 Posted on: October 29, 2013, 07:00:51 AM

Developer
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 3107

View Profile
Well fuck me, becase that is the exact issue I just posted about why Tetris don't work in Direct3D, it drew everything with default black because I did add the color to the draw sprite calls, now I don't know what to do. But again, as for your and their excuse I don't agree about it being that big of a drag, we are going to redo the entire ffp with shaders anyway once we get all this sorted out and the abstract device/state managers are finished. I like it being easy for noobs to draw transparent models and stuff, but that doesn't mean it has to be slow either.

http://enigma-dev.org/forums/index.php?topic=1378.msg15410#new
Logged
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.

Offline (Unknown gender) TheExDeus
Reply #3 Posted on: October 29, 2013, 02:21:30 PM

Developer
Joined: Apr 2008
Posts: 1872

View Profile
Quote
I don't agree about it being that big of a drag
I am not necessarily talking about technical reasons, as everything could be made and especially by using shaders. But we need to make a decision on how it should work. Because one way will not be compatible with another. That is what that topic was all about. I decided to do the middle way and add color to vertices when vertex_color is used and use on the fly bound color when only vertex_ is used. So draw_set_color() will sometimes color the model (if no color is added to vertices) and not color it another time. If you really want to do color per vertex and then blending with color per model, then it will break shit ton of stuff (like compatibility), but I don't have that big of an issue with that. On the other hand will that only work with primitives/models or should also be applicable to sprites? If so, then it will break even more stuff.
Logged
Pages: 1
  Print