Unlimited Game Object and Monster Graphic Assets

timkilgore

New member
Hi everyone,

One of the beta testers here who should really be more active than he is. The game I'm hoping to work on is a twist on the beat 'em up engine that will be a wrestling game. However I can't really see how that will work with the number of Game Object and Monster Graphic Assets. I understand that NES Maker is really adhering to the NES limitations for ram however I was wondering if there could be a way to continually add those in to the graphic assets and then point to them for different animations.

I think it's awesome that many are trying to put together a game on a cartridge and that's the ultimate goal of the project, some of us like myself aren't so interested in putting the game on a cartridge as much as putting it on our Raspberry Pi or NES Classic. Which would allow for larger game files. I'm wondering if the ability to add more Game Object and Monster Graphic Assets could be put into the NES Maker with possibly a pop up message saying that the rom you're creating will not be able to be moved to a cartridge as soon as you go over the amount of ram for the cartridge.

Apologies if I'm misunderstanding overall how the NES games work. I'm just not really able to picture my final dream project working the way things are now. I can totally see making a fantastic platformer, and RPG/Zelda type game which I no doubt will want to do eventually. My game really won't need even a fraction of the background tiles that we have allocated but probably double the number of Game Object and Monster Graphic Assets. I'm hoping there's some way to do what I'm hoping.

Thanks Joe (and anyone who reads this and knows the answer so Joe can spend more time feverishly coding).
 

MistSonata

Moderator
I'm not an expert, but I'm assuming that the way the NES works that expanding the size of the rom might require more programming than would be practical, especially increasing the amount of game objects (I assume you mean increasing the amount on screen at one time), as that's a fairly hard limit of the NES itself.

If your game idea is that far beyond what the NES is capable of, then you might just be better off using GameMaker, and simply making it in a retro style. You may not be able to play it on a NES classic or a Raspberry Pi (though, I suppose a way exists out there somewhere) but it'd be easier than trying to program NESmaker to do more than its target scope could.

EDIT: You can export gamemaker games to android systems, which can then be run on a Raspberry Pi. It requires a special OS called RTAndroid so it doesn't look like you'd be able to install alongside Retropie, but you could install it on a separate SD card and swap between them easily. Even then there are probably some complications or considerations I'm missing but still...
 

Bucket Mouse

Active member
On a related subject.....one of my ideas was a Robotron clone, but after seeing a limit of just four monsters onscreen, I had to file that away. They're talking about expanding it to eight, but I don't know if that's enough. This type of game doesn't work unless you feel overwhelmed by monsters. How many onscreen sprites was Smash TV able to get away with?
 

timkilgore

New member
I don't think that my idea is really beyond what the NES is capable of because of what I see with things like River City Ransom and especially Nekketsu Kakutou Densetsu. That game has essentially 4 different characters you can choose from with completely different attacks based on the birthday selected. That game wasn't even the largest NES game there. I thought I had read in a previous post (probably on the Facebook group) that technically it's the bank switching that NES Maker is automating, in the Tutorial I see that when creating the walking animation there's a drop down that selects the sheet it's being pulled from, I'm just wondering if you could keep going there where if you add them into the Graphic Assets it would be recognized and could be used.

Bucket Mouse is kind of hitting what I'm hitting on here with that issue. The reason for the 4 monster limit is because of the flicker on NES. Look at a game like Super Dodge Ball, there are WAY more enemies on screen than 3. I think there are 5 on each side. So there's 10 Sprites in total. The problem is that as soon as they are on the same horizontal axis more than 8 pixels they flicker like crazy. Smash TV got away with this because they came in at different times and mostly attacked from top down. Something like Space Invaders. Side Scrolling Shooters you'll notice always had things at different heights, even Contra did the same trick. I get that you don't want to have a bunch of games that have all these shitty flickering graphics constantly because the creator didn't adhere to the 8 sprite per horizontal line limit and then brag they made it with NES Maker, but on the other hand people might have some pretty creative ways to get around that by putting things in all different spots and attack patterns. I would think in that situation why not allow unlimited monsters on screen but put a pop-up box saying something to the effect of "Exceeds 8 sprite limit per scan line and will cause flicker". Some Emulators you can turn that off on, it's not REAL NES but again people might just want to play it in an Emulator which means since they can turn the flickering off there they don't care if it works on the actual machine or not.

