[2.xx] Expanded FFC Things

[Gleeok]

Destructors, linked lists, queues, stacks, more complex efficient implementations. Encapsulation, polymorphism, inheritence, etc. You just gotta think.

C++ was made to optimize memory management as perfectly as possible.
if you need help with that, I'm on board. I have a book on Game Design if you want, it's graduate level though but I'm sure it'll be easy for you.

Object-Oriented Programming for the win.

AGILE manifesto, team iterative processes, etc. Basic Software change procedure.

Concept Location -> Impact Analysis -> Prefactoring -> Actualization -> Postfactoring -> Verification -> iteration -> ... -> Conclusion

You guys are stuck in the Waterfall Pardigm from what I can see, that's why we need OOP

The problem is that ZC has no dynamic resource handling. Think about it if ZC were a skyscraper built on sand, and you wanted to add some support to the foundation, maybe concrete, without collapsing the whole thing. Jenja!

I thought about today while I was doing laundry (This is when I do most of my deep thinking), and I think the best solution is in-memory compression; although rarely used nowadays would be the easiest, cheapest, and fastest solution. I'll look into different compression types for the FFC structure (something combining RLE concept and LZx probably) and see what ratio I can get. If I can get 20:1 FFCs shou;d be able to be increased with no additional problems. Additionally: If I can work out a special case where any screen that has no FFC data can safely be treated as its own type then I should be able to get 6500:1 ratio O_O.

There's also the problem of this potentially bloating quest files, how the editor can cope with all of it, and FFC script buffers, etc.

It's still problematic. Maybe this can be the first community project when the open source version gets done.

[Samer]

Dynamic Memory Allocation? That's easy, use a doubly Linked list, and use all your memory management needs in a Singleton Class for abstraction, and keep on extracting concepts until the efficiency for running time is in O(log N) at least. Building a skyscraper uses the waterfall, waterfall does not work in software engineering since software evolves at a moments notice.

In the Waterfall, all requirements are done at once and only maintenance is needed. Requirements change nonstop in software and that's why the paradigm shift from Waterfall to AGILE took place.

What I don't get is why only patches are being made, patches is during the servicing phase when all development has ceased for a version of a particular software.

Edit: Dynamic Resource Handling? Get the Qt Libraries, it's cross-platform.
@Gleeok
I know what you mean, I can tell the code is a mess just from your description.
You don't have to take my word for it, but I'm a Computer Science major doing Software Engineering.
Allegro5 fixes some of the rubbish Allegro4 is known for.

"FFC", what I can tell is handled the same way as a script. Scripts are known to slow things down considerably.

Software is quite liberal

[Saffith]

I was thinking we'd just avoid keeping blank FFCs on inactive screens in memory. There's already a set of flags indicating whether each FFC is blank, so that should be relatively easy to implement.
I was leaning toward replacing FFCs with something more flexible rather than simply adding more, but that wouldn't be until 3.0.

[Gleeok]

I thought about that initially but then I thought the about the added complexity of ffc-carry-overs, RunFFCScript(), and the like. You surely know the usage details of those in ZQ better than me though, so if you think that is easier then I'll take your word for it.

My idea was essentially moving FFCSet away from mapcsr and having something like FFCSet"Manager" that would hand out FFCSets on demand given a screen index, so it would be free to crunch all that data into as little bytes as possible, or something to that effect.

[ZoriaRPG]

I was thinking we'd just avoid keeping blank FFCs on inactive screens in memory. There's already a set of flags indicating whether each FFC is blank, so that should be relatively easy to implement.
I was leaning toward replacing FFCs with something more flexible rather than simply adding more, but that wouldn't be until 3.0.

Would that work, in conjunction with instructions to fetch an unused FFC slot? I'd imagine that you'd need to add routines to replace finding an FFC (with a Combo ID of 0 assigned to it, or no running script), if you went that route. (I suppose that rehashes what Gleeok stated, regarding RunFFCScript(), and so forth.)

I'm not sure I could even imagine carrying over the present data types into ZC3. It seems like that would be the right point, to nip all the legacy support in the bud, so that artefacts of this sort cease being so problematic. In fact, it would be better to provide a legacy framework for backward-compatibility, whilst adding entirely new methods of data handling, than to expand on all the old models.

Wouldn't it be better, to keep only the current map, and al its objects, in memory, and to fetch that information only when requested (or needed)? That would help ease memory management--or well, reduce memory usage--in general.

[Gleeok]

I'm not sure I could even imagine carrying over the present data types into ZC3. It seems like that would be the right point, to nip all the legacy support in the bud, so that artefacts of this sort cease being so problematic. In fact, it would be better to provide a legacy framework for backward-compatibility, whilst adding entirely new methods of data handling, than to expand on all the old models.

Wouldn't it be better, to keep only the current map, and al its objects, in memory, and to fetch that information only when requested (or needed)? That would help ease memory management--or well, reduce memory usage--in general.

The overwhelming consensus is that 'ZC3' would have zero compatibility with ZC, and also use zero code from ZC, and I also strongly agree. However, both would be open source, so tools could be written to 'upgrade' quest data to other, more useable, formats.

Back before 2.5, it seems ZC didn't really need any resource handling, and that's one of those things you have to put in at the core of the engine. FFCs currently take up roughly 3/4 of all map memory, that's why all the fingers are being pointed to that right now. :) (I actually had no idea that was the case until you brought it up last week)

[ZoriaRPG]

The overwhelming consensus is that 'ZC3' would have zero compatibility with ZC, and also use zero code from ZC, and I also strongly agree. However, both would be open source, so tools could be written to 'upgrade' quest data to other, more useable, formats.

Back before 2.5, it seems ZC didn't really need any resource handling, and that's one of those things you have to put in at the core of the engine. FFCs currently take up roughly 3/4 of all map memory, that's why all the fingers are being pointed to that right now. :) (I actually had no idea that was the case until you brought it up last week)

See now, my repeated questioning, and analysis, does give useful results. :p

I'll be curious what, if anything, you decide to do about this, for 2.60.

As to zero-compatibility, it all comes down to what you use as a base. I see no reason why ZScript couldn't have an API, to compile, or run via a JIT compiler, but tile datum, and other references would need a compatibility library. As long as you are in control of the engine, making such a library set, or entire framework, should be possible; but clearly not a primary objective. As I've said before, ZC-ifying Solarus might be the easiest route there.

You may even disambiguate it, with a name shift, such as ZC-III. That would prevent versioning problems with future forks of the ZC sources. I can only imagine the confusion if the present ZC source, after 2.60, makes it past ZC 3.0, while ZC3 is using the same numbering scheme, and especially if someone releases ZC 3.1 using the present engine, while the new ZC3 is at 3.0. Utter, confusion.

I'm more curious on what your plans are for engine changes in 2.60, at this point. I don;t know how much practical aid I could render, but suggestions, feedback, and testing are all well and good from my standpoint. Never having seen a single line, of any of the sources, and knowing only vague bits of the internal workings, I'm essentially stabbing in the dark with many of these suggestions, comments, and concerns.

[Gleeok]

Yeah, who knows. It's not like it's started yet or anything.

I'm more curious on what your plans are for engine changes in 2.60, at this point. I don;t know how much practical aid I could render, but suggestions, feedback, and testing are all well and good from my standpoint. Never having seen a single line, of any of the sources, and knowing only vague bits of the internal workings, I'm essentially stabbing in the dark with many of these suggestions, comments, and concerns.

That's all Saffith right there since he's the only one actually working on it so far. You'd have to ask him.