GMLscripts.com

Discuss and collaborate on GML scripts
Invert

You are not logged in.

#101 2013-05-20 21:26:15

icuurd12b42
Member
Registered: 2008-12-11
Posts: 303

Re: CHALLENGE: Conway's Game of Life

Hey Xot!

I'm sorry to bother you but I was wondering if I could borrow you brain for a bit

You remember the trailing you did, above. It worked great but I simply wont work in studio and I am clueless as for why. I just get a blank screen...

Here is the gmk and the gmz
http://host-a.net/u/icuurd12b42/wirewor … s-demo.zip

I would be greatful, as usual, if you can figure this enigma. I'm finally bringing it over into that tron like tank game I showed you a while back...

Offline

#102 2013-05-21 03:48:00

xot
Administrator
Registered: 2007-08-18
Posts: 1,201

Re: CHALLENGE: Conway's Game of Life

I spent some time with this, moving all of the drawing code into the draw event and I still couldn't get it to work.

I tried a couple experiments and it looks like GM:Studio may be actively preventing the drawing of a surface to itself. It would make sense for it to do this since that sort of thing can crash a device, according to Mike Dailly. (edit: Mike tells me that nothing is actively preventing this.)

The next step is to rewrite those parts to "ping-pong" between two surfaces to achieve the same result. Those parts will be much slower. Something that currently takes 8 passes would take 12 passes plus the extra overhead of switching targets each pass.

Since this is already running more than an order of magnitude slower than GM8, I wonder if this is even viable in GM:Studio. I'm hopeful that when shaders are added in version 1.2 a much more efficient solution will present itself.

Last edited by xot (2013-05-23 07:01:46)


Abusing forum power since 1986.

Offline

#103 2013-05-21 15:29:41

icuurd12b42
Member
Registered: 2008-12-11
Posts: 303

Re: CHALLENGE: Conway's Game of Life

From this I change the low pass and the hipass to not draw on itself

//  surface_lowpass_mask(surface,low)
//      source      surface to be masked with filter
//      low         colors darker than low with pass
//  returns a surface that is white where colors pass, black elsewhere
{
    var src,lo,w,h,tmp;
    src = argument0;
    lo = c_white ^ argument1;
    w = surface_get_width(src);
    h = surface_get_height(src);
    tmp = surface_request(w,h);
    surface_copy(tmp,0,0,src);
    surface_set_target(tmp);
    draw_set_blend_mode_ext(bm_one,bm_one);
    draw_rectangle_color(0,0,w,h,lo,lo,lo,lo,false);
    draw_set_blend_mode_ext(bm_inv_dest_color,bm_zero);
    draw_rectangle_color(0,0,w,h,c_white,c_white,c_white,c_white,false);
    var t2; t2 = surface_create(surface_get_width(tmp),surface_get_height(tmp));
    if(surface_exists(t2))
    {
        repeat (8) 
        {
            draw_set_blend_mode(bm_normal);
            
            surface_set_target(t2)
            draw_clear_alpha(c_black,0);
            draw_surface(tmp,0,0);
            draw_set_blend_mode_ext(bm_one,bm_one);
            surface_set_target(tmp);
            draw_surface(t2,0,0);
        }
        surface_free(t2);
    }
    draw_set_blend_mode(bm_normal);
    surface_reset_target();
    return tmp;
}
//  surface_highpass_mask(surface,high)
//      source      surface to be masked with filter
//      high        colors brighter than high will pass
//  returns a surface that is white where colors pass, black elsewhere
{
    var src,hi,w,h,tmp;
    src = argument0;
    hi = argument1;
    w = surface_get_width(src);
    h = surface_get_height(src);
    tmp = surface_request(w,h);
    surface_copy(tmp,0,0,src);
    surface_set_target(tmp);
    draw_set_blend_mode_ext(bm_inv_dest_color,bm_zero);
    draw_rectangle_color(0,0,w,h,c_white,c_white,c_white,c_white,false);
    draw_set_blend_mode_ext(bm_one,bm_one);
    draw_rectangle_color(0,0,w,h,hi,hi,hi,hi,false);
    draw_set_blend_mode_ext(bm_inv_dest_color,bm_zero);
    draw_rectangle_color(0,0,w,h,c_white,c_white,c_white,c_white,false);
        
    var t2; t2 = surface_create(surface_get_width(tmp),surface_get_height(tmp));
    if(surface_exists(t2))
    {
        repeat (8) 
        {
            draw_set_blend_mode(bm_normal);
            
            surface_set_target(t2)
            draw_clear_alpha(c_black,0);
            draw_surface(tmp,0,0);
            draw_set_blend_mode_ext(bm_one,bm_one);
            surface_set_target(tmp);
            draw_surface(t2,0,0);
        }
        surface_free(t2);
    }
    
    draw_set_blend_mode(bm_normal);
    surface_reset_target();
    return tmp;
}