I have Game Maker, I also have Clickteam Fusion. I just don't like the feel of how they create games, I can get them to do basically what I'm looking to do it doesn't feel like an NES game. Plus Game Maker is pretty much impossible to recognize the NES Controller which is frustrating. I grabbed a book on C++ programming and I might do it that way because of the color limit for sprites being too small with NES. However I really want to do a NES Rom, I definitely think given enough assets for sprites it can be done because it's really just two sprites on a background every time, it's just the number of animations that is causing the problem.

However if you take YYCHR and pull some games there and take a look at the page upon page of graphics that show up with certain ROMs I really think that it could be done. I would just need a means to point to them all.
 

Kasumi

New member
timkilgore: You may find this topic interesting: http://nesmakers.com/viewtopic.php?f=20&t=213&p=1203#p1164
A quick overview: Not all NES games had the same limitations. Hardware inside the cartridge could extend the NES capabilities in different ways. The set of limitations a specific game has is related to its cartridge hardware or "mapper". Just because another NES/Famicom game did something does not mean it's compatible with NES Maker's mapper. (For example, compare this version of the Zelda Title Theme which used NES audio extensions: https://www.youtube.com/watch?v=KQ7NVh1_QOM to the "regular" one: https://youtu.be/uyMKWJ5e1kg )

The NES gets 256 sprite tiles in memory at once. Assuming all the animation frames you want don't fit in 256 tiles, NES Maker's mapper makes it somewhat difficult to "stream" more tiles into memory. Assuming all your animation frames DO fit in 256 8x8 tiles, the "NES practical" limit for how much you can put on screen is really RAM. (And... how much you care about what the player is able to see. :lol: )

How Nekketsu Kakutou Densetsu juggled its four players around in memory isn't really an option available to NES Maker's mapper. I understand you don't care about if your ROM won't work on a NES Maker cartridge, but supporting multiple cartridge types would actually be difficult. (They are very different. It's not just like having music extensions vs not having them. Choosing a mapper with one kind of music extension might totally change how you have to access data that has nothing to do with music. Supporting the mapper most Nekketsu games use would make a large portion of how NES Maker loads graphics not work. Similarly you can't make up new extensions like having an endless amount of RAM. Or... you could, but no emulators would support them so you couldn't test them on anything.)

NES Maker appears to allocate RAM for 16 objects in the underlying code. 16 is quite a few! With 16 things that are 16x16, you've already hit 64 8x8 sprites. But making sure your all your animation fits in 256 tiles is an exercise in extreme planning.

Bucket Mouse: I would bet Smash TV can get at least 20 enemies on screen. Each enemy is a single 8x16 sprite. An old game I made got around 40 things on screen at once before it started to slow down:
OhQfQjg.gif

For a game like Smash TV (hoards of very small enemies that don't need to collide with each other), the "NES practical" limit is 64 enemies. Even then nothing stops you from having more, it's just at that point the player is guaranteed not to be able to see them all every frame. You're limited only by RAM.
 

RadJunk

Administrator
Staff member
Kasumi is right - by default, NESmaker treats all objects *the same* (they all have the same variables that make them up...positioning, type, hit points, width, height, etc). Now, it would be totally possible to rewrite the engine to redistribute the bytes if one needed less info...for instance, if none of your game objects required hit points...or if you wanted to make different classes of object, some of which used more bytes than others, etc. The problem, then, is you'd have to write new drawing routines. New movement routines. New routines that accessed that data.

Keeping it uniform was a way to make it versatile and customizable. Most of the limits of NESmaker exist for that reason. Sacrifice *DEEP, PARTICULAR* functionality for *DIVERSE* functionality. Anyone who is deeply devoted to something dramatically different would probably be best served by learning to create their own engine from scratch.
 

RadJunk

Administrator
Staff member
Also to note, to declare, say, what object is drawn to the screen, it needs an index reference. Essentially, objects 0-15 are game objects (pulled from game object tileset) where objects 16-xx are monsters. They pull their data from tables. So for instance, when monster 27 is loaded, it pulls the width located at MonsterWidths table at position 27 and fills the object slot with that value.

Since these are all 8-bit tables, it would require a max number of objects to be 256 (240 monsters). I believe it is natively set up for just 64 (48 of which are monsters), but it wouldn't require much stretching logic to push it to 256...the problem is for ALL the tables that each object needs, you'd have to rearrange memory and put data across banks, because for that many objects, ALL the tables would likely not fit in a bank (don't know for sure, but I'm inclined to say no). This would completely alter the loading routines, too, having to jump around to various banks depending on which variable it was filling.

Again, once you're into that territory, you're completely rewriting the foundation of the underlying engine...if you know how to do that, and it's what you want to do, you're probably best creating your own engine for your specific needs :)

There are SOME tricks you could employ though, if mechanics are the the thing you want more of. For instance, you could have a global variable called "attackLevel", and have certain rooms load different attackLevel variables...then in AI routines, you could read the attackLevel and do different things based on the attack level. That's just off the top of my head. Or even easier, it could just read the screen number...if you've reached a certain screen, it behaves like this, otherwise it behaves like that sort of thing. That sort of thing would be MUCH easier and give the feeling of diversity.
 

timkilgore

New member
Sorry if it's redundant I just want to make sure I'm understanding what you're saying so I don't ask something similar as I'm working going forward. I've read alot about NES programming but I haven't done any really, my background is in SAS/SQL and VB programming. Basically I know enough about the subject to grossly misinterpret things.

I understand the mappers are vastly different, like the UNROM mapper used in Pro Wrestling is totally different than the MMC1 mapper used in Nekketsu Kakutou Densetsu. My understanding when it came to graphics is that bank switching was pointing the graphics to a different area.

For example: The Player's idle state, walking state and running state fit into the Player Object. However the Punch and Kick animations are in one of the Monster Objects. I was assuming that when a button is pressed say the B button, there is a variable that is changed to "punching" which then can access the animations in the Monster Objects but drops the Player Object from being able to be accessed until the animation is completed.

You're saying that basically all the tiles 256 of them have to be accessed at all times to be written to the screen, so the idea of having just an endless number of sections for animations isn't doable based on the way the Mapper 30 works.

Am I understanding correctly?
 

RadJunk

Administrator
Staff member
I have absolutely no idea what you mean here...very confused. I can only try to break it down again, as I did above. Note, this is how OUR engine does it, and is generally a common method, though certainly not the only way to do things.

Each object has a bunch of definitions in ROM memory. There are tables for all the things an object needs to know to function. For instance, there is a table for object widths, and there is a table for object heights, and there is a table for object hit points, etc etc etc. Each is a big table array.

When you load an object, you create it with its index. Player might be object type #0, projectile might be object type #7, squid monster might be object type #42.

If the player is loaded, it looks at the value 0 in each array table.
If projectile is loaded, it looks at the value 7 in each array table.
If squid monster is loaded, it looks at the value 42 in each array table.

Each object also has tables of animation data. Each animation can have unique setups for all 8 directions (URLD and diagonals). Each object also has tables of action data (8 actions per object), which can have various animations attached to each action.

When each object changes to any of the states or animations is completely up to user. You might set up action 1 as the "player punching" action, and you might set it up so action 1 is linked to the "player punching" animation for the player. Then you might make it so pressing the b-button puts the player object into action 1 (which will put him into "punch" action, which shows punch animation, because that's the way YOU set it up).

That's how animations work in NESmaker.

As far as graphics - for all intents and purposes, the NES loads a page of 256 8x8 pixel data for sprites at a time. When the screen is turned off, you could load different sets of graphics (most games handle this between screens). This is how the NES hardware works for all mappers.

Is this helping to answer the question?
 

Kasumi

New member
Here's my own reexplanation: https://i.imgur.com/D1HkJPz.gif
On the left side are the tiles in NES memory. On the left of the left, are the 256 background tiles available. On the right of the left are the 256 sprite tiles available.

Notice that as the character moves, the tiles change out to whichever ones are needed to display them. This single character uses one slot or "bank" of 64 tiles. You can swap out a full 64 tiles at once. 256/64=4, so there are four banks for sprites with this setup. Nekketsu Kakutou Densetsu does this exact thing. Each of its four players uses one bank. This mapper can put any of 256 unique sets of 64 tiles in any of those four banks at any time. This is what allows four characters that seem to ignore the tile limit.

NES Maker's Mapper (Mapper 30) can swap out tiles, but not in 64 tile sections. It must swap all 512 tiles at once. (Both the background tiles AND the sprite tiles.) The mapper can use any of 4 sets of 512 tiles. Say Player 1 and Player 2's current frame of animation can use the current set of 256 sprite tiles in memory. Then Player 1 needs to display a new frame of animation that requires tiles not currently in memory. All 512 tiles have to be swapped out to display it. This would make player 2's current frame of animation be displayed as garbage tiles unless it were duplicated in the same place in the other set. Since you only get four unique sets you can swap to, and because you have to swap everything at once, the need to duplicate the parts that don't change eats a lot of the benefits of swapping for this kind of character animation.

If all the animations for all the players involved in the current fight fit in 256 tiles, no swapping is needed and it'll work either way.

As Joe said, you can update a bunch while the game is not drawing anything (to allow different characters to be put into memory before the fight has started). You can also change tiles once the fight has started (while gameplay is happening), but not in a way that's really fast enough for animation like the above across four players.

Edit: For what it's worth, I've been talking more about tiles because that's the thing that will eventually stop you. The NES itself doesn't you as far as how many animations or states, or objects or whatever.

More edits: But maybe ignore all my posts! I think of Nekketsu stuff as a tile/animation problem more than an object/state problem. If you want that sort of gameplay, but without such large characters/detailed animation I don't really see why you couldn't.
 

timkilgore

New member
I just want to thank you both for explaining things so thoroughly. I have to read through these responses to make sure i understand everything. I appreciate your help and time :)
 

RadJunk

Administrator
Staff member
You're welcome. I may be making this tool, but Kasumi is still the Jedi Master here, btw . :)
 

timkilgore

New member
You're not kidding, holy cow Kasumi is great.

I'm pretty sure I understand it now.

In the NES Maker tool where you're creating each screen, all graphics are loaded when you go to each screen. For example

Screen 1: Player Graphics, Monster 1 Graphics, Monster 2 Graphics and Background Graphics

Screen 2: Player Graphics, Monster 2 Graphics, Monster 3 Graphics and Background Graphics

These are loaded as you enter the room.

The game I was discussing Nekketsu Kakutou Densetsu has a routine in it that different player graphics can be loaded while you're on the screen. For Example:

Screen 1: Player Standing Graphics, Enemy Standing Graphics, Background Graphics

When player hits button B the following graphics are loaded:
Player Punch Graphics, Enemy Hit Graphics, Background Graphics.

NES Maker doesn't work like that though so I wouldn't be able to do something like this with NES Maker. I would have to figure out a way to get all the Player Animations into what is loaded into each screen upon entering it. If I wanted to do something like Nekketsu Kakutou Densetsu it could totally be done but I'm going to have to write it on my own.

Again thank you so much! NES is hard LOL
 

RadJunk

Administrator
Staff member
It's that you "can't", per se. But there are limits to what CAN be done. NES can only load so many graphics during the NMI. This would absolutely not be enough to handle this. Though you COULD load graphics into CHR RAM banks, which might be an option...it's just that...there might not be a single solution to do it, but for one thing, it certainly is not how NESmaker is intended to work. So it might even be EASIER to write an engine ground up than trying to make NESmaker's underlying code do this thing. :)
 

timkilgore

New member
Ok understood. Nothing worth having is easy, well I mean minus that emo girl from the bar a few years ago. That was totally worth having.
 
Top Bottom