1x1 is a single sprite, right? You don't mean 36x21 screens, I assume.

yeah. that figure is in tiles

each screen is 9x7, and so the 36x21 is actually 4 screens by 3 screens.

Progress Update

World sprites done. And coded. Program is at 800 bytes and change.
Still have 4 dungeon maps to do, then code all maps in.


@ Kerm (or anyone else). Do you happen to have around, or can easily produce, two routines (in assembly or preferably in AXE), one that can compress hex data into RLE, and another than can convert RLE back into hex. They both can target appvars. The RLE->hex must target the appvar named "ZeldaI". The hex->RLE can target any arbitrary appvar.

Doors CS's MOS compatibility libraries have a few routines for working with RLE'd data, but only to perform decompression, not to perform compression. I'll wait to see if anyone else has a set of routines in either language handy before I give you some code.

well, nemo linked me to one on omnimaga, but it sort of confuses me.

In ASM or in Axe? What do you find confusing about it?

It is in Axe. It seems to be a bit, err... well, complicated.

http://ourl.ca/7818

It is in that list, and it is the one-byte method.

Well, since I don't really know Axe, I'm a little vague on the syntax, but that sort of makes sense to me. Is there anything I can explain about it? Is the underlying RLE algorithm confusing you, or the implementation?

No I'm good with the concept of RLE. It's kind of like the exponential notation of programming, compressing 3x3x3x3 into 3^4, but it is just the way that particular routine goes about it that took my brain for a spin, then stomped on it once more, just for good measure.

Haha, gotcha. Well, perhaps you should write out your understanding of RLE in quick-and-easy pseudocode, and see how it jives?

getDataStart->A ; gets the start of the data to be compressed
getDataLength->B ; gets the length of the data to be compressed
createTempVar->D ; place to store compressed data (A,B,D=PTRs)
Zeros(2)
0->E ; set counter of bytes
0->F ; set counter for temp var
Repeat A=B
{A}->C
If {A}={A+1}
E+1->E
Else
{A}->{2F+D}
E->{2F+D-1}
0->E
F+1-F
End
End

???

Ooh, that looks like great code! Do you mind if I use it in my Installer project? I'll put you in the credits if you want me to.

I HAVE NO CLUE IF IT EVEN WORKS. IM WAITING ON SOMEONE GOOD IN AXE TO TELL ME IF IT WORKS. IF IT DOES, SURE YOU CAN.

Well, Repeat A=B won't work because A is a pointer to the start of the data and B is a pointer to the length. It would work if B were the end of the data plus one, but you also forgot to increment A. 2F+D won't work because Axe doesn't do implied multiplication, and even with F*2, that should be an E->{F*2+D+1} in the next line. And you stored {A} to C without using it later

lol. fail on my part. should it work, otherwise?

Not sure, I didn't actually try it.

What's Zeros(2) for?

It adds the two bytes to the pointer that stores the data, so that I can add the data for the next number. Which reminds me, Zeros(2) belongs also in the conditional for ELSE.

Zeros(2) doesn't actually add two bytes to anything. It's not even part of the code. It's just two bytes of zeros that are stuck in at the end of the program you're currently running. It doesn't matter either whether it's inside or outside of any loop or If block. It only matters to the program at all when it's being compiled, and never again.

As an Axe outsider, what's the point of that, then?

Zeroes(2) basically adds 2 bytes of 0 to the end of the data structure last used. For instance, if you had:
Code:

{Pic1} would contain [1234560000]