Ok, I'm trying to add OOP to Happy.
I only have a small problem:

Where do I place te objects, and how big?

It is simple with objects like this:

type point[2] {
    ubyte x;
    ubyte y;
}

// And in the program or global declarations:

point lol;


I can place this with the other vars after the code, and I know I need 2 bytes of space

But even this approach gives problems:
For example, how do I give it initial values? 

Amd when using the stack, How do I know the amount of space left?

And this gives even more problems:

type string[] { // Yup, no native support
    ubyte[] value;
    
    empty create(ubyte[] in) { // empty is a subroutine type
        // Loop and copy the string
    }
}

This one doesn't make sense, because we have the same data twice in RAM.

type enemy[10] {
    ubyte x;
    ubyte y;
    ubyte[8] sprite; // The monochtome sprite data

    empty move(sbyte dx, sbyte dy) {
        x = x + dx;
        y = y + dy; // update the pos
    }
}

To make it short:
1. Happy doesn't always know how big it is
2. How can initial values be set?
3. How do I stop the program from corrupting things in RAM, with a ever-growing stack?

@Eeems Lol, I met some Canadians, they were really nice people!!!

Poof, new update, I have been busy on my axe libraries, school, a notes program, Happy, minecraft (sadly), and some other things, but here it is:

* Fixed some annoying bugs, like falling through blocks.
* Blocks aren't (completely) hidden in walls anymore.
* As always, I did more but I forgot ... (0x5)

now version 0.6.7

As always, NEWJUMP is the program, SNEWJUMP the source.

Please report any bugs!!

LOOOL DT!!!!!!!!
Lasers there are pretty cool too, have a 30mW one here

the cooking page: two dolphins doing ... uh ... yeah

sorry for the off-topic:
Try again, you have missed something.

Does Happy/Random count as a calc project? (If not, I have DionJump (I should upload my new version))

Ok, I am working on a new version. which will be designed top-down (that means, first get the parsing large things right, then the smaller ones).
Currently this is valid:

{
    if() {
        ;
        ;
    } else {
        ;
        ;
    }
}
yup, that's right, nothing yet...  To see what it actually does, type dev in the options box.
But if I would merge it with the old parser, I would have an almost working one!
However, I don't want to  , because I'm going to add support for data types and so on...

some questions:
default signed or unsigned? (or 16bit signed and 8bit unsigned)
C or am I allowed to make it more calc-specific and consistent?

I'll keep you updated via the first post and my sig.

Wow, you're bored and think: Let's create a new language! LOL
How did you make it on-calc?

@DT, wowlol

I think a deja vu is a mistake by our brains, but because we don't know everything about them, it could be something different.

^Baaaaad grammar, I know