igwgames / nes-starter-kit

A Beginner's Guide and toolkit for NES game creation.
MIT License
214 stars 24 forks source link

Adding Metasprites to game #24

Closed haseeb-heaven closed 3 years ago

haseeb-heaven commented 3 years ago

Hi, can you add examples of adding metasprites into the game as shown here and your game engine uses oam_spr() method to draw sprites and not oam_meta_spr() along with buffer_4_mt() method from nesdouug lib.

The only problem with that library is either your can use buffer_1_mt() or buffer_4_mt() to draw metasprites in game and tiles has to be 32x32 size and not other known sizes.

And can you improve these for both 8x8 Sprites (Square) and 8x16 Sprites(Rectangle) as well

Last can you include nesdoug library also? that also has useful utilities method which are worth checking. Thanks.

potatolain commented 3 years ago

Hey,

There are a few things here, so let me go through them one by one.


For the first point on metasprites, as of now the library doesn't really use the metasprite functions built into neslib directly. When writing it I felt it was more flexible to use oam_spr() directly, and handle metasprites within the engine. There are details on how it works in these two chapters:

I don't explicitly mention this, but the goal of having the SPRITE_SIZE_8PX_8PX and SPRITE_SIZE_16PX_16PX values as part of the meta sprite definition is to let you make other sprite sizes. (For example, in my own games I have made SPRITE_SIZE_24PX_8PX before)

I hope that makes sense. Would it help if I wrote a section on creating new sprite sizes?


For the 8x8/8x16 sprites thing, I see you have also opened a task about supporting them - let's keep further discussion there.


Lastly, while I really like nesdoug's library, I don't think including his whole library here is the right move. If we had unlimited space and cpu time, it could make sense, but the NES (and mmc1 mapper) are both fairly limited. I want to give as much of that space to users as possible by default.

That said, if you want to include doug's library in your own project, you probably can. It's written for a slightly newer version of cc65, so there is a chance you may hit some challenges, but in theory what you would need to do is:

  1. Copy nesdoug.h and nesdoug.s from here: https://github.com/nesdoug/26_Full_Game/tree/master/LIB and put them in the project (maybe in source/library)
  2. Update source/neslib_asm/crt0.asm to load this .s file (I think it would look like .include "source/library/nesdoug.s"
  3. Update this same file for Doug's changes, here: https://github.com/nesdoug/26_Full_Game/blob/master/crt0.s#L104
  4. Add a #include "source/library/nesdoug.h" to the file you want
  5. Start using it

Hope that helps get you rolling, and I'm open to continuing to discuss this

haseeb-heaven commented 3 years ago

I hope that makes sense. Would it help if I wrote a section on creating new sprite sizes?

Yes if you have time please also include bounding box collision with those sprites also.

Lastly, while I really like nesdoug's library, I don't think including his whole library here is the right move

I know but he also had modified neslib by Shiru and made sprites draw faster by removing Sprites Id from parameter and he has done for Metasprites as well. But your library still uses SPR_ID parameter thats why i was telling if its faster then we can adapt that method and update it.

potatolain commented 3 years ago

That makes sense, I won't promise exactly when I'll write it, hopefully soon.

As a bit of a preview (or maybe to get you going faster)

I'll expand on that in the chapter when I write it; just wanted to get that written down now.

potatolain commented 3 years ago

This is now added to the third section of the guide! Here's a direct link:

https://cppchriscpp.github.io/nes-starter-kit//guide/section_3/adding_new_sprite_sizes.html


I realized I forgot to respond to your thought about nesdoug's library's modifications to how sprites are drawn. While that method is faster, it's also restrictive - it would actually break how the library currently implements sprite flicker.

Changing that would make some areas of the engine harder to understand. My first priority with nes-starter-kit is to make it understandable to newcomers - I have opted to do less efficient things in a few places in hopes the result is easier to read. As such, I don't really want to change that right now.


I'm going to close this issue since the task is done, but if there are issues or things to discuss feel free to open a new issue, or just comment here.

Thanks for the suggestion, and I hope this helps!