Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Ryan Timothy B

#1541
Oh right on.  I was editing my post while you guys were responding.  Har har.  Anyway, no idea if it would still work.  But at least Calin's works.

Gotta go!  Pig roast time.
#1542
Code: ags

function room_Load()
{
  oS1.X=0;
  oS2.X=800;
}

function room_RepExec()
{
  oS1.X-=5;
  oS2.X-=5;
  if (oS1.X<=-800) oS1.X=oS2.X+800;
  if (oS2.X<=-800) oS2.X=oS1.X+800;
}


Something like this should work, I believe.
#1543
One solution is to just use your own Int as a timer.

Where in the dialog you set a global variable to 800:
Code: ags

  timer = 800;


In the script you could do something along the lines of this:
Code: ags

if (timer>0)
{
  timer--;
  if (timer==0) doWhatever;
}


Perhaps running that in the global script repeatedly_execute if the player isn't only in that one room under this time restraint.
#1544
I see what you mean.  I used this to see if this is what you were talking about:
Code: ags

function repeatedly_execute() 
{
  if (Game.DoOnceOnly("TESTING"))
  {
    PauseGame();
    PauseGame();
    UnPauseGame();
  }
}

But if you do two UnPausegame()'s back to back, it would start working again.


I'm not sure if you could call this a glitch since it IS doing what you're telling it to do.  I could possibly see a purpose for having it not unpause in moments where you may have called pause twice or more.
It's a pesky feature. :P


In your scenario, the only thing to stop it from calling PauseGame again is to do this before calling PauseGame:
Code: ags

  if (!IsGamePaused()) PauseGame();

Edit: Now that I've read it again, it seems you already had the solution:
Quote
I fixed it by only letting the game run the function if the game isn't already paused.
#1545
General Discussion / Re: Votes for yourself?
Thu 15/07/2010 20:27:49
Your roommate is that dude in the wheelchair with what looks like cerebral palsy?
#1546
Well if you have PauseGame() running in the repeatedly_execute_always with no restrictions along with UnPauseGame() just before or after, the game would always be paused.

I have the space bar pause the game in the one I'm currently working on, and this is the code I used:

Code: ags

bool spaceIsHeld;

Code: ags

function repeatedly_execute_always() 
{  
  if (!spaceIsHeld && IsKeyPressed(eKeySpace)) 
  {
    if (!IsGamePaused())
    {
      PauseGame();
      SetSkipSpeech(2);    //this is to prevent the glitch with the mouse click skipping text during pausegame
    } 
    else 
    {
      UnPauseGame();
      SetSkipSpeech(0);    //this is to prevent the glitch with the mouse click skipping text during pausegame
    }
    spaceIsHeld=true;
  } 
  else if (!IsKeyPressed(eKeySpace)) spaceIsHeld=false;
}


The reason I put both pause and unpause in the repeatedly_execute_always, is since you may want to pause the game during blocking moments like dialog, etc.  I also needed that spaceIsHeld boolean to prevent it from pausing and unpausing each game cycle until you've released the space bar.  This way it will act like on key press.

Edit: tweaked the code slightly better
#1547
General Discussion / Re: chess?
Thu 15/07/2010 04:02:46
I imagine there is source code all around the internet for such a thing.
#1548
I'm not sure if this one has been posted before, but it's definitely a must see 3D video!

http://www.youtube.com/watch_popup?v=jEjUAnPc2VA
#1549
Also, another little hint.  You shouldn't put object visibility in the room_AfterFadeIn.  If you have have a room transition (ie: fade), the object will appear after the transition.  You'd see a sudden flash of the object appearing.

You should always put stuff like that in Room_Load, which occurs before the fade.  AfterFadeIn should be used for cutscenes and blocking events that occur when you enter.
#1550
Dualnames' code wouldn't work since DrizelMaNizel (what a name) wants the object in Room 1 to become visible once the player talks to the NPC in Room 3.


I would use a global bool.  You set it up in the global variable manager, which you can see on the side bar in the editor.  Its default value will be false.  
Pretend you named it: crazyThingVisible

So when you're in the dialog, you do something like this (note the spacing in front of the in dialog scripting - it only works with the spacing):
Code: ags

@S  // Dialog startup entry point
man: I just saw some crazy thing over there.
  crazyThingVisible = true;
return


Then when you're in the room script, you do this in the room load function.  Which in case you didn't know, you have to create it in the room editor first, you can't just copy this:
Code: ags

function room_Load()
{  
  crazyObject.Visible = crazyThingVisible;
}

Since the bool is either true or false, setting the object's visibility with one works.

Basically what Geork has posted, but I felt it was missing that little extra description to help out Drizel.
#1551
AGS Games in Production / Re: Over the Edge
Tue 13/07/2010 22:28:38
Hey, Theo, it's good to see you posting this production thread.  I almost emailed you the other day asking if you had added all that missing music yet.

This game was lots of fun to beta test, and I was completely impressed with the graphics.  If you want me to do a final beta test (that would be like the 6th or 7th beta test now. haha), I would definitely give it another go.
#1552
It's a good idea.

Quote from: Arj0n on Mon 12/07/2010 08:58:13
Darn, 261 x re-importing room-backgrounds....
I guess I also need to re-import the guy-backgrounds?
I haven't checked this program out yet.  I'm not sure what the 'guy-backgrounds' are, but I'm curious, instead of using room backgrounds why don't you just import them into the sprite manager?

