34 replies to this topic

[Joe123]

I was referring to Revfan and TD (Anthus).

TD is Anthus?
I didn't know that.

Not that I know anything about Anthus, but I recognise the name.

[Twilight Knight]

Remaking ZC is bad idea for existing questmakers, unless the "new ZC" can run old quests, or even edit them...
Then if AGN and PZC merging is a bad idea... Well, AGN's activity should be raised somehow, as long as it's ZC's home it should be more active.

[Russ]

Hey, we're working on ideas to raise AGN's activity. We've already set up a SotW that's completely different from the one here, which also means I have to crank out a new screen for it each week.

[Alestance]

Remaking ZC is bad idea for existing questmakers, unless the "new ZC" can run old quests, or even edit them...

DN had mentioned a complete rewrite wouldn't allow old quests to be used, or at least, not directly. He mentioned that the format would have to be converted. Something like 2.5(and possibly 2.7, he mentioned a 2.7, too) files would have to be converted to 3.0 format via a program. If WE were to write a new ZC, however, that converter wouldn't be written, as only the devs would understand the current ZC file format.

Edited by Alestance, 13 November 2008 - 02:20 PM.

[Koopa]

Some comments on the first post.

Sooner or later we'll have to break with the past and make a new ZC - not completely from scratch, we can copy some code over with only some adaptations - without the limitations we have today.

I think ditching allegro for something like SDL is a good idea. A paint-like interface in the editor is a must. We don't need to restrict ourselves to 16 colors/tile in a world where screens can show millions of colours.

Let me explain though how some of the features came about. ZC 1.0 was written for DOS. Under DOS, you have no user interface given, just a rectangular screen (640x480 or similar) to draw on. If you want something like a "button" you have to code every detail yourself down to the colour change of its outline when you click it and you need to code the mouse click detection and handling too. Obviously, if you want a really nice user interface that takes time.

Nowadays, there's a user interface library (windows, gnome, gtk, wx, ...) on pretty much every PC. All but the first I mentioned are in fact cross-platform. Making a button goes something like "Button b = new Button("OK");" and the rest is magic.

There's one disadvantage to taking on board every new feature though. That's why I am against using Java or Objective-C. The first ZC fit on a floppy disk or two (1.44 MB, for those who don't remember). And those were the days when 16MB of RAM was a lot.

If we use the most modern languages and techniques, we'll end up with a ZC that is let's say 100-200 MB big and maybe requires as much space again for libraries (extra files required to run the program). If we use Java, .NET or so we need to add the whole runtime environent to that which is as much again. Then we could say any reasonable PC nowadays has at least 2 GB of RAM so we'll only guarantee it runs at a reasonable speed on such PCs. That would give us a game with what I like to call "Vista syndrome". The main problem is thinking why should I make my program run fast on a 1GHz processor and at most 1GB of RAM when I can just demand customers use a state-of-the-art modern gaming PC instead?

Here's what I'd suggest. Stick with C++ as a language. Not C, make full use of object-oriented features. Use a simple, but modern user interface toolkit like GTK or wx (a windows-only ZC might be easier to code but would exclude quite a few users). Use a graphics library like SDL (or the newest Allegro, if it's improved enough compared to the one we use now). And above all, go that little bit further and make it run on computers that may be a couple of years old too.

We will need third-party libraries for at least these components: Graphics, editor user interface, sound/music playing and image import "ripping" and export "screenshots". In addition, a copmression library for quest files can't hurt. That's in my opinion the only way - we can't write our own operating system for the graphics and our own mp3 playing library for sounds.

I reckon from the moment decelopers seriously start planning to the first usable version, it'll take at the very least 2-3 years of time unless we get massively more people in to code it. Though it's worth every minute extra it takes to code cleanly and avoid those "shortcuts" that land you with a buggy product which eats up the saved time 10 times over when you're trying to maintain and extend it.

Size wise, I wouldn't be surprised if it comes in at 20-50 MB. That's more than the current ZC by far, but it's unavaoidable in a way.

Ditching the current palette system and the screen/map/dmap/palette/cset relations would definitely help make ZC easier and more user-friendly. The cost is we'd make a complete break with existing quests and not even have any reasonable way to convert them except "remake it by hand". I mean, throw dmaps out the window and you've broken one of the core concepts current quests are built on.

Basically, any requirement that future quests be compatible with current ones or even that they can be converted automatically puts extreme restrictions on what we can do with the new ZC and also means 50% of the problems we have with the current ZC just carry over to the new one. If we want a clean and stable ZC, let's be prepared to start from the ground up.

Here's an example of why some arcane concepts like palettes/csets exist. One of the main DOS graphics modes is "256 Colors". It works like this: The screen can display colors from quite a large set (several million) but only 256 fixed ones at any one time. This was in fact a hardware limitation on screens at one time, and also determined by the size of graphics RAM available (measured in KB!). So, you construct a palette of 256 colors something like this:
Color 0 = #000000
Color 1 = #00FF00
Color 2 = #00FFFF
...
and use a system call to load that palette into a certain address of graphics memory.
To draw on the screen, you have let's say 640x480 resolution. The screen is represented in memory by 640x480 bytes of memory at a certain location - remember one byte can hold one of 256 different values. To set the pixel at location (10, 25) to whatever your color 2 is, you do something like "screen[10][25] = 2;".

This system takes only 300KB of memory for the actual screen and less than 1KB for the palette. It allows you to use any 256 of 16.7 million colours at once.

If you want to run a screen in full 640x480x16.7 million mode (palette-free), that's already 900 KB. Clearly if you have 512KB of graphics RAM, that won't do. 1024x768x16.7 million colours is about 2.25 MB.

The ZC palette system allows you to use that 256-colour mode, but as the subscreen, enemies, Link etc. need their colours too we can't have 256 colours for tiles alone. Instead, we have a palette of 16 csets of 16 colours each (16x16=256). Tiles can each use one cset and we have not only several csets for tiles, allowing us to use cliffs, houses and trees in the same screen, but we have enough csets left over for Link and friends too. Just that any one tile can have at most 16 colours. And still we need only 301 KB of graphics RAM.

This is one of the examples why things are as they are in ZC, and I hope it's instructive. I said we shouldn't require everyone to have 2 GB RAM - but making a modern program run on a system where you have to worry about each KB is nonsense too (in fact, modern computers only emulate the old 256-colour mode, taking up marginally more resources than if we used the full colour set directly).

Here's a short summary of the whole looooooooooong post:

ZC is how it is for a reason. It's not complicated on purpose, it's made in the best way that was possible at a time that's now past.

I think, once ZC 2.5 is out, it is time to break with that past and make a new ZC in the best way possible today.

That involves giving up compatibility with old quests completely.

Despite this, we should try and make its size and other requirements resonably small.