AGS 2.72 Final 2 - World Cup Edition

Started by Pumaman, Sat 14/01/2006 22:47:30

Previous topic - Next topic

Gilbert

The music folder was for the editor to find its resource, in this case, it looks for music files in the music folder in the game source's folder.

On the other hand, the engine looks for all the files (if not packed into the executable or vox, .ags, etc.) in the game's "compiled" folder, so this is the expected behaviour.

Wretched

Well it seems a bit odd having to have the music in the root and and Music folder yet the sounds just in the Sounds folder. Make sence to me if acwin looked in the music folder.

strazer

Look, the Music and Sounds folders only exist so the game source folder doesn't get clogged up.
When your game is saved/compiled, sounds get compiled into the game exe, digitial music will be bundled into the music.vox file.
Everything you need to distribute the game (except video files) will be put into the Compiled folder.

Wretched

#163
Ah, nevermind I'll just live with duplicate music files.

EDIT: I just thought I'd clarify the problem in the hope it might one day get resolved. If you have have a big game say 50+ rooms, it becomes impracticable to use the test game command as it is too slow. Instead I copy the acwin.exe into the game directory and run it from there (after just needing to do a quick save), this allows instant game testing. Unfortunately as acwin.exe does not look in the media folders, it can't play the music. Seems a shame that this is not catered for as it is such a useful way to test games.

Radiant

#164
What would help is simply testing with a lesser amount of rooms, by temporarily moving room files you won't need at the moment to a storage subdirectory.

By the way could you please implement hotkeys in the "Module manager" menu? In particular, I'd like to be able to close the screen by pressing ESC.

HeirOfNorton

Just noticed this, while playing around. "Auto-number speech lines" does not number any lines that are in a script module. I can see how you might want that, if it's a third-party module, but if you made the module yourself just to separate some of the code, than you might want some of that speech auto-numbered.
Perhaps an option, or a prompt like it does for Display() ?

HoN

Radiant

SetLabelText still truncates the text at 200 characters.

monkey0506

I tried bringing that up...but only brought confusion.

Radiant

#168
Sorry if this message is rather long...

With the latest beta, it is still possible to get the "internal tree processing error" when deleting an (empty) 2nd-level folder of sprites, thus crashing AGS without possibility of saving anything.

My game is 16-bit color. So is my desktop. When I use RawDrawImage and the game is set to windowed mode, the following warning is generated: Sprite 156 colour depth 16-bit not same as background depth 32-bit. Weird.

If a character is set to have no diagonal loops, it kind of makes sense to use loop 4-15 for miscellaneous other animations (e.g. picking things up, stuff like that). A character with no diagonal loops will behave strangely if FaceLocation() is used for it while it is in a loop greater than three. Examples of strange behavior include spinning around, or resetting to frame zero of the loop.

Characters may also start to spin if FaceLocation() is used on them while they're not on a walkable area.

When typing long lines in the editor, the autocomplete suggestions tend to run out of the window, making them illegible.

Exporting a room's additional background frame as a GIF results in an entirely black GIF (the room was 16-bit color, btw).

When exporting a room's additional background frame, the 'default' file format (if nothing else is entered) is the seldom-used TGA. Maybe it should default to PNG or BMP?

When exporting that room's background frame again and typing the same name, AGS will assume it is the TGA file again and complete to 'test.tga'; if I then select e.g. GIF from the pulldown menu, the result is the filename 'test.gif.tga'

From a tester's report, I believe that Windows XP and/or windowed gameplay mode may interfere with SetMousePosition. Running under ME myself I have been unable to verify that.

I would appreciate it if saving when you close the AGS editor defaults to quicksaving rather than fullsaving, given the time taken by the latter. Or, on the "would you like to save" box, add an extra button for it.

If the game has just been quicksaved (or otherwise not been modified), quitting AGS still gives the query "would you like to save the game".

Quicksave also saves things that haven't actually been modified since the last save. In particular for a compressed sprite file, this takes quite a while.

If you quit AGS and select not to save, the editor deletes your executable. AGS also tends to delete the executable at other moments when it decides it would be out of date; this is rather annoying when testing things, and my takes a long time every time since windows automatically backs up executable files whenever they are deleted. I would prefer if there was an option so that AGS never deleted the executable under any circumstances.

This is a weird one... if you press then release the control key, then subsequently press escape, it will not trigger on_key_press.

