Messages

@CW:  That was it!  Changed from DD5 to D3D9 and all works perfectly now.  Thank you so much...

3. When  testing the game from the editor, in a windowed mode, the screen flashes black (more than once) before going back to normal and running the game.

Hmm, that doesn't happen to me, I can't think of anything that I've done that can cause that.
Maybe it's related to #4.

I just checked, it also happens using AGS3.2.1.  I didn't remember this happening before either.  But I am running on Win7-Dell-x64 now?  Any ideas?

4. Running the compiled version (i.e. the exe) gives an error complaining about font-0.
   (Isn't there anything anyone can do about not being able to clip the error messages out of the message box?)

Also doesn't happen to me, can you provide a screenshot with the error message?

Turns out I copied the exe out of the _Debug folder to the compiled folder to get this error.  If I turnoff debug mode and rebuild AGS puts the proper exe in the compiled folder and it works as it should.  Sorry for the false alarm.

I guess this goes way back to V2.1 or earlier ... When starting a game, on Windows 7, in widowed mode the scree goes black for an instant and then everything comes back to normal and the game window appears.  I don't remember if this happens on earlier versions of windows or not but.  Can something be done about this as it's really annoying?  Thanks

[edit]
CW told me to change from DD5 to D3D9 and that fixed everything..

I have a couple suggestions:

1.  Display runtime errors so that the error test can be selected, copied to the clipboard, and pasted into a forum post or email.

2.  Make command line arguments available to the script.  Probably needs some editor work as well to accomplish.

tzachs: found a couple of apparent bugs ..

1. No default templates n your distribution so can't create a new game.  Perhaps at least provide a blank template.

2. Loading a game from a previous AGS version (3.2.0), editor doesn't detect, inform, or perform upgrade. 

3. When  testing the game from the editor, in a windowed mode, the screen flashes black (more than once) before going back to normal and running the game.

4. Running the compiled version (i.e. the exe) gives an error complaining about font-0.
   (Isn't there anything anyone can do about not being able to clip the error messages out of the message box?)

I would like to suggest that the conventions also include a file naming convention for editor and engine distributions so that when people post their latest and greatest AGS version the zip or rar files will be named consistently so that the origin and lineage of a specific version can be determined by it's zip file name. 

For example a monkey alpha version of the editor and a beta version of the engine, derived from AGS V2.2.1,  would perhaps look something like the following:

AGSEDIT-V2.2.1-MKY-A00.01.ZIP   
AGSENG-V2.2.1-MKY-B01.01.ZIP

The format isn't really important as long as it contains enough information to identify the distribution and  doesn't break the internet.  So feel free to modify or invent something that serves the above stated purpose.  If we can agree on something it would be beneficial to all.

I would also like to suggest that there be a standard format or convention for release threads similar to how CJ used to do it.  First post to contain synopsis of distribution, change log for various versions, and link to latest version.  Subsequent posts to contain bug reports, support, feature/testing discussions, etc.

Sorry for sort of hijacking the thread as this isn't exactly "Engine Coding Conventions" but it is intimately related and will be decided and used by the same group of people.

Rick

@Crimson:  I agree with your point, and have done similar things in the past.   But since it actually does something I didn't think of it as being empty ... although I suppose it actually is.  The only thing I (and presumably you also) would change in the example is the eol comment.

Code: c++

for (int i = 0; i < ptr_array.size && ptr_array[i] != NULL; ++i) ; // find first free slot in pointer array

Nice job monkey, very nice job.  The others make some good points to consider.  The final draft of course ought to reflect the consensus of the people doing the work.  Adopting a consistent set of conventions that everyone can live with is more important than adopting the "absolutely most best out standing standard", because that one probably doesn't exist; though you have come pretty close.  This is just my caution to everyone to not get all religious  about this .

Here are a couple of my opinions on a couple of issues:

1.  I prefer the c_style_notation for parameters and local names.

2.  Curly braces {} I have used both styles (opening brace on same or next line) and don't think one is better than the other; it's more a question of personal preference.

3.  I agree with monkey about pointers, i.e. int *doThis; // Preferred

4.  Indent of 2 spaces is too small.  Btw what's the deal with even numbers here?  It doesn't matter but I'm just curious.

5.  Empty Loops - Presumably empty loops are place holders for future code.  In this case wouldn't it be better to document why the loop is empty?" 

Code: c++

while (false) {
    // Future stuff goes here ...
}

6.  Block Comments /* */ - I agree with monkey.  If they are not normally used then they could be used during testing to comment out whole sections of code.

7.  Block or Banner Comments vs end of line comments -  I think there needs to be some discussion on when/how to use each ..

I think you guys are all doing a great job.  Keep up the good work...

@Joseph:  What language is the following written in?

Code: ...

  if( condition ) 
  {
    // Do something if condition is true
  }

  if( value < 10 ) 
  {
    // Do something if value is less than 10
  }
  else
  {
    // Do something else if value is greater than or equal to 10
  }

  :
  :

  // Loop, where the condition is checked before the logic is executed
  int i = 0;
  while( i < 10 )
  {
    // Do something
    i++;
  }

  // Loop, where the logic is executed before the condition is checked
  int j = 0;
  do 
  {
    // Do something
    j++;
  } while( j < 10 );

Spoiler

http://www.angelcode.com/angelscript/sdk/docs/manual/doc_script_statements.html

[close]

Looks a lot like AGS script doesn't it.  They have an army of contributors and even more users.  It seems foolish to reject such options out of hand without even taking a look or having a discussion about it.  Heaven forbid if we happen to learn something along the way.  Imagine that...a group of humans getting together and making an informed and objective decision...the world would probably come to and end.  

How do you think AGS's fabulous script editor came about?  It was an off the cuff comment to CJ similar to "You may want to have a look at this  scintilla.org".  Honestly, if you people were running the show back then it would have never happened.

[TextBox]

Here is my wish list for improvements to the GUI system.  Likely most of the following will also require changes/additions to the engine but I thought I would start here.

TextBox - Currently the (all instances) text input box always has focus all the time.  I would like to suggest that there be an option to put multiple TextBoxes on a GUI and a settable option to give them focus via click or tab/key press.

Add the following controls:

• MultilineText - alignment options right, left, center, and justify.
  
• RadioButton/CheckBox - or see containers next
  
• Containers - Allow a gui to contain other guis or groups of controls.  Thgis would allow people to make reusable widgets consisting of multiple controls.
  
  And some pie in the sky.;..
  
• HTML Viewer - sort of like a text box only it can display HTML and navigate hyper links.  Maybe it could be better done via plugin and use webkit or other browser engine. 
  
• GUI/Control Plugins - is it possible to write plugins that add controls to the editor?

I agree with what Snarky says about his.  His comments about JS and live editing are interesting in that google has released V8 their Chrome/JS engine as open source.  One has to wonder if the game engine couldn't just be built around V8?  And if this were the case what else would have to be in place for AGS games to run on standards compliant browsers?

The upside to using a fully developed language is that there would not be a need to add new or a need to maintain a compiler.  People and resources that would otherwise be spent on language definition and compiler maintenance would be able to spend their time on other things such as editor improvements, engine portability, plugins, etc.

The downside is of course there will be a disruption in the community.  Effort would have to be spent making libraries, translators, and/or other technological measures to maintain some degree of compatibility with the current language and/or to provide an upgrade path.

I think it would be foolish not to take a look at the possibilities and objectively weigh the pros and cons.   

[WIKI BAD! DEVELOPERS DOCUMENTING THEIR OWN WORK GOOD! OTHER PEOPLE CONTRIBUTE, DEVELOPERS REVIEW GOOD!]

@Timo ... WTF?

1.  I didn't say anything about CHM!
2.  I didn't say anything about MS, Linux, or any other OS
3.  I didn't say anything about mono, forks, stagnation, or anything of that nature.
4.  Your response to my comments are irrelevant to the conversation, please go back and read the previous posts so you know what is being discussed.

what I said was ...

WIKI BAD! DEVELOPERS DOCUMENTING THEIR OWN WORK GOOD!  OTHER PEOPLE CONTRIBUTE, DEVELOPERS REVIEW GOOD!

I appoligize for shbouting but some people don't hear very well...

Wiki is a bad idea because there will always be clueless people about who think they know more than everyone when in fact they know very little. 

This is not even the main point of my comments, the main point was ...

ABILITY TO ADD SUPPLEMENTAL HELP FILES TO AGS HELP MENU GOOD!

If someone were to make a TCP/IP Communication Plugin what lib should they use to make it cross platform compatible?  Also do we have source available for one already as a reference?

I also agree on making all of them open source.  We ought to put a statement saying so in the plugin programming guidelines. 

Why do you want to split between standard and user created? That means the standard one gets less updated and users will start something new instead. And there will be overlaps. Why not one good documentation where everyone can contribute?

I am not advocating that the standard help file be split.   What I am suggesting is that there are other materials beyond the scope of the AGS Manual and that it would be useful if those materials could be made available in the same form as and from the same menu as the standard help file.   You concede the point about modules but how about such things as templates, tutorials, programming conventions?  For group projects there could also be project specific guidelines, storyboard, instructions and policy on archiving and repository submissions, etc.   

I don't see how any of that would fragment the AGS Manual.  A wiki on the other hand would do exactly that; over time the AGS manual would become fragmented, self inconsistent, less concise and less understandable.   Changes to the standard AGS Manual ought to go through the save review process and receive the same scrutiny as changes to the editor and engine code.       

...But I'd like it even more if there was a way to add useful articles (I learned all about the way you write functions as part of a struct by looking how SSH's modules did just that, for example) quickly to the helpfile...

I don't think Ghost is talking about a wiki at all.  What's needed here is the ability to access multiple help files from the editor's menu.  If someone were to make a module they could also make a help file, perhaps using the same tools and methods use to make the AGS help file.  There would also be value in having tutorials and other supplemental docs as add on help files.  There would be help files that are present on every AGS project and there would be help files present on per project basis.  So probably the ones present on every AGS project would live with the editor install directory and the per project ones would live in the project directory.  Help files tied to a module would be available to every AGS project but only included if the project uses the module.   

Of course to manage everything there would have to be categories of help, both standard and user created.  This would require the AGS editor to support the concept of sub-menus.  Ohhh! if only someone would think to implement such a feature how sweet life would be . 

I don't like the idea of automatic updates to help files.  Although a manually initiated tool that could update one or all would possibly be useful.   

The big advantage I see with AGS is that it's relatively easy for someone with little programming experience to create a game. I think the goal should be to make it easier for those people, not add more complex language structures or more languages (unless they are necessary or cause things to be obscure today).

The ironic perversion is that lack of support for function and structure pointers and many of the other language features conspire to make things more difficult for inexperienced programmers.  For example, would make it possible for a predefined module to call later/user defined functions, for predefined modules to be dynamically/programtically bound to gui controls, to have call back functions, to create event handling modules, as well as jump tables and other higher level, easier scripting gadgets as Crimson describes.   The kinds of things we are talking about here would allow more functionality to be encapsulated into predefined modules that hide the underlying complexity from the module user. 

Since there is effort to separate editor-compiler-runtime, one has to wonder if it wouldn't be easier and better to just move to an existing high level OO script language such as python, angel script, etc, etc, ...?  We would end up with a full featured language complete with compiler/runtime and wouldn't need to expend any effort on compiler and related issues. 

Just for good measure set the first enumerated value equal to 0 which is currently the default behavior but not necessarily guaranteed.  Then as monkey says use end or none as the last enumerated value.

I think both features are reasonable additions.  Since Monsieur OUXX has already implemented them I see no reason why they should not be included.   

I'll probably at least update the social media aspects of the site to reflect modern preferences (remove ICQ!).  I'll look at social bookmarking too, assuming it's not too cluttering and annoying.

Please reconsider.  I highly value privacy and don't want to have any part of facebook or be anybody's facebook friend.   I don't even want anybody to "Like" me.  I Really believe we would be much better of without it.

[edit]
Ah! Just realized you were talking about the website and not the forum.  Facebook and their ilk are never the less annoying scumm;  the cyber equivalent of STDs that are best to avoid.