[Nedemai]

Hello all,

I've been playing around with C programming with DevkitPro to created a ZZT interpreter for the GBA... I guess calling it an interpreter is the best way to describe it. Right now all it will interpret is a single board file, which can be loaded off of a flash card on real hardware using the DLDI drivers.

So far I've managed to get board files to load and display, Although boards that have a 1 runlength for every tile on the board cannot display correctly. i.e. it creates a new tile for each new runlength. Once the location specified for the tile exceeds what appears to be a 32K block it kind of wraps around and does funky tile manipulation like horizontal and vertical flipping starting with the first tile in the specified tile base. There is enough space to store the tiles though... but anything outside a specified tile base just cannot be accessed by the map base it appears.

I've managed to make it so ammo, torches, gems... that stuff can be picked up, and a display showing what you've picked up can be displayed. Doors can be unlocked. But as for the rest of it I mean the player cannot shoot, enemies don't move... obviously can't walk over to another board yet... Im thinking I might implement loading scrolls tonight, since it seems like an easier task to do.

Well now getting to my point, this project is starting to take a more serious path of me wanting to complete it rather than just hobbyst fun. I was wondering if anyone in the community would be willing to help me look over and clean up my code, such as better ways to accomplish certain tasks... maybe help make clear up what the sprite code does, since although I can use it Im still confused to how it works. I've just learned how to use pointers recently so I imagine those parts of the code can be written in a more efficient manner. Im also wondering how I would document my progress correctly.

Im not going to post any part of the actual project until I am able to document it correctly. If there is anyone out there willing to give me some help with my project Id be really happy recieving the advice.

If anyone has questions or comments please Id like to hear. Also if anyone can think of some complex boards in zzt please post what they are here so I can test it out on what I've created. I would like to anticipate issues where they may lie.

[Exophase]

Someone was working on ZZT for GBA a few years ago. I'm not sure exactly how far it got.

I don't know if you've heard about DreamZZT - that's a ZZT player for DS.

http://dev.c99.org/D...wiki/DreamZZTDS

A GBA version could be pretty similar. You can also take the route Kev Vance does for getting 8x14 hardware rendering. I'm interested in hearing exactly how you're doing rendering right now.

If you need help with C or GBA stuff let me know.. I guess you can find me on AIM.

[Lachesis]

Heh, sounds really cool, actually. I'd love to help but I don't know much about zzt world format, c or c++, or documentation.

[Xx*SaturnineMatthias*xX]

I suppose it's easier to render ZZT because it uses plain text mode instead of an augmented text mode emulation that "requires" 8x14 (unless you change it in a way that makes normal MZX games unusable, such as SquareZeux). With ZZT, you could use 8x8, 8x14 or even 5x5 snd every game (that doesn't use fonts) will work with it.

[asiekierka]

I'm planning to make my own text-mode GCS for consoles. Specially designed for them.

[T-Bone]

Exophase, on Sep 20 2007, 08:30 PM, said:

I don't know if you've heard about DreamZZT - that's a ZZT player for DS.

I remember DreamZZT originally playable on the Dreamcast. That was like 8 years ago

[nooodl]

asiekierka, on Sep 21 2007, 01:10 PM, said:

I'm planning to make my own text-mode GCS for consoles. Specially designed for them.

*facepalm*

No offense, but how are you going to do that? :D

[ajs]

The hardest part about reimplementing ZZT is getting all of its quirks exactly right. That's why almost nobody uses the billion subsequent ZZT clones released. They don't play every ZZT game correctly, even if they look and feel like ZZT in every way.

--ajs.

[Elig]

I think this is an awesome idea. It might not perfectly emulate ZZT, but I still think it's a really cool idea. In terms of the quirks of ZZT, as far as I know, they're documented and very well known. It wouldn't be That hard to reimplement them. Even a basic emulator would be neat though. Even if it didn't emulate things properly, having a starting point that emulates something is good because over time more compatibility can be added.

[ajs]

Well, I prescribe to "seeing is believing", and I don't think anything less than a 100% correct emulation of ZZT is really that useful. I'm yet to see anything offer that.

