Hello Guest, please login or register.
Did you miss your activation email?
Login with username, password and session length.

Pages: 1 [2] 3   Go Down

Author Topic: Getting Started  (Read 7998 times)

0 Members and 1 Guest are viewing this topic.
Re: Getting Started
« Reply #20 on: March 28, 2009, 11:37:50 pm »
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Posts: 728
I decided to at least upload a .exe of what I was working on. Nice avy 4sword btw.
Logged
  • Pyxosoft
Re: Getting Started
« Reply #21 on: March 29, 2009, 01:06:26 am »
  • *
  • Reputation: +3/-0
  • Offline Offline
  • Gender: Male
  • Posts: 3374
Still, I don't think you should compromise what's already there just so people with GM lite can use it. I know it brings it to more people, but it works well atm.
As for the shadow, we are trying to make it MC style, right? Just draw the shadow with some alpha and blend it black or something, that'd work.
Logged
Quote from: Jason
Your community is a bunch of stuck up turds.
Re: Getting Started
« Reply #22 on: March 29, 2009, 01:53:36 am »
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Posts: 728
Yeah, I agree, I'd rather use the pro version. As for the shadows. The way I'm doing it right now is the closest to MC style. Hell, I'd gladly do what you said. Make it black and alpha blend, because it's what I did with my original LA engine. However, that would not be MC style.

I have an example of what I described earlier. But you don't have to take my word for it, pull your emu out and play for a bit.
Logged
  • Pyxosoft
Re: Getting Started
« Reply #23 on: April 02, 2009, 10:44:36 pm »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6604
Sorry, I have gotten really busy. I have Linear Algebra homework due Monday, a Stats test next week on Tuesday, and programming assignment due Wednesday, Unix homework due by that week Thursday possibly, and other things as well - figuring out if I am still in the Honor's program technically and then if I am making one of my programming classes an honor's one next semester.

Anyway, with the shadows, they will be a solid color due to how it is done in the Minish Cap. Not only is it authentic, but in terms of Game Maker, it would be easier to implement. Anyway, I was tinkering around and trying to get the concept worked out for how sprites/animations could be reused by dividing up certain animations based on common elements.

In Link without the hat and Link with the hat standing, there is a pixel difference in the hair line which if not there would make some of the divisions easier - that is not to say that the change should be made to correct this. The concept of dividing certain animations up still works, I am just also trying to get it efficient - a problem encountered is that Game Maker does transparency by the lower-left pixel, which is pain in the ass if you take it for granted.

Currently I am trying to finish up the standing and walking with this concept (taking into account how holding works into the animation divisions), Xfixium's blinking, and working in either a "states" or multiple Link object way of handling actions. Chances are we are going to build off of Goodnight's walking engine as well - a while ago I made some tweaks to it which I think handle sprite correction better as well.
Logged
Re: Getting Started
« Reply #24 on: April 03, 2009, 11:36:52 pm »
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Posts: 728
Sounds great, can't wait to get some direction here so we can progress. I worked on debugging the dialog scripts in my test project. I found that putting 2 tags in a row made some new problems so I fixed that. I also made it more encapsulated, and customizable. I like the suggestions you made, and it will be fun to implement them.
Logged
  • Pyxosoft
Re: Getting Started
« Reply #25 on: April 05, 2009, 09:07:58 am »
  • *
  • Reputation: +0/-0
  • Offline Offline
  • Posts: 2245
Just inserting my opinion here.. but how far ingrained is the code that requries the pro version?
Would it be possible write all the pro code in a way where it can be easily disabled if necessary (like using an contant), so those using the lite version can still code, if its all graphical effects and stuff, I presume that most people coding could forgo those sorts of things.
Logged
Re: Getting Started
« Reply #26 on: April 05, 2009, 04:57:25 pm »
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Posts: 728
Well, with the source I wrote, here are the Pro functions used:

The dialog object uses surface functions for all the drawing.
The script scr_clear_surface uses surface code.
Use of draw_background_ext in dialog code for when the dialog background is scaled.
Use of data structures for globals, like an item list.
The use of draw_sprite_ext for the shadow color blending.
Use of data structures for dialog default images.

