I am pleased to give you the 675th Zelda topic I have opened on this forum

While I have been fussing over a Ubuntu install and trudging through class, I have secretly resumed progress on Legend of Zelda, Ganon's Rage. At present, I have the Installer, Initialization, Main Menu, About Screen, Splash Screen, Text Rendering Routines, Saving/Opening File, New Game, and Maps done.

Yet to do...The engines... That includes the Sprite Display, Event Scripts and Triggers, Movement Engine, and the AI...

I can handle the Events and Triggers reasonably quickly.
I believe that some others were handling the Sprite Display engine, movement, and AI, although I don't remember who.

In short, once these last parts get done...beta time.

Oh, as an aside: this game looks like it'll be 3 pages, unless I can compress the maps. Even then, it still may be.

Prizm? Ti? I want more informations!
/me drools of impatience

he's talking about a z80 flash app

Wha, cool! I can't wait to see the final result.
I would also volunteer as a beta tester

Quick question.... Can you conditionalize a bcall or bjump using the flags, like you can with call, jr, and jp.

Edit:

so...is this right

#define b_jumpz(xxxx) jr nz,$+5 \ call 50h \ .dw xxxx
#define b_jumpnz(xxxx) jr z,$+5 \ call 50h \ .dw xxxx

And the c, nc variations done the same way.

Yup, that should work fine, except I think that the $+5's should be $+7. call is 3 and .dw is 2, and the jr itself is 2, so that's 7 all together.

$+5 is correct. jr $+0 doesn't take you back two bytes, but instead, leaves you at the end of the jr instruction. The +n part refers to _after_ the jr. And, yes, those are the correct instructions to use, and I believe something similar is in BrandonW's ti83plus.inc or TI's.

I maintain that jr $+0 takes you to the _beginning_ of the jr instruction, so that jr $+0 would be an infinite loop (rather than an effective no-op). I'd be happy to be proven wrong, however.

jr $-2 is an infinite loop. As _player1537 pointed out, $ is updated to point to the next instruction before operands are calculated. See Z80 Bits for examples.

As an aside, I found an Archive/Unarchive optimization using this...

Code:


Now, as you can see...the Arc_Unarc bcall occurs only if z is reset, but bcall ChkFindSym occurs twice, regardless. Can I use bcallnz here too? How much of a slowdown occurs as a result of doing that twice?

Edit 2: Oh, btw...is there an easy way of counting bytes in a program's code? I mean XCode can count by lines, but I'm not sure if it can or how to count by bytes.

Also, I'm thinking of trying to RLE encrypt the maps, so that just maybe I can pull in at 2 pages. If so, I need a computer program that can compress a string of bytes and an on-calc RLE Decryption routine. I'm sure there's one of those lying around on here or on omni.


Edit3: Who here was going to help me with the Rendering, Movement, and AI engines? Because that's pretty much all that is left.

When it comes to compressing the maps, I can't seem to work the utilities, between finding the binaries and the fact that im on a Mac. If I post here the data that I need compressed, how trivial would it be for someone to run it through the utilities and post the result back.

How about this:
Code:


Put a label called CountStart or something where you want to start counting from, and at the point where you want to stop counting, you can do something like:
Code:

This actually should do what I need

Code:

Are you asking or telling? And please, for the love of all that is technological, never use $+N jumps. Labels exist for a reason. Also, you either need to xor a right before the ld a,b, or jump directly to the ld hl,Health line.

Edit: And either way you also need to increment de twice; otherwise you're going to trash the size word.

Asking, with some degree of certainty, if that makes any sense. And, what is wrong with a $+N jump? They work, don't they? And yeah I keep forgetting about the size word. And, yeah, I noticed that in alot. Yet I don't understand why its needed?

You don't realize how much I dislike those types of references. LABELS, USE. If you don't have the size of all tops memorized, then you will be forced to look up each op. For ex, random $+12 jumps are killer to understand.

In other words less yelling, nice work on progress! Its always nice to see more flash apps for the z80 calcs.

Well, I don't use those types of jumps for alot, only when I want to do a conditional, and there is a little bit of code in between. So like, where in TI Basic, you would do

If [condition]: Then
// code
End:
code

I do

[condition]
jr [false condition], $+distance to if-false, do block
Then block
Else block

In all other cases I use Labels

Hrm, wasn't there a special temp label that you could do, like
$:
...
jr -$

to go backwards and
...
jr +$
...
$:

to go forwards? Also, you can use temp labels. Not sure if your assembler has it, but mine lets me make 5 digit temp labels that can be reused in other routines, like 10001$:

Ok... anyone here experienced with graphics rendering in greyscale? I need some help with a greyscale smooth scrolling system. I will set up the entry to the engine so that

hl - points to the start of the current map data
de - points to the start of the sprite data
The map data is configured...
1 byte width followed by map data
The sprites are 8x8, and are ordered sequentially, with 2 sprites per tile, so that tile $00 corresponds to sprites 1+2 and tile $01 corresponds to sprites 3+4 and so on. I have $5B sprites.

If you use them at all, you're making your code unmaintainable. All you need to do is insert one opcode while forgetting to update the length of the junk, and you have an instant hard-to-trace bug. Labels are free, use them.

Every program starts with a 2-byte size word, then its contents. Without that, there would be no way to tell how big a program is.