Messages

Dear AGS'ers, I'm trying to convert the old style coding for audio to the new format.
I have no clue where to begin. Ags tells me that I can't convert an AudioClip to an int which makes sense but its been so long away from scripting I've lost my touch.

This is my current code (old format):

Code: ags

function room_RepExec()
{
  //===== FOOTSTEP SOUNDS =====//
  ViewFrame *vf;
  int fstep, idle, norm;
  if (Region.GetAtRoomXY(player.x, player.y) == region[2]) {
    idle = footstep2Bfx; norm = footstep2Afx;
  }
  else {
    idle = footstep1Bfx; norm = footstep1Afx;
  }
  while (fstep<8) {
    vf = Game.GetViewFrame(EGOWALK, fstep, 0);
    vf.Sound = idle; // idle footstep
    vf = Game.GetViewFrame(EGOWALK, fstep, 4);
    vf.Sound = norm; // regular footstep
    vf = Game.GetViewFrame(EGOWALK, fstep, 10);
    vf.Sound = norm; // regular footstep
    fstep++;
  }
}

As you might see, its a little dated. Anything I'm missing that I need to add in order for this function to work with the latest incarnation of AGS?

Merry wishes,
Sparky.

For what it's worth I think Indy deserves a stylised look. Theres no use in pulling out rulers and graphs when all you need is a good artistic eye. In my experience, for both games and film, going with whatever looks right doesn't necessarily mean going for what's physically accurate.

Here's my interpretation of what feels right as an artist:


Cheers,
Sparky.

I'm Australian but to clarify, I would be paying in US Dollars.

Sparky.

[All about Bink!]

We use Bink a lot in Unreal 3 and also use it in our own proprietary 2.5d engine. It removes a lot of the overhead that comes with installing many of the other codecs out there such as distributing the right codec version with the game, game-incompatible codec updates, and many other obvious drawbacks that users have experienced so far.

Many game engines use Bink Video because of the following advantages and features as listed on their website:
http://www.radgametools.com/bnkmain.htm

All about Bink!

• Bink videos look amazing! Bink can scale its data rate from 1200 kps for 1280x720p videos down to 75 kps for Nintendo DS videos. Bink will always make the best possible video for your data rate.
• Bink's SDK is simple and powerful. Your game is always in control - there are no callbacks or other difficult-to-debug constructs. Using Bink is like using a codec that you wrote yourself.
• Bink is completely self-contained - it needs no special system software, it needs no other audio codec, it needs no other surrounding architecture. Just one small library and you are good to go - there are no external installation or dependencies.
• Bink is super, super fast. In some cases, up to 10 times faster than other modern codecs. It's fast enough to use for in-game videos, as well as cut-scene videos.
• Bink uses as little memory as possible. In some cases, up to 16 MB less than other codecs. You don't have to worry about a simple video codec hogging all your memory.
• Bink runs on every platform. You can use the same API and data files on 14 different platforms.
• Bink runs on most game engine middleware natively. Epic supplies pre-written Bink support for the Unreal Engine, for example.
• Bink has a VBR psycho-acoustic based audio codec capable up to 15:1 compression built-in. You don't need to license another codec for your audio.
• Bink can play many audio tracks at once - this allows the playback of 5.1 and 7.1 sound tracks (on supported platforms) as well as optional language tracks where you can turn on and off a language based on the system setting.
• Bink runs on every game platform and is customized to take advantage of each one. It uses SPUs on PS3, VMX on Xbox360, SSE 2 on x86, massive assembly optimizations on Nintendo DS, etc.
• Bink includes sound support for every platform it supports. We have 16 different modules for sound playback on the various platforms.
• Bink is super robust. The fact that it ships in so many games makes it better and better - it just doesn't crash. Bink can also handle bad input data - it just keeps chugging along until the input data gets better again.

The Nintendo DS example is particularly exciting to me because of all the full-screen animated video effects in our 320x200 game.
For us, one word describes Bink: transparency

For our adventure, we want our video's to be transparent in file size and totally transparent as video, blowing the player away with its undetectable compression.
At the same time we want the player to be able to just install the game and run it making the codec installation process transparent to the player.
Bink also works in conjunction with other full/partial screen effects including pixel shaders and script-originated effects (flashlight module). Again, transparent integration into room interactions and events.

The license is $6000 USD however I for one would be glad to chip in $300 bucks, CJ. If enough of us jump on the bandwagon we could cover the license fee rather quickly.
In any case, I really believe Bink would be a great fit with today's AGS.

Cheers,
Sparky.

Thats some nice thinking GarageGothic. An idea like yours never struck me and now I feel stoopidz.
But seriously, if designing our games for a set of target resolutions at least in the way your describing would be a big step up in the way our games could presented. Cue applause.

Sparky.

