Messages

(We're hijacking this thread btw...)

:

If this thread was a train, it got hijacked and subsequently ran off the rails. And it's still going.

PlaySound command featured in densming's videos, just doesn't work for me...

If you're using the latest version of AGS I'm not surprised. PlaySound() is obsolete and doesn't work anymore. To play a sound, you simply type the name of the sound file and add ".Play;" to the end of it.

Just as an example, here's how some sounds in one of my games is played:

Code: ags

function PlayRicochet()
{
  int RicoNum = Random(4);
  if(RicoNum == 0) aRic1.Play();
  else if(RicoNum == 1) aRic2.Play();
  else if(RicoNum == 2) aRic3.Play();
  else if(RicoNum == 3) aRic4.Play();
  else aRic5.Play();
  return 0;
}

The sound files themselves are just 'Ric1' to 'Ric5' and when importing them in, AGS automatically adds the 'a' to the beginning of the name.

Of course, if you still wanted to be able to use PlaySound() then you'd have to go into the General Settings of your game, and change 'Enforce new-style audio scripting' to false (second from the top in the 'Backwards Compatibility' section)

edit: dammit dammit dammit Khris! You ninja'd me >:/ (why does this keep happening? *sob* )

 Good catch, monkey it's been a long night, and it's promising to get longer (just so long as I can stay awake until that 2nd pot of coffee is done. Code doesn't write itself (usually...))

I don't know too much about the pros/cons in the different video files, but seeing as OGG is unrestricted by any software patents, and can use the lossless audio compression codec FLAC, I heavily recommend it 

[10th of July]

I'm going to go and set the deadline for this activity as the 10th of July.

I will release 2 games I've been working on. Just for this.

(This is the first thread with >3 pages that I actually read beginning to end, and I must say that what you guys are creating is phenomenal. I wish I had even a sliver of the graphic design talent running around here)

First on the list is a game that I started a looooong while ago but eventually got bored of it and stopped. Just as recently as 3 days ago I restarted the project from scratch. Here's a first look:

There's still much to do, adding in more enemies, a shop to buy bigger/badder weapons & upgrade them, bosses, music, destroyable scenery, etc. Now, I'm terrible at graphic design, and this picture demonstrates it quite nicely :  Those turrets (and bullets) were created 100% by me, the fighters you see were not. In fact, I hate doing graphic design. This game (and the next one) is an effort in programming, with graphics attached 

Here's a taste of the music I'll be using (shamelessly ripping...programming is my strength, and not much else   )

Now, for the second game...

Now, I'm not completely certain I'll be able to finish both by the 10th but damn will I try. Plus, I'm gonna finish the first one before I continue work on this.

A bit of history about AGS-GH: This is a project I started way back in March of 2010. It would have been completed if my laptop didn't get stolen About a month ago I found one of my old USB sticks that had an earlier version of the work I did on it, and since then I've been meaning to get back to programming it. Thankfully, I had some help with the images and they're saved online so it shouldn't take longer then a few days to knock it out 

[and all this information was found in the AGS help]

AGS has built-in support for OGG Theora (.OGV) video files, and can play anything that Windows Media Player can play (just so long as the end-user has the correct codec installed).

the code is pretty simple, and if you want it to play when the player enters the room:

Code: ags

function room_AfterFadeIn()
{
  PlayVideo("VideoName.OGV", eVideoSkipNotAllowed, 1);
}

Just keep in mind that the game is paused while the video runs.

and all this information was found in the AGS help Remember: F1 helps  

edit: (.OGV, not .OVG)

30000  imported sprites
.
.
.
unlimited loops per view
unlimited frames per loop

You could potentially have a view with 1,000 loops, and 30,000 (maximum amount of imported sprites) frames per loop. When you tell AGS to animate one of those loops, it will go through each and every one of those thirty-thousand frames. (@40 fps & delay = 1, it would take 12 minutes and 30 seconds to see that animation beginning to end. Absurd I know but AGS will let you do it.)

If only the object limit was more then 40...

...Direct3D allows fast high-resolution alpha-blended sprites, but DirectDraw is better at RawDrawing

RawDrawing can eat FPS if not done efficiently in both D3D-9 and DirectDraw-5, especially if the image is large with lots of changing pixels. Using DirectDraw-5 mitigates the FPS loss but can still get bogged down if you're using RawDraw a lot. D3D-9 is used for fast rendering of complicated sprites but doesn't deal with RawDrawing very well.

A trick I found to minimizing the amount of RawDrawing is to preload the sprites into memory.

So for example, lets say you had one sprite that you wanted to be able to rotate 360 degrees, one degree every loop. Instead throwing 360 separate images into an animation or rotating it as a DynamicSprite one degree every game loop, rotate and save every image into an array before the sprite is ever needed.

Code: ags

DynamicSprite *sprite[360];
int Angle = 0;

function CreateSpriteRotationIndex()
{
   sprite[0] = DynamicSprite.CreateFromExistingSprite(StartingSprite);

   int counter = 1;
   while(counter <= 359)
   {
      sprite[counter] = DynamicSprite.CreateFromExistingSprite(StartingSprite);
      sprite[counter].Rotate(counter); 
      counter++;
   }
}

//before the sprite is to be used, create and save all possible variations.
function game_start()
{
  CreateSpriteRotationIndex();
}

//then, in the game loop
function repeatedly_execute()
{
  //lets just say that object 7 is being used to display the rotating sprite
  if(Angle == 359) Angle = 0;
  object[7].Graphic = sprite[Angle].Graphic;
  Angle++;
}

This is just one example and you could potentially do this with any DynamicSprite modification, not just rotating  

cheers

I thought it was something one of you guys could have just seen and knew what it was right off the back...

Well you see, that's the problem in the first place. No two computers are the exact same (except when you compare brand new computers before retail sale, but even then...) so information contained within the error report generated by your computer probably will not be the same as one generated by someone else. The only thing this error tells me is that AGS had a memory error.

Plus, there can be more then one reason that you got a particular error. That's why the specific details of what you were doing, the code that caused the error, which build of AGS you're using, what your computer is, etc. is so important. What if you were using AGS 3.1.2 on Ubuntu, or AGS 2.71 on Mac (and the error didn't helpfully put in the version number or OS)? It's usually assumed that people are using Windows XP/Vista/Seven & the latest stable build of AGS, so if you weren't using Windows or were using an earlier AGS build and you didn't mention it, the help we would give is potentially useless  

Now having said that, I do recall seeing this error before (in an older build of AGS...3.1 I think) and I'm pretty sure it involved an object in some way, but I don't remember specifics or how I solved it  

Based on the information you've given, this seems a likely candidate to what happened.

...An illegal operation may mean a bug in the application program (or occasionally in the operating system) or it may be the result of a combination of unusual circumstances that the program and operating system could or did not anticipate. In the latter case, the problem may not be repeated or may be intermittent.

I also did a bit of searching around the forum for the same problem (which is a good habit to get into to diagnose problems   ) and it looks like this error stems from something not being loaded into memory or not existing at all. These are of older versions so they might not reflect the problem you are currently having, but it is insight  

 :o  (and yes, I just saw this game now  )

Impressive, sir. Other then a glitch and a few minor bugs it's solid. The worst thing that happened was when I tried battle mode against the bot, and on the second turn I found I couldn't move the units I deployed. Well, it sounded like I could but the image never moved. I could even deploy new units on top of the 'unmoved-moved' units, or whatever you'd like to think of them as.

Occasionally, when the bot decided it was a good idea to attack my shiny new tank with his injured infantry, it calculated that my tank took negative damage? As well, the bot was pretty easy to defeat. If I throw away my tactics and strategy the bot can be a nuisance, but doesn't look like it knows how to do much more then defend. When I'm far across the map, the bot just makes it's units spin in circles. Even when outnumbered and outgunned I found it easy to out play the bot.

I got all the way to mission 6 before I stopped

Spoiler

I was dutifully sending my soldiers to their deaths, making sure not to fire on my own units (never even did it once the whole game) when the private catches on to the plan, stating that I'm firing on my own soldiers, and I lost the mission. I wasn't, one of my infantry just got slaughtered by some artillery when the private said it.

[close]

The sheer awesome that this game represents makes up for any flaws I could find. Well done.

I tried it. The editor didn't crash and when I tested it the only thing that happened was the editor bitching at me for not putting a semi-colon at the end of the line. Maybe AGS just had a sudden cardiac arrest?

AGS 3.2.1 on Windows XP SP2.

edit: dammit, you ninja'd me. So this problem only occurred once / you couldn't repeat it?

More of a metal head but it sounds nice 

...and give me back my name 

Glad I got the error actually fixed for you though. Can I ask what this is for?

You may  

It's one half of my attempt to implement hitscan in a birds-eye view styled shooter. Next is collision detecting!

Even if I gave the project 6 hours of attention a day, it'll probably still take a solid month or two to finish  

edit: If you want to get an idea for the feel of the game, here's a sample of the music I'll be using (shamelessly ripping...hey, I'm terrible at graphic design and creating music, give me a break  ). Thinking about it, the picture describes it pretty well too. I'm pretty sure I can get away with it, seeing as I don't expect anyone to pay to play, and the source will be available when it's done   And of course, anything in it that is not my own creation will be credited

On a totally unrelated note, hey suicidal pencil, welcome back, we missed you!! 

lol, thanks    My hiatus was partially due to laziness, but when my laptop was stolen with my unfinished Guitar Hero clone, it took me quite a while to get the drive to program back. I had just finished the song editor, too 

This is actually one of two projects I'm working on at the moment. Might resurrect AGS:GH, but not after I finish this ^_^

And MonkE3y, that code works as perfectly as the first iteration, without that error of course  Much appreciated.

Just to make sure, you're calling it like this, right?

Code: ags

  Display(ExtrapolateShot(400.0, 300.0, IntToFloat(mouse.x), IntToFloat(mouse.y)));

The function is called like this:

Code: ags

String ShotEnd = ExtrapolateShot(IntToFloat(FiringX), IntToFloat(FiringY), IntToFloat(AimX), IntToFloat(AimY));

The data is printed on a gui label just before returns. The only time this function gets called is on left mouse click.

That's the expected result if the mouse is sufficiently off-center horizontally.
Are you saying that my function fails if the mouse is closer to the upper or lower screen edge?

When the extrapolated line is to intersect the upper or lower edges before the left or right edges, Y is supposed to stay at 0 or 600 respectively. If the extrapolated line is to intersect the left or right edges before the upper or lower edges, X is to be 0 or 800 respectively. When I tested your code Y constantly changed when it was supposed to stay at 0 or 600, and X was either 0 or 800, and not the in between values when it is supposed to be.

So, is this solved yet?

Technically yes, the first code segment monkE3y posted that had the divide by zero error (seen below) worked perfectly (except when rise or run were 0, of course). I still need to check how accurate it is, but it should be no more complicated then just drawing that line.

Code: ags

  String ExtrapolateShot(float x1, float y1, float x2, float y2) // defining String as the return type means you CAN return a String (not a string though)
  {
    
    float rise = (y2 - y1);                                    // rise
    float run = (x2 - x1);                                     // run
    float xedge = IntToFloat(System.ViewportWidth);            // positive run heads toward right of screen
    float yedge = 0.0;                                         // positive rise heads toward top of screen
    if (rise < 0.0) yedge = IntToFloat(System.ViewportHeight); // negative rise heads toward bottom of screen
    if (run < 0.0) xedge = 0.0;                                // negative run heads toward left of screen
    float xsteps = ((xedge - x1) / run);                       // the number of steps in the X-direction before we hit an edge
    if (xsteps < 0.0) xsteps = -xsteps;                        // make sure the number of steps is positive
    float ysteps = ((yedge - y1) / rise);                      // the number of steps in the Y-direction before we hit an edge
    if (ysteps < 0.0) ysteps = -ysteps;                        // make sure the number of steps is positive
    float steps = xsteps;                                      // get minimum number of steps before we hit an edge
    if (ysteps < xsteps) steps = ysteps;                       // if fewer Y-steps, use those
    xedge = (run * steps) + x1;                                // get X-edge coordinate
    yedge = (rise * steps) + y1;                               // get Y-edge coordinate
    return String.Format("%f,%f", xedge, yedge);               // return coordinates of edge collision
  }
  

Still, I tested your code. The data it's giving me isn't correct, not quite as wild as my original attempt but just as weird. X equals either 0 (when mouse is left of origin) or 800 (when mouse is right of origin) and never anything else. Y on the other hand is accurate only when the extrapolated line hits the x edges.

edit: I checked the accuracy of monkE3y's function (the first one...) and it's perfect.

Thanks for pointing out that divide-by-zero error. It should be corrected now.

I won't lie, I'm being a bit lazy right now (watching a 3 1/2 hours movie), which means I didn't get to analyzing the code on paper or writing in the handling of the divide-by-zero, but I've tested both iterations of your code and the latest has another tiny problem...

Okay, that's a euphemism. The function is borked. The extrapolated line goes past the top edge, any location in the bottom left quadrant is a set (400,300), and any location in the top left quadrant causes AbortGame to be called. I commented it out and tested it, and the result is the same as the bottom left. Bottom right works fine, and so does top left (if the extrapolated line doesn't cross the top edge).

You didn't need to go to the trouble of handling the divide by zero, but I'm thankful you have. As well, your description did help my understanding   Still going to look at it on paper just so I'm 100% confident that I know how it works  


I wish this scripting language looked and worked more like Perl...if to name only one advantage, regular expressions =) but I know that Perl would make no sense as the scripting language...maybe for a MUDD based adventure game

Not only did I learn from my mistake, I learned something new  

Thank-you both, I understand a bit more now and your code works perfectly, monkE3y. I only had to change one line outside that function for it to fit. The only problem your code has is when it divides by zero    Whenever the mouse is perfectly in line horizontally or vertically with the origin, run and rise respectively end up being zero. I can take it from here, thank-you again =D

(I'm going to be honest, I'm going to go through your code on paper so I know exactly what's going on. I can't really do math in my head very well, but I have no issues with it on paper.)

[far]

Now, I am willing to admit that my math sucks. Pretty bad, but almost every math problem I encounter I can usually work through by bashing my head against it. This problem, so seemingly simple, has made my procedure end in a concussion, instead of success.

here's a visual representation of what I'm doing:


Let me explain:

• The intersection of the blue dashed lines is the origin of every line (400, 300)
  
• The red lines represent the known line
  
• The yellow lines represent the extrapolated path of the red lines
  
• Where the red lines turn into yellow lines is the location of a mouse click
  
• The end of the extrapolated line will always be at the screen edge, never farther.
  

The issue I'm having is accurately extrapolating that line. My first attempt at a solution was relatively simple: get the slope, increment/decrement x which changes y, and keep going until I hit an edge. Slow and time consuming, but at the time I was just looking to brute force it so I could continue on other stuff (optimization comes later). However, the results are far from accurate. Depending on where the click happens, the end of the extrapolated line is in the thousands, or it's a location in the completely wrong direction.

Could someone advise me on what I've done wrong? Code below.

Code: ags

  function ExtrapolateShot(float x1, float y1, float x2, float y2)
  {
    //x1 and y1 represent the origin
    //using floats for accuracy
    float rise;
    float run;
    int xdirection = 1; //which way x is going to move, 1 = positive
    
    //debugging...
    DL7.Text = String.Format("x1 %f y1 %f x2 %f y2 %f", x1, y1, x2, y2);
    
    if(x1 > x2)
    {
      run = x1-x2;
      xdirection = 0;
    }
    else run = x2-x1;
    if(run == 0.0) return 0; //just catching the error, to be removed
    
    if(y1 > y2) rise = y1-y2;
    else rise = y2-y1;
    
    float slope = rise/run;
    float eX = x2;
    float eY = y2;
    String EdgeCoor;
    
    while(eX > 0.0 && eX < 800.0)
    {
      if(eY < 0.0 || eY > 600.0)
      {
        EdgeCoor = String.Format("%f %f", eX, eY);
        DL8.Text = String.Format("%f %f y", eX, eY); //debug
        return EdgeCoor; //I'm aware that I can't return strings, this is just to show where the function can escape
      }
      
      if(xdirection == 1) eX += 1.0;
      else eX -= 1.0;
      
      eY = eX*slope;
    }
    
    EdgeCoor = String.Format("%f %f", eX, eY);
    DL8.Text = String.Format("%f %f x", eX, eY); //debug
    return EdgeCoor;
  }

I'm also trying to keep the code flexible so that the origin can move around the screen (instead of being stuck at 400,300), but while the code doesn't work this is of little concern.

Instead of incrementing 'trans' by one, try a higher number.

try 'trans += 5;'

what if instead of retrieving web pages, but a plugin that gets data from a database? It could be pretty useful. High scores, for example.

if the integer you're using is 4000 all the if statements will actually be processed...

Code: ags

if (t < 6000) { //morning
}
if (t < 12000) { //afternoon
}
if (t<18000) { // evening
}

ok, this is pretty funny

you just got it reversed. The code you put will check the variable every time if t = 4000, not Cal's code else if is a wonderful thing . I'd rather Calin's code than Khris's code. Khris's will check t twice before moving into the if statement, whereas Cal's only checks once.

edit: Damn, Ryan, you beat me to the punch