(Final)NitroSpritesLib

[YoshiInAVoid]

Thanks! I'll test it immediatly!

[YoshiInAVoid]

Will give an error. Requires the shape parameter.

[Foxi4]

The Shape parameter has been deprecated, it's automatically computed from Size (aka, no need to use it in the function).

I know it gives errors, it's a draft that I still have to work on. You get the gist of how it'll work though.

I posted it for revision purposes, debugging alone takes forever.

What I now have to do is look through it function by function and debug everything. Let's call this the backbone of the end-product.

[Foxi4]

About 15% ready with bugfixing. Loading Palettes and Sprites now works separatelly, creating GFX files works (each sprite may be created with a separate GFX out of 128 GFX'es or from a pre-existing GFX). Free'ing and whatnot will be fixed later, stay tuned, I'll likely finish tonight.

[Buck_7]

Will it be easier to use? I did't even get how to use the first version.

[Foxi4]

It's really a few very simple steps:
1. Attach your Resources (Palettes and Sprites) to Nitro Files.
2. Load said Resources with the specified functions.
3. Spawn the Resources.
4. Delete/Purge at will.

[Foxi4]

Pretty much everything working now.

Thanks to Yoshi for making the extra functions (and for motivating me to make some changes).
Now all that's left to revise is the Backgrounds lib lol. But... not today *yawn*.

Do post your impressions.

PS: YES, I am looping through all 128 slots. Why not just through the used ones? Because for some bizzare reason the loop sometimes left a few slots untouched, leaving unnecessary Gfx's, Sprites or Resources.

The UnloadAll and DeleteAll functions should be used only on loading screens ANYWAYS, so it doesn't particularily matter. If you want to Delete or Unload a single Sprite, nothing's stopping you.

It's also worth noting that DeleteSprite means Deleting BOTH the Sprite and the corresponding Gfx. If the Sprite has been created from a SHARED Gfx, use the standard PAlib function instead or you'll end up deleting a Gfx you did not intend to delete!

[YoshiInAVoid]

The Shape parameter has been deprecated, it's automatically computed from Size (aka, no need to use it in the function).

4 hours later he releases the lib with the Shape parameter for FAT_CreateSprite and FAT_CreateSpriteFromGFX... I hate to say I told you so but well...

Anyway, this is really great work. When loading Lizza, the main character on Zombase using my previous one, the first frame had a few odd pixels in the corner. Hopefully this updated version of the lib will fix that. Too tired to test now though.

[Foxi4]

I was actually going to sprintf OBJ_SIZE%dX%d but the compiler didn't feel like accepting my parameters. The argument was indeed deprecated and I have no clue as to why it "doesn't work" because even now you're not really inputting any shape - just the size macro.

As far as the "odd pixels" are concerned, it's likely that the sprite was created before the resource was fully loaded. This is why loading resources and creating sprites are separate functions in the lib.

[YoshiInAVoid]

"I was actually going to sprintf OBJ_SIZE%dX%d but the compiler didn't feel like accepting my parameters. The argument was indeed deprecated and I have no clue as to why it "doesn't work""

Of course it won't work! OBJ_SIZE_64X64 is a define for something like "1,0" I don't know the exact value. But if your strcpy and strcating the size, it will not be defined.

[YoshiInAVoid]

For persons whom wish not to trouble themselves with palette loading and messing with tiles... I present:

Code: Select all

char _Sprite[50];
char _Pal[50];
void FAT_BasicCreateSprite(u8 Screen, u8 SpriteNum, u8 PaletteNum, char FileName[39], u8 Shape, u8 Size, int X, int Y) {
   strcpy(_Sprite, FileName);
   strcat(_Sprite, "_Sprite.bin");
   strcpy(_Pal, FileName);
   strcat(_Pal, "_Pal.bin");
   FAT_LoadPal(PaletteNum, Screen, _Pal);
   FAT_LoadSprite(SpriteNum, _Sprite);
   PA_WaitForVBL();
   FAT_CreateSprite(Screen, SpriteNum, PaletteNum, Shape, Size, X, Y);
}

Extreamly inefficient but it gets the job done :)

[YoshiInAVoid]

It's definatly better, but thier still is this one pixel. Aaaaaaaaagh! It's driving me insane!

StoopidPixel.png (3.52 KiB) Viewed 924 times