That way you only have one room for the backgrounds and it loads the sprite whenever.  You'd only need to define the amount of sprites and it would be much less work for you.  It's just a thought.
#1553
Gilbet, yes I definitely did read your tests and they were very interesting.
#1554
First off M. Ouxx, I love how you're trying to explain to me how a dynamic array works.  When all I've been trying to tell you that your assumption of how AGS 'doesn't' delete sprites in a dynamic array when you recreate it is wrong.


Quote from: Monsieur OUXX on Mon 12/07/2010 08:56:48
TEST 4:
Code: ags

  test = new DynamicSprite[1];
  test[0] = DynamicSprite.CreateFromExistingSprite(0);
  test = new DynamicSprite[1];
  test[0] = DynamicSprite.CreateFromExistingSprite(0);


I believe you should see approx. the same space usage as in TEST 3.
You should see:
Space(TEST3) = space(TEST1) + 2*sprite size

Like I've mentioned in the post above, this won't store 2 instances of that sprite, with one hidden unusable in the ram.  I've tested it again and again with a very large sprite size, checking the memory usage in the task manager and it remains identical for each instance.  Unless for some reason the task manager is unreliable.



The only thing with DynamicSprites that I'm unfamiliar with, and apparently you two and probably everyone else.  When is it that you MUST delete a DynamicSprite?  Do they actually need to be deleted before you restart the game, or quit it?

I would love feedback on this one CJ. 
I was playing VinceTwelve's InfinityBit the other day and when I quit his game it created a text file with a warning of a few DynamicSprites that weren't deleted.  I on the other hand have never seen this text file with one of my games in production and I've used DynamicSprites for quite some time now.
#1555
Quote from: Vince Twelve on Sun 11/07/2010 03:24:23
One thing different between the front layer and the other nine, is that the deeper layers all use scaled sprites while the front uses unscaled.  Might that slow it way down?
If you're scaling them every game loop, I'd say that would definitely be one reason it could be so slow.

When I played it earlier it looked as though the back layers don't change at all while you're playing in the front layer.  I would be creating and scaling those layers only once during the change of each level and keeping them in memory to be used each cycle.
#1556
Hmm.. That's weird.  I've drawn approximately about 600 30x30 sprites per game loop without any slowdown on this laptop.

One thing that does speed things up is keeping the drawingsurface open the entire time you're drawing on the background, instead of opening it each time you draw a new sprite.  Which is what your code above looks like it's doing already.

Oh, and another thing that 'could' speed things up (don't quote me on this, I haven't fully tested it) is instead of using:
sprite = DynamicSprite.Create(w, h, false);
each game loop, you can save it to a DynamicSprite and just reuse it each and every time.  I'll have to give it a speed test one of these days and see if I'm right or wrong.
#1557
Okay, I've played the game very briefly just now.  I can't control the guy the way I want to at all.  He's either lightning fast or standing still, there appears to be no acceleration.  I also have no idea how to save the game and stuff, I'm always dying on the second level.  Perhaps your game thread speaks about this, I'll have to check it out and post in it later when I'm done work (on lunch right now).

I'm only getting 20 fps and my machine can run some pretty crazy AGS tests that I've done with DrawingSurfaces at the full 40fps or higher.  I'm assuming you've either lowered the gamespeed to stay at 20, or it just lags that badly with those GUI's.

Nothing as far as I've gotten appears to have alpha channel except for the outer box perhaps, but that seems to be drawn at 100% opacity even when you die and it shrinks down.  From what I've seen, it looks like you could easily draw on the room background instead of the GUI's.
#1558
Yes, I've learned that myself too.  Minimize your GUI count and you'll notice a big difference.

If it must be a GUI, why not just draw on Buttons instead.  Only 10 buttons on one GUI instead of 10 GUI's.  Or just draw on the room background as Queefshade has suggested. ;)

Although, you wouldn't be able to take advantage of 10 layers with different transparency levels by using Buttons, which could be your reason for using GUI's in the first place.  But drawing on a background you can draw with a transparency just as long as the sprite doesn't have alpha channel.
#1559
From both your responses I'm still at a loss to understand if you're saying I'm a bad programmer who isn't deleting his dynamicSprites
OR
It's an issue with AGS.

Because even doing this:
Code: ags

  test = new DynamicSprite[1];
  test[0] = DynamicSprite.CreateFromExistingSprite(0);
  test = new DynamicSprite[1];
  test[0] = DynamicSprite.CreateFromExistingSprite(0);

back to back will not cause an issue, nor will the memory usage change from this way to the other.
The dynamic array is still deleting itself, but at least this way it actually deletes the DynamicSprite on its own but just not when the game restarts.
#1560
Quote from: Gilbet V7000a on Fri 09/07/2010 13:08:28
However, from what I have read in the manual, it seems that a DynamicSprite won't be destroyed automatically when no pointer is pointing at it any more

so I'd expect the above codes would work as intended but would also cause a memory leak at the same time.
But the manual itself states:

Quote
If the DynamicSprite instance is released from memory (ie. there is no longer a DynamicSprite* variable pointing to it), then the sprite will also be removed from memory.

So with Monsieur's code, the second time it assigns the non-null value to the sprite, it removes the pointer from the original sprite and then AGS automatically deletes it.
I even tested it with:
Code: ags

  int i;
  while (i<30000) 
  {
    test = DynamicSprite.CreateFromExistingSprite(0);
    i++;
  }


And the memory usage remains the same as without the while loop (although it takes forever to finish the loop, heh).


I think it's just an overlooked issue with Dynamic arrays that CJ didn't think of.
SMF spam blocked by CleanTalk