This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

organizing memory for multijointed bosses

organizing memory for multijointed bosses
by on (#120334)
Anybody know of a good way to organize objects to allow them to link to eachother?
Re: organizing memory for multijointed bosses
by on (#120335)
My objects always have some general purpose bytes they can use as they see fit, so I would just use part of that memory to store the indices of the slots that contain the child objects. The parent object would be responsible for calling it's children's AI routines (they wouldn't be processed by the normal loop that processes objects), in order to have full control over the order in which sprites are rendered.

If a boss has too many individual parts (like a neck composed of several spheres), I'd probably have the entire neck be a single object, and the general purpose bytes would hold coordinates for several spheres.
Re: organizing memory for multijointed bosses
by on (#120357)
I have a grab system in a place in my game. Each object has a byte to specify a holder object's index, and a byte to specify the index of the object it's holding. If the object is holding itself (the index in it's "holding" byte is its own index), it's not carrying anything. If the object is held by itself, it's not being carried. Each object also has two bytes that specify its "hotspot", or a set of relative coordinates. An object that is held has its position set to its holder's hotspot, minus half the held object's height/width. (This is done after all positions in the game are final except for movement because of being carried, so there's (almost) never any visual drag. But there would be visual drag if an object needed to carry an object that was also carrying something, and the object's respective indexes weren't in order. It's very possible to combat this with extra logic, or allow objects to hold multiple objects.)

For bosses, I could almost certainly just ensure the indexes were in order if I ever needed a part connected to a part connected to a part. I'd probably just try to keep the boss as one actual object, though, and just do all the logic for the individual parts within its main routine. In the absolute worst case I needed a bunch of positions stored in RAM, I'd create another invisible object solely to use some of its RAM. (My main character actually uses one of his bullet objects to store extra info about himself)
Re: organizing memory for multijointed bosses
by on (#129320)
I think I'll special case this, and have a designated area of memory for bosses. I don't really like the idea of borrowing slots.

I wouldn't be surprised Treasure's own engine was limited to just 1 boss at a time.
Re: organizing memory for multijointed bosses
by on (#129330)
It's fun because I am also in the hassle of creating bosses and their AI and this is a very hard thing to do. Although at least designing bosses is more interesting than designing random enemies, which is hard AND not very interesting.

What I do is that I cheat and rely on different boss parts to be at exact specific slots, for example my bosses AI rely on the main boss being in slot #0, and this allows me to free both X and Y for other usage. I haven't done multi-part bosses yet but I plan to. Normal enemy AI routines normally always have X=slot number of enemy, and if it has to be overwritten it should be restored back. In bosses AI I'd have to do it so often it doesn't make the cut since I KNOW it'll be in slot #0 there's no way to waste bytes and time for all that saving/restoring of a de-facto constant value.
Re: organizing memory for multijointed bosses
by on (#129335)
Nice idea, and you can use the other slots specifically for specific parts.

For an SNES game, I'd use the direct page for normal enemies, but use X-index for boss parts since it is has the benefit of incrementing and decrementing, and long addressing.

The way the data format will work is to have a structure table that has all the information about how the boss is structured, followed by key frame parameters and the duration of the "sweep time" between key frames.
Re: organizing memory for multijointed bosses
by on (#130114)
If I only need to save the angle of the sprites I can probably fit it all within a single slot. The only issue is my complicated animation engine requiring words for vram and dma management.