Zelda classic source code- Please read.

[_Mitch]

Greetings everyone!

I was under the inform that zelda classic and zelda quest were going to become open source. I've also noticed that there has not been any recent developments on these games. I was interesting in participating, but couldn't find a repository.

Why was it claimed that it would be open source, when it isn't becoming available?
I'd like access to the source code so I can add a few features in particular:

1) Multiplayer (local only)
2) Possible Wii port (homebrew)
3) More items (gauntlets, etc)
4) More enemies

[Tamamo]

it's a wip

[mrz84]

Things take time, some things more than others.

[_Mitch]

Hi, nice to meet you.

Do you mean the repository is a work in progress, or the game (which I'd say was pretty far along for that phrase)?
A repository shouldn't be so hard to set up, besides, since this game is mostly non-profit, it should already be open source, right?
Can one even imagine all the cool features that would be possible with an entire community working together?

Also, what happened to DarkDragon, is he still around? I sent an email to his old address, hoping for a reply.
Not to complain but the default font size seems kinda small...

[_Mitch]

Nice to meet you too.

I know it takes time to add new features and stuff, but I could easily add those,
and even port to Wii (with gamecube, and wiimote controls)- all in less than 3 months (if I had no work).

[Anarchy_Balsac]

One thing to remember about writing code, it is ALWAYS more burdonsome than you imagine it. It's worth it if you're determined enough to see it through (which is, unsurprisingly, a very small percentage of people), but difficult.

[ZoriaRPG]

It's taking a long time, to get the code into a state, that is ready for opening it. There are many obstacles, and it'll take as long as it takes.

GitHub is a likely repository, when it's ready.

I should note, that a Wii version isn't likely to happen. The ZC engine relies on the Allegro (v4) libraries, and unless those are ported to the Wii, or other systems, ZC is not going to run on them. You'd need to redesign the entire graphical engine to run on another set of libs.

[_Mitch]

I'd really like to add multiplayer, a four swords adventures type setup. I'm pretty experienced, but also pretty busy, so I'll not be able to help out all the time.

Porting to the Wii is not difficult (I've ported much harder stuff than this in all seriousness), it's probably not that helpful (since it's homebrew, and Wii is old, most will probably just use the PC version anyways).
The only challenging thing in a Wii port is Endianess (it's BIG endian) and Wii is 64 bit.

Any well designed graphic procedures should be simple enough to port. SDL is already ported to the Wii, with a few ifdefs, and an SDL/ALLEGRO define, it would likely be simple enough; maybe a couple dozen hours, likely far less.

You guys talk as if you have access to the code, which I doubt. Also, it's one thing to "take a long time", it's another to be several years.
I don't intend to sound rude, but I'd say it's hurting the ZC community, and something should be done. I don't even think ZC has had a legitimate update in many years.

[Anarchy_Balsac]

It's probably taking this long primarily because it is something people do in their free time, and at least one person is also working on Final Fantasy Classic.

[_Mitch]

I understand. And I respect the project and the people who worked on it.
It just makes me sad, because it has so many fans and hasn't had received any new features in a while.
I also feel many of the fans could contribute a great deal if it was available.
Plus I myself would be willing to get involved.

[Anarchy_Balsac]

Well, if you want to contribute, I imagine that, like in most communities, your have to become a well respected member whom the staff feels they can trust first, but I hear ya.

[Gleeok]

I totally agree. The source code needs to be hosted publicly; indeed, we we are way overdue for that. To be completely honest (in all fairness to the community), the only reason it's not done yet is because of the notion of keeping password protection on password-protected quests, and being open source at the same time. Those are two very different things, and to be even more honest about it: I sort of don't work on trying to make these two things possible because in the back of my mind I know that someone's just going to fork the repository and put in all the encryption stuff anyway, so it would be like painting my house during a sandstorm (or some other analogy, you get my point)... I guess you could say that motivation for it does not exceed the minimum requirements to overcome laziness.

But it really does need to get done.

[edit] Also, there's nothing really stopping it from being released I guess, minus the fact that ZC cannot load quests, and the license is basically GPL.

[_Mitch]

Nice to meet you Gleeok, I've heard a lot about you.

Wow, I didn't expect to get so many replies, thanks.
I realise nobody should trust me, that's why I don't expect to get access to the source before release.

Ah, I know the password thing is a big hurdle; you want the old quests to work, and their security to still matter.
Perhaps you could just remove support for passworded quests, and their authors can would have to open them up for other people to use?

Was there ever a contract that said "armageddon games reserves the right to remove your password with future versions of ZC/ZQ"?
That would have been great, then it could just disregard the passwords which will be labeled "deprecated" (although that may offend some).

Unfortunately that really does sound hard to fix. It's either everyone's quests become editable, or are not available any more (unless converted).

[EDIT]
It's just that these days nobody has much free time to spend on these projects. Free projects like these need the community to survive and thrive.
So the faster it gets opened up, the sooner everyone can benefit from it! I'm sure that once it's opened more quest makers will pile up and start making levels!
Even if it means losing compatibility with the old quests, it'll get more over time. Besides open source projects get a lot more publicity.

And perhaps a closed-source app can be made that you input a password and outputs a converted quest?
Still an application like that needs special security measures, because the hacking community would probably be lurking.

[ZoriaRPG]

I totally agree. The source code needs to be hosted publicly; indeed, we we are way overdue for that. To be completely honest (in all fairness to the community), the only reason it's not done yet is because of the notion of keeping password protection on password-protected quests, and being open source at the same time. Those are two very different things, and to be even more honest about it: I sort of don't work on trying to make these two things possible because in the back of my mind I know that someone's just going to fork the repository and put in all the encryption stuff anyway, so it would be like painting my house during a sandstorm (or some other analogy, you get my point)... I guess you could say that motivation for it does not exceed the minimum requirements to overcome laziness.

But it really does need to get done.

[edit] Also, there's nothing really stopping it from being released I guess, minus the fact that ZC cannot load quests, and the license is basically GPL.

I hadn't mentioned this in the past, but how about supplying a pre-compiled password library file, as a separate download, for compatibility concerns?

Using that, a person could compile ZC, drop in the lib, and load quests; or write their own encryption protocol; or use no encryption, all at their discretion. The library would be user-end, so if it exists, ZC uses it. if it isn't in the path, ZC uses either (A) no encryption, or (B) user-defined encryption.

Forking will happen, no-matter what you do. It's an inevitable fact of open-source projects, and often, vital to their evolution.

[_Mitch]

ZoriaRPG That actually sounds like a great solution. Good idea actually.
But I bet someone would reverse engineer it eventually (the lib).
Perhaps if it's designed cleverly enough though, that could pose a challenge.

[Tamamo]

rewrite the encryption complety again and write a password updater that opens with the ol and saves with the new

[Anarchy_Balsac]

That also wouldn't work if it were open source. It might make it a llittle harder for people to dig through the code and figure things out, but they could still do it.

The best approach is to bury the encryption deep within some random place of the source code, with no comments dictating what it is or how it works, but it could still be found even then.

[_Mitch]

Actually Anarchy_Balsac, if you are talking about ZoriaRPG's post, it could work -but you are probably talking to Tamamo.

ZoriaRPG is saying that you could compile the password code into a static library that gets linked into the main program.
Also, an dynamic link library would work. But still, this could be reverse engineered, but pretty much anything can be so.

Burying the encryption in the code and releasing it online would most definitely get found eventually.
If the encryption is ever changed a closed source tool could be useful in converting maps, but that could just be implemented in an external compiled library for ZQ as well.

[Isana]

ZoriaRPG That actually sounds like a great solution. Good idea actually.
But I bet someone would reverse engineer it eventually (the lib).
Perhaps if it's designed cleverly enough though, that could pose a challenge.
The only difference between reversing ZC as it is now and reversing a library is that, assuming the library's sole purpose is encryption, there would be a lot less code to look through.
You could throw a bunch of junk code in there with it and use a few other tricks to change that though.

I think the external library is a fine idea.

To be honest, though, all these arguments about someone still being able to screw around with the code to do something like open password protected
quests are pointless. If everyone thought like this literally nothing would ever get released...
Aside from that, as you're all already aware, it's already possible to open password protected quests.

These are useless without knowing where to apply the patches, but this is all it takes to make ZQuest disregard passwords in the latest release of Zelda Classic...
E9 58 FF FF FF - Linux
E9 57 FF FF FF - Windows

[_Mitch]

That's why I said someone would probably reverse engineer it, simply because it has less code and would be easier to do.
Yeah, but voiding or disregarding the passwords would be disregarding the user that created the quest some might say.

Are you saying all it takes is overwriting a few bytes in the quest file to open a passworded quest?
If so, that's kinda sad, and poor design- and that is only 5 bytes! But why is it different in the windows and linux version?

By posting those 5 bytes, could anyone with basic knowledge on file comparison and a hex editor could search for that string in a non-passworded quest,
overwriting it at the same location in a passworded quest- likely opening it right up (assuming the offsets are the same)?
It sounds like there was not much security to begin with really.

[Isana]

That's why I said someone would probably reverse engineer it, simply because it has less code and would be easier to do.
Yeah, but voiding or disregarding the passwords would be disregarding the user that created the quest some might say.

Are you saying all it takes is overwriting a few bytes in the quest file to open a passworded quest?
If so, that's kinda sad, and poor design- and that is only 5 bytes! But why is it different in the windows and linux version?

By posting those 5 bytes, could anyone with basic knowledge on file comparison and a hex editor could search for that string in a non-passworded quest,
overwriting it at the same location in a passworded quest- likely opening it right up (assuming the offsets are the same)?
It sounds like there was not much security to begin with really.
Yeah, and I'm not saying we should just disregard the wishes of users who have
chosen to protect their quests.

Rather, I'm saying that, with this being as simple as it is, there really doesn't seem to
be a whole lot of interest in reversing ZC to accomplish this, so I don't see why this
would change with an open-source release bundled with an optional library for the
encryption/password functions. Or a program to simply update/remove passwords
so that quests could be opened in the open source release, as Tamamo suggested.

No, not the quest files, but ZQuest's executable itself. The quest editor.
It's different because there are differences between the Windows and Linux builds.
No, you can't use these bytes to find out where to apply the patch as these
are only the new instructions; none of the original bytes are there.

[_Mitch]

OH, I see what you mean. You could just modify ZQ to ignore passwords- good point. I really wasn't thinking of that.

Well, I agree, it's probably fine. Still, I think at this point no matter what choice is made it will probably have some saying I'd have rathered it this way, or that.
Regardless I'm sure the knowledgable staff will make the right decision. I personally approve of the idea of invoking a DLL, or, even better, using a static link library.

[BFeely]

A little note regarding the source release, if/when it happens:
When I was developing DXGL to be compatible with ZC, I compiled the version of Allegro so I could trace the Allegro runtime source to find out what was breaking. I found out that there was actually some patch required to make it work, and I found it floating somewhere on the Internet but don't remember where I found it. Do you plan on releasing that little Allegro patch too?

[ZoriaRPG]

A little note regarding the source release, if/when it happens:
When I was developing DXGL to be compatible with ZC, I compiled the version of Allegro so I could trace the Allegro runtime source to find out what was breaking. I found out that there was actually some patch required to make it work, and I found it floating somewhere on the Internet but don't remember where I found it. Do you plan on releasing that little Allegro patch too?

Hello Bill!

What did you do with DirectDraw that specifically relates to ZC?

Further, did you want that patch released? I'm not sure how to read your question: If you need the code again, if you want it distributed with ZC sources, or if you want it maintained separately.

[BFeely]

Hello Bill!

What did you do with DirectDraw that specifically relates to ZC?

Further, did you want that patch released? I'm not sure how to read your question: If you need the code again, if you want it distributed with ZC sources, or if you want it maintained separately.

What I did was get my DirectDraw emulator DXGL compatible with the version of Allegro that ZC uses.
When I compiled that specific version of Allegro from its official source code and copied it to the ZC directory it was missing a certain entry point. When I Googled that particular entry point (I don't remember what it was) I found a little code patch for Allegro to add it.