AGS 2.71 Final 2 - Politically Correct Edition

Started by Pumaman, Sun 05/06/2005 23:32:14

Previous topic - Next topic

Rui 'Trovatore' Pires

#20
CJ - yeah, 4 or five full loops 16bit color 640x480. But ingame, and even with sprite compression on, no noticeable slowdown. And yeah, the problem with deleting the folder happens every time. I've ever rebooted (on unrelated reasons, but a reboot's a reboot). No luck, it still happens. And BTW, maybe something got corrupted somehow, becase I made a NEW folder and tried to delete it... and WHAM, got the error again... :(

EDIT - Oh, and there were also 3/4 loops with a regular-sized sprite, I don't remember what it was but it was about 50x70... maybe. It's an estimate from memory, so that's probably wrong. The point is, the grand total of loops in that view was 7/8. But the problem disappeared when I cleared the 4/5 loops of huge sprites.
Reach for the moon. Even if you miss, you'll land among the stars.

Kneel. Now.

Never throw chicken at a Leprechaun.

Pumaman

Hmm, can you create a New Game and try to delete a sprite folder? See if we can check whether it's your PC or something specifically in your game?

Rui 'Trovatore' Pires

Hmm, probably my PC... it didn't work either. I started a new game, I randomly chose the Discworld template, and tried to delete a folder - no luck.

Ah well, I guess I'll have to live with it.
Reach for the moon. Even if you miss, you'll land among the stars.

Kneel. Now.

Never throw chicken at a Leprechaun.

Pumaman

It's probably a rather obscure bug in AGS that only shows up in certain circumstances, I doubt it's actually a problem with your PC.

Does anyone else get this problem when trying to delete a sprite folder?

Did you have the problem with 2.7 ?

bullfrog

#24
I get the same error message.

Then I create new sub-folders and delete them several times in AGS 2.7..

I get  randomly an error box "Internal error in tree processor (callfrom 0)"

____________
Sorry...my English sucks... ::)

Gregjazz

Quote from: monkey_05_06 on Mon 06/06/2005 17:15:30
Quote from: JLM on Mon 06/06/2005 15:32:36
By the way... Are you going to implement a new conversation system (or something) to AGS 2.71? I mean especially a feature to define different colors for read/unread topics. It would be necessary option for my game.

EEK!  Don't do that! :o

Heheh, I just got my own dialog thing working, too! I may just upload the source code sometime, too. It's very simple and easy to use.

HeirOfNorton

Quote from: Rui "Brisby" Pires on Mon 06/06/2005 15:25:22
"We're sorry, the AGS editor has encountered a serious error (yadda yadda yadda) Exception 0x00000000 at EIP 0x00000000, AGSEDIT v2.71.605, SIP=26, please not the numbers above yayya-yadda-yadda."

I get the exact same error with a couple of large arrays in a struct, more detail in the other thread:

http://www.adventuregamestudio.co.uk/yabb/index.php?topic=21191.msg258912#msg258912

HoN

Pumaman

I've just looked into it further and there is indeed a bug when deleting sprite folders. It affects 2.7 too. I'll get it fixed for the next beta.

monkey0506

Quote from: JLM on Mon 06/06/2005 15:32:36I mean especially a feature to define different colors for read/unread topics.

I just noticed this part.  I'll have to implement that into the new SM... ::)

And Chris I swear if you beat me to this, I am going to...well...I'll probably just bow down at your feet for finally updating the dialog system...

strazer

#29
What do you think about renaming the built-in enum names from "Direction" to "AGS_Direction" for example to decrease the likelyhood of them being used as variable names by the user and thus causing conflicts?

And now that we are able to flip dynamic sprites, I think it would be essential to be able to determine if a view frame is flipped or not (via GetGameParameter or whatever).

Oh, and how about DynamicSprite.CreateFromBackground(int background_frame) ?
That would make manipulating the background a lot easier.

Things from the tracker that I think are long overdue:

- Crossfading problem when changing rooms
- Better character collision handling
- topic-option-on/-off/off-forever
- Turning off startup dialog script
- eEventBeginDialog / eEventEndDialog
- Allow "repeatedly_execute" in room scripts
- Crossfade ambient sounds

Edited by Gilbert: Hehe how come you still posted this to the old thread when we're at a new version cycle already, especially when the suggestions are related to feaqtures in the new beta ? :=

