ThePerfectK wrote:Chilly Willy wrote:Something to think about - rather than try to mimic mid-line color changes, draw everything except the water, then draw the water with alpha. It would actually look more like water that way as well as avoiding palette tricks.
Hmm - that would be on a per-layer basis, of course. That way if the water is in the background, the foreground would be in front of the water.
Well that is what I plan to fall back on if nothing else works, but thats my worst case scenario. The water in sonic games looks really distinctive, and an alpha blended layer looks nothing like the effect.
True, if you're trying to get the exact "Sonic" look to water, it's not quite the same. It is the easiest way to handle it, though.
Beaides I sort of like bogglez idea and want to try my hand at it. Funnily enough, I sort of feel like all this was easier when I wrote the entire renderer from scratch in software on my PC, lol. That gave me very fine control over every single pixel draw. But part of the fun of taking up new hardware is thinking outside the box. I'll admit that I'm having loads of fun right now.
That's good. Nothing keeps a dev on a project like enjoying the work they're doing.
One problem with your suggestion, though - in order to blend all my sprites with a water alpha layer, that would mean I'd also have to draw all my sprites as translucent polygons, right?
You would need to at least use the ARGB1555 mode (for the pixels or the palette entries if paletted sprites) to specify on/off for the pixels making the sprite. Over reasonable size and numbers of these type of objects, I've not noticed any performance problems on the DC.
Looking at other topics, there is a debate about how much slower drawing translucent polygons is than drawing opaque or punch-through polygons, correct? Would I be getting a substantial performance hit by drawing water this way? If I did want to draw water as an alpha layer, I could cut it into smaller tiles and give the water a pattern to blend in, rather than just color (so I could, like, draw zig-zagging waves in the water). In that case, I'd be drawing more polygons than if I just did one giant polygon and stretch it over the field - is that slower as well? To give a rough estimate of the number of polygons I'd like to draw - I'd say, at most, Sonic has maybe 100 sprites on screen at once, counting forground objects and the background layers as sprites as well. That would be about 100 polygons drawn per frame.
I'm sort of paranoid about performance and want to do as much as possible to keep things running as fast as possible, haha. I'm using fmath, for example, because it's apparently optimized with sh inline assembly?
I doubt you'll see any performance issues on a simple 2D game like this. At least on the rendering end of things. You'll want to watch the entity-ai side of things - remember the ring slowdown on hits as an example of how not to do that.
Fast math is fast because it ignores things like checking arguments for NaNs, signed zeroes, and other such ieee nonsense. It has nothing to do with assembly, per se. When compiling, during the optimization phase, nothing beats generating the assembly source to see what the compiler is actually doing. Just add "-S" to the compiler options to get the assembly for that file.