[Kewlio]

Because I was freaking bored, I decided to make a level loader/viewer for the game Chip's Challenge. It doesn't generate the best-looking maps ever, but it loads them right. Get it here or here:
 chipsmzx.7z (276.08K)
Number of downloads: 86

One caveat is that it takes a long time to load level data, even at speed 1. The official level set takes about four and a half minutes. I made it slightly more interesting (and make it look like it's actually doing something) by displaying the first eight characters of each level as it loads. Once it's all loaded, it takes only 2-3 seconds to load each level into the viewer.

The viewer itself allows for selecting levels either by number or also by level password. A legend is included in case you have no idea what it is you're looking at.

A save file with the user-generated Chip's Challenge Level Pack 2 (as well as the level pack itself) is included. To avoid copyright trash, the original level set is not included.

So, now that such a thing exists, would there be any interest at all if this was made into a fully functional (at least, as fully as MZX would allow) Chip's Challenge emulator?

This post has been edited by Kewlio: 01 November 2011 - 02:37 AM

[asgromo]

There would be my interest. I would enjoy that. Isn't that hard? Isn't Chip's Challenge rules/timing actually, like, ZZT-level idiosyncratic?

[Kewlio]

I figure it would be no easy feat to actually get it done. But hell if I'm not crazy enough to actually try. XD Fortunately, the Chip's Challenge wiki seems to give information on pretty much all of the intricate mechanics involved in the game. I know that most things move at a rate of five moves per second (so 200ms/move), with a couple of exceptions. I've played enough to know what does what and why it wouldn't do what in whatever case. The main problem I can see is in collision (where pretty much every sprite has to move all at the same time, and two monsters cannot occupy the same space).

I might make some test levels and play around with this...

[Maxim]

Put this in the first robot in the loader:

set "commands" "(-1>>1)"

[Kewlio]

Maxim, on 01 November 2011 - 06:44 AM, said:

Put this in the first robot in the loader:

set "commands" "(-1>>1)"

That just seems to make MZX seize up more than anything...

[Dr Lancer-X]

In that case you've got a busy loop (that is, a loop that continues infinitely without a wait 1 in it). Setting commands insanely high from the beginning is useful because it makes those extremely obvious so you can fix them.

[Lachesis]

But use something that's not stupidly high, something more reasonable like [set "commands" "(10^7)"] so MegaZeux doesn't lock up entirely. Total lockups are more counter-productive than it just slowing to a crawl, and all you really need is an obvious indication that something's wrong. Increase magnitude if needed

[Kewlio]

I still seem to get some freezing... Not as bad, but the file loads a lot faster. The viewer still seems to work better at the default 40 com/s, however. What's the best way to determine the best time and place to toss in a wait 1?

[Lachesis]

Well, you probably have a loop that looks something like:

: "loop"
. "stuff"
...
goto "loop"

Unchecked, this will run until the number of lines have been executed equal to what you set "commands" to. This is clearly a lot of commands, so we put a "cycle 1" right before goto "loop" so it will end the cycle after the code's been executed once.

edit 2: Perhaps I should clarify. Since the cycle command is very rarely used for its intended purpose anymore, and since wait 1 has unwanted side effects when a robot sends another robot to a subroutine, it's sorta started becoming standard practice to put "cycle 1" where a lot of people originally would have put "wait 1". I say sorta because of birds like Lancer-X who keep saying "wait 1"

: "loop"
. "stuff"
...
cycle 1
goto "loop"

edit: Ah, here it is, I think. From the robot Selector at 35,00, there are two bits that need the cycle ended:

: "inputloop"
if leftpressed then "prevlevel"
if rightpressed then "nextlevel"
goto "inputloop"

Change it to:

: "inputloop"
if leftpressed then "prevlevel"
if rightpressed then "nextlevel"
cycle 1
goto "inputloop"

From the same robot:

: "finalloop"
if "selectwait" = 1 then "finalloop"

Change it to:

: "finalloop"
cycle 1
if "selectwait" = 1 then "finalloop"

In the loader board, the timer robot needs one too:

: "startloop"
if "local1" = "TIME_SECONDS" then "startloop"

Change it to:

: "startloop"
cycle 1
if "local1" = "TIME_SECONDS" then "startloop"

Now, I couldn't really say why, but about half-way through loading the levels something starts wasting a lot of processor cycles (or the levels get really big). I haven't been able to figure out what's causing this The viewer should run smoothly now, though.

This post has been edited by Lachesis: 03 November 2011 - 04:30 PM

[Old-Sckool]

I've discovered some time ago that with my pokemon red/blue trainer pokemon/wild pokemon viewer, there becomes a point where initializing new variables dynamically suddenly becomes incredibly costly. Perhaps that's it?

[Spectere]

Lachesis, on 03 November 2011 - 11:58 AM, said:

...and since wait 1 has unwanted side effects when a robot sends another robot to a subroutine...

Sorry to bump this slightly off topic, but I'm curious: what kind of issues does that cause?

I'm out of the loop. -_-

[Lachesis]

When the robot returns from the subroutine, it executes the wait 1 again.

[Spectere]

Ah, good to know. Thanks.

[Kewlio]

Sorry for the late reply. I kind of have several projects going on right now. Combined with lack of energy to work on any of them consistently. Not exactly an ideal mix.

Anyhow, thanks for that, Lachesis. I'll be implementing that when I get back into this thing.