Edit by strazer: Whoops! Thanks! ;D

Gilbert

Quote from: Pumaman on Mon 06/06/2005 19:10:18
QuoteHaven't tried it yet, however, since it's possible that not all sprite are loaded at once, in time critical events (like cutscenes which required music synchronizing animations, etc.) it can make the animations jerky (for loading sprites). I'll suggest adding 2 functions, like (well, sorta stole the idea from how AGI works):
PreloadSprite(int slot)
and
ReleaseSpriteControl(int slot)
QuoteIs there any way to pre-populate the cache, if a particular cutscene uses a lot of new sprites?Ã,  Something like:

Well, this would certainly be possible. The question is, is there a performance problem in this sort of scenario? I can certainly add a feature like that if necessary, but is it necessary?
Well, I'm not quite sure, but that can be handy if it's really a LARGE game with TONS of sprite, which doesn't apply to me (I think I won't make that kind of HUGE games anyway, moreover for some reasons I'll stick to V2.62, at least for now), unless the game players set the sprite cache to as low as, like 2MB in setup, which I can't prevent.

Pumaman

Quote from: strazer on Tue 07/06/2005 08:23:21
What do you think about renaming the built-in enum names from "Direction" to "AGS_Direction" for example to decrease the likelyhood of them being used as variable names by the user and thus causing conflicts?

Well, there's two possible problems:
1. if people are already using them as variable types (eg. custom functions taking a Direction parameter) it could cause problems to change them
2. the script editor call-tips could look a bit odd with "AGS_Direction" as one of the parameters

Quote
And now that we are able to flip dynamic sprites, I think it would be essential to be able to determine if a view frame is flipped or not (via GetGameParameter or whatever).
Oh, and how about DynamicSprite.CreateFromBackground(int background_frame) ?

Those are reasonable enough requests, if anyone else would find them useful?

Quote
eEventBeginDialog / eEventEndDialog

On the subject of this, can anyone think of a better name for a new handler than "on_event_always" ... it would sound a bit crap calling it that.

Quote
Well, I'm not quite sure, but that can be handy if it's really a LARGE game with TONS of sprite, which doesn't apply to me (I think I won't make that kind of HUGE games anyway, moreover for some reasons I'll stick to V2.62, at least for now), unless the game players set the sprite cache to as low as, like 2MB in setup, which I can't prevent.

I've been wondering about changing the sprite cache size options, actually. Realistically 2 MB is far too small and nobody has that little RAM. Also, with 640x480x32 games, you won't fit many sprites into the default 10 MB cache size, so maybe I should replace the options with 10, 25 and 50 MB.

Gilbert

Quote from: Pumaman on Tue 07/06/2005 19:50:34
Quote
And now that we are able to flip dynamic sprites, I think it would be essential to be able to determine if a view frame is flipped or not (via GetGameParameter or whatever).
Oh, and how about DynamicSprite.CreateFromBackground(int background_frame) ?

Those are reasonable enough requests, if anyone else would find them useful?


This can actually be very useful, even better, if CreateFromBackground() can accept 4 more optional parameters:
DynamicSprite.CreateFromBackground(int frame, int x1, int y1, int x2, int y2)
Which clips the sprite in a rectangular area.

Rui 'Trovatore' Pires

Just one little thing I thought I'd mention which is pretty much common knowledge but undocumented. Maybe it should be in the manual that if you have a "text window" set us as the dialog GUI the options will be centered on the screen and the text window will resize to fit the options. I mean, it's quite nifty, but if it ain't in the manual, how's people gonna know?
Reach for the moon. Even if you miss, you'll land among the stars.

Kneel. Now.

Never throw chicken at a Leprechaun.

monkey0506

Something else I would like to see is user-defined optional parameters (i.e., allowing us to create them for our own functions).  I've come across several instances where it would be much easier to just leave the parameter out instead of having to #define a ***_DEFAULT action for *** action.  Not a high priority task I guess, but it would have its perks. :=

strazer

That works fine already, just like with normal optional parameters:

Code: ags

// main script

function SomeFunction(MyEnum thevar) {
  Display("%d", thevar);
}


Code: ags

// script header

enum MyEnum {
  eFirst = 2, 
  eSecond = 3
};

