GMLscripts.com

Discuss and collaborate on GML scripts
Invert

You are not logged in.

#1 Re: GML Creations » Yet Another Idiotic Light and Shadow Engine » 2012-01-17 23:03:26

If it helps, your reply had me in fits. About as subtle as a brick through a window biggrin And fair enough too.

#2 Re: Off Topic » future unimprovement of gamemaker » 2011-08-20 09:15:24

@Paul to clarify, you may still be missing my point.

I agree with you, the syntax structure {} is far cleaner than using functions. The problem I have with it is that it is not intuitive in the current GameMaker frame work. It would be adding a new syntax to an already mashed up language. If Mike wants the structures to be defined in curley braces he should make ALL resources done in that way. Do you see what I mean? That way anyone learning GameMaker (It is a learning tool after all) only needs to learn one syntax structure and then they can apply it to lots of different things.
Sorry for the diversion, wont happen again biggrin

#3 Re: Off Topic » future unimprovement of gamemaker » 2011-08-12 06:59:59

however I for one am eagerly waiting for this feature to be added

Don't get me wrong, I am really looking forward to structures too! And it's not that I don't understand the syntax, it works great in something of a C++ framework. The issue I have is if Mike Implements structures in GameMaker with the same syntax that is used in C++ because it would be adding another layer of complexity to an already mashed up language. Structures should be implemented as a resource, as that is the GameMaker flow. Thus I think they should be treated as such

Expand// Instead of this 

struct MessyCode 
{
    // structure code here
}

// It should be like this

MessyCode = structure_add()
instance_create(x,y,MessyCode)
structure_delete(MessyCode)

Something like the above is what I mean, I feel like it would integrate better with the current frame work. On a side note, I feel constants and triggers are also handled poorly as they are not in the left-hand menu with all the other resources and are hidden away for users to stumble upon. Both need to be moved out into the menu with the other resources, and in addition I think constants could be turned into constant groups, (Enums?) that'd make them more useful IMO... But I dunno, each to their own. I just feel that doing everything in the same or at least similar way is the way to a more intuitive program, and thus a far better program.

What on earth will happen to the sprite_create_from_ functions? They are such a pain in the **** to use when you have to use them in the draw event. Ugh, all I want to do is load my sprites at the start of the room. I am disappointed in this decision to be honest. Surely it wouldn't be too much to ask to still allow drawing in the other events, even if they make it painfully slow? That way at least we still have the option if we really need it. I got GameMaker because it just gets out of the way and lets you do your thing, now it's sounding more and more like its gonna get all fussy on me, and I don't like that.

On the flip side, Mike has A LOT more experience than me and he knows what he's doing. It will be interesting to see what sort of repercussions this has... Only time will tell.

EDIT: Oh and if you read my other post before this one you'll notice my opinion shift quite drastically, that's because I have spent the last couple of days writing code with all drawing in the draw events and I am now officially frustrated haha.

#4 Re: Off Topic » future unimprovement of gamemaker » 2011-08-04 09:15:31

OK. It does appear that all drawing will have to happen during the draw event in the next major version of GM.

This is interesting, it's the first major change to GML that I've experienced while working with GameMaker and you know what? This doesn't bother me. If anything it's more intuitive for beginners to see all drawing happen in one place plus the debugging tools should get better with time so hopefully refreshing the screen to check how a variable is going will be a thing of the past.

One thing that I hope hope hope gets taking into account here is the design of GML itself. All events are set up to respond in a uniform way atm. If they are only allowing drawing in the draw event I feel there needs to be a clear indication that that event is different. For instance, perhaps the object events box gets divided into 2 areas, one contains the draw/create and possibly step events that can't be deleted (even if they're empty) and then the other events are separated as they are something different altogther.

29x9ncp.jpg

Another alternative is that the draw event is opened like the creation code of a room, a separate thing altogether rather than an event. I fear that a lot of GameMaker is simply getting tacked together at this stage, I do not think this is the way a program for beginners should be approached.. I dunno usually I hate people discussing what Yoyo should do as it seems so arrogant but I can't keep my nose out of this one. It's like how Mike wanted to introduce a COMPLETELY different syntax for structures... Yes beginners wont use it anyway, but even so, even pros like stuff to be done in a sensible way, if rules HAVE to be introduced they need to be communicated clearly...

