4. I understand, it's good to get experience. I hope that after a certain point you'll use libraries, though; I've gone the route of rolling my own everything in other languages, and it gets tedious. Plus Benryves gets angry at you.

5. That's what I figured.

6. Yes. Any 8-bit to 8-bit register load is a single byte, whereas loading an immediate (a number) to an 8-bit register is 2 bytes. Loading an immediate to a 16-bit register is 3 byte, 1 for the opcode and 2 for the value. There is no 16-bit to 16-bit register load other than ex de,hl (which is 1 byte) and push r16a \ pop r16b, which is of course two bytes and quite a few cycles. As far as writing good code, it's good to start to get a sense for how opcode size figures into your program. Another good one that's key is that jr blah is 2 bytes, jr condition,blah is 2 bytes, jp blah and jp condition, blah are both 3 bytes, and bcall() and call are both 3 bytes.

Ok, I've looked through your program a little, and I must say: you did a good job!
There are a few optimizations possible though. Although I reaize some of them involve tricks and techniques you haven't come across yet.
P.S. Sorry for the upparcase mnemomics, it's just my way of coding.

Code:

could be changed to XOR A, to save 1 byte.

Code:

What would you think of:

Code:

Moving on:

Code:

There are many successive bytes in memory you reset here. Your code took 19 bytes...

Code:

This takes up 17 bytes.

Code:

I'm not exactly sure what you're using HL for, but I guess it involves a countdown for the character to move a place down. I'd recommend using an interrupt service for that, but I think you're not familiar with that, so this could be a future optimization.

Code:

As kerm said, OR A works much better for resetting carry.

Code:

I guess you mean $500?

Code:

OR A, again, would work best.

Code:

Would be redundand if you were using interrupts.

Code:

Again, XOR A saves you space.

Overall, you did a wonderful job, really!
An idea for the score displaying mechanism:

Code:

It should do, but b_call(_DispHL) takes up 5 characters on the screen, which would interfere with you're game screen. I don't see any other place to display the score though.

Kerm: I know that I'll have to use libs eventually. I dragged my feet with c for a long time, but I came around eventually. Idk if it will ever happen in z80 though because, like I said, a lot of my users will be too lazy/ignorant to download a shell.
And anyways, I wouldn't want to get on Ben Ryves's nerves. Before I even knew cemetech existed, I stumbled across his personal webpage and some of the projects he's finished amazed me (especially the z80 computer). I don't like getting on the nerves of awesome people.

arriopolis:
Thank you for all the helpful remarks =)
1/2. Cool, easy to understand
3. This was crazy helpful and I would have continued to do stuff the stupid way had you not pointed this out. Imagine me writing a big project and initializing 30 or 40 vars like that. Ouch.
If I'm going to copy the data at the VariableSetup label to AppBackUpScreen, wouldn't it just be better to have code like:

Code:


4. I'm aware of interrupts, but I don't know how to use them yet. New post time in my questions thread!!!

5/6. Got those too =)

7. Oops!! I wanted to make the delay longer, but I forgot to update it in the comments!

8-10. Acknowleged and remembered!

11. As for the score display system, I was already aware of the b_call(_DispHL), but I want the score to be displayed vertically in the same column where lives are displayed:


Code:


So I will have to come up with a function to convert that int to a string (Which I would like to do on my own )

Hehe, you preempted my suggestion. I wouldn't try to mess with interrupts for a good long while; there's a lot to understand with ports and the underlying hardware if you want to properly understand what you're implementing rather than copy-pasting code.