Messages

the better solution (without resorting to Photoshop) is the one using the "tint" setting in a dynamic sprite.
Because the so-called tint overlay will ruin the contrast (it's like you're painting some red (for example) on top of the scene, instead of turning colors into red -- do you get the difference?). It works, it's fast, but it's the second-best solution.

However that solution also requires you to set the tint setting on the characters, objects etc.

So, just a quick addendum to the solution:
Yes, the issue was that there were two variables with the same name (the "global" one, created with the editor, and the one declared in the global sript).
But just in case some day you decide to stop using the Editor's "global" variables, and go for the global script variable solution, then be careful with the scope of variables -- watch out for all the export/import stuff. Just sayin'. Good luck for the rest of your game!

Congrats on the kiddens!

OK but then what would be the connection between the 60fps of the physical screen, the vsync and the fps if my game?
Like, what would happen if I turn on vsync in a 40fps game on a 60fps screen?

The top image is actually a train station and the grey horizontal line near the bottom is the platforms edge. A train is seen arriving at some point..

O yeah OK that makes sense!
Maybe add one or two vertical lines in the black area to make it more obvious? But it's fine as it is.

Yes, they are very acceptable, both in their own way (I see that you reduced the color count even more in the first one).

that said, in both, you have a slight contrast problem. After reducing color count you might want to decide to boost the brightness or slightly change the tint in some areas, so that the eye can separate the areas of the scene more easily.
For example in the first background I'd recommend to use full black only behind the pillers, which means that the pillars wouldn't be any darker than "dark gray" at most. for the same reasons, maybe you could make the ground slightly brigter.
Same thing goes for the second background: maybe make the ground brighter so that the eye reads the scene more easily.


BEFORE
[imgzoom]http://i1181.photobucket.com/albums/x423/qikfire/SUBWAY%2018_zpshxk070ty.png[/imgzoom]

AFTER
[imgzoom]https://68.media.tumblr.com/766341f4565c6c860d6f114974f84e9a/tumblr_omz04f3jEu1tsfksfo1_400.png[/imgzoom]

I said C++ but indeed I meant C# or any language that is "managed". (I keep bringing up C++ because AGS brings back a flavor of old C).
Apart from that, you got me : yes, writing AGS scripts would be  like writing plugins (in a managed language!) EXCEPT we could maintain the AGS compiler as some sort of syntax checker that would force to use only basic C# features that are very similar to current AGS language. any language feature that could cause risks of memory leaks or unnecessarily-complex debugging would be forbidden. To keep it as a script-like language.
Imagine the Lua plugin, just with C# syntax if you will.

But then again, I'm just daydreaming. I'm not pushing for that kind of deep refactoring. Unless you think that incorporating the Lua plugin (or any C-like syntax language -- Lua is weird) is within reach. Then yes, that would be marvellous and, in my humble opinion, the best option on the long run.

Thanks for your feedback.

I keep hearing about V-Sync in let's play Videos and stuff but I've never really known what it's for. I don't play modern games, you see

[ccInstance::Run]

Found it : ccInstance::Run

Something that puzzles me is this:
If the purpose of the byte codes is to map the x86 instructions, or some specific CPU instructions, then I suppose that originally CJ would directly let DOS or whatever low-level system execute that byte code where possible (by copying the instructions into the registers, or DOS interruptions?) -- and execute some "meta" code the rest of the time.

But nowadays that doesn't make much sense does it? it's like writing an assembly compiler manually. Wouldn't it be simpler, considering AGS syntax is almost exactly C++, to let the compiler compile it to some sort of DLL with a big interface containing all our script custom functions -- that the engine could just call? We wouldn't have to care about syntax or optimization or "escape" instructions at all anymore.