I'm sure this can be re-worked for a lite version. The dialog script will suffer the most. The data structures can be replaced with arrays with some speed sacrificed.
Logged
  • Pyxosoft
Re: Getting Started
« Reply #27 on: April 05, 2009, 05:49:16 pm »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6604
Personally I think that the Lite version should be what is primarily developed for. We could have it though so people could download different "implementations" for the Lite/Pro versions of certain things; this assumes that a call to a function to draw something like a text box could be written with the same number of arguments and produce a same result (albeit some of the resources might be different and possibly other scripts needed).

I am a little unsure of how the data structures work but meh; a lot of it seems to be with things relating to text. The shadow blending can be handled by a multiple image shadow sprite with Link's drawing of the shadow draw differently the sub-image depending on a variable.

Also, I was working on the movement code and trying to make it similar. I found that because Game Maker treats key statuses as boolean and numerical value, you can do logic and operational properties better. Looking at Goodnight's code, he takes advantage of this in some places, but not in all. Here is the current code I was working on (for Link's step event):

Code: [Select]
var hold_u, hold_d, hold_l, hold_r, move_count, move_step;

hold_u = keyboard_check(vk_up);
hold_d = keyboard_check(vk_down);
hold_l = keyboard_check(vk_left);
hold_r = keyboard_check(vk_right);

if (hold_u == 1 && hold_d == 1){
  hold_u = 0; hold_d = 0;
}

if (hold_l == 1 && hold_r == 1){
  hold_l = 0; hold_r = 0;
}

switch (hold_u + hold_d + hold_l + hold_r){
  case 2: move_step = sqrt(2); break;
  case 1: move_step = 1; break;
  case 0: move_step = 0; break;
}

move_count = move_speed;

if (move_step != 0){
  while (move_count >= 1){
    if (place_free(x + hold_r - hold_l,y)){
      x += hold_r - hold_l;
    }
    else if (hold_u + hold_d == 0){
     
    }
   
    if (place_free(x,y + hold_d - hold_u)){
      y += hold_d - hold_u;
    }
    else if (hold_l + hold_r == 0){
   
    }
   
    move_count -= move_step;
  }
}

A key to the concept I mentioned above only works with prioritized movement effectively. Because pressing up and down cancels them out, the only possible values that pressing all directional keys can attain is either 0, 1, or 2.

What the code needs to finish though is the corner cutting. I do not think that you need a for-loop for it per-say. I am still trying to figure out that - it comes down to if you bounding boxes aren't overlapping but will be if you move then you stop (if you run smack into it), if your bounding boxes do overlap and you move then it will determine your position in relation to the colliding objects bounding box and yours (you hit it off-smack).

If you are going down, for example, if you hit it perfectly you run in place. If you hit it off-perfectly, the code checks to see if you are pressing left or right (if you are on the left of the colliding object, pressing left will make you still go correctly, but if you go right you stop - just like in the Minish Cap). If you are just pressing down though and you are off-perfectly, the code adjusts your move_step value and should just move you in a left or right direction by one each step.
Logged
Re: Getting Started
« Reply #28 on: April 07, 2009, 11:37:33 pm »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6604
Anyone have luck with getting my movement code to include corner cutting? If so, it would save a lot of code complexity compared to Goodnight's version (at least I would think so, even the direction checking corrections could possibly be reduced).

I will be able to work more on this Wednesday night, unless I decide to go to a Shakespeare Twelfth Night show in Chicago - I probably won't because I will be pulling an all-nighter for tomorrow's homework that I have due.
Logged
Re: Getting Started
« Reply #29 on: April 11, 2009, 03:39:47 am »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6604
Anyway, I worked on the movement code a bit and like I thought I was able to reduce the code's overall length and if I am thinking about it right, it's code complexity and possibly it's big O notation (w00t). Here is some new code (still needs the corner-cutting, I know how to implement it, but it is not fully ready done):

Code: [Select]
var hold_u, hold_d, hold_l, hold_r, move_count, move_step;

hold_u = keyboard_check(vk_up);
hold_d = keyboard_check(vk_down);
hold_l = keyboard_check(vk_left);
hold_r = keyboard_check(vk_right);

if (hold_u && hold_d){
  hold_u = 0; hold_d = 0;
}

if (hold_l && hold_r){
  hold_l = 0; hold_r = 0;
}