I still get a blank screen,

As for the speed. in the tron like game the surface is 256x256, and the game itself does very little so I would hope the method is still useable in that case.

[edit]
I also looks like the surface fade is not working. is it possible Studio broke the blend modes?

Last edited by icuurd12b42 (2013-05-21 17:26:25)

Offline

#104 2013-05-21 17:44:52

icuurd12b42
Member
Registered: 2008-12-11
Posts: 303

Re: CHALLENGE: Conway's Game of Life

Yep. Running this
http://gmc.yoyogames.com/index.php?showtopic=512187

Under studio. result is not the same... And It looks Like we cant report bugs anymore on bugs.yoyogames.com. the Report Issue is missing.

Offline

#105 2013-05-21 22:51:56

xot
Administrator
Registered: 2007-08-18
Posts: 1,201

Re: CHALLENGE: Conway's Game of Life

Bugs are supposed to be reported through the main site now.

http://gmc.yoyogames.com/index.php?show … try4280688


Abusing forum power since 1986.

Offline

#106 2013-05-22 02:27:05

icuurd12b42
Member
Registered: 2008-12-11
Posts: 303

Re: CHALLENGE: Conway's Game of Life

I guess I'm fubar thinking I can have this in studio for my Win Big submission. darnit

Offline

#107 2013-05-23 21:14:11

xot
Administrator
Registered: 2007-08-18
Posts: 1,201

Re: CHALLENGE: Conway's Game of Life

I get identical blending results with Phantom107's example. I had to alter the project some to get it to work right with GM:Studio.

First, I moved all of the drawing code to the Draw Event.

Second, background_create_from_surface() doesn't seem to work, so I changed the project to display the surface directly.

Third, I disabled cropping in the Texture Groups tab of the Global Game Settings.

With those changes I could not visually detect any differences in the displays. Comparative analysis of screen_save() images revealed some extremely minor differences that appear to manifest from slight antialiasing and gradient drawing differences. These were isolated / edge pixels that differed by less than 1% intensity.


Abusing forum power since 1986.

Offline

#108 2013-05-24 00:52:19

icuurd12b42
Member
Registered: 2008-12-11
Posts: 303

Re: CHALLENGE: Conway's Game of Life

I dont have texture management in my version of studio...

Offline

#109 2013-05-24 06:29:52

xot
Administrator
Registered: 2007-08-18
Posts: 1,201

Re: CHALLENGE: Conway's Game of Life

Really? That's pretty weak. I guess if the sprite was loaded from a file at run-time, you could do a proper comparison.


Abusing forum power since 1986.

Offline

#110 2013-05-26 12:55:48

xot
Administrator
Registered: 2007-08-18
Posts: 1,201

Re: CHALLENGE: Conway's Game of Life

I'm still trying to get the Wireworld demo working in GM:Studio. I think I've rewritten everything that needed to be fixed but it is still not working right. There seems to be something weird happening but this example is too complex to easily tell where it is going wrong. I need to do some simpler tests to get some answers.


Abusing forum power since 1986.

Offline

#111 2013-05-26 18:48:14

icuurd12b42
Member
Registered: 2008-12-11
Posts: 303

Re: CHALLENGE: Conway's Game of Life

Like I said, even the fading is broken. Something must have changed in the blending itself i think. Like the resulting rgba values from the blend are not 100% like they were in GM81

And if it's a bug we are going to have to prove it. LOL, I got the standard "Studio is not 100% like gm, you're going to have to fix your code" reply from the bugs report. tongue

Studio has had a lot of features and functions changed, removed & renamed. If you are importing files from older version such as 8.0 and 8.1, you will need to go through the project and ensure the functions are correct.

