Gameboy Development Forum

Tag365 wrote:

Did you add Background Map attributes yet?

I think that only Works for game boy color.

I hope I did it correctly, I cloned Zalo's project on github and updated the engine here:

ZGB_Clone

I also added a demo to test things I am going to use in my games:

video https://www.youtube.com/watch?v=GWu-MOOYdj4

Super Princess' 2092 Exodus will compile with this, but won't work because I had to modify "ScrollSetMap" function.

The make.bat file has two settings to compile games.
        COLOR:
        yes = enable game boy color functions, ROM wil only work well on GBC.
        no = disable game boy color functions, ROM will only work well on DMG.
        CPlayer:
        yes = enable Carillon player for music, disable GBT player. Only .sav files will be used.
        no = enable GBT player for music, disable Carillon player. Only .mod files will be used.

Hope you like it .

Last edited by Mills (2017-03-29 16:03:18)

Zalo wrote:

Impressive job, Mills

Now you just need to do a pull request so I can start reviewing and merging all the changes (and Fix Super Princess so it can work with all these changes)

I forgot to say... bank 0 and 1 are so full, you can't init all states and sprites from main in bank 1.
It only lets you init about 3 states and 3 sprites.
But doing it from other banks works well, so you just have to init all sprites in a start function of a state in other bank, and then go to the level or menu they are used, and they will be there . (This way I could compile princess, because it filled up the first bank).

Also the animation structs seem to fill the ram used by carillon editor (depending on the game itself). This only happens on color mode, not in DMG mode.

Last edited by Mills (2017-03-30 04:27:37)

Zalo wrote:

Yes, I also wanted to change that initialization to another bank because I almost run out of memory in Super Princess

I also forgot to tell you... "Find tile in corners" function was disabled to fit the code in the banks... But I realised it fits in bank 0 again, so just activate it.

Ups.. it produced some random gfx problems... it is surelly filling up the rom bank..

Last edited by Mills (2017-03-31 16:32:48)

Which version of gbdk are you using? You should use 2.95-3

Hey, so... New question:
I was following the tutorial from the github page, but got lost when you tell to change the player sprite to the boy and export it.

I've changed it, added two frames, but where do I export it to? From where does the engine load it up? I couldn't find any sort of 'include "player.b2.c"' or anything of the sort anywhere.

I tried exporting the new sprite anyway, but the build.bat now just gives me an error ("Duplicate symbol 'bank_SPRITE_PLAYER', synbol IGNORED") right on  SpritePlayer.c's third line. The whole file looks pretty much the same it does on the tutorial, so what am I missing?

@Zal0 why did you ignored my email when I needed help on using ZGB. I was asking to help me find out why when I hit compile on the ZGB template nothing shows on bgb. Lucky I found out why and fixed it myself it tooked me a nearly month too.

@Millis why all of a sudden you stop helping me via email and replying ? Lucky that I got it sorted

npzman wrote:

@Zal0 why did you ignored my email when I needed help on using ZGB. I was asking to help me find out why when I hit compile on the ZGB template nothing shows on bgb. Lucky I found out why and fixed it myself it tooked me a nearly month too.

Because as I told you, you were starting the get annoying. You should really calm down a bit, wait for people to answer and listen to what they are saying. You don't enter a forum and say people are pissing you off and start posting about whatever you want anywhere. Also sending thousand of emails to people won't help. I'd like to think you are just too young...

@Zalo, I think I found a mistake in the tutorial. When you teach how to do collisions for the enemy, there's the following:

In order to collide with the enemy you have to add the next code at the end of the method Update of SpritePlayer.c

#include "ZGBMain.h"
...

void Update_SPRITE_PLAYER() {
    UINT8 i;
    struct Sprite* spr;
    ...

    SPRITEMANAGER_ITERATE(i, spr) {
        if(spr->type == SPRITE_ENEMY) {
            if(CheckCollision(THIS, spr)) {
                SetState(STATE_GAME);
            }
        }
    }
}

If i'm correct, the part in bold should be above, with the other declarations. It just doesn't work inside the Update, but once I took it all up there, the code compiled flawlessly. I also realize it's something really minor, but to people who aren't quite "fluent" in programming, it's a needless hassle.

DU0 wrote:

@Zalo, I think I found a mistake in the tutorial. When you teach how to do collisions for the enemy, there's the following:

In order to collide with the enemy you have to add the next code at the end of the method Update of SpritePlayer.c

#include "ZGBMain.h"
...

void Update_SPRITE_PLAYER() {
    UINT8 i;
    struct Sprite* spr;
    ...

    SPRITEMANAGER_ITERATE(i, spr) {
        if(spr->type == SPRITE_ENEMY) {
            if(CheckCollision(THIS, spr)) {
                SetState(STATE_GAME);
            }
        }
    }
}

If i'm correct, the part in bold should be above, with the other declarations. It just doesn't work inside the Update, but once I took it all up there, the code compiled flawlessly. I also realize it's something really minor, but to people who aren't quite "fluent" in programming, it's a needless hassle.

I compiled it that way, and it works, you just have to be sure the UINT and struct are the first lines inside the update function, and then you can add other things.

Mills wrote:

DU0 wrote:

@Zalo, I think I found a mistake in the tutorial. When you teach how to do collisions for the enemy, there's the following:

In order to collide with the enemy you have to add the next code at the end of the method Update of SpritePlayer.c

#include "ZGBMain.h"
...

void Update_SPRITE_PLAYER() {
    UINT8 i;
    struct Sprite* spr;
    ...

    SPRITEMANAGER_ITERATE(i, spr) {
        if(spr->type == SPRITE_ENEMY) {
            if(CheckCollision(THIS, spr)) {
                SetState(STATE_GAME);
            }
        }
    }
}

If i'm correct, the part in bold should be above, with the other declarations. It just doesn't work inside the Update, but once I took it all up there, the code compiled flawlessly. I also realize it's something really minor, but to people who aren't quite "fluent" in programming, it's a needless hassle.

I compiled it that way, and it works, you just have to be sure the UINT and struct are the first lines inside the update function, and then you can add other things.

I just tested it here, and indeed, it works if those are the first parameters. Will it make any relevant difference if I leave it inside or outside of the method?
I remember hearing about how this stuff should always be outside, but I don't know if there's any difference on the Game Boy or anything.

Xephyr wrote:

I don't think it should for this specific function.

If you declare your variables outside of it, it means they are globals : they can be use by any function of your file (or other files using the extern keyword). If declared inside of your function, they can only be used by this specific function.

Declaring non-global variables is usually safer since it avoids side functions to write on your variable.
However, on GBDK, the main difference is that global variables are statically allocated to a specific RAM address while non-global variables are store on the stack, which requires some calculation to access them (hence more time). It's speed versus safety if you prefer.

Thanks, that's very well put. I recall reading about something GB-specific, but I didn't make a lot of sense at the time.