Help! Make a Game Maker project compatible with Enigma.

[Goombert]

I think this might actually be a bug I introduced in ENIGMA. The problem is that you are probably not drawing anything else. Try to add draw_set_color(c_red); directly after the players drawing code or add the following if you were using the default drawing:

Code: (edl) [Select]

draw_set_color(c_white);
draw_self();
draw_set_color(c_red);

If that fixes it then that should confirm the bug I think exists. Basically when I introduced the global batching system I don't think I made it flush itself if there isn't any state change at all. I keep randomly hitting this issue myself.

[hpg678]

that's quite interesting to hear Goombert. I've been using ENIGMA on my LINUX machines and I've yet to encounter such a bug. Of course, I've encountered others but that's another story.

The bit of code given is excellent. However for the sake of newbies who may be reading this post, I wish to clarify a few things on two sets of code.

'draw_set_color(c_white)' used in the Draw event sets what is called the base color of the room or object referred to. The base color affects all the other elements, like fonts, text, forms primitives and 3D.
'draw_self()' used in the same Draw event is a function that forces the sprite's image, (whether you indicate one or not) to be drawn.

[Hoohee]

That turned the text red, but it didn't fix my actual problem--yet.  Is this how the full code should look?

Code: [Select]

draw_sprite_ext(sprite_index,0,x,y,image_xscale,image_yscale,image_angle,image_blend,image_alpha);
draw_set_color(c_white);
draw_self();
draw_set_color(c_red);

[Goombert]

Yeah, is that in the object that isn't drawing? Strange, and it's exactly what I've encountered before. Basically what I did is make all the general drawing functions go into a single vertex buffer before being sent to the GPU (this is called batching and GameMaker: Studio now does the same thing, it's faster this way). But if you change the drawing color, texture, or draw a shape of a different stride (any kind of a state change) it has to "flush" that vertex buffer to the GPU, as in actually draw the contents of the vertex buffer, clear it and start over.

Anyway, I basically just never added a check to draw the vertex buffer I think if no state change ever occurs, i.e. you draw a few things but never change the texture or color. That was a mistake and should be fixed in ENIGMA if I am truly remembering correctly. I could be wrong, I may have actually added such a check or it may just be malfunctioning in some other way.

One other thing you can try is to draw a circle in place of setting the drawing color to white.

[Hoohee]

I ended up getting the thing to render just by throwing out the code and using the default draw action.  I'm not sure why I had the code, but for now the draw action works.  So on to the next issue.

I have multiple objects that are programmed to jump to the position of another, or near it.  One of these is an accessory that warps to around the player character when a button is held--or at least, it did in Game Maker 8.  For some reason here, though, it gets reversed; instead of the accessory jumping to the position around the player character, the player character jumps to where the accessory starts!  There are other weird things, too, but let's start with this one; why is it happening?

[Goombert]

Oh boy, I can't really say without seeing how the "jumping" is done. I am also not that familiar with our collision systems, just never worked on them much. It might be helpful to post the relevant actions or code you are using to make the jumps.

[hpg678]

what you can also do is download a screen recorder Like Snaggit, to record the strangeness you encounter, post it as well as the segment of code.

Snaggit can be downloaded from here http://download.cnet.com/Snagit/3000-2192_4-10004813.html

I also recommend you watch this video..... https://youtu.be/8kHOsRSRbaA .

[Hoohee]

Alright, I have done some troubleshooting experimentation, and it would seem that the Step events are what cause the bug.  I've attached two slightly different versions of a sample "game" I made to figure this out, so if possible run each of them, first in Game Maker and then in Enigma, to duplicate my findings.

"JumpDemonstration" works like this: There is a ball object, and an arrow object.  The arrow starts in a different place, but pressing J makes the arrow jump so it points to the ball.  It doesn't ever jump back in this version, since there's no release event.  This version works identically in Game Maker and in Enigma, proving that, contrary to what I postulated earlier, jumping to positions in itself is not glitched in Enigma.

"JumpDemonstration1" responds to the J button both being pressed and being released.  To do this, I employed a binary variable (called "Jump"), triggered in Create, Key Press, and Key Release events, and checked during the Step event.  Press J, and the arrow jumps and points to the ball; release J, and the arrow jumps back to its original position.  Now try it in Enigma instead: Unlike last version; this one works differently.  No code whatsoever has been changed (at least not that I can see), but in Enigma, it's the ball that jumps when you press J.

What I seem to have discovered is a bug where during Step events, if you tell "Object A" to jump to a position defined by where "Object B" is, "Object B" jumps instead...somewhere; I'm not sure what logic it uses.  Feel free to use those files to dissect this issue further.

[hpg678]

In the first example you could've add a KEY RELEASE J event and place a JUMP TO START action to the Arrow object to get the same result instead of using a STEP event.

[HitCoder]

This is odd, as checking your logic, the arrow should definitely be jumping to the ball position.
Instead, the ball is jumping to the position you've specified for the arrow to jump to, which is relative to the ball position. This is why the ball glides up and right.
So, I think I know why this is happening. Because the IF statements are "with(object_Ball)", I think the statements that follow this are using this same with(object_Ball)

In which I think if we convert this logic to GML in both circumstances we'd have the following