Oh well I'll be interested to see where this all goes but to be honest, I hope Yoyo have taken a good look at how the software is designed and come up with something elegant.

#5 Re: GML Code Help » Collision detection for verlet physics *** SOLVED THANK YOU XOT *** » 2011-07-16 06:08:33

One thing I don't think I pointed out enough with this is that all credit for the collision detection is owed to papalazaru of gamedev.net. I am not confident that it's the best technique, but I just wanted to get something working haha. Why rewrite something that already exists right?

EDIT: Ditto  \/ \/ \/

#6 Re: GML Code Help » Collision detection for verlet physics *** SOLVED THANK YOU XOT *** » 2011-07-16 04:50:35

XOT I LOVE YOU! That has been giving me hell! For so long! I might cry... I'll do it... I'll cry... Thank you so much! smile smile smile

#7 GML Code Help » Collision detection for verlet physics *** SOLVED THANK YOU XOT *** » 2011-07-15 21:06:14

Rani_sputnik
Replies: 5

Right so all you need to know is this is collision detection for a verlet physics engine. This particular section is for moving particles colliding with moving constraints. I've found code that works on GameDev (Written in C++) and I've translated it into GML. But I must have made a tiny muck up somewhere along the way. I can't see it though, so can someone please have a look over this and let me know what could be going wrong? What should happen is some collisions should be missed, but the vast majority found (They should only be missed when the discriminant is very close to 0, in practical terms it means the particle has crossed the constraint's axis either twice very quickly or once only),

What happens is that bodies collide very often even when they are far away, because of this I have a feeling the problem lies in the variable u (towards the bottom). What this variable should do is cut out any 'collisions' with the infinete axis AB rather than the finite line segment AB, hence why I feel it is the problem, it's the only reason I can think of for the bodies colliding when they aren't even close to one another. I'm afraid that's as specific as I can be, I haven't found any patterns as yet. Anyways here's the code

Spoiler
Expand// Source code that works
    Vector AP = Pold - Aold;
    Vector AB = Bold - Aold;
    Vector Vp = Pnew - Pold;
    Vector Va = Anew - Aold;
    Vector Vb = Bnew - Bold;
    Vector Vap = Vp - Va;
    Vector Vab = Vb - Va;
Expand// My code
var APx,APy,ABx,ABy;
APx  = Poldx - Aoldx
APy  = Poldy - Aoldy
ABx  = Boldx - Aoldx
ABy  = Boldy - Aoldy
var Vpx,Vpy,Vax,Vay,Vbx,Vby;
Vpx  = Pnewx - Poldx
Vpy  = Pnewy - Poldy
Vax  = Anewx - Aoldx
Vay  = Anewy - Aoldy
Vbx  = Bnewx - Boldx
Vby  = Bnewy - Boldy
var Vapx,Vapy,Vabx,Vaby;
Vapx = Vpx - Vax
Vapy = Vpy - Vay
Vabx = Vbx - Vax
Vaby = Vby - Vay
Spoiler
Expand// Source Code
    double a = (Vap.x * Vab.y) - (Vap.y * Vab.x);
    double b = (AP.x*Vab.y + AB.y*Vap.x) - (AP.y*Vab.x + AB.x*Vap.y);
    double c = (AP.x * AB.y) - (AP.y * AB.x);
    double d = (b*b - 4*a*c);
	double t;

	
	if (fabs(a) < 0.00001f)
		return ParticleSegmentCollide(Pold, Pnew, Aold, Bold);

    if(d < 0.0f) 
        return false;
Expand// My code
// Quadratic formula
var qa,qb,qc,qd;
qa = (Vapx * Vaby) - (Vapy * Vabx)
qb = (APx*Vaby + ABy*Vapx) - (APy*Vabx + ABx*Vapy)
qc = (APx * ABy) - (APy * ABx)
qd = (qb*qb - 4*qa*qc)

// For now this just returns false - should be a script
if abs(qa) < 0.00001 then return false
if qd < 0 then return false
Spoiler
Expand// Source code

    double t0 = (-b - sqrt(d)) / (2.0f * a);
    double t1 = (-b + sqrt(d)) / (2.0f * a);
    double tmin = (t1 < t0)? t1 : t0;
    double tmax = (t1 > t0)? t1 : t0;
    
    if(tmin > 1.0f || tmax < 0.0f) 
        return false;

    double  tcoll = (tmin < 0.0f)? tmax : tmin;

    if(tcoll > 1.0f || tcoll < 0.0f) 
        return false;