If you import the global messages from a dumped file, the editor panel that shows them doesn't update and still lists the old one - even if you move to another panel and go back. It works when you quit and restart AGS.

If you quit the editor and decide not to save, it appears that AGS saves some editor information anyway, but not all of it. I believe the current sprite set is saved and the global script is not, or something. This is confusing. It also means you cannot go recover a mistake by quitting, unless you "force-quit" through ctrl-alt-del.

When clicking to change one of a GUI's properties on the floating menu, the old value is automatically highlighted so that any typing will overwrite it. When clicking on an animation frame's delay or sound effect, the old value must be deleted manually.

A font with automatic outlining is wider than one without. In the GUI editor, this is not accounted for; thus any label that has text in an outlined font will look differently in-game.

Wretched

#169
Mouse.SetPosition() is clipping the Y value to the range 0-200, even though the mouse freely moves within the 0-240 range, the 240 letterbox option is greyed out and checked. I've tried using SetBounds(0,0,0,0) and SetBounds(0,0,320,240) but this still happens. Game resolution is 320x240, 32 bit.

Also suggestion for a Mouse.IsOutsideWindow(), to know if, in windowed mode, whether the mouse (i.e. the Windows Mouse pointer) is outside the game window. I want to add a jitter to the mouse but not grab the mouse back if it is outside the game window. Allowing the player to acces the exit application button, or switch to another windows program.

Pumaman

QuoteEDIT: I just thought I'd clarify the problem in the hope it might one day get resolved. If you have have a big game say 50+ rooms, it becomes impracticable to use the test game command as it is too slow. Instead I copy the acwin.exe into the game directory and run it from there (after just needing to do a quick save), this allows instant game testing. Unfortunately as acwin.exe does not look in the media folders, it can't play the music. Seems a shame that this is not catered for as it is such a useful way to test games.

I will resolve this for the Sounds folder so that the engine will look in the Sound sub-folder, however for now for music and speech you'll just need a copy of the VOX files in the game folder if you want these to work.

QuoteJust noticed this, while playing around. "Auto-number speech lines" does not number any lines that are in a script module. I can see how you might want that, if it's a third-party module, but if you made the module yourself just to separate some of the code, than you might want some of that speech auto-numbered.
Perhaps an option, or a prompt like it does for Display() ?

I'm not sure about this one, I wouldn't like it to be changing module code ... and if it did, it'd need a per-module option for whether to number the lines or not. I'd prefer to say that modules shouldn't really have any hard-coded speech strings in them, ideally.

QuoteSetLabelText still truncates the text at 200 characters.

It does, however Label.Text="" will now allow you to have 2048 characters. I have tested this with a 350 character string and had no problems.

QuoteSorry if this message is rather long...

Sorry, in future could you try to post things in smaller installments, as it is it's quite difficult for me to verify whether all these issues are bugs or not before I reply to the thread.

HeirOfNorton

Quote from: Pumaman on Sun 19/03/2006 18:32:02

QuoteJust noticed this, while playing around. "Auto-number speech lines" does not number any lines that are in a script module.

I'm not sure about this one, I wouldn't like it to be changing module code ... and if it did, it'd need a per-module option for whether to number the lines or not. I'd prefer to say that modules shouldn't really have any hard-coded speech strings in them, ideally.

Yeah, I can understand this. I mainly noticed it playing around with my IconDialog module , in which the user HAS to put the dialog into a module for it to work right.
(which I keep meaning to debug/update, but I'll probabky wait until 2.72 final, just in case you decide to continue updating the dialog system like you've started...  ;D)

It may yet be possible to work around, now that I know about that limitation. I'll think on it a bit. If nothing else, I could do it as a template instead of a module.

HoN

Pumaman

#172
QuoteWith the latest beta, it is still possible to get the "internal tree processing error" when deleting an (empty) 2nd-level folder of sprites, thus crashing AGS without possibility of saving anything.

Is there any way you can reliably reproduce this? I have tried to do it myself but have been unable to get the problem.

QuoteMy game is 16-bit color. So is my desktop. When I use RawDrawImage and the game is set to windowed mode, the following warning is generated: Sprite 156 colour depth 16-bit not same as background depth 32-bit. Weird.