Code: (EDL) [Select]

with(object_Ball){
        if(Jump==1){
                x=object_Ball.x+5;
                y=object_Ball.y-20;
        }else{
                x=100;
                y=100;
        }
}
In which case, the "with(object_Ball)" tells all of the code in the braces that follow it to run through that object. This would mean that setting x would set the object_Ball.x instead of object_Arrow.x as the code is being told to run through object_Ball remotely.

Where in Game Maker, the jump function switches back to other in this context, and I think with GML the with(other) might be using with(self) instead in which, Enigma would look as the self constant as the current object, in which would be object_Ball. I'm not sure how GM works on the backend (since it's not open source). I only have GM8.1 for reference though.

So using this logic, Game Maker would be doing it sort of like this in contrast to the above code;

Code: (EDL) [Select]

with(object_Ball){
        if(Jump==1){
                with(other){
                        x=object_Ball.x+5;
                        y=object_Ball.y-20;
                }
        }else{
                with(other){
                        x=100;
                        y=100;
                }
        }
}
Not sure why Enigma is handling it like the former, but it kind of makes sense.

So the fix in code would be to use the second code extract in place.

Also, I did test this in "realtime" while typing all of this; everything seems to add up here so I'm fairly confident this is what is happening.

And the solution in the drag-and-drop functions would be to set both jump functions to apply to "other" as follows.


Tested and works.

[Goombert]

Nice work HitCoder, it seems you may have found an actual bug in the with() construct.

There was a case of with() smashing that was causing a memory leak in ENIGMA for a while, but Josh patched that.
https://github.com/enigma-dev/enigma-dev/pull/999

It's possible his changes introduced this regression however, so you could try reverting his changes and see if it occurs.

[hpg678]

with all due respect, I don't agree such qualify as a basis for finding a bug.

First let me say that I believe it is a tad too much for one to expect GM files to be that compliant with ENIGMA without some type of error at some time.

Now let's examine the files in question.

In the first one, the arrow moves towards the ball by way of the KEYBOARD event. Simple enough.

In the second one, a variable Jump is placed in the Create event of the object Ball. In the Step event in the object Arrow, it is to move towards the ball and back through change states of the variable Jump..... i.e Jump=1 and Jump=0. This action is to be done through the KEY PRESS and KEY RELEASE of the letter J in the object Ball.



Although it runs perfectly in Game Maker, we see a problem in ENIGMA in that when you press 'J' on the keyboard the ball moves and not the arrow. My concern is the placement of objects.  When I remove the arrow object, the ball is in the correct place. When placed back in, chaos returns. It seems then the arrow object or rather the code, is the problem.



https://imgur.com/9yNtyh8


I rewrote the object ball to this:

https://imgur.com/DH8naJv

and there you have it.

I believe this shows that there is no bug. I can't be sure but I believe it has to do with how ENIGMA interprets GM code as well as bad code writing. No fault on the coder. We all make mistakes and we're not perfect coders.

[HitCoder]

I believe this shows that there is no bug. I can't be sure but I believe it has to do with how ENIGMA interprets GM code as well as bad code writing. No fault on the coder. We all make mistakes and we're not perfect coders.

I'm still going to have to agree to disagree; while I see no reason to revert such changes which have caused this "bug", since there can still be workarounds due to code logic, the bug present is that the with(object) method of the variable tester is carried through to the jump to position function. This is not how Game Maker's logic is supposed to function in terms of using these drag-and-drop blocks, due to every single one requiring a reference, or control from said object, being newly specified each time.

In this case, I don't think it's necessarily a bug, but, I would not say it is an "incorrect" way of programming it. It is not "bad code writing", as taking such an approach doesn't necessarily make it inferior. It's just another approach that works fine in Game Maker, but Enigma handles the logic differently.

Though, because of discrepencies like this, I personally stick with using GML/EDL rather than using the drag-and-drop blocks, and I personally treat Enigma and Game Maker as different engines/programs/software/tools entirely, despite having identical interfaces and very very similar logic.

[hpg678]

Ok........ so maybe I came off a bit brazen and critical in my comments about 'bad coding' and some other things i've written. My intention was not to be that way. I apologize.

My intent was to show a more efficient way to solve the problem but somewhere I got carried away. Again I apologize.

I too prefer to use GML/EDL over DRAG N DROP, although at times it becomes necessary to use it. i also Believe I may have misread some of your comments.

Lastly i want to clear up what you may be perceiving as a misunderstanding on your part. I do not consider you in the same class of people whom "I believe it is a tad too much for one to expect GM files to be that compliant with ENIGMA without some type of error at some time". i was generalizing since based on people's past comments on this forum, Game Maker's forum and other places I had researched, that was commonality among them.

i have the deepest praise for ENIGMA and its creators. I think its a brilliant, wonderful and fantastic piece of software. The fact that it is compliant with Game Maker which i spent the majority of my life learning, as well as being able to run on LINUX, is an added bonus.

[Hoohee]

While it's not like every game creation program has to work exactly like Game Maker, it should work exactly like its own internal documentation says it will.  So if there's a workaround and it works so well that no reversion of the program is necessary, at least the text in the drag and drop interface should probably be changed a bit.