Expand// My code
// Finding the two solutions
var t0,t1,tmin,tmax,tcoll;
t0 = (-qb - sqrt(qd)) / (2 * qa)
t1 = (-qb + sqrt(qd)) / (2 * qa)
tmin = min(t0,t1)
tmax = max(t0,t1)

if tmin > 1 or tmax < 0 then return false
if tmin < 0 tcoll = tmax else tcoll = tmin
if tcoll > 1 or tcoll < 0 then return false
Spoiler
Expand// Source code
    Vector Pcoll = Pold + Vp * tcoll;
    Vector Acoll = Aold + Va * tcoll;
    Vector Bcoll = Bold + Vb * tcoll;
    
    AP = Pcoll - Acoll;
    AB = Bcoll - Acoll;

    double u = (AP * AB) / (AB * AB); // '*' = dot product!
   
    if (u < 0.0f || u > 1.0f) 
        return false;
Expand// My code
var Pcollx,Pcolly,Acollx,Acolly,Bcollx,Bcolly;
Pcollx = Poldx + Vpx * tcoll
Pcolly = Poldy + Vpy * tcoll
Acollx = Aoldx + Vax * tcoll
Acolly = Aoldy + Vay * tcoll
Bcollx = Boldx + Vbx * tcoll
Bcolly = Boldy + Vby * tcoll

APx = Pcollx - Acollx
APy = Pcolly - Acolly
ABx = Bcollx - Acollx
ABy = Bcolly - Acolly

var u;
// Is the point on the finite line
u = dot_product(APx,APy,ABx,ABy) / dot_product(ABx,ABy,ABx,ABy)
if u<0 or u>1 then return false

Just a heads up I can read C++ okay, I can't code it, so please speak BASIC to me (Ahahahahah get it?) Man I'm lame, thank you so much to anyone who looks this over.

I'm not fussed about people getting the source for this because so far I haven't done anything that original, so here we go...
Here's the link to what I've done
Also this is where I got the C++ code from,
I downloaded the first example that Papalazaru gave, (The working one).

With my example, yes the drawing is messed up I did it to check the engine checks each particle and constraint, and when it detects a collision is found it'll call keyboard_wait() so if it freezes - it's found a collision but you can keep it going but pressing any button.

#8 Re: GML Creations » Yet Another Idiotic Light and Shadow Engine » 2011-06-12 01:43:57

Lmao okay to defend my seemingly idiotic coding practises just for a second... biggrin

Creating/deleting in each step - If I'm writing a script I like to make it as self contained as possible, therefore it's nice just to set up a temp surface, it's no problem for this situation where I'm writing the engine for my own use, but it could hit me again in the future, I'll come nagging to you xot if it does tongue tehe

I have to wonder how querying the dimensions of non-existent surfaces could ever useful. I can't really fault Game Maker for that "issue".

Okay I know how it looks *hands in air in protest* but at the time I didn't know the surface was non-existent, probably should've mentioned that...

Some of the drawing functions change drawing settings. For instance, drawing a sprite will disable texture repeating. Targeting a surface will probably change the screen projection. You maybe experiencing similar issues. You may have to ensure your drawing settings are reset correctly after using certain functions. You certainly should not be trying to manipulate surfaces during the draw event.

Oooh more stuff I didn't know. The surfaces/draw event thing I was aware of but I had no idea drawing spites changed texture repeating. Interesting... I am in awe of how much you know about Gamemaker, just wow. I found something out though! I don't know if this is already common knowledge or not but I was having some issues with flickering around the shadows, turned out it was rounding error from mouse_x and mouse_y, it seems that using window_mouse_get_x is way more accurate than mouse_x, I was proud of myself for discovering that so can we all pretend that nobody else knew? Haha.

On topic - Engine is going okay, I have stuff working fine, except for when I try to draw a sprite for the lighting, some kind of scaling issue. I might try get something uploaded tonight for anyone who's interested.

Cheers!

EDIT: Not at all proud of my work yet, it's horribly un-optimised, but have at it. I'm not gonna be able to work on it til after exams anyways...

