Messages

Can there be an AGS Editor portable that can be used in a flash drive?

When a zipped version of the current engine is lacking, what I generally do is just install AGS the regular way, copy the whole folder to somewhere else (and also remove the two files in there related to the uninstaller), then deinstall the official install again. What I'm then left with is a copy of the AGS folder that works without having to install anything. Additionally I then put that folder in Dropbox so I can access it from anywhere. I've never had a problem running AGS that way.

Ha yeah I had a similar experience years ago with someone who was willing to proofread my script, and came back a day later claiming there were over 30 grammatical errors in the first paragraph alone (there weren't), and subsequently requested to have my complete source code so he could correct them. Uhmm... no.

You could try disabling the walkable area he is standing on via the script, something like

if (whatever) {
  RemoveWalkableArea(1);
}

I've noticed the poor aliasing with TTF fonts aswell, more and more now recently as the resolution of my games go up and the polish of the graphics becomes higher. Widening the font outline (or being able to set it manually) would help a lot probably, though the outlines are still kinda choppy.

Yeah I saw that, great work! After watching MOON I was totally inspired to make an adventure game aswell.

The fact that the Orange Box - a hit game made by huge company - is offered for incredibly attractive prices doesn't mean every one has to sell/buy stuff that delivers equal content per 1$ value. Not to mention that such value depends greatly on what the buyer likes, and also that someone might wish to not only pay for a game, but invest in an indie developer too.

I'm sorry if my message came off that way, I wasn't trying to compare indie developers with the production monster that is Valve, I was merely using the Orange Box as an example to point out to the creator of this game that for less $$$ than what he is charging, someone could buy plenty of games right now with astronomically higher production values than his. So how is he going to justify charging that price? Why would people spend their hard-earned money on something that looks like it was thrown together in Paint in two afternoons over something that has the potential to offer a well-designed and satisfying experience for weeks, even months, to come? Even a supporting investment in him as a developer should be backed up by some sort of evidence of his ability other than the fact that he made it through the AGS tutorial, so to speak.

But I see your point in how I was kinda comparing apples to oranges, so perhaps using Gemini Rue would have been a better choice, since the same rhetoric applies: GR's production values are so much higher than this game, yet Josh only charges half of what It's My Life is priced at. And even if the situation was reversed and GR was $30 and IML $15, GR would still be agreeably priced while this game was still way overpriced.

And that is because GR has something that IML lacks: love for the craft.

For me that is the mark of a worthwhile game, when you can feel the developer really put his heart into it, regardless of whether the genre is up my alley or not, or even if the game is without its flaws or not. That is why in my opinion Josh would have been well within his right to charge more than those 15 dollars for Gemini Rue. Whereas if Msd really loved the medium he would not have charged a dime since he would realize that he is not offering his potential customers value for their money.

So don't get me wrong, I am all for charging for your content - IF you make it worth it for the consumer. But I think we can agree on that point, and I hope Msd realizes it now too. Otherwise he is in this for all the wrong reasons.

Seconded.
I was on the fence just reading this, but $32 is a ridiculous price point. They're selling the Orange Box for even less than that, and I seriously doubt this game could deliver an experience even remotely on par with Half Life 2, Portal AND Team Fortress 2.

So good luck. I'll be interested in seeing the sales figures for this a year from now.

Woof that's a tricky one. Walkbehinds are kinda hampered by the fact they only have one horizontal baseline, so I imagine in cases like this that becomes quite a headache, because if you set the baseline near the 'bottom' of that block it will cut the character's head off when he is in front, but if you set the baseline near the top he won't be able to walk behind it down there on the left side..

I think a workaround for this might be to divide the walkbehind you have now into several different neighbouring walkbehinds with different baselines. It's not a perfect solution but atleast it'll make this problem a little less glaring.

True, that would be best-case scenario. I'll have to fiddle with it some more, use it in some real situations to see how it handles. I already found I had to add IsGamePaused as a third conditional since pausing the game only halts movement and animations. But at least for now it works great, thanks to your code

Hm ok well maybe I did it wrong then but when I modified the timerspeed in your script I observed only a minimal difference and I had to actually reduce the value to get it to go faster. And from 2 down there's not a whole lot of digits left Presumably this had to do with the fact that there the timerspeed variable is linked to counter (the delay between the rendering loop) and not to timer (the distance between the sides and the center of the rectangle).

And in fact I see you're right that I don't need the very last countdown == 2 bit, but I do need the double conditional above it, because once the timer runs out it won't idle, it will keep repeating the section under timer <= 0 until the next time it is called upon. That's why I'm keeping it contained with the countdown variable. It basically represents the scope of the timer - when the countdown is activated (1), it could either be counting down (timer > 0) or processing the action triggered when it has finished counting down (timer <= 0), and then shutting the countdown off again (0).

Code: ags

...
  else if ((timer <= 0)&&(countdown == 1)) {
    
    cEgo.Say("Balls.");
    countdown = 0;
  }

I could wrap both timer checks inside one countdown check too actually... but this works just as well.

Ahh you do it the other way around, clear first then draw. That's smart. Well I still can't wrap my head around it fully, but it works!

Code: ags

int timer;
int timerspeed = 2;
int countdown = 0;
int counter;
DynamicSprite*sprite;
export timer, timerspeed, countdown;

function repeatedly_execute() {
  if ((timer > 0)&&(countdown == 1)) {
    if (counter == 0) {
      timer -= timerspeed;
      sprite = DynamicSprite.Create(640, 480);
      gCountdown.BackgroundGraphic = sprite.Graphic;
      DrawingSurface*surface = sprite.GetDrawingSurface();
      surface.Clear();
      surface.DrawingColor = 15;
      surface.DrawRectangle(320 - timer, 420, 320 + timer, 430);
      surface.Release();
      counter = 1;
    }
    else counter--;
  }
  else if ((timer <= 0)&&(countdown == 1)) {
    countdown = 2;
  }
  if (countdown == 2) {
    cEgo.Say("Balls.");
    countdown = 0;
  }
}

Only thing I changed is the elsed sprite.Delete which gave me a null-referenced error so I did away with that whole conditional. And I changed timer--; to timer -= timerspeed; so that the timerspeed variable actually has an impact on the speed of the timer bar.
The added countdown int is to track when the timer actually finishes (not unimportant) so it can process what should happen next.

The trigger thus becomes:

Code: ags

  timer = 160;
  countdown = 1;
  timerspeed = 2; //optional

Thanks a million for the help guys! Abstract logic is not my strongest suit..

Well sure but the point is that it has to pause halfway through the script, not at the end, to give the bar enough time to render before I clear it again. Otherwise it goes from full to null in the blink of an eye.

And turning the while statement into an if statement - though it works - makes my cursor and description label flicker constantly while the bar redraws.

I'm not exactly sure how that factors in, but in my current implementation attempt of it it does nothing (where it even froze the game up completely a tiny edit ago).

Code: ags

int timerleft = 320;
int timerright = 320;
int timergoal = 320;
int timerspeed = 2;
export timerleft, timerright, timergoal, timerspeed;

int counter = 2;
bool countdown = false;

function repeatedly_execute() {
  
  while ((timergoal > timerleft)&&(timergoal < timerright)) {
    if (countdown) counter--;
    DynamicSprite* sprite = DynamicSprite.Create(640, 480);
    DrawingSurface *surface = sprite.GetDrawingSurface();
    gCountdown.BackgroundGraphic = sprite.Graphic;
    surface.DrawingColor = 15;
    if (counter > 0) {
      surface.DrawRectangle(timerleft, 420, timergoal, 430);
      surface.DrawRectangle(timergoal, 420, timerright, 430);
      countdown = true;
    }
    else {
      countdown = false;
      surface.Clear();
      surface.Release();
      gCountdown.BackgroundGraphic = 0;
      sprite.Delete();
      timerleft += timerspeed;
      timerright -= timerspeed;
      counter = 2;
    }
  }
}

*I added a second bar btw so the timer shrinks down into the center from both sides now.

The main purpose of the Wait was to keep the bar visible until it clears off, otherwise it loops through the whole thing in one frame.

For completeness, this is what the trigger code is:

Code: ags

  timerleft=timergoal-160;
  timerright=timergoal+160;

Ha! Yes that works, thanks. I had a feeling it would be something inane like that I wrongfully assumed the newly created sprite would be on the screen, not in some sort of limbo waiting to be assigned.
Alright well now I only have to figure out the non-blockingness of it then.

[int timer]

Hey fellas,

I'm trying to make a visual timer countdown bar using rawdrawrectangle, but I'm running into a few issues.

Firstly, the code I have now (in the global script rep_ex):

Code: ags

int timer = 320;
int timergoal = 320;
int timerspeed = 2;
export timergoal, timerspeed;
function repeatedly_execute() {
  while (timergoal > timer) {
    DynamicSprite* sprite = DynamicSprite.Create(640, 480);
    DrawingSurface *surface = sprite.GetDrawingSurface();
    surface.DrawingColor = 15;
    surface.DrawRectangle(timer, 380, timergoal, 390);
    Wait(1);
    surface.Clear();
    surface.Release();
    sprite.Delete();
    timergoal -= timerspeed;
  }
}

It's structured like this:
- int timer is the left end of the bar in room coordinates
- int timergoal is the right end of the bar (the same by default)
- int timerspeed handles how fast it counts down (so essentially the actual timer part of this contraption)
Once an action updates timergoal to be higher than it's default (say 480), the while check kicks in which draws a white rectangle between timer and timergoal, which gradually becomes smaller as timergoal get closer to timer again.

Now my issues:
I began by rawdrawing the bar on the background, which yielded two problems:
- if I called surface.clear it would erase the entire background, not just the bar
- if I didn't use surface.clear, you would not be able to see the progress since the previous rectangle would never be removed.
So I tried to create a seperate blank drawing surface the size of the screen and draw on THAT (the code above), but now I cannot see the bar at all. The script executes fine but it never shows up.

This is my first real foray into using rawdraw stuff, so maybe I don't understand too well how this works, but what am I doing wrong?


Oh and one additional thing, I'm using Wait(1) now, but I'd like this thing to be non-blocking so I can do other stuff at the same time. That'd probably come down to timers, but I'm not sure where to put one here so it doesn't cause an infinite loop.

I had that very same problem. Had to consult a walkthrough to find out I apparently just klicked in slightly the wrong place 5 times in a row.

*seconds all of the above opinions*

I agree with what's been said before. You did a good job implying the character is running as fast as he can because he looks pretty winded, like he's struggling to maintain his speed.

And somehow the background reminds me of the streetcorner in the suburbs where future Marty lives with his family in Back to the Future II

Well the Intel one is quite good actually, it can run older games as well as the Nvidia would, and the laptop switches dynamically between the two to save mucho power when you don't really need to throw the full scala of Nvidia's power at something (like AGS games). They call it Optimus.

Also the other thing is there is no mention of the GPU's anywhere in the BIOS

Dave's suggestion unfortunately didn't work for me. Presumably because I have two GPU's in this laptop, a built-in Intel one and a dedicated Nvidia one, but somehow I cannot force AGS to use the Nvidia one on Directdraw games.