Messages

- the current font needs to go -- and I plan to make one of my own

Might I suggest the 8x14 EGA font? http://www.seasip.info/VintagePC/Images/pgcfont.png

Good luck with the game. Magenta has an amazing look. Bewildered by her own superpowers. I look forward to playing it!

Great stuff, Slasher! We have been enjoying it thoroughly in IRC.

I love the way you voiced all of the characters.

Just a heads up, do not try to play this in DX9 mode like I did. I lost half my progress when I got up to an area that used the flashlight plugin (which is incompatible with DX9).

Other than that, really enjoying it so far. All of the puzzles that seemed insanely difficult (e.g. the steam train) have actually turned out to be quite reasonable. Just a matter of examining and thinking things through.

Really good work with some of the GUIs too. I like the Memory brain GUI.

Wow, Xland devs judging! Yes, that's correct Fitz! I think most people would know its title as released by Epic, Electro Man. Your turn.

I would prefer to break up into two groups. I don't think it's good to keep people waiting in a queue.

6-8 is the magic number, I think. I would be happy with letting us choose a group (8 slots per group), and assigning stragglers by lottery. Just be sure to say somewhere that there are only 3 spots left or we might have to break up into 3 groups.

Yeah, I know. This was a shareware title by one of the biggest 90s shareware publishers too. I'm surprised there wasn't a lawsuit, but they seemed to get away with a lot back in those days.

Sorry, no. The main character looks very similar, but it's not Robocop.

Alright! Your guesses, please...

[imgzoom]http://i.imgur.com/wI2qbxq.png[/imgzoom]

@Gurok and others, unfortunately I was pretty busy lately, and will be even more busy in next 5-10 days on my job (we are having deadlines here too ), so if you post new variant of RTTI feature I may not be responding for some time.

Telling this just in case.

Not a problem, CW. We are all busy with other commitments and jobs. I find it hard to squeeze in time too.

[EDIT:]

I was just about to come in here and post about that, CW

We can't really do a global table because each room is a separate compilation unit. We could perhaps serialise the script-specific table as we are now, but read it back when producing final output (regardless of whether the room was compiled) in order to create a global table. Seems cumbersome and difficult to do. I much prefer the suggestion you made of using a string at runtime. Perhaps the struct name with a script name as a qualifier, e.g. GlobalScript::Weapon

One thing I'm not clear on. To make my proof of concept work, I substituted a type ID for the "size" parameter in SCMD_NEWUSEROBJECT. This allowed SCMD_NEWUSEROBJECT to correctly identify the type of the object it was creating. How do you propose we pass this information to SCMD_NEWUSEROBJECT when the primary type identifier is a string?

EDIT: Regarding my last question, would you be happy if we:
- Use the script-specific type ID only when an object is created
- At that point, create an entry in the global type table using the true name of the type (e.g. GlobalScript::Weapon) if it doesn't exist
- Have the destructor use the global type table to find the type info when deleting the object?
Because I think that could work. I hope that's what you were getting at and I'm not completely off track.

EDIT:

The file format version for scripts was bumped earlier in the 3.3.1 commits, so compatibility-wise the new chunk of info in script files should be fine.

Just being curious, why was it bumped? I probably missed this.

I think I bumped it when new commands (do, for, break, continue) were added. In retrospect, it was probably not a file format change, but it would have been weird to have an earlier interpreter open it.

Also, I need to look into how exported types are loaded when a script is compiled. It's my understanding that the script compiler loads all previously exported symbols and then compiles the script (making it possible for a type ID to refer to types declared in previous modules). I'm not sure if my new "rtype" field gets populated at that time, however.

[inside]

Furthermore, the RTTI should probably be written to separate file in game package. It should include all types from all scripts (I guess this is what it does now?).
I suggest to introduce a new file to the game package, for example "script_rtti.dat", which would contain RTTI info from sym table in a simple format, e.g.:
- RTTI file signature ("AGS_SCRIPT_RTTI")
- RTTI format version (1?)
- the data
You would not need to increase game data version, because this is a separate file. Engine should just check whether it exists. If it doesn't, then scripts will work in "backwards-compatibility" mode, not allowing managed user objects, etc.

