[OBSOLETE TEST] AGS 3.3.1 Alpha 2 + Custom Resolutions

[Crimson Wizard]

P.S. If you could hold off on making further changes to the game data format, I am honing in on completion here. I've got more than 80 of 90 KB of my test project verified...shouldn't be too many major mistakes left to correct.

Here's something I just wanted to say: in my honest opinion I think that you're doing a big mistake by continuously merging changes from main development branch.
I am strongly advising to first finish your feature and be sure that it works with all the old code, and then update it all at once to the latest development state. That will make things much easier to you.
It is a common thing in parallel development that two or more developers change the code that affect other's work in separate branches. If they would continiously merge their changes before they are ready, they will go mad.
I think I'll even make another post in our sticky thread about this .

(stream->WriteArray(&structInstance, sizeof(MyStruct), MAX_STRUCT_INSTANCES) seriously made me want to assault someone)

Lol, and that is why I had to create AlignedStream to read the data written that way and count structure padding.
BTW, what about "stream->ReadArrayOfInt32(&numItems, 11);" where numItems is the first integer in struct of 11 ints? Something I am refactoring right now.

[monkey0506]

in my honest opinion I think that you're doing a big mistake by continuously merging changes from main development branch.
I am strongly advising to first finish your feature and be sure that it works with all the old code, and then update it all at once to the latest development state. That will make things much easier to you.

My fear in this is that if I don't pull in intermediate changes that I'll end up so far behind that merging the changes back together will be a nightmare in itself, constantly trying to play catch-up to the changes that other people are making to the existing native code while I'm trying to port it to C#. Especially given how fractured a process writing the data file is, there are several dozen script files that could contain relevant changes that I would have to manually piece back together. I'm not saying you're wrong, but considering how close I am to having the code ready for a pull request, I don't think that I can afford not to keep up at this point.

[Crimson Wizard]

in my honest opinion I think that you're doing a big mistake by continuously merging changes from main development branch.
I am strongly advising to first finish your feature and be sure that it works with all the old code, and then update it all at once to the latest development state. That will make things much easier to you.

My fear in this is that if I don't pull in intermediate changes that I'll end up so far behind that merging the changes back together will be a nightmare in itself, constantly trying to play catch-up to the changes that other people are making to the existing native code while I'm trying to port it to C#. Especially given how fractured a process writing the data file is, there are several dozen script files that could contain relevant changes that I would have to manually piece back together. I'm not saying you're wrong, but considering how close I am to having the code ready for a pull request, I don't think that I can afford not to keep up at this point.

That is true that the changes may be significant, but not that significant to render all of your work completely obsolete. In current situation it will require simply to fix some of the modular parts, like add a thing or two into routine that writes game data.
What is more important, IMO, you are continiously distracting yourself to merge the changes and worry about possible inconsistences, instead of finishing the core of the task first, and worry about updating it only later. If you have a feature ready and tested, you are more sure of what you do. If there are problems after merge, you would know that they come from the merge and not wonder what are these. You are also staying focused at one task.

BTW, I had a similar situation updating hugely refactored development branch with changes to master. I usually waited 'till I finish current rewrite I was doing, then did one big merge, sometimes even followed by few updating commits to fix any problems arised from that merge.

[monkey0506]

I think you definitely make a valid point here, and I appreciate your advice and feedback. I mostly felt concerned about it because I was duplicating so much code from so many different places that sometimes it was hard to wrap my head around what was going on, nevermind keeping track of changes that might be introduced in the meantime. I also realize it creates extra commits that clutter up the history, but for what it's worth it was my way of ensuring that I wasn't inadvertently undoing the work of others.

That said, with the latest commit I'm happy to say that the data file can now fully be built from the managed editor code (sans the script compiler, which is still invoked from native). There are some final things that need to be cleaned up or reviewed before I submit a pull request, but the data file format is thankfully no longer one of them. There's a note about this in the commit message, and this is definitely getting off-topic for this thread (sorry for the derailment). If I have further questions I'll make a separate thread.