The room background itself might be 32-bit. Unfortunately this bit of information is not shown anywhere in the editor (I'll add it for the next beta).

QuoteIf a character is set to have no diagonal loops, it kind of makes sense to use loop 4-15 for miscellaneous other animations (e.g. picking things up, stuff like that). A character with no diagonal loops will behave strangely if FaceLocation() is used for it while it is in a loop greater than three. Examples of strange behavior include spinning around, or resetting to frame zero of the loop.

I'll look into this.

QuoteWhen typing long lines in the editor, the autocomplete suggestions tend to run out of the window, making them illegible.

Fair point, but it's not too serious. This seems to just be the way that the text editing component that AGS uses works, so it's probably not something I can change.

QuoteExporting a room's additional background frame as a GIF results in an entirely black GIF (the room was 16-bit color, btw).

Yes, if you attempt to export a 16- or 32-bit background as a GIF, you'll get a black image. This is because GIF only supports 8-bit, and it seemed a better idea to give an obviously wrong black output than to dither it down to 8-bit colour and get complaints that the export had made the colours go funny.

QuoteWhen exporting a room's additional background frame, the 'default' file format (if nothing else is entered) is the seldom-used TGA. Maybe it should default to PNG or BMP?

Yes, I'm not sure why it chooses TGA -- I guess it could be that it chooses the last one in the list. I'll see if I can change this.

QuoteWhen exporting that room's background frame again and typing the same name, AGS will assume it is the TGA file again and complete to 'test.tga'; if I then select e.g. GIF from the pulldown menu, the result is the filename 'test.gif.tga'

This is probably some strangeness with the Windows File Dialog, I don't know that I can do anything about it.

QuoteFrom a tester's report, I believe that Windows XP and/or windowed gameplay mode may interfere with SetMousePosition. Running under ME myself I have been unable to verify that.

Interfere with it in what way?

QuoteI would appreciate it if saving when you close the AGS editor defaults to quicksaving rather than fullsaving, given the time taken by the latter. Or, on the "would you like to save" box, add an extra button for it.

I guess this is a reasonable idea.

Quotef the game has just been quicksaved (or otherwise not been modified), quitting AGS still gives the query "would you like to save the game".

Yes, the editor does not currently have a "game dirty" type flag so it doesn't know if the game needs saving. This would actually be quite difficult to add so it's unlikely to be fixed anytime soon.

QuoteQuicksave also saves things that haven't actually been modified since the last save. In particular for a compressed sprite file, this takes quite a while.

Again, because there is no concept of a dirty flag, it will save everything. The only exceptions to this are the sprite file and the script compilation, which it can skip if no changes have been made.

However, with the sprite file don't confuse the actual creation of the .spr file (which will be skipped if unchanged) with the creation of the ac2game.dat data file (which includes the sprite file, and will be generated regardless).

QuoteIf you quit AGS and select not to save, the editor deletes your executable. AGS also tends to delete the executable at other moments when it decides it would be out of date; this is rather annoying when testing things, and my takes a long time every time since windows automatically backs up executable files whenever they are deleted. I would prefer if there was an option so that AGS never deleted the executable under any circumstances.

This is to make sure that people don't accidentally run the old EXE file and then start complaining that "AGS has lost my changes" and so on.

QuoteThis is a weird one... if you press then release the control key, then subsequently press escape, it will not trigger on_key_press.

That is a strange one, seems like it's something wierd with allegro, I'll have a look at it.

QuoteIf you import the global messages from a dumped file, the editor panel that shows them doesn't update and still lists the old one - even if you move to another panel and go back. It works when you quit and restart AGS.

Well spotted, I'll get it fixed.

(Edit by strazer: AGS v2.72 Beta 6: * Fixed Global Messages pane not updating after Importing Dumped Text.)

QuoteIf you quit the editor and decide not to save, it appears that AGS saves some editor information anyway, but not all of it. I believe the current sprite set is saved and the global script is not, or something. This is confusing. It also means you cannot go recover a mistake by quitting, unless you "force-quit" through ctrl-alt-del.

If you quit the editor and choose not to save, nothing at all is saved. The only information that AGS saves in that case is the editor window size, no game data is saved. What is giving you the impression that it is saving something?

QuoteA font with automatic outlining is wider than one without. In the GUI editor, this is not accounted for; thus any label that has text in an outlined font will look differently in-game.

This is only 1 pixel so shouldn't make a difference in the majority of cases, but I see your point. Is it GUI labels where this is particularly noticable?

QuoteMouse.SetPosition() is clipping the Y value to the range 0-200, even though the mouse freely moves within the 0-240 range, the 240 letterbox option is greyed out and checked. I've tried using SetBounds(0,0,0,0) and SetBounds(0,0,320,240) but this still happens. Game resolution is 320x240, 32 bit.

Thanks for spotting that, I'll get it fixed.

(Edit by strazer: AGS v2.72 Beta 6: * Fixed Mouse.SetPosition clipping the Y to 200, even in 320x240 games.)

QuoteAlso suggestion for a Mouse.IsOutsideWindow(), to know if, in windowed mode, whether the mouse (i.e. the Windows Mouse pointer) is outside the game window. I want to add a jitter to the mouse but not grab the mouse back if it is outside the game window. Allowing the player to acces the exit application button, or switch to another windows program.

I'm not sure how difficult this would be to implement, but I'll take a look at it.

SSH

Quote from: Pumaman on Mon 20/03/2006 15:38:34
QuoteThis is a weird one... if you press then release the control key, then subsequently press escape, it will not trigger on_key_press.

That is a strange one, seems like it's something wierd with allegro, I'll have a look at it.

Sounds like Windows' StickyKeys to me
12

Radiant

Quote from: Pumaman on Mon 20/03/2006 15:38:34
QuoteWith the latest beta, it is still possible to get the "internal tree processing error"
Is there any way you can reliably reproduce this? I have tried to do it myself but have been unable to get the problem.
I'm afraid not. It happened only once, most of the time it works fine (including after reloading immediately). Is there any particular information I should write down if it happens again?


Quote
QuoteMy game is 16-bit color. So is my desktop. When I use RawDrawImage and the game is set to windowed mode, the following warning is generated: Sprite 156 colour depth 16-bit not same as background depth 32-bit. Weird.
The room background itself might be 32-bit. Unfortunately this bit of information is not shown anywhere in the editor (I'll add it for the next beta).

I should point out that these warnings didn't happen in the last non-beta version of AGS.

The room probably is 32-bit, since I've imported it from a 24-bit BMP file. However, I'm wondering why it works this way? If a game is 16 bit, then it won't ever display a 32-bit background as other than 16-bit, thus needlessly increasing disk size and processor load. Can I decrease my game size by (nearly) half by importing 16-bit backgrounds (and, assumedly, sprites)? And how do I do that?


QuoteYes, I'm not sure why it chooses TGA -- I guess it could be that it chooses the last one in the list. I'll see if I can change this.

This is probably some strangeness with the Windows File Dialog, I don't know that I can do anything about it.

IIRC there's some obscure flag you can use to fix both of these. If you're using CFileDialog, the parameter "LPCTSTR lpszDefExt" should fix the former. I'm not sure what windows quirk caused the latter, but it might be solved by adding an "all files|*.*" option to the end.


Quote
QuoteFrom a tester's report, I believe that Windows XP and/or windowed gameplay mode may interfere with SetMousePosition.
Interfere with it in what way?
Oh, sorry. Interfere as in causing the SetMousePosition() call to be ignored (or overridden) by the Windows kernel. By the way it wasn't related to windowed mode, it also happens in fullscreen mode, but not on all computers. Sorry that I can't be more helpful about this. I'll try if I can construct a demo for it.


Quote
However, with the sprite file don't confuse the actual creation of the .spr file (which will be skipped if unchanged) with the creation of the ac2game.dat data file (which includes the sprite file, and will be generated regardless).

Okay, but isn't that the complete game data file except it's not linked to the AGS runtime? Does a quicksave have to recreate that?


Quote
QuoteA font with automatic outlining is wider than one without. In the GUI editor, this is not accounted for; thus any label that has text in an outlined font will look differently in-game.
This is only 1 pixel so shouldn't make a difference in the majority of cases, but I see your point. Is it GUI labels where this is particularly noticable?

Yes, mostly labels; buttons tend to be graphical, or wider than their text. Case in point, I made some GUI labels with minimal width in order to fit more text on the screen, then when running the game I found out that all that text is actually a couple pixels wider so part of it gets moved to the next line. It's no big deal but it is unexpected.


Quote
QuoteIf you quit AGS and select not to save, the editor deletes your executable.
This is to make sure that people don't accidentally run the old EXE file and then start complaining that "AGS has lost my changes" and so on.

I understand that, but could you please have an option to turn this off? Pretty please with sugar on top? It does cause a lot of disk trashing here (with a 25-meg executable). Also, when I have the executable running and am editing in AGS in another window, AGS's attempts to delete the executable anyway and fails after a timeout. Then again I'm probably the only one coding 25-meg games on a low-end system :)


Pumaman

Quote from: Radiant on Mon 20/03/2006 16:44:34
The room probably is 32-bit, since I've imported it from a 24-bit BMP file. However, I'm wondering why it works this way? If a game is 16 bit, then it won't ever display a 32-bit background as other than 16-bit, thus needlessly increasing disk size and processor load. Can I decrease my game size by (nearly) half by importing 16-bit backgrounds (and, assumedly, sprites)? And how do I do that?

Current versions of AGS should automatically convert backgrounds to the game colour depth, so if you import one now it should get changed to 16-bit. This didn't used to happen so it might be that you originally imported the background with an earlier version of AGS.

Quote
Okay, but isn't that the complete game data file except it's not linked to the AGS runtime? Does a quicksave have to recreate that?

I've rechecked the code and a quick save does not recreate that. What makes you think it's saving something that it shouldn't?

Quote
I understand that, but could you please have an option to turn this off? Pretty please with sugar on top? It does cause a lot of disk trashing here (with a 25-meg executable). Also, when I have the executable running and am editing in AGS in another window, AGS's attempts to delete the executable anyway and fails after a timeout. Then again I'm probably the only one coding 25-meg games on a low-end system :)