This feels a bit wrong to me, only because a game author would need to take this into account. e.g. He/she might need an alternate object management system just in case script_rtti.dat is deleted. I would prefer that we incorporate it into the main output file or add a flag when managed user objects are used so that the resultant game won't start without the script_rtti.dat file present.

No, no, you seem to misunderstand what I mean. The script_rtti.dat will be inside game package, as well as all the other files.
Every script is a separate file too, and deleting them would screw the game anyway.
Game author would not need to worry at all, because this file will be added to final package automatically.
"Game data version" only refers to main game data inside the game package (ac2game.dta) - the one that describes the game generally.

Okay, let me try building a global table instead and get a commit up when I think it's ready for review again. I have a better idea of what to do now.

[EDIT:]

The issues I found:

1. RTTI should not be stored in Script objects, but in a global struct, or inside a global object. By "global" I mean not necessarily literally 'global' in C language, but the one persistent and accessible all the program time.
Why: the managed object must keep the reference to Type, - either a pointer, or numeric Id, - all the time until its deallocation. If it is a pointer - we can't tell if the script we took this reference from will be available when the managed object is destroyed. If it is a numeric id - the managed object class does not have any reference to current (or any) Script (and should not have, because its illogical), therefore it won't know where to take type info from.

This is really hard, but I'll try. Copying the type information to the managed object when it's constructed would also solve the problem.

Furthermore, the RTTI should probably be written to separate file in game package. It should include all types from all scripts (I guess this is what it does now?).
I suggest to introduce a new file to the game package, for example "script_rtti.dat", which would contain RTTI info from sym table in a simple format, e.g.:
- RTTI file signature ("AGS_SCRIPT_RTTI")
- RTTI format version (1?)
- the data
You would not need to increase game data version, because this is a separate file. Engine should just check whether it exists. If it doesn't, then scripts will work in "backwards-compatibility" mode, not allowing managed user objects, etc.

This feels a bit wrong to me, only because a game author would need to take this into account. e.g. He/she might need an alternate object management system just in case script_rtti.dat is deleted. I would prefer that we incorporate it into the main output file or add a flag when managed user objects are used so that the resultant game won't start without the script_rtti.dat file present.

1b. You must not change how existing script commands and their arguments work, i.e. SCMD_NEWARRAY, because thus you will break compatibility with older scripts.

Oops. I take it I screwed up with the changes to read the size of the object. I'll fix that. Where/how should we embed the ID of a type in the compiled script then?

EDIT: My feeling was that we could pass the ID instead of the size to SCMD_NEWARRAY and SCMD_NEWUSEROBJECT, but use the file format to determine how it behaves (if < 90, treat it as size otherwise treat it as an ID)

You may only do the compiler / serialization part. I can take care of the engine part after the compiler will be saving proper data.

2. Maybe we should start using std::vectors for expanding arrays, otherwise we will have to write "expand" function for every new type/array we put into program.
We are moving towards converting all the code to C++ anyway.

I can use those. No problem.

3. I have a thought that maybe we should allow to call "new" on any struct, even ones without "managed" keyword, because there's really no difference. What makes it managed is whether it is created on stack/global data or with "new" keyword. I would like to hear what others think about this.

Ummm, that might get messy when people wonder why they can't return a struct created on the stack. Or wonder how to convert from stack variable -> heap variable. I kind of like the object management system the way it is. It's clunky, but it alleviates potential problem areas.

In order to make an int globally accessible, you need to do a little bit of gymnastics:

In GlobalScript.ash

Code: ags

import int myCounter;

In GlobalScript.asc

Code: ags

int myCounter;

export myCounter;

If you want an easier way to do this, use the Global Variables section in the Explore Project sidebar. It's designed to make this very thing easier.

