Messages

You may try IconArt.

[pure]

Well because old versions of AC/AGS didn't have a window$ engine, so some of the games are stuck forever in their DOS forms.

I'll say as DOSBox is a general emulator and ScummVM is a game resource interpreter, if the game is supported by ScummVM I think it's better to run it via ScummVM.

I agree that DOS is like faded out in most areas, but still there are happy pure DOS users (like me) and DOS affiliates who would like to play a game under DOS whenever possible (like me). Whether a DOS version of a game should be made is up to the creators, it's his personally decision, personally I'll only test my games thoroughly under DOS and make sure they work there, I won't care much how well they'll work under window$. The good thing is, if you can make sure that an AGS game runs perfectly under DOS, it'll probably also run without any glitch with the window$ engine, but not teh other way round.

1. I see no point to (apart from the possible open source multi-platform part of course). AGS is still actively in development, and is very different from some of the more restrictive old commercial engines, I'm not sure but I think the main point of ScummVM is to bring back old games so they can be played with modern computers.
2. I think the Linux port was ready for plugins already, don't know whether the distributed one can use plugins or not though. The problem is that if you use plugins for the Linux port, you need to have these plugins to have a linux compiled version, which is not the case now. I'll say scrape plugins completely if you really want your game to be compatible and run on different platforms, most of the time you don't really need them, and I'm serious.
3. This had been discussed for many times already, do a forum search. For example you get this.





SSH: Scumm was not open sourced but I think ScummVM is.

More characters, too, like a space girl in tank top.

Hi Joe. From what I understand you can run AGS games on Linux.

Well, not if the game used plugins, I don't know whether this game used plugins or not though.

I guess some people just don't like to use "standardized" graphics, which would make a lot of games feel the same. I know I wouldn't.

Right, don't use that generic emotionless spaceman, use Roger instead -->











Actually I think the IG should got its content increased, currently there're only a few errr... things in it, making all games made with it looked identical.

Actually I'm quite amazed some of you westerners learned of the news so late, we got the news on Sunday morning.

But but but... that's because you're in teh game!1!

BIAS!1!

Did you change anything from the global script?

Yeah I think he eventually found the Fountain of Youth, and is "now" (well time has no meaning to him anyway) disguised as a U.S. art school graduate, waiting for his chances to REVENGE and annihilate all of us out of existence. Sooo, BE CAREFUL!1!

PWNED!1!

What error message did you get?

The walkable area is also a different color than the walkbehinds.

? Walkable areas and walkbehinds are two different and independent things, whether they're drawn with the same colour or not doesn't matter.
I'm not sure what your problem, but what I guessed was that you might have the areas mixed up, and drew "walkable areas" when you're drawing walkbehinds in the editor. You need to choose what kind of areas you're going to draw in the editor.

[RawSelectScreenSlot(int slot)]

But the down side is that you cant rawdraw on 2 or more frames simultaneously, and then restore them both to their original states (unless the player leaves the room).

--EDIT--
I suddenly have an idea, is that you can save up to 5 bgs simultaneously (because there're a limit of 5 bg frames/room currently I think). So all we need is a new function:
RawSelectScreenSlot(int slot)
which will select the save slot you save the screen to or restore from.
I know this can increase memory consumption drastically but it's the game creator's own resposibility to choose whether he should use it (if a slot is not used, it won't consume memory, furthermore these saved bgs are automatically destroyed when the player leaves the room currently I think).
Of course, it would also be nice if we can have functions like:
RawSaveBGframe(int frame)
RawRestoreBGframe(int frame)
which can operate on frames currently not visible.

I know that's fantasy, but it's just a sudden idea flown up in my mind, they're not feature requests and I don't really need them (at least for now), just think they can be nice and probably not difficult to implement.

Actually I'll say the temple part was just annoying, not really hard, it just adds up to the length of the game.

In my opinion this game is quite entertaining and has good length, lots of stuffs to do, and it's packed with nearly everything, which is one weak point of the game (apart from the silly story and lame jokes), so I'll say this game is worth a try, but it's definately not a good game, just fun, period.

Also that irritating walking speed and that you need to walk to and fro scenes (I think if I knew what to do better beforehand I can walk less though) lengthens the game drastically.

I know that I need to save the bmp file in this mode
>> 32K/32,768 colorsÃ,  Ã, 

And be aware that you shouldn't be saving your BMP files in this mode, the AGS editor only supports importing of 8-bit (256 colours) and 24/32-bit BMP images (even if your game is set to be hicolour, you need true-colour images for import).

Well you can always copy the whole script to notepad, do the stuff and then copy it back.

But I think adding such a feature to the editor is quite handy. The text editor is actually adopted from http://www.scintilla.org, don't know waht version CJ was using but seems that the current version if the scintilla supports replacing now.

Heh actually I'd never tried rawdrawing on a room with multiple frames before, but someone did a test and told me it was drawing on all the frames, so I believed it and I think it should be done that way.

Now I had just done a little test, and verified that it only draws on the current frame, BUT that can cause problems.
The problem was that I just noticed if you use RawRestoreScreen() it will restore the saved screen to  the current frame. This can be messy if you do something like below (but can also be handy if it's your intention):

In a room with 2 different bg frames do this:
- When in frame #0, RawSaveScreen() and then raw draw something on it.
- Switch to frame #1, and call RawRestoreScreen()

The result was that frame #1 got overwritten by the saved bg image of frame #0

I think this feature can be handy if you are aware of how it works and always do things right, otherwise it can be confusing.

So I think it's okay staying that way, but needs to be more documented of teh phenomenon so people using these features can be more adware of it.

Or use custom room properties.

I think that may reset the follower's animation every loop, making it sluggish, moreover, it should be MoveCharacterBlocking() I think.

[X]

I didn't read much, but are you sure that the falling animation is using the "down" direction loop of the character?
Moreover, I don't quite understand why you set his target X coordinate to "100+Random(60)", if he's falling down, shouldn't his X coordinate be the same as that before he falls? Unless that "random" parameter was actually intended for his Y coordinate, so you may have got the X,Y coordinates swapped.

What I was thinking is:
MoveCharacterBlocking  (i, character.x,100 + Random (60),  1);