Well, if you have some sort of application running that keeps backing up EXE files when they get deleted, could you turn it off or disable it for your game EXE? Alternatively, you could enable Split Resource Files which will significantly reduce the EXE file size.


Anyway, beta 6 is now up ... nothing in particular of note, various fixes and minor bits and bobs.

Radiant

Quote from: Pumaman on Mon 20/03/2006 21:53:22
Current versions of AGS should automatically convert backgrounds to the game colour depth, so if you import one now it should get changed to 16-bit. This didn't used to happen so it might be that you originally imported the background with an earlier version of AGS.
Thanks, I'll go re-import everything then and see if that works (or, if you plan on implementing an indicator some time soon, I'll wait for that).

Speaking of which - it would be rather useful if, in the sprite list, there was an indicator as to which sprites were in a different resolution (e.g. 640x480) or in a different color depth (because those are likely an author's mistake that is hard to see as of now). Maybe in the right-click menu "select all sprites with such-and-such resolution" would help.


Quote
Quote
Okay, but isn't that the complete game data file except it's not linked to the AGS runtime? Does a quicksave have to recreate that?
I've rechecked the code and a quick save does not recreate that. What makes you think it's saving something that it shouldn't?
Mainly the amount of time it takes to quicksave anything. Come to think of it that could also be because my global script is rather large.


QuoteWell, if you have some sort of application running that keeps backing up EXE files when they get deleted, could you turn it off or disable it for your game EXE?
Not really - it is part of windows' really idiotic System Restore function, that is so integrated with everything that I have been unable to turn it off. When I manually delete big EXEs, I rename them first. I'll give split resources a try, though.


Speaking of split reosurces. This is probably a rather complex idea, but it would be really nifty for testing purposes if it were possible to upgrade things without having to redistribute the entire game. In particular, the global script or any particular room file. You're probably aware that Sierra games allow this (they always look for 'loose' resource files first, and if none are found they check their big library files; thus you can 'upgrade' any script by simply dumping a script file in the game directory). So I guess this would be something like "if a file 42.crm (or globalscript.txt) exists in the current directory, load that instead of grabbing it from the resource library".

monkey0506

Hmm...that last suggestion sounds potentially dangerous to me.

Thanks for the new beta Chris.

Radiant

Quote from: monkey_05_06 on Mon 20/03/2006 22:35:38
Hmm...that last suggestion sounds potentially dangerous to me.

You mean that I can haxx0r your game by replacing one of the rooms by mine? Sure, but some kind of signature code could prevent that, and at any rate I fail to see how that would help me finish your game easier, or screw it up royally, or indeed do anything that isn't completely pointless.

InCreator

#179
I like the resource upgrade idea and I think it would be useful.
Full support here.

Why are we downloading versions of games *just released* again and again? Most of games are released untested (or poorly tested, to be correct), and bugs will be noticed very quickly. But for a 40+ MB game, well... That's a pain to download whole thing again just to prevent some stupid lockup bug in second room.

Bugfixes would be much easier to make this way. Not sure how difficult would it be to implement this, though...

SMF spam blocked by CleanTalk