Celius wrote:
I would definitely stick with having a display engine that somehow displays what's going on inside the game world without the code in the game world being concerned with it. It shouldn't be the logic engine's responsibility to worry about what's displayed; the display engine should be the only code worried about that. It just makes cleaner, more logical, and more reliable code that is easier to modify should you decide to make changes.
Are you familiar with the
Model-View-Controller design pattern? If you're not, take a look at it. This is a simple image that describes it:
Look at how the controller can, well, control both the view and the model, and how the view watches the model, but the model is completely unaware of what surrounds it. Ideally, that's how games should be. The controller is a sort of manager, which handles inputs and things like that and modifies the view and the model as necessary. The view watches the model in order to draw a representation (or representations) of it, while the simulation keeps going indefinitely in the model. This allows for some cool things, like having different cameras watching different parts of a level and things like that.
Quote:
Not only that, you actually have to wait for the sprite #0 hit, wasting possibly dozens of scanlines in a loop.
That's not correct. Using sprite 0 for detecting game object collisions is very different from using it for raster effects. For raster effects, you know for sure that
the hit will happen, and knowing
exactly when it happens is the crucial thing, because that's when you have to modify some PPU register for the effect. But if you are trying to figure out if the player is touching the ground or not, there may be a possibility that
the flag doesn't get set (when the player is jumping, for example), so if you wait for it in a loop your program will lock up when the character jumps. Also,
it doesn't matter when in the frame the hit happened, you just want to know if it happened or not, so reading the flag once during VBlank will do the trick.
Still not a good idea by any means, but I felt like explaining this because it's not the first time that someone in this thread said that it would be necessary to wait for the sprite hit like it happens with raster effects.
Anyway, using sprite 0 to test collisions is a bad idea for several reasons: The background would have to be blank, because everything that wasn't would be solid; The player would have to be 1 pixel into the floor, because you wouldn't be able to predict the collision, you'd have to let it happen before detecting it; When going back to the ground after a jump the player would sink several pixels into the floor if moving at more than 1 pixel per frame before being ejected back; Since you would only read the flag during VBlank, you'd only have the previous frame's data; Since there's only 1 sprite 0 you could only do this for 1 character (what about the enemies?); There are probably dozens of other reasons I can't think of right now.
Quote:
Don't get me wrong, sprite #0 can be a life saver, and bazillions of NES games wouldn't be the same without it. I can't tell you how many games use it for something like displaying a status bar and having the rest of the screen scroll.
I don't know what the designers of the PPU had smoked when they came up with this feature. It's so limited! If at least it generated an IRQ or something... Or if it at least always set the flag when found to be in range... Seriously, doesn't every single game that uses sprite 0 hits make sure a hit will happen? Not a single game I know of is interested in knowing
whether a hit happened, they are aways interested in
when it happened, so Nintendo could very well have skipped the whole overlapping solid pixels bullshit.
I tend to disregard sprite 0 hits, much like I do with MMC3 IRQs. I know it may be a little extreme, but I can always think of several instances where those features would fail in my programs, so I'd rather design them without even considering those.