(Oh, by the way, don't worry, I'm not having a rewritis attack . I'm not saying that everything should be thrown to the bin. I'm just wondering that's all)

[EDIT]

Right now it is MSVS 2008 SP1, but I just removed all restrictions in the master branch (precompiled libs), so you can use any.
I was thinking about upgrading to MSVS 2015 Community Edition.

Yes I think it'd be time to upgrade, 2008 starts to be really old (I can go as far back as 2010).

It may be a good idea to include these. (...) but what should be kept in mind: because of VC redistributable packages I think it is better to make official releases strictly with particular MSVS.

did I miss something or is there a contradiction between those statements? It would be silly to create CMake scripts (and make it possible to easily create projects for every VS version) when in the end the redistributables decide of which VS is the "correct VS". That said, I would be surprised if it wasn't possible to link to a specific redistributable package, regardless of the Vs version used to edit and compile. EDIT Well it seems like it's super hard. Lol.

Oh, OK, I didn't get it. That's clever. Yeah I'll do that.

By the way at the moment which Visual Studio version is it? Maybe I have it (I'm toying in a professional environment where I have many machines with lots of software installed).

Off-topic : I remember a project using a tool called CMake which can be rather simply used (through a rather simple script language) to generate projects for any IDE or compiler. You feed it the .cs and all, and it gives you the .sln and .csproj, for any verison of Visual Studio (or even other editors) you wish.

You're very clear.
On the back of my head I have that vague idea that some day, the use of "*" should be completely removed, to stop making it look like these are pointers, since they are more like C#/Java References.
Anyways, back on topic : I'll toy aroun din C# with [][] to see if I'm not overlooking something (I usually use List<int>) and then see what I can do.
On the engine side, the code is much less clear to me (not to mention it's C++, with which I used to be much more comfortable a long time ago). Maybe you could point me towards the place where "a pointer to int" is read (and interpreted) from the compiled script?

A lot of LCD monitors have a default refresh rate of 60 Hz, so if you want to use the V-Sync to get an optimal smoothness (e.g. for pannings), a setting of 60 fps should be the best match.

Good point. Is V-Sync setting still a thing when D3D9 is selected?

If you were splitting changes by kind and commit them separately (e.g. one commit for solution/project update, second commit for changes in actual code), this migration can be done with much less effort.

That's what I did, but I don't see how it causes less efforts, as git has a tendency to make you merge the whole branch history (i.e. the complete list of commits), without letting you choose which inner commits to push. But I don't know git well, so I probably have no idea of what I'm talking about.
I suppose we can see at merge time; my changes would maybe add new files in the project, but the XML of the .csproj files is easy to understand at merge time (to sort the important structural changes to the file from the "version-related" ones)

[int* a]

in AGS script int* a would mean managed pointer to integer, and int* arr[] - would mean array of managed pointers to integer.

Yes but as you know, in C/C++, an int* is both a pointer to an int and an array. The symbols [] are used "only for declaration", like a synctatic trick, but the "real" type of an array of int, to manipulate it afterwards, is int*. (That is explained very clumsily, I hope you understand what I mean).

I don't know exactly why int[][] is not suitable here. Just my guts telling me that if C/C++ made "[][]" mean something else (2D arrays), then it would mean that there is a core incompatibility between those syntaxes. An ambiguity somewhere, either in parsing or in meaning, that we don't detect at first sight (you know how C++ can be tricky synctatically). But if you think I'm wrong, then why not. I find it indeed less confusing.

I think I'm just completely forgetting my Java. I forgot that [] is used all the time in Java.

I think my instinct is triggered by the fact that in C you cannot do this :

Code: ags

int[] newArray(int size)
{
    int[] newArray = new int[100];
    return newArray;
}

instead you are forced to do this :

Code: ags

int * newArray(int size){
    int * array = malloc(sizeof(int)*size);
    return array;
}

...But I completely forgot that tehe first syntax is possible in Java and C#.
However do these languages also allow to return int[][] ?

By references I mean C# and Java-like references. Not the memory-leakish pointerish sort.

But my initial queston still stands: how do we formally (synctactically) manage arrays of arrays? It doesn't exist in C# and Java (apart from 2D arrays, like int[][], which is something relatively different) because they use templates (List<int>).
In javascript they just do this: var array1 = []; var array2 = []; array1[0] = array2;



On an unrelated note: the new compiler (on the Editor side) is wonderfully written. The tokenizer, precompiler, etc. are really easy to read. That's pretty cool. I must say. Amognst many things, i liked the way it's piling up modifiers until there's an encounter with an actual attribute or function. It maintains the "read tokens left to right" stream without adding unnecessary states to the syntax state machine.

[a managed struct to store a dynamic array]

Let's imagine for a second that I branched from the AGS engine, and let's imagine that I manage to make heads or tails of the interpreter's memory management. 

If we decide that there was no good reason for a managed struct to store a dynamic array, and if we go further along those lines and allow to store an array into another array, then... what should be the syntax?

Code: ags

int array[] = new int[100];
int* arrayOfArrays[] = new int*[10]; //this?
arrayOfArrays[0] = array;
int* arrayPointer = array; //this?

Also, as you know, C++ can manage pointers and references. The two are very similar but have some differences (I won't detail here). A long time ago, Chris Jones has made the choice of making referencing go down the "pointers" road instead of the "references" road (except in some very specific cases). I suppose that felt more natural for something that spawned from C then C++.
However, if I implemented references, how woud you picture it? Would there be some syntax traps caused by AGS' C-like-but-not-completely syntax?
Actually maybe it's already there. I never ever try to pass structs (managed or unmanaged) as parameters to functions, except for built-in ones. I have no clue.

It's just a question :
-If I branch away from the project and open it with a Visual Studio version more recent than the files in the repository, ...
... i'll have to commit all my changes, including the automated update to the solution and project files (.sln, .csproj...) made by visual Studio at the time I opened them.

Should I commit that? If not, how should I handle it?

OK so this is a weird questions but hear me out :
- AGS games are 40FPS by default
- That's probably a legacy reason (point n click games didn't require to have fast or fluid animations).
- But nowadays, let aside the aesthetic reason ("it's prettier") is there a reason that would make me favor 60FPS?

Some example I'm making up on the spot: "it's better for compatibility/ easier to sync on mobile devices" or whatever.

[EDIT]

I'm interested but it will be a complicated summer (a wedding to attend, not much holiday left, etc.). So I can't give a final answer yet.

EDIT : not my wedding