ZZT as a GCS is kind of archaic, superseded in every respect. Playing classic titles is surely critical for it to be useful (networking sounds cool, but it's fairly impractical).

Like you say, it's good to have a starting point, but there's a lot more complexity to ZZT than a board viewer. A long way to go!

--ajs.

[Exophase]

ajs, on Sep 21 2007, 07:05 PM, said:

Well, I prescribe to "seeing is believing", and I don't think anything less than a 100% correct emulation of ZZT is really that useful. I'm yet to see anything offer that.

ZZT as a GCS is kind of archaic, superseded in every respect. Playing classic titles is surely critical for it to be useful (networking sounds cool, but it's fairly impractical).

Like you say, it's good to have a starting point, but there's a lot more complexity to ZZT than a board viewer. A long way to go!

--ajs.

Of course ZZT on GBA can't literally be 100% correct, but the required differences are probably not in the same category as the important ones you refer to. From what I understand clones exist that will play over 90% of ZZT games but no one uses them anyway, possibly because they're extremely picky, but more likely because DOS ZZT still "works" so there's no reason to replace it, especially if compromises have to be made. It'll never "just work" on a platform like GBA (PSP via DOSBox, on the other hand...) so if people do want to play it there they may be more willing to take what they can get.

On the other hand, it could just be that most ZZT games are crap and some of the most popular ones are the ones that exploit it the most...

If people do want portable ZZT they'll probably turn to DreamZZT (given that they have a DS and not just a GBA, which is a likely scenario). You can't really beat it on a GBA, and even if you could it has a huge head start. If just getting the best ZZT on GBA was the top priority then I'd recommend back-porting that, but that's not really any way to learn and have fun with a project.

[commodorejohn]

So...how well-documented are the quirks that people use as programming tricks? I would think that if they're consistent enough to use in a game they shouldn't be too hard to emulate.

[Nedemai]

Well I think Exo described in so many words what Im trying to accomplish. I just want to learn. 100% compatibility would be kewl, but it would take a lot more figuring and reading and documenting that Im willing to put into this project. I more or less just want something to run. Either way I might have to rethink the whole project just to ensure I get a high percent of compatibility... but at least a fair amount of my code could be recycled.

IF I do continue with this project however, Im probably going to reprogram a fair amount of this. I want to make this work well, and right now what I have is kind of hacked together from broken ideas.

[Elig]

ajs, on Sep 22 2007, 12:05 AM, said:

Well, I prescribe to "seeing is believing", and I don't think anything less than a 100% correct emulation of ZZT is really that useful.

I think people shouldn't program things just because of how useful they are or aren't. Besides, programs are built slowly. MZX is up to version 2.81g, you've got to start somewhere. MZX didn't start as much.

[asiekierka]

In fact, we will never get 100% ZZT emulation.
Way better will be our own text-mode GCS made specifically for consoles. Or something.

"You will never get 100% if 99% is enough."

[ajs]

Saying 100% compatibility is impossible is just stupid. Of course it's possible. The difficulty is that a lot of the quirks are just bugs, and probably implementation specific. And the original pascal was lost. Another difficulty is implementing all of the pickups, enemies, and builtins (correctly), which are obviously essential for ZZT games.

The point is that reimplementing the editor and other frivolities in ZZT is a waste of time, and more effort should be spent on compatibility. Just my two cents. I think it's inarguable that the clones aren't used because they just aren't as good as the original ZZT.

Of course, as Exo points out, ZZT actually works properly in DOSBox (unlike MZX, historically), so there's less motivation to reimplement it. Why risk a reimplementation when you can run the original perfectly? I don't think that in any way justifies console ports lacking compatibility, however.

@Elig: MegaZeux is an entirely different beast. Compatibility has been broken occasionally, but Exo did a port _from the original sources_ and compatibility is largely identical to the original DOS version. Any problems that do come up are rarely conceptually difficult to fix, and normally just bugs. See the veritable stack of bugs we fixed in 2.81g, with respect to compatibility. We even fixed a bug that existed in 2.51, before anybody besides Greg touched the sources. Hypothetically, some 2.02 games will play in 2.81g that wouldn't play in 2.51!

--ajs.

[asiekierka]

I think there SHOULD be a port of ZZT for non-DOSBox machines (GBA, DS).
EDIT: that dosen't suck (DreamZZT DS crashes on my fav games!)

This post has been edited by asiekierka: 22 September 2007 - 05:51 PM

[ajs]

Totally agree, I just don't think ZZT warrants a console-only implementation. It's too simple and perhaps Yet Another ZZT Clone would be useful, if it had perfect compatibility.

--ajs.

[Elig]

ajs, on Sep 22 2007, 02:36 PM, said:

Saying 100% compatibility is impossible is just stupid. Of course it's possible. The difficulty is that a lot of the quirks are just bugs, and probably implementation specific. And the original pascal was lost. Another difficulty is implementing all of the pickups, enemies, and builtins (correctly), which are obviously essential for ZZT games.

The point is that reimplementing the editor and other frivolities in ZZT is a waste of time, and more effort should be spent on compatibility. Just my two cents. I think it's inarguable that the clones aren't used because they just aren't as good as the original ZZT.

Of course, as Exo points out, ZZT actually works properly in DOSBox (unlike MZX, historically), so there's less motivation to reimplement it. Why risk a reimplementation when you can run the original perfectly? I don't think that in any way justifies console ports lacking compatibility, however.

@Elig: MegaZeux is an entirely different beast. Compatibility has been broken occasionally, but Exo did a port _from the original sources_ and compatibility is largely identical to the original DOS version. Any problems that do come up are rarely conceptually difficult to fix, and normally just bugs. See the veritable stack of bugs we fixed in 2.81g, with respect to compatibility. We even fixed a bug that existed in 2.51, before anybody besides Greg touched the sources. Hypothetically, some 2.02 games will play in 2.81g that wouldn't play in 2.51!

--ajs.

Right, but what I'm mainly saying is that a project's worth is more what it's worth to it's creator, not what it's worth to other people. For instance, if I created a ZZT clone, I might be doing it for my benefit or for my enjoyment, and that's a lot better than doing it so that there's another ZZT clone. Unarguably, we don't need more ZZT clones, but I think that's not looking at it from the perspective of the developer. Maybe the developer wants to learn about this or that through the production of a ZZT clone, or maybe the developer is just having fun trying to implement a ZZT clone.

Plus, emulators are traditionally built over a very long time with varying degrees of compatability. And what we're talking about is probably closest to an emulator, so, I see a lot of similarity there.

Sure, we don't need another NES emulator, but it might be a lot of fun for the developer.

Edit; Also, ZZT hasn't been done on the GBA before outside of DreamZZT to my knowledge. So, this would be a project that hasn't been done before.

This post has been edited by Elig: 23 September 2007 - 02:54 AM

[Dr_Dos]

I like how a mzxer works on porting ZZT to a handheld while a zzter works on porting MZX to a handheld. And I guess exo ports a handheld to a handheld.

[asiekierka]

You're right. a bit!
Nedemai (mzxer) works on porting zzt to a handheld.
Exo ports GBA to PSP.

[Elig]

Dr_Dos, on Sep 23 2007, 04:31 AM, said:

I like how a mzxer works on porting ZZT to a handheld while a zzter works on porting MZX to a handheld. And I guess exo ports a handheld to a handheld.

Awesome. That is just awesome. I completely agree.

[ajs]

Well, the difference is that Kev's job is much easier, because he IS porting. Nedemai would be implementing from scratch. That said, the DS is probably the hardest port to write yet.

--ajs.

[asiekierka]

EDIT: Whoops... i re-readed and got it.

This post has been edited by asiekierka: 23 September 2007 - 12:33 PM

[Nedemai]

Dr_Dos, on Sep 22 2007, 11:31 PM, said:

I like how a mzxer works on porting ZZT to a handheld while a zzter works on porting MZX to a handheld. And I guess exo ports a handheld to a handheld.

Thats both cute, and weird. Cute is all I can describe it as.

[T-Bone]

... and your weird for calling it cute