[YoshiInAVoid]

My mistake, it was Aschaschi's sprite that had a little pixel that looked almost identical to magenta on every jumping frame I fixed it though.

[Foxi4]

Making OBJ_SIZE a string was my crude attempt at code generation which obviously failed.

I'm glad that it's working better now, but there are still a few revisions I wish to make, especially with the way the library counts Gfx files, but that's for the future.

For now, the lib is programmed to believe that all sprites are loaded from Nitro and everything else is controlled via standard PAlib functions, which will likely change in the nearby future. Unfortunatelly there's a whole lot of exams on my head and I really don't have the spare time to work on it.

Parhaps next week I'll make a revision, for now this can be treated as the *final* version, as no functions (or the syntax) will be changed, only the way they work.

As far as your loading function is concerned, all's dandy but I suggest...

Code: Select all

void FAT_BasicCreateSprite(u8 Screen, u8 SpriteNum, u8 PaletteNum, char FileName[39], u8 Shape, u8 Size, int X, int Y) {
   strcpy(_Sprite, FileName);
   strcat(_Sprite, "_Sprite.bin");
   strcpy(_Pal, FileName);
   strcat(_Pal, "_Pal.bin");
   FAT_LoadPal(PaletteNum, Screen, _Pal);
   FAT_UnloadSprite(SpriteNum);
//While Slot is being wiped... (may take more than one V-Blank afterall with bigger sprites)
   while(SpriteCustom[SpriteNum]!=NULL){
       PA_WaitForVBL();
   }
//While FAT_LoadSprite is in progress...
      while(FAT_LoadSprite(SpriteNum, _Sprite)){
       PA_WaitForVBL();
   }
//If loading was infact successful...
   if(SpriteCustom[SpriteNum]!=NULL){
      FAT_CreateSprite(Screen, SpriteNum, PaletteNum, Shape, Size, X, Y);
   }
}


Untested, but even if I made a mistake then it's likely to be blatantly apparent - I'm just tired out of my mind atm.

[YoshiInAVoid]

Thanks a tonne Foxi4! That should hopefully stop any more problems, I've added it into Zombase

[Foxi4]

I take it that the code's working? Good.

If there will be any problems with the While loop, just change the void function into a bool and return(1); when loading is finished... or something.

[YoshiInAVoid]

Didn't test all of it, I just added in the first while and the Unload function; it's all that the code needs. This is what I'm using:

Code: Select all

char _Sprite[50];
char _Pal[50];
void FAT_BasicCreateSprite(u8 Screen, u8 SpriteNum, u8 PaletteNum, char FileName[39], u8 Shape, u8 Size, int X, int Y) {
   strcpy(_Sprite, FileName);
   strcat(_Sprite, "_Sprite.bin");
   strcpy(_Pal, FileName);
   strcat(_Pal, "_Pal.bin");
   FAT_LoadPal(PaletteNum, Screen, _Pal);
   FAT_UnloadSprite(SpriteNum);
   while(SpriteCustom[SpriteNum] != NULL) { // I LOVE the word NULL! It just sounds so cool!
      PA_WaitForVBL();
   }
   FAT_LoadSprite(SpriteNum, _Sprite);
   FAT_CreateSprite(Screen, SpriteNum, PaletteNum, Shape, Size, X, Y);
}

//Zombase specific code:

#define CreateObject(Object, FileName)\
   FAT_BasicCreateSprite(1, Object.N, Object.P, FileName, OBJ_SIZE_32X32, Object.X>>8, Object.Y>>8);

...

More stuff here.


EDIT: I see I still left my comment in

Also, upon calling your FAT_UnloadAllSprites or whatever it's called, it throws an error in no$gba saying the ROM Image crashed. You will need the while loop from here:

FAT_UnloadSprite(FreeLoop);
while(SpriteCustom[FreeLoop] != NULL) {
PA_WaitForVBL();
}

In order to get it working.

[Foxi4]

You sure? Seems to be working fine on a DS, that function needs no arguments, just a declared freeloop var.

[YoshiInAVoid]

Also, might want to change the X and Y positions to a signed 16bit value (s16), I like to have my sprites loaded off screen (-64, -64 not 256, 192).

[Foxi4]

That *is* a great suggestion, I'll note that for the next revision!