import function SomeFunction(MyEnum thevar=eSecond);


GarageGothic

Some feedback:

1) I don't feel any difference with the editor sprite caching, except perhaps that there's a bit more hard drive acces when opening up a sprite folder.

2) Sprite compression doesn't cause any slowdowns either on my 2.4GHz P4. On the other hand, it isn't quite as effective as I had hoped. My game .exe file went from 69MB to 55MB, which is decent. But compressing the files afterhand using WinRar, gave me a slightly larger distribution file for the version where the sprites were already compressed (22MB and 23MB). I'll have to see how much this changes when I downgrade my sprites to 16 bit.

I'm very happy with the new DynamicSprite functions. I am wondering though, if it would be possible to add a character.LockGraphicOffset command? I'm aware that it could be a problem as character sprites are normally assigned using the View/Loop/Frame system. But it would allow you to put e.g. a floor reflection at the same x,y as the player sprite and thus use area scaling instead of DynamicSprite scaling (which I understand is slower?). I suppose an alternative would be the already suggested LockObjectOffset command, but for many situations, re-using a character would be preferable to setting up separate objects in every room.

This leads to another question... Is DynamicSprite.Resize actually slower than area scaling if the x/y ratios are identical?

Thanks for a wonderful beta!

bullfrog

Yet another:
We're sorry, the AGS editor has encountered a serious error Exception 0x00000000 at EIP 0x00000000, AGSEDIT v2.71.605, SIP=26,

I created a new GUI and wanted to change its background image.
Same thing with new buttons...

The existing ones work properly...

monkey0506

Quote from: strazer on Thu 09/06/2005 06:59:25That works fine already, just like with normal optional parameters:

Ah...But it only works with global functions. :-\  I'd like to see it available for local functions as well...

Pumaman

QuoteThis can actually be very useful, even better, if CreateFromBackground() can accept 4 more optional parameters:
DynamicSprite.CreateFromBackground(int frame, int x1, int y1, int x2, int y2)
Which clips the sprite in a rectangular area.

I can see the uses for that, I'll certainly consider it.

QuoteJust one little thing I thought I'd mention which is pretty much common knowledge but undocumented. Maybe it should be in the manual that if you have a "text window" set us as the dialog GUI the options will be centered on the screen and the text window will resize to fit the options. I mean, it's quite nifty, but if it ain't in the manual, how's people gonna know?

It is mentioned in the descriptjon for hte "Dialog options on GUI" setting, but perhaps it should be more explicit. I'm not really sure where it should be mentioned, though.

Quote1) I don't feel any difference with the editor sprite caching, except perhaps that there's a bit more hard drive acces when opening up a sprite folder.

If your sprite file is relatively small, you won't notice any difference and in fact it might be slightly slower. The change is designed to speed up loading large games (ie. where the sprite file is getting on for 100 MB), where you do notice the difference.

Quote2) Sprite compression doesn't cause any slowdowns either on my 2.4GHz P4. On the other hand, it isn't quite as effective as I had hoped. My game .exe file went from 69MB to 55MB, which is decent.

The effectiveness of the compression will depend on how much detail is in your sprites. Because it's just basic RLE compression, it'll compress down any transparent areas of the sprite well, but if the sprites are detailed and varied it won't work as well as it would with 'plainer' graphics.

QuoteI'm very happy with the new DynamicSprite functions. I am wondering though, if it would be possible to add a character.LockGraphicOffset command?

If you mean a way to set the character to a sprite slot rather than a view, it would require fairly major changes to AGS. It is currently assumed that all characters have a current view/loop/frame so it's not an easy addition to make.

QuoteThis leads to another question... Is DynamicSprite.Resize actually slower than area scaling if the x/y ratios are identical?

No the actual resize operation is the same speed. But using walkable area scaling, AGS will do tricks like caching the scaled graphic where possible to minimize the amount of resizing it has to do.
Therefore, a simplistic scripting implementation with Resize calls every game loop would be slower.

QuoteYet another:
We're sorry, the AGS editor has encountered a serious error Exception 0x00000000 at EIP 0x00000000, AGSEDIT v2.71.605, SIP=26,

I created a new GUI and wanted to change its background image.
Same thing with new buttons...

Thanks for the info, I've found and fixed the bug for the next version.

SMF spam blocked by CleanTalk