switch (hold_u + hold_d + hold_l + hold_r){
  case 2:
    move_step = sqrt(2); is_moving = true;
    switch (facing){
      case "U":
        if (hold_d)
          facing = "D";
        break;
      case "D":
        if (hold_u)
          facing = "U";
        break;
      case "L":
        if (hold_r)
          facing = "R";
        break;
      case "R":
        if (hold_l)
          facing = "L";
        break;
    }
    break;
  case 1:
    move_step = 1; is_moving = true;
    if (hold_u)
      facing = "U";
    else if (hold_d)
      facing = "D";
    else if (hold_l)
      facing = "L";
    else if (hold_r)
      facing = "R";
    break;
  case 0:
    move_step = 0; is_moving = false;
    break;
}

move_count = move_speed;

if (move_step != 0){
  while (move_count >= 1){
    if (place_free(x + hold_r - hold_l,y))
      x += hold_r - hold_l;
    else if (hold_u + hold_d == 0){

    }
   
    if (place_free(x,y + hold_d - hold_u))
      y += hold_d - hold_u;
    else if (hold_l + hold_r == 0){

    }
   
    move_count -= move_step;
  }
}

About the corner cutting though:
1) It checks to happen if your next place is blocked by something
2) If, for example, you are going up and pressing left or right and the left place is not blocked, moving right makes you collide with a diagonal orthogonal to your motion, moving left does the corner cutting for you).
3) If with the previous example you were not pressing left or right, if your bounding box was not overlapped already with the collision objects, you wouldn't do anything (you are hitting a flat surface head on), but if it was overlapped, you would then do the corner cutting (you are hitting something off-center which is what corner cutting corrects)

I think that that logic explains the crux of the code.
Logged
Re: Getting Started
« Reply #30 on: April 11, 2009, 04:22:51 am »
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Posts: 728
The code seems to work perfectly. However, I am having trouble with the move speed. Originally, I calculated 1.5 as the move speed for Link at 60 fps. However the script seems to ignore fractions. There is a big difference between 1 and 2 on the move_speed variable. Both not close to the MC engine. Either too slow or too fast. I tested the script on 30 fps, and there seems to be more control over this, but with animation choppiness.

Link does have the correct feel when he collides with a solid, more so than the old code. It just needs some tweaking.
Logged
  • Pyxosoft

Xiphirx

wat
Re: Getting Started
« Reply #31 on: April 11, 2009, 04:35:58 am »
  • Xiphirx
  • *
  • Reputation: +0/-0
  • Offline Offline
  • Gender: Male
  • Posts: 3007
I like the way you think in your algorithms 4sword. It's intriguing to me :P
Logged
  • For The Swarm
Re: Getting Started
« Reply #32 on: April 11, 2009, 05:25:33 am »
  • *
  • Reputation: +3/-0
  • Offline Offline
  • Gender: Male
  • Posts: 3374
keep it at 60 fps, I can't stand how choppy 30 is >_>
Logged
Quote from: Jason
Your community is a bunch of stuck up turds.
Re: Getting Started
« Reply #33 on: April 11, 2009, 05:48:26 am »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6604
I had the move_speed set at 3, the image_speed at 0.5, and the game speed set at 30 frames per second. I wasn't sure if running 60 frames per second would be work well on many machines at consistent levels.

Anyway, I looked into it and the error with fractions is an error on my part. In Goodnight's original version, the movement was move of a "continuous" process while mine was based on "potential" based on move_speed. Essentially, I think, all mine was doing at a speed of 3 diagonally was moving 2 lol. The likelihood is that I was doing it wrong. I have corrected it in my code but I am looking into how and if changing movement from non-diagonal to diagonal causes problems because of the decimal poop - if the decimal poop is negative, I am looking into how that affects the number of times the loop iterates.

I like the way you think in your algorithms 4sword. It's intriguing to me :P