I got the new version of studio. at least in that one they added the use for 3d for sprites in my version, but that option you mentioned is still not there

Last edited by icuurd12b42 (2013-05-26 18:52:44)

Offline

#112 2013-05-28 00:56:30

xot
Administrator
Registered: 2007-08-18
Posts: 1,201

Re: CHALLENGE: Conway's Game of Life

Whew! I managed to get it working. There were a few bugs in the original demo which threw me off a little, along with a code block ordering error I made when moving the drawing code to the draw event. Ultimately blending appears to be working as expected.

Once those bugs were out of way, I encountered a really weird bug in GM:Studio that breaks everything under very common circumstances. There is a problem with drawing when views are used and the view and port heights are exactly the same. It resulted in the surface being drawn shifted upwards by several pixels each step. If you hadn't put in that scrollwheel code for me to accidentally execute, I might not have ever isolated the problem.

When you run the fixed demo it won't work right unless you adjust the view with the scrollwheel and reset the pattern with 'W'.

If you turn off views, everything works. If you manually change the port or view height by at least one pixel, everything works. Although everything works, it works unbelievably slowly for me: 1/10th the speed of the GM8 version. Perhaps 256x256 will be speedy enough for your purposes.

http://host-a.net/u/xot/wireworld-blend … -fixed.gmz

You'll see some new objects, backgrounds, and rooms I added during debugging. They can be safely removed.


Abusing forum power since 1986.

Offline

#113 2013-05-28 15:24:35

icuurd12b42
Member
Registered: 2008-12-11
Posts: 303

Re: CHALLENGE: Conway's Game of Life

It runs at 84/600 fps even on a 256x256 size setup. It's pathetic. I guess using surfaces in studio is a bad idea. I got 24 fps leeway. I'm going to ask someone to try on a portable device.

Offline

#114 2013-07-04 03:56:20

xot
Administrator
Registered: 2007-08-18
Posts: 1,201

Re: CHALLENGE: Conway's Game of Life

I've been having a fun time with the new shader functionality added to GM:Studio. I've got Wireworld running and it's not too bad. It's a little clunky in a couple places because I don't quite know what I'm doing.

The good news is that it is much faster than the blend mode version. You can also use any colors you want for the four states and I've even implemented the fade effect. For the large prime computer pattern I'm getting between 70 and 80 fps.

The bad news is, for a 256x256 pattern I top out around 140 fps. I honestly thought it would be a lot faster. The full pattern run only 15-20% faster than the GM8 blending version. There may be some limiting factors I don't understand. It's also worth noting that my graphics card is pretty outdated. A few more fps could be gained by hard wiring some values.


Abusing forum power since 1986.

Offline

#115 2013-07-04 16:53:30

icuurd12b42
Member
Registered: 2008-12-11
Posts: 303

Re: CHALLENGE: Conway's Game of Life

If you can post me the gmz. I'll send it over to my test guy on whos machine the shaders and the Windows YYC works. I'm having problem with the new Studio and the YYC accessing MSDev Studio which I think is needed for shaders and YYC. I may be wrong.

In any case good job on that. 140 fps is ample enough. The game I want this on is very resource friendly so it I got 80 fps to play with which should be enough.. All the fluff will be done through the shaders. explosions and such propagating in the room through the 256x256 surface.

Shaders are given much too much credit and is seen as the fast sln to everything smile.  In reality is adds to the device's blitting system so things overall should be slower when using a shader. But faster than if you implemented the effect the old fashion way.

Offline

#116 2013-07-04 17:18:20

xot
Administrator
Registered: 2007-08-18
Posts: 1,201

Re: CHALLENGE: Conway's Game of Life

I'll send you something a bit later. I'm still working out some issues with color matching which is apparently due to precision errors. At the moment only certain colors are working harmoniously.

I don't think you need VS to compile GLSL ES shaders. I don't believe I have it installed on my machine, although I might be wrong. AFK at the moment.


Abusing forum power since 1986.

Offline

#117 2013-07-04 19:49:31

xot
Administrator
Registered: 2007-08-18
Posts: 1,201

Re: CHALLENGE: Conway's Game of Life

OK, I figured out the precision problem and I've put together a Wireworld shader demo.