#9 Re: GML Creations » Yet Another Idiotic Light and Shadow Engine » 2011-06-10 23:55:28

I figured this was the way you probably wanted to do it in the first place, but unfortunately there are a couple of problems.

Turns out the surface *fix* that was supposed to sort out drawing surfaces in 3d is not all it's cracked up to be, trying to implement this engine is such a pain in the **** because of all the little exceptions there are surrounding how these things work. For instance, it would appear that creating surfaces and using them on the fly in 3d is not allowed. I haven't tested thoroughly yet but the exact same code, one using a surface created and destroyed in the step/draw event and one using a surface created in the create event, perform in completely different ways. Creating them in the step/draw leads to all sorts of depth issues when drawing any other geometry.... grr. That's one issue, there's another one where surface_get_width was giving me random values even though the surface I was giving it was actually non-existant. Though I can't reproduce that one so it might have been my fault...

All complaints aside it runs at about 280fps with 115 cubes on the screen, so not too bad, I don't think it's much faster though tbh, certainly not at this stage, but I'll upload it once I get it to a stage I am comfortable with. Please let me know if I'm treading on your turf a bit to much though xot, this was your idea pretty much after all...

#10 Re: GML Creations » Yet Another Idiotic Light and Shadow Engine » 2011-06-10 19:28:00

Yeah I remember I tried this out ages ago and looking through this topic was what convinced me to sign up to gmljoint in the first place. Theres so much innovation in your work, as much as I wish I could just pick up where you left off, there's no way my efforts would come anywhere near what you can achieve... smile I'm gonna be writing my own version of this to help me understand it, hopefully it all goes well... I'll edit here with any problems I encounter.

Thanks for the info and the support, Ryan

I was sitting here wondering how you knew my name, then I realised I signed my post with it XD, that's too funny. Anyways more to the point, thank YOU for such an inspiring topic, I can't stand it when people complain "Gamemaker sucks! it's too slow," etc. It's just fast enough imo.

EDIT:
Oooookay I've ended up going a similar but completely different way to you. The way I do it is I take a top down perspective of the environment for each light but I extend the geometry so that it's height is ridiculous. The simple act of looking at the geometry, drawn in black, from above when the geometry has near infinite height gives me the shadow map. smile Now to optimise and see if this is actually anywhere near as good as yours.... *Clings to hope desperately*

#11 Re: GML Creations » Yet Another Idiotic Light and Shadow Engine » 2011-06-10 07:30:19

Hey xot I hope you're still working on this, it is absolutely incredible and with the 3d improvements to GM8.1 it's made it even faster.

With blurring set to 2, All lights at dynamic, Flickering etc all the bells and whistles I get a guaranteed 150fps and it's usually hovering around 175,
With everything fleshed out, kill enabled etc i get well over 400fps!!!

I'm running a NVidea Quadro FX1800M -> sucks for Game Maker smile

Please continue with this, it's brilliant.
Ryan.

#12 Re: GML Creations » Today I hijacked the zbuffer. » 2011-05-30 21:45:09

I wonder what sort of practical uses a 3D Voronoi diagram would have.

It makes frieken sweet models! smile Also I'm thinking I would do some kind of destructible terrain thing with it, where that land is made up of point masses and the mesh is extracted from the points - similar to what you do with surface extraction in a liquid.

Yeah, most definitely a 3d 'raster' voxel thing (Is that what I should call it?) is a bad idea with conventional geometry, I agree now 100% I guess that's me desperately hoping for a way around doing math *sighs.

#13 Re: Script Submission » voronoi diagrams » 2011-05-27 09:12:49

Wow there are people that study this? I didn't think it was that common. Sweet, I feel like a bit of a read haha. Cheers guys.

#14 Re: GML Creations » Today I hijacked the zbuffer. » 2011-05-26 07:40:53

Lmao I literally just submitted the same thing to the script submission page! It would seem great minds think alike tongue Very nifty I'm downloading now to see if you have any little speed ups I can add to mine, haha.

I hope this isn't too topic hi-jacky-y but anyone care to speculate on a 3d voronoi grid of this nature? I'd be keen to hear ideas (because incidentally it's what I'm moving on to next). The problem with the depth buffer method is that you need a higher order of dimension because you are effectively taking cross sections in a strange way. To do the same thing in 3d you'd need some kind of voxel renderer or something... and that's where the breadcrumbs end...

