ZC Development Proposal

[DarkDragon]

To answer the back-end concerns: I've switched various 'multimedia' libraries many times for other hobby projects in the past, sometimes halfway through a project, all without changing a single line of program code. I can drop in an allegro5, SDL, sfml, GLFW, etc. library to a project and all it needs is about 12-20 functions 'wrapped'. That's it. Trust me when I say that none of this really matters. The [only] important thing here is designing a very small concise API that can replace allegro calls directly in ZC; it doesn't matter where it goes after that, and who cares anyway?! ~Open a window; get an OpenGL context; get input; done.

That makes sense. Wrapping Allegro code into a small set of functions (and cleaning up the code a bit in the process) seems like a helpful modification no matter where the project goes, in terms of switching to Allegro 5, or SDL, or what have you. I will take a stab at doing this in the free time I have here and there.

More urgently, though, we need to do something about the status of the repository, and establish standard procedures (if they don't exist already?) for how patches by contributors are reviewed, what standards are expected from the patches, etc. Do you have thoughts on this?

[Gleeok]

That makes sense. Wrapping Allegro code into a small set of functions (and cleaning up the code a bit in the process) seems like a helpful modification no matter where the project goes, in terms of switching to Allegro 5, or SDL, or what have you. I will take a stab at doing this in the free time I have here and there.

We should probably decide if the end goal is going to be rendering on the GPU or not. This affects all the palette code, as well as most of maps.cpp and part of link.cpp.

More urgently, though, we need to do something about the status of the repository, and establish standard procedures (if they don't exist already?) for how patches by contributors are reviewed, what standards are expected from the patches, etc. Do you have thoughts on this?

Not really. >_<

I think we need to modify the quest loading routine to handle quest files that aren't binary compatible with it though. So if someone else changes the format of a quest file it will bail out instead of corrupting it 'gracefully'.

[ZoriaRPG]

We should probably decide if the end goal is going to be rendering on the GPU or not. This affects all the palette code, as well as most of maps.cpp and part of link.cpp.



Not really. >_<

I think we need to modify the quest loading routine to handle quest files that aren't binary compatible with it though. So if someone else changes the format of a quest file it will bail out instead of corrupting it 'gracefully'.

That makes sense. Wrapping Allegro code into a small set of functions (and cleaning up the code a bit in the process) seems like a helpful modification no matter where the project goes, in terms of switching to Allegro 5, or SDL, or what have you. I will take a stab at doing this in the free time I have here and there.

More urgently, though, we need to do something about the status of the repository, and establish standard procedures (if they don't exist already?) for how patches by contributors are reviewed, what standards are expected from the patches, etc. Do you have thoughts on this?

Here's my question: Aside from Gleeok, Saffith, potentially DD, and the three of us doing 2.future, who is even participating at this point? Tamamo bailed. The bloke who did some minor stuff to the dead master branch never joined the forum, and all his changes were cut, AFAIK.

Sorting the repo should be the highest priority. It's not possible to do a push at all at present, because there's no logical candidate set up.

[DarkDragon]

What is 2.future?