Every good programming technique

[psycopathicteen]

There's a lot of good programming advice scattered across this board, so I think I'll try to make a list of every programming technique here. If there are any contradictions in this list, that means it is something that should be discussed.

Here's some techniques that I personally recommend doing:
-Set up DMA channels for OAM and tile scrolling before vblank, so all that's left to do in vblank is writing to $420b.
-Place sprites offscreen by doing a DMA fill with the value $e0 to the remainder of OAM during vblank.
-Region based level object spawning

Here's some techniques that should be thought about before doing:
-Using linked lists on objects to avoid searching through object slots


Some techniques that sound good on paper, but I haven't tried yet:
-Using 10.6, 11.5 or 12.4 fixed point coordinates

[tepples]

12.4 is also a fine choice so long as your levels aren't more than 16 screens wide. It might speed up background collisions if you're using 16x16 pixel metatiles. But it might be a little slower to draw because of all the shifting to translate to a pixel value, and object widths suddenly become 2-byte values (and thus larger in the size lookup table).

[psycopathicteen]

The only question is having several fireballs shot in a circle at once, might not look like a circle.

[Stef]

I'm using 10.6 fixed point (signed) variable in SGDK, it's really convenient as you can manipulate it directly through 16 bits registers and it provides a good compromize between float part accuracy and integer part [-512..511]
Of course that is not always enough but for me it's definitely a good choice.

[psycopathicteen]

Today I've been setting up a link list object system, and it's a lot more confusing than I thought it would be. I think I should only use a linked list for open slots, doing it for active slots I find unnecessary.

[rainwarrior]

For open slots, instead of a linked list, maybe just don't start at 0 every time?

Like, just store the last used slot, and start your next search there (and loop around). That puts the newest objects at the end of your search, and the oldest objects at the beginning, so you're likely to hit an open slot on the first test. Worst case tests them all, but average case you're probably getting an open slot the first time almost every time.

[tokumaru]

I do it for active slots so I can group objects. Update order is important for some object interactions (carrying, pushing, etc.) So I process object groups in the same order every time, catering to these dependencies. Another reason to group objects is to minimize collision tests, so each object only collides against groups of objects it's supposed to interact with. You can have a group fit enemies, another for bullets, and so on.

For composite objects I have a "link" field, that each part uses to connect to the next part. For a spider I'd probably have pointers (using the general purpose bytes) to all legs in the main object, and each leg section would link to the next.

For open slots, instead of a linked list, maybe just don't start at 0 every time?

Why? Linked lists are so cheap to maintain, you can remove or insert an item with like, 3 instructions.

[psycopathicteen]

Why? Linked lists are so cheap to maintain, you can remove or insert an item with like, 3 instructions

Really? In order to clear an object I had to change the previous slot's "next" value, and the next slot's "previous" value, and change the "next" value to the "first open slot" value, and the "first open slot" value with the address of the slot being cleared.

Did I completely miss the point of linked lists?

[rainwarrior]

Why? Linked lists are so cheap to maintain, you can remove or insert an item with like, 3 instructions.

I don't see the point in debating it outside the context of a specific implementation?

I just wanted to offer another technique for "find an open slot to use" besides a linked list. I've found this one useful many times.

[tokumaru]

Did I completely miss the point of linked lists?

Ah, so you're using doubly-linked lists... I use singly-linked lists. Any reason in particular why you need to scan the lists in both directions?

[psycopathicteen]

Did I completely miss the point of linked lists?

Ah, so you're using doubly-linked lists... I use singly-linked lists. Any reason in particular why you need to scan the lists in both directions?

So the previous object can be linked up to the next object when clearing the current object.

[tokumaru]

So the previous object can be linked up to the next object when clearing the current object.

I felt the need to reference the previous object in a few cases too, but instead of complicating the linking system because of this one reason, I simply had each object save its index in a variable, that I can check when processing the next object.

[psycopathicteen]

So when you're removing a multijointed boss, you'll replace the previous object's "next slot" variable with the "next slot" variable of it's last child object?, and also link the last child object to the beginning of the open list.

[tokumaru]

I don't know the exact structure you're using for composite objects, but assuming you do process them in the order specified by the list, simply saving each object's index in a variable (a single global variable, overwritten by each object) as they're processed will allow every object to know which the one immediately before it is.

[psycopathicteen]

I tried your suggestion of using a shared "previous" variable, but I ran into a problem. When there's two consecutive objects dying at once, the second object links the already dead first object to the next object, instead of linking the last active object to the next object.

I don't know what your doing, but I'm going to have the object handler detect blank slots, and do the link-list rearranging inside the object handler routine.