Messages

Please try this out guys and make sure it's stable.

Assuming there are no major problems, in a few days I'll make it official and publish it to a new thread, to the website and make a ZIP version available.

Agreed, alter the blood colours but keep your lighting as it is. Its an interesting style and, I think, one you've already used in all your other backgrounds

Like killing off one of their leads, who they could have used to promote the film further upon its release?

Its a sad loss. I've not seen Brokeback Mountain, but I thought he was a pretty good actor in his other films. Still, I'm with Vince, this is a tragedy for his 2 year old daughter.

We're officially down to less than an hour to go, but I'm going to bed instead of judging so there's a little more time if anyone wants it.

I don't remember DemoQuest making use of any of the 256 colour features like pallet cycling etc (though I could be wrong), and that to my mind would be one of the main reasons of using 256 colours. An upgrade to 16-bit would make it easier to jump into (AGS's default is now 16-bit after all) and potentially easier to develop so I'd be for it.

Is there any particular reason for not suggesting going straight to 32-bit (and demoing alpha channel effects) if you're thinking of using it to demonstrate AGS's superior graphics?

As a side note, what's happening with DemoQuest development? Its something I'd be interesting in contributing towards, though I don't know if my programming ability/creativity is up to it, or if I have enough time...

Ok, a case of "I'm going to do it my way because I can"? That makes sense. I guess using integers gives you split second control. I'll make a mental note not to use timers in case I become frowned upon by the AGS elite...

You want to break it down into two different movements; a horizontal one and a vertical one. Assuming you don't have anything like air resistance your horizontal velocity is going to be constant, so you can just have an amount being constantly added (or subtracted) to the object's x coordinate.

The vertical velocity will change due to gravity, so you will need to constantly add an integer to the object's y coordinate, but this integer will be made bigger and bigger, and will eventually become positive at which point the object will start to fall. The code below does something like this, but you might have to alter it slightly to your needs.

Code: ags

//at the top of the script
int xVel=1;  //the amount the object will move in the x direction each loop
int yVel=-3;  //the amount the object will move in the y direction each loop. Initially negative so that it will start moving upwards
int gravity=1;  //the amount the yVel will change every loop
int xFinal=25;  //the x coordinate the object will finish at
int refreshRate=5  //the number of loops to wait until moving the object

//in the function where the object is thrown
while(object.x<=xFinal){  //while the object has not yet reached its target
  object.x+=xVel;  //move in the x direction
  object.y+=yVel;  //move in the y direction
  yVel+=gravity;  //change speed down
  wait(refreshRate);
}

With certain values your object could start falling too fast, so you could add a terminal velocity in there. You'd need another integer (such as termVel=10), and replace the yVel+=gravity with

Code: ags

if(yVel<termVel){
  yVel+=gravity;
}

No sound for me either  :'(

Its a little off topic so sorry for that, but I was curious about why all the answers (including the other linked topic) use integers that are changed every game loop instead of timers? Are there any problems with timers, or issues you might run in to using them that I'm not aware of?

Just wondering

And Tequila, because the timer is counting down game loops (approximately 40 a second, your 9 minutes is actually 540 seconds multiplied by 40 loops a second which is 21600. Your code would be waiting for the countdown to hit 13.5 seconds (540 loops/40 loops a second = 13.5 seconds).

Oh, and have you made sure its in repeatedly_execute?

Then again, the Demo Game is unfinished, and that's not very good form either. I feel tempted to suggest replacing the DemoGame with OpenQuest.

I suspect this is best discussed elsewhere, but I'd also be wary of distributing Demo Quest in its current state with AGS. I'd still offer it for download though, as a lot of the more advanced code is very useful.

I can't believe 3.0 is (almost) here! Seriously, I've got a stupid grin on my face. Wonderful work CJ!

Ok everyone, you have until midnight of the 22nd GMT, which is approximately 25 hours from now (see time stamp of this post), so plenty of time to whip up a quick entry. If anyone suddenly decides they need a day or two more than this, post your request here.

They're good entries so far, but can we get a few more?

Isn't that what the "No transparency" transparent colour option is for?

There seems to be a few mixes in style, with the windows being done in a kind of Maniac Mansion/Zak McKracken way and a high colour texture on the floor, with everything else somewhere between the two. I'd also suggest the shading was a little off on the door frame/outer edge of the door in the middle of the screen as there doesn't seem to be any particular light direction on it. Anyway, you might still be working on all those areas.

I'll second most of what Cyen said about the plants, the one on the right looks good but flat and the one on the left doesn't look much like a plant, and also looks flat. The right hand plant has a darker outline, so why not use the same on the left, as it won't jump out as much. I'd have a go at using just your shading tones to try and define volume on the left plant, rather than using the outline colour all over it like that. You could use the outline colour in smaller amounts, but connecting all the lines makes it seem like your plant is made of lots of irregularly shaped blocks. For the right plant I'd try to get more overlap in the leaves where they meet the stem, so it doesn't seem like they're all coming from the sides. You need to work on the shading of the pots too, your band of light is horizontal which makes the plant pots look flat. You need to curve the shading around the pot, and probably put more of a curve on the base of the left pot too.

Overall its well on the way to being a very good background

Congrats guys, and well done to any of you that actually got a vote 

This is Josephine


She doesn't sit on laps and hates being picked up, but if you're the only one in the house she'll follow you around meowing incessantly.

[Edit:]

Start>>Run>>mplay32.exe

You may not have to find it on disk 

Edit: And brief tests suggest it doesn't affect the MIDI volume, and will play side by side with Media Player 11

First one sounds like some incarceration of the Iron Giant to me, though it does also sound a bit like the Mega Man games. I haven't seen much anime outside the Studio Ghibli stuff though.

Very nice work! Boobs too...

Ah yeah, just seen your post so I guess you beat me to it. A quick Google search suggests Media Player's control of your MIDI volume goes back to the days of Media Player 6.4, if not earlier, and it seems to be built into Media Player so you can't stop it. Solution is to use something else to play the MIDI then, or put up with changing the volume back again.

Mine too, when I checked when I was writing that reply. Doing something in Windows obviously turns it right down...

BAM found it!

Try this out, set your SW Synth level to the middle. Open a MIDI in Media Player. Check the level, its now at the top. Close Media Player. Check the level, its now right at the bottom. Its all Media Player's fault!