Meh, the only thing neat about my algorithm was how diagonal/non-diagonal/and no movement could be related through knowing that all the keys added up when prioritized could only be 0, 1, or 2. It just shortened the code and allowed some things to be combined when now possible - which also reduced the conditions when the events would be checked or that the same condition wouldn't be checked twice.
Logged
Re: Getting Started
« Reply #34 on: April 11, 2009, 02:25:40 pm »
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Posts: 728
lol, nice. Great to see that you have an eye for things. 3 works just fine as Link's movement speed at 30fps. Which makes sense when you bring it up to 60. 1.5 being half that amount. I wonder if we can make the move speed and image speeds relative to the fps? Perhaps then we can give an option on the fps of the game.
Logged
  • Pyxosoft
Re: Getting Started
« Reply #35 on: April 11, 2009, 02:43:26 pm »
  • *
  • Reputation: +3/-0
  • Offline Offline
  • Gender: Male
  • Posts: 3374
lol, nice. Great to see that you have an eye for things. 3 works just fine as Link's movement speed at 30fps. Which makes sense when you bring it up to 60. 1.5 being half that amount. I wonder if we can make the move speed and image speeds relative to the fps? Perhaps then we can give an option on the fps of the game.
easy, just add the room speed to all the equations. Don't know how that would affect performance though. and if collisions aren't programmed correctly they'd mess up too.
Logged
Quote from: Jason
Your community is a bunch of stuck up turds.
Re: Getting Started
« Reply #36 on: April 11, 2009, 02:58:01 pm »
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Posts: 728
Quote
I wonder if we can make the move speed and image speeds relative to the fps?

Maybe I should have put "should" in there instead of "can". :)
Logged
  • Pyxosoft
Re: Getting Started
« Reply #37 on: April 13, 2009, 11:49:32 pm »
  • Doesn't afraid of anything
  • *
  • Reputation: +42/-0
  • Offline Offline
  • Gender: Male
  • Posts: 7002
That shouldn't be too difficult.  Just have some script that changes the speeds on the room start based on what the selected fps is.  I haven't gotten a chance to look at the code yet, I'm getting on that now, though.
Logged



i love big weenies and i cannot lie
Re: Getting Started
« Reply #38 on: April 14, 2009, 12:19:07 am »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6604
I have been a little busy, but here is the concept for sprites reducing redundancy (pressing "A" changes to wearing or not wearing the hat). I didn't have time to put in the sprites for left and right though. Also, you are prompted at the start of the level to set the movement speed; the actual setup of this can be altered and made more professional though.

Here is some number crunching I did with the diagonal, non-diagonal loopage, to figure out what could go wrong. There is an error I figured out, but it is minute. You see, if your move_count is negative from the result of moving diagonally and then you immediately switch to moving non-diagonally, there is a little bit of delay.

You see, if the loop which figures out the movement is positive and not above 4, it runs three times for non-diagonal movement (e.g. 3.5 2.5 1.5). If the move_count starts out negative before you add three too it before the loop you could get something like this (2.5 1.5). That indicates that there is a little delay (it corrects itself after the delay - the next loop is 3.5 2.5 1.5 which is normal, but just saying for that one movement you are delayed).

Anyway, here is some of my unfinished code (the movement is almost done. That error in the above paragraph could likely be fixed by a condition check in the hold_u + hold_d + hold_l + hold_r switch statement - the check being to see if you are moving non-diagonally and doing some kind of alteration to the movecount, such as adding a number to it or absolute valuing it (adding a number is better though and more practical - avoids a function call and the numbers we are overcoming are decimals - aka one is enough and not to much to fix it).

Without further ado, the code is in the attachment. It works in Game Maker 7 Unregistered.
Logged
Re: Getting Started
« Reply #39 on: April 14, 2009, 03:00:02 pm »
  • *
  • Reputation: +0/-0
  • Offline Offline
  • Posts: 2245
Just to restate my position on pro here, I'm not suggesting that pro code be rewritten or anything like that. I'm just suggesting that for development purposes that pro code be encapsulated within a constant that can be turned off by those developing using the lite version of game maker in order to avoid getting any pro warnings that would disrupt development and for the bits and pieces that require logic that you have a basic alternative that can be implemented in order for those that have the lite version can use that code, for example for dialog you could probably get away with using popup dialog boxes, as long as the logical flow is the same, because when developing, what it looks like is unimportant.
Logged
Pages: 1 [2] 3   Go Up

 


Contact Us | Legal | Advertise Here
2013 © ZFGC, All Rights Reserved



Page created in 0.163 seconds with 75 queries.