[2.xx] Expanded FFC Things

[MENTION=42228]ZoriaRPG[/MENTION]

I'll do you one better, let's you and me team up and make the number of FFCs a vector. :grad_white:

Tamamo wrote:[MENTION=42228]ZoriaRPG[/MENTION]

I'll do you one better, let's you and me team up and make the number of FFCs a vector. :grad_white:

o.O I am lost as to what you could mean.

Increasing the number of FFCs per screen would be useful. While I haven't come close to using them all yet I imagine it could be possible at some point in my quest. Then again at that point I would just consolidate. Then again I have no understanding of why the current limit is in place so I can't even begin to comment on how feasible it is.

Tamamo wrote:[MENTION=42228]ZoriaRPG[/MENTION]

I'll do you one better, let's you and me team up and make the number of FFCs a vector. :grad_white:

First, and foremost, I have no idea if this is a genuine request, or if it's meant to be sarcastic, particularly with that choice of emoticons following your statement... :/

Second, even if genuine, I would think that approval from the core developers would be a necessity, before anyone else would be able to work on the basecode.

Last, should I be interested, I would need to familiarise myself with the ZC components, to understand how everything is tied together, and would certainly need to be 'in the loop', to avoid making a change that tosses a spanner into the works, that could in any way conflict with changes that the developers are making at present. I don't know how modular any of the engine components are, how intrinsic anything is, to anything else, and would generally need to see the code in question, and preferably, any documentation that details what is going on, what the general plan is, and so forth.

In short, I do not oppose this proposal, but for anything that I may do, I would need to be professional in the undertaking thereof. If the main developers support this kind of action, I will discuss it further.

i was talking when the source is released. 😛

I had an idea here... Would it be feasible to add an FFC flag that executes FFC functions during screen init, before Waitdraw()? I don;t know at exactly what point 'run at screen init' runs the FFC instructions, but clearly, drawing called in an FFC happens a frame later. Would the present order of execution allow something like that?

Tamamo wrote:i was talking when the source is released. 😛

I'll consider it, at the point that it becomes relevant, and possible to muse on the notion.

Just looked into possibly doing this after 2.10.2. There's a major problem: If FFCs were increased to 255, for example, this would mean that memory usage would increase about 7 times in ZC, and 255 maps would require over 2 Gigabytes of system memory alone. x_x

Gleeok wrote:Just looked into possibly doing this after 2.10.2. There's a major problem: If FFCs were increased to 255, for example, this would mean that memory usage would increase about 7 times in ZC, and 255 maps would require over 2 Gigabytes of system memory alone. x_x

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

Samer wrote: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.

For the record, I doubt that Gleeok would need to read more reference material. The basic problem here, is the hand-me-down nature of the ZC source. I believe that five different sets of programmers have worked on it over the years, and it's just a mess. I would however, support another set of hands working on this sort of thing, for 2.60.

I agree with you, the old school pre 80s implementation is what's making this so difficult.

Shoot POS systems use OOP.

It's ok though.

Samer wrote: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! :P

I thought about today while I was doing laundry (This is when I do most of my deep thinking), :P 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.

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.
[MENTION=42714]Gleeok[/MENTION]
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

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.

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.

Saffith wrote: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.

ZoriaRPG wrote:
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)

Gleeok wrote: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. 😛

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.

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

ZoriaRPG wrote:
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.