The problem is that for the variable to shared, the 'instance' of the int needs to exist in a .asc script somewhere. With your current definition, I believe every script gets its own "myCounter".

I need some feedback on this:

https://github.com/gurok/ags/compare/adventuregamestudio:develop-3.3.1...331_runtime_type_information?expand=1

Is it correct?
Is this enough information at runtime?
Can we build upon this to free relevant pointers when managed user objects are deregistered? (I don't know how to do this bit.)

The runtime type information currently presented is:
- total size of the object's type
- an array of offsets for any pointers to managed non-builtin objects contained within

Offsets tell you where the pointer is relative to the base address of the object. e.g. 4 -> pointer is at baseaddr+4

The file format version for scripts was bumped earlier in the 3.3.1 commits, so compatibility-wise the new chunk of info in script files should be fine.

I think this is a small amount of double handling. Is there an argument for dumping the symbol table (and ALL flags about objects) into each script and reading it back? I think not because with the structure of the symbol table, this would mean a long scan of all symbols to get info about the pointers inside a struct.

Sorry if this doesn't make sense. I was up all night trying to work out how best to do this. If this isn't right, it's at least a start.

Hmm, I'd rather vote for "eDirectionNone" to comply with other similar constants (e.g. eKeyNone).
Its value should probably be "SCR_NO_VALUE".

Of course! I'm totally on board with that and the other comments you made. I just wanted to check that I wasn't randomly adding features when these possibly show up as pull requests in the future.

I haven't thought about it, but I'll put it on my list of things to investigate.

Current priorities are:
-- Investigate destruction of stack struct variables that contain pointers to user objects (something seemed weird about the way they were cleaned up)
-- Modify the script format to support writing out parts of the symbol table for RTTI
-- Implement switch...case
-- Function pointers, type coercion for floats<->ints, etc (these are more things I'd like to put up for discussion before even attempting)

eDirectionNone would be (relatively) useful.

I meant to comment on this a while ago. I think both this and the FaceDirection suggestion are worthy of inclusion in the standard library, but I don't know how others feel. I also implement this in most projects. I tend to call it "eDirectionUnknown" because you aren't facing none, you're just not specifying the direction faced. Right now, I think all the directions in the direction enumeration have a 1:1 mapping with loops. Not sure if we need to consider that when adding eDirectionNone.

Also, regarding the standard library of functions, there's one that seems peculiar to me:

Code: ags

GetRoomProperty(const string property);

No idea why this is a global function and not a static function on the room (like Room.GetTextProperty). Would anyone object to tidying that up?

Open one packet of Mi Goreng. Add water and noddles to bowl. Put in microwave for 4-5 mins or until it beeps. Remove bowl, add soy+flavour+spice to the noodles. Stir, optionally drain and serve.

This cooking thread is working out well. Loving all of the recipes so far. Mmmmmm.

Oh, you could probably (ab)use GiveScore and the eEventGotScore event to achieve the same effect. It might even be a bit simpler.

GiveScore(1) to activate the first function, GiveScore(2) to activate the second.

In on_event, a series of if/else statements for the eEventGotScore event, checking what the value of data was.

Of course, this would break the built-in scoring mechanism, but it's pretty easy to write your own if you need one ;-).

This looks EXTREME. Good job.

320x200 is the best resolution for me. It has tradition on its side. Both 640x400 and 320x200 have the best aspect ratio (8:5 or 16:10), which approximates the golden ratio.

Virtually nobody has a monitor nowadays that can't display the highest resolution that AGS 3.3.0 (standard version) supports. If anything, you should be worried about monitors struggling with lower resolutions, though the situation there has improved with the 3.3.0 hotfixes.

You're getting distracted from making your game. Make your game at 640x400! Nobody's going to care if the curves of your cartoony game have slightly less stepping. Also, the higher you go, resolution-wise, the more noticeably jarring things like switching from idle standing view to walking can be.

Mike and the Mechanics - The Living Years used to give me goosebumps, but now I think it's pure cheese.