Well I was thinking more in line with a dynamic resolution system where you can set target resolution/s in the AGS Editor and compile to that. The room & gui editor would need to reflect these resolutions in order to support artwork and layouts for each. Again I imagine this to be a huge overhaul of the way the editor works but its something I think is ultimately going to be necessary.

Cheers,
Sparky.

Well Chris did mention that he was looking to overhaul the resolution system at some point. We'll have to see what turns up on that front.
Any news from yourself Chris?

Cheers,
Paul.

Is it possible to execute code just before the window loses focus? Like having a sprite display on-screen indicating the game is paused as soon as you click outside the window and vice-versa?

Sparky.

Thanks CJ. You rock man! 8)

Ahh too right you are! We'll thats me for ideas.

Sparky.

Of course you would have to change speech skip to mouseclick or timer only (or using game.skip_speech_specific_key ) so the keypress wouldn't automatically cause the text to disappear.

Or you could manually set up all your skip speech keys in code to get around this. Adding a couple of variables would allow you to toggle different functions for any given key. That might see this part done!

Cheers,
Sparky.

Most appreciated for yours answers Chris! And yeah that was a room script quirk and is completely normal as I understand it now.

Cheers,
Sparky.

[BUG:]

BUG: AGS compiles and runs fine with errors in the script such as naming a View that doesnt exist but later on (and seemingly at random) picks them up and then wont run the game until the code is fixed.
This late detection is rather unusual.

Also, I can't seem to open more than one room at once. I can't remember if this was normal or not. It would be good to be able to edit more than one room for corrospondance between interactions/coordinates/etc.

SUGGESTION (Aesthetic): Switch Character.ChangeView(VIEW) to Character.SetView(VIEW) to stay consistant with objects.

Edit: Is there any reason why repetedly_execute in room scripts are named inconsistantly with the global script? It may sound ridiculous but I actually prefer the slightly longer name for aesthetics and clarity sake.

Cheers,
Sparky.

Hey there. I've got a SCUMM game going and noticed that when I set my walk to points in the room editor, the action defaults to a blocking one.
Would it be a drama to add a blocking/nonblocking toggle below "WalkToPoint" in the properties pane?

I've coded around this with a semi-blocking function for now.

A more elaborate suggestion would be to make semi-blocking events trivial to set up in a future versions of AGS. Is this something you would consider doing in the near future, CJ?

Cheers,
Sparky.

Thanks guys, You rock!  8)

Cheers,
Sparky.

Thanks, I already know that. However I have no clue how to incorporate a timer into this which activates the animation of my sprite. I've explained it better above.

Cheers,
Sparky.

Hey folks. I'm trying to create a repeating random timer that runs the following code anywhere between 45 to 70 seconds each time.

Code: ags

oIdol.SetView(IDOL_SPARKLE, 0, 0);
oIdol.Animate(0, 1, eOnce, eNoBlock);

I must admit I'm a little clueless on how to approach this.

Cheers,
Sparky.

Thats actually a fantastic idea. To be able to control the amount of panning going on with character coords would be good too.

Cheers,
Sparky.

As would I. Although not clearly stated, the suggestion implied that a black border could be drawn fullscreen with or without scaling on.

Agreed on the telescoping though Chris - I used to play all the LucasArts games with black borders on because I hated the double sized pixels but that was in a time before HD monitors. I'm all for pixel clarity if it can be managed, and for some, pixel smoothing might be the style your going for.
Hq3x does tend to blur a bit more than the other algorithms I suggested which is why one of the reasons I started this topic. The key words here are clarity and scale. Mixed together you have a pretty darn good excuse to play the latest 320x200 games on a widescreen monitor at full-screen.

I have the misfortune to have to scan through a screen filled with triple sized pixels due to my 30"monitor and its not a pleasant walk in the park. Running DirectX9, naturally, the scene looks like a godforsaken mosaic.
I continue to press the DirectX9 implementation because AGS still supports low res games and therefore some kind of smoothing (not to be confused with blurring) needs to happen.

Please treat this request extremely casually, it's not a slit-your-wrists if not had feature but I strongly believe it needs to happen at some point. If only for the sake of enjoying our beloved low res games AGS first became famous for.

Cheers,
Sparky.

I've always found these filters to be horribly ugly and destructive to pixel art, so I can't really get behind this suggestion.

I've always found that pixel art at 2560x1600 looks horribly ugly and requires filters for feature distinguishability. Having said that, I'm sure Hq3x is good enough for some but it doesn't quite offer the best smoothing as you can see above.
So no chance of emulating these algorithms in DX9 Mode Chris? The DX9 Antialias filter just blurs everything at large resolutions. Not something I'd recommend for my players. It almost seems the only way to experience decent graphics in all its glory is to run games below 800x600 in a window. Personally, I don't like the desktop looming about in the background of my games because it breaks immersion. Anyone enjoyed the cinemas with the lights on? :'(

Perhaps another suggestion: full-screen + black border could be introduced? This is a long-time request so.....BUMP!  

Cheers guys,
Sparky.