OROW 9 is now underway. Visit the thread to take part!

Show Posts

You can view here all posts made by this member. Note that you can only see posts made in areas to which you currently have access.

Messages - Snarky

Pages: [1] 2 3 ... 199
Engine Development / Re: Best video format for AGS
« on: 03 Sep 2015, 10:33 »
I would argue that even in a low-resolution game, there are very few use-cases for lossless video. Video is much more forgiving of minor compression artifacts, since because each frame is displayed for a very short moment, you don't have time to study it and notice them. A high-quality lossy encoding should be indistinguishable in practice and save a lot of storage. If you do need absolutely lossless video, you can just import the frames as sprites and display them as an animation.

In any case, x264 apparently allows encoding lossless into h.264 format: https://stackoverflow.com/questions/768999/what-is-a-good-lossless-video-codec

Adventure Related Talk & Chat / Re: STASIS
« on: 01 Sep 2015, 22:19 »
Congratulations! I crowdfunded or preordered it or something ages ago, so I have a key, but I have such a backlog of games I haven't had time to play...

The reception does seem great so far. You must be feeling pleased.

I'm curious about the logistics of something like this. I suppose anyone could just decide to walk from London to Cambridge, but how is the challenge run and structured? Was it just non-stop walking, or did you stop e.g. for meals and stuff? And did you all walk together (at the beginning, anyway), and along the same path? How was it marked, did you have a map, or what? Were there checkpoints?

Wait, I can just read about it on the web site: http://www.london2cambridgechallenge.com/

Very cool, and the (semi?)rural English landscape is beautiful. Nice going! :P

Haven't done anything remotely like it; I have a vague plan to bike around Lake Z├╝rich, but that's only about 6-8 hours.

That's good news for us, CW! Hope you enjoy the new work-work balance. :P

Proximity, if you think a commercial game release means guaranteed instant retirement, you have another think coming. (laugh)

The problem is caused by one of the changes you made between when it was working before and when it's not working now.

More constructively: Objects block walking by default. Check the BlockingHeight/Width.

Now that you're a mod, you can, by the power vested in yourself, split the thread if you think it belongs in a separate topic. ;)

Beginners' Technical Questions / Re: Stopping all sounds
« on: 30 Aug 2015, 19:37 »
Code: Adventure Game Studio
  1. int i=0;
  2. while(i<System.AudioChannelCount)
  3. {
  4.   System.AudioChannel[i].Stop();
  5.   i++;
  6. }

(Merged threads: Don't start multiple threads on the same question.)

Great work, CW! I've never had mouse problems myself, or I'd help test it.

Advanced Technical Forum / Re: Very slow cutscene skip
« on: 30 Aug 2015, 09:00 »
I believe the problem is that you can't just automatically skip the rawdraw commands, because there's no way for AGS to know that those drawings don't persist outside of the cutscene, so you might end up with an inconsistent state. The intention is that the state of the game at the end of the cutscene should be the same whether or not you skipped through it, and that means that every state-changing action has to be executed.

Is it possible to not use Allegro for mouse input?

Yes, reading the updates on this issue, I've also wondered if AGS is taking the wrong approach.

I'm not well versed in the technical details here, but my general intuition is that when you're just using the mouse to move a cursor around, the mouse should under normal circumstances behave just like it would on the desktop, and that it should be up to the OS/shell to translate mouse inputs to cursor coordinates (so AGS shouldn't have to set the sensitivity or define screen borders). So I'm wondering if the mouse APIs used by AGS are too low-level. After all, e.g. FPS games that use the mouse for targeting probably need much more direct access to the mouse, so a library like Allegro might provide API calls that are more suitable for such a scenario.

Some caveats to this argument:
-Is there actually a higher-level API available? I mean, I know that when you write a windowed app you don't have to code in the mouse movement yourself, but is that available to the type of application AGS is?
-This might work well in windowed mode or if AGS could run in "pseudo-fullscreen" (scaled to the desktop resolution in an undecorated window), but how does Windows and other OSes handle mouse sensitivity/acceleration when the screen resolution changes? Is the speed in pixels scaled so that the amount of mouse movement needed to cross the screen remains the same?
-In a multi-screen environment, or if the game resolution is not the same as the screen resolution (because of borders etc), would a higher-level API allow us to elegantly keep the cursor within bounds?
-What if we want to be able to adjust these parameters in-game, or use the mouse in some other way. Would that still be possible?

Oh right, I think I see your confusion.

The "keyhole object" oKeyhole is just the thing you click on to make the character look through the keyhole? In that case, it's completely irrelevant to the problem. The only thing that matters is the graphic you actually want to display, and you should make sure you don't confuse "the overlay where we display the graphic that shows the view through the keyhole into another room" (let's call it keyholeView) with "the object that represents the keyhole for purposes of interacting with it in the room" (oKeyhole).

So this line is wrong:
Overlay oKeyhole = Overlay.CreateGraphical(20, 20, oKeyhole_40, true);

What you're actually doing here is to define a new overlay (a graphic displayed on the screen) that has the same name as the object oKeyhole that already exists. You should never try to define two different things with the same name that exist at the same time: either it won't compile and run, or it will lead to bad bugs. Also, oKeyhole_40 isn't a thing, you can't use that as an argument. You need to just take the number of the sprite you want to display, in this case 40.

So what you should do instead is something like:

Code: Adventure Game Studio
  1. Overlay* keyholeView = Overlay.CreateGraphical(20,20, 40, true);
  2. Wait(GetGameSpeed() * 3); // 3 seconds
  3. keyholeView.Remove(); // Note the same name!

Notice also the * after Overlay in the first line. That's important (it means that keyholeView is a pointer: you don't have to understand what that means, just remember that you have to use it for some things). Some people, like Khris, put the space before the *. It works either way, but IMO it makes much more sense to have the * as part of the type rather than the variable name.

Now, to make this run is where oKeyhole comes in. You probably want to add it as an OnClick (or OnInteract or whatever) handler for that object. So go into the oKeyhole events (in the room editor), and select the event you want. It should generate a new function for you that is called something like oKeyhole_OnClick(). Put the code inside that function.

If what you need to display on the screen is a combination of two sprites (a room image and a black screen with a keyhole-shaped hole in it, or something like that), it gets a little more complicated. Some options:

-Pre-combine them into one sprite in an image editor, and simply display that like Khris explained
-Use rawdraw commands to draw first one, then the other to a new dynamic sprite (slightly complicated)
-Display two overlays at the same time, one on top of the other

If I'm misunderstanding you, could you post the two sprites and how you want it to appear in the game so we can see what you're talking about?

(I only have access to the 3.2.1 manual right now, and I know the API for facing different directions was updated in 3.3, so this could be slightly out of date, but should hopefully still work.)

This is what the manual recommends to run a custom animation:

Code: Adventure Game Studio
  1. cEgo.LockView(12);
  2. cEgo.Animate(0, 0, eOnce, eBlock, eForwards);
  3. cEgo.UnlockView();

The first argument to the animate function is the animation loop of the view. This corresponds to the direction the character is facing, so instead of passing 0 (which means up/north in AGS), use the character's current loop:

cEgo.Animate(cEgo.Loop, 0, eOnce, eBlock, eForwards);

This assumes you have provided loops for all the directions your character might face.

Compare this...

Character.SetIdleView(int idleview, int delay)
Pass IDLEVIEW as -1 to disable the idle view completely.

to this...

Code: Adventure Game Studio
  1. cJones.SetIdleView(10, -1);

... until you spot your mistake.

Pages: [1] 2 3 ... 199