It is currently Sun Nov 19, 2017 5:04 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 7 posts ] 
Author Message
PostPosted: Wed Nov 06, 2013 12:06 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2359
Anybody know of a good way to organize objects to allow them to link to eachother?


Top
 Profile  
 
PostPosted: Wed Nov 06, 2013 12:17 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10112
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Wed Nov 06, 2013 8:50 pm 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1035
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)

_________________
https://kasumi.itch.io/indivisible


Top
 Profile  
 
PostPosted: Wed May 28, 2014 9:12 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2359
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.


Top
 Profile  
 
PostPosted: Thu May 29, 2014 1:27 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7266
Location: Chexbres, VD, Switzerland
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.


Top
 Profile  
 
PostPosted: Thu May 29, 2014 3:39 am 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2359
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.


Top
 Profile  
 
PostPosted: Sat Jun 21, 2014 7:18 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2359
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 7 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 6 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group