Anyway, sorry for the sort-of-divergent conversation, great work man smile

#15 Script Submission » voronoi diagrams » 2011-05-26 07:25:57

Rani_sputnik
Replies: 4

Voronoi diagrams take a bunch of points and calculate the closest point to each pixel/position/whatever. I found a use for them making pretty pictures smile  Mostly I wanted to post this for analysing because I need it to be as fast as possible (who doesn't?) and I think it's pretty much there. Basically it just jumps into 3d and draws a cone at each position on the grid, then the depth buffer does all the work of finding the intersections. Enjoy:

Expand// vor_create_from_object(obj,x,y,w,h,maxdist,precision)
// Creates a voronoi diagram using all instances of the object obj and their positions
// within the region x,y,width,height
// maxdist refers to how far the instances we be apart, if any instances are beyond
// this distance apart there will be dead zones on the surface
// Returns a surface that has pointers to the instances id
// precision refers to the quality of the diagram 
// Script by Rani_sputnik

var s,d;
s = surface_create(argument3,argument4)
d = draw_get_color()

d3d_start()
d3d_set_perspective(false)
d3d_set_projection_ortho(argument1,argument2,argument3,argument4,0)

surface_set_target(s)
draw_clear(0)
var n; n=0
repeat instance_number(argument0)
{
    i = instance_find(argument0,n)
    draw_set_color(i-100000)
    d3d_draw_cone(i.x-argument5,i.y-argument5,argument5,  i.x+argument5,i.y+argument5,0, -1,1,1,false,argument6)
    n += 1
}

surface_reset_target()
draw_set_color(d)
d3d_end()

return s

Note that I had to set it so that the colours drawn onto the voronoi surface are set to the instance id - 100000. Not that this is a big issue but I was pretty sure that there are 16 million+ colours, anyone got a reason as to why this could be happening? Cheers in advance smile

EDIT: NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO

I just rolled on over to the creations topic and this was the first thing I saw listed by Daniel! I felt so smart, now I just feel like a copy-cat sad sad sad

#16 Re: GML Creations » CHALLENGE: Conway's Game of Life » 2011-05-04 20:53:14

Hmm, but if you made a two surfaces (room_width,room_height/2+1) then couldn't you have the same row, on each surface stored in the seperate colours to prevent slow downs?

But don't get me wrong, I don't think it's worth the effort any more at all, I am merely curious. I just read your draw_set_blend_mode topic and I finally understand blend modes! So hopefully I can now have a bit of a play around. Cheers xot!

#17 Re: GML Creations » CHALLENGE: Conway's Game of Life » 2011-05-03 20:25:35

Cheers for clearing that up xot. Is there any reason for that? it seems not so sensible to me...

Apologies for my impending stupid, I promise I'm smart! I'm sure one day I'll contribute something valuable to the forums.
Today is not that day, today I make naive suggestions:

I see how you run three channels seperately and that makes me think that couldn't that be used to reduce memory footprint?
Idea - Use them on the same grid?
What I'm thinking is that the red channel simulates the top half of the room the green channel the bottom half. Ideally (though I can't think of how this could be posible in Game Maker), we'd have four channels RGBA and divide the grid into quarters. Now I know that getting the RG top-bottom sim to work is possible, xot proved that, but what I can't work out is how to seperate them so that they are drawn in two seperate places. My questions are these...

1 - Manipulating alpha channel in Game Maker? Comments? Suggestions? (Nice broad one to start off with)
2 - Is my suggested change worth it? Say we were porting to an iOS device and we need all the memory we can get, will this change slow down the engine too much? I know it will slow it down a tiny bit at least. Actually, will you need to add another surface for this? hmm only just thought of that...
3 - ... Oh I only had two questions.

Sorry for the onslought of requests but you allnknow so much, I MUST LEARN.... *twitch smile

#18 Re: GML Creations » CHALLENGE: Conway's Game of Life » 2011-05-03 10:19:54

Sorry this is a bit off topic but does anyone know why the draw_clear and draw_clear_alpha() functions break xot's method? I tried to replace the primitive code because it was after all just drawing a rectangle over the whole scene but yeah, draw_clear doesn't work. Does it not respond to blend modes?

Board footer

Powered by FluxBB