http://host-a.net/u/xot/wireworld-shader-demo.gmz

This works in a much more straight-forward manner than the blending tricks used to power the original Wireworld demo. GLSL is practically a general purpose language. It has interesting limitations offset by some amazing strengths. Even if you are not familiar with GLSL you should probably be able to follow the code. The performance disappointments I had initially may not be a factor on more capable systems. Even the most trivial shaders top out at around 150 fps for me, so clearly this has more to do with bandwidth than processing power. Wireworld will be very much device dependent. It performs 9 texture lookups per pixel and some hardware will choke on that (typically low-power/mobile). Press the shift key to alter the room speed.

OK, so what about the demo? What's nice about this version is that you can use any colors you wish for the four CA states (empty, wire, electron head, electron tail). These colors have to be passed to the shader each time it is enabled. You'll find that code in the draw event of oWireShader. It is vital that these colors are the same as the ones used in the initial pattern image.

The color precision problem I had was overcome by changing places where I compared colors exactly (color1 == color2) to a more flexible measurement. Now the distance between the colors is measured -- colors are just vectors as far as the GPU is concerned -- and if the distance is smaller than epsilon they are considered the same. Epsilon is a constant defined by the granularity of the color components, 1/255.

Another feature of this shader is that it can gradually fade the tail color to the wire color when it makes that state transition. This makes cool "Tron" trails as the electrons run through the wires. The fade rate is controlled by a parameter called fade. The lower the value, the longer it takes to fade. A value of 0.05 will fade very slowly and a value of 1.0 will fade instantly.

There are a couple of caveats I need to mention with regard to the fade effect.

First, because it uses a simple multiplicative fade, the electron trail may not entirely fade to the wire color due to rounding errors. This is mostly a cosmetic issue. Any color that is not one of the other three states will be treated as a wire. It should be possible to create a more robust additive fade if this is a problem.

Second, and this is more critical, if the fade from the tail color to the wire color happens to create colors used by the other states, it will break the automation. For instance, if a tail is white and a wire is black, the fade might pass through 50% gray. If that gray color is being used for the head, the automation will interpret those parts of the fading trail as heads. Most color selections won't pose an issue, but it is important to be aware of the possibility. I've not actually tried to break it this way myself yet.

Oh, yes, one more thing. You may experience a bug in the GM:Studio Windows runner with regard to drawing large surfaces in small views/rooms. Under some circumstances that aren't entirely clear, the surfaces may be drawn shifted or scaled strangely causing the pattern to scroll or cease to function. For me, if I zoom the view with the mouse wheel, it will start to scroll. It's actually the opposite behavior I experienced when I mentioned this problem elsewhere in this topic. Press the W key to reset the pattern. *shrug*

http://host-a.net/u/xot/wireworld-shader-demo.gmz

EDIT:

The GM:Studio bugs mentioned above have finally been corrected fixing a wide range of issues with surfaces.

Last edited by xot (2014-03-06 09:31:17)


Abusing forum power since 1986.

Offline

#118 2013-07-04 21:17:57

icuurd12b42
Member
Registered: 2008-12-11
Posts: 303

Re: CHALLENGE: Conway's Game of Life

Its freakin Fantagasmic that's what it is. not caring much if the automata is preserved. it's the effect that matters most to me.

Offline

#119 2014-03-06 09:37:03

xot
Administrator
Registered: 2007-08-18
Posts: 1,201

Re: CHALLENGE: Conway's Game of Life

Here is a real treat. John Conway himself talking about his discovery of the Game of Life and his somewhat adversarial relationship with it. This interview was conducted by the always interesting .

Does John Conway hate his Game of Life?

Inventing Game of Life

The third segment will probably appear in the next few days.

EDIT:

Or not.

Last edited by xot (2014-04-04 22:09:54)


Abusing forum power since 1986.

Offline

#120 2014-05-10 09:52:37

xot
Administrator
Registered: 2007-08-18
Posts: 1,201

Re: CHALLENGE: Conway's Game of Life

It took a while but here it is.

"Life, Death, and the Monster" is a reflective piece about Conway's literal life, his ambitions, and his mortality.


It also serves as a preface to a mind boggling topic explored in "The Monster Group".


Abusing forum power since 1986.

Offline

Board footer

Powered by FluxBB