SMB 1 sprites

[Arne]

Well, that took a bit longer than expected. I used an RLE optimization. It could use some more work, but it already brings down the calculations to well under a millisec for my 700*180 map, and that's only if the water is disrupted. On top of this, I actually make 10 simulations per frame, not once per game tick, like in say, Boulder Dash. This way my water will flow nicely and quickly though corridors and such. Other techniques have the disadvantage of teleporting the water so you can't see how it flowed, or move the water too slow, making it seem like sand or lava.

Another thing that I do is scattering the water. Some algorithms will produce nasty vertical shafts if there's a leak. This happens when falling down is always prioritized. It will cause an 'edge of the world' wall of water. I occasionally jitter the edges a little so the water forms nice splashy piles.


RLE bottom-top optimization plotted for clarity/debugging. It took some head scratching to get it to work. Static water cells are removed from the simulation until disturbed (or their neighbors are).

Idea mentioned in earlier post. This will be a visual effect and nothing that's part of the water simulation. I can look at neighbors and perhaps figure out a suitable water tile. I'm worried that since the water jitters around a lot, it will look kind of crappy. Also, it will probably be hard to figure out if the waves should be toned up or down. I might be able to build a table, like the HQ3x algorithm does.


Edit: I'm retarded! My millisec counter code was wrong and when I corrected it the MS count jumped up 20x! The sim still runs under a 18ms (which is a frame), so I didn't see this. Luckily I also discovered that I was compiling in debug mode, which has a bunch of bound checks and so for arrays which are VERY slow. When I made a normal build, the simulation was pretty fast again, but not fast enough. Then I realized that... Well, I'm dealing with large water masses here. A pixel (which represents a tile) is probably a cubic meters of water. Running the simulation 10 times per frame just looks good when looking at the entire map from a distance, but Zoomed in, a tile could potentially travel 10px per frame this way. So I just run the sim one time per frame now, and I'm back to 0.5ms or so. This way waves will jitter around less too.

[Arne]

Yay, so much progress today.

Flowing water and BG tones in the game. I had to slow down the water even more, from 10x to 1x to 1/8th. Probably doesn't use the CPU notably at all now.

The BG tones are not some simple transparency. Instead I can set light and shade color for each sky type. Water is a bit square still. You can see the homeless water surface blocks.

[ptoing]

Oh, one thing I forgot to mention.

When playing the demo I noticed that you can not run through a single block gap. That just feels wrong as far as Mario goes to me. Small Mario is 1 block high and Super Mario 2 blocks, which works very well in the original games. Something to consider.

[Arne]

You mean that you can't glide under a block? Or run over single blocks placed like a [...] ? Both these issues are mentioned in the readme.

I'm actually doing big Mario first because it's more difficult. Since he's taller than a block, I have to check more side collision spots.
I had to get ducking in there too, but right now it's only an animation. Not sure if small Mario can duck.

It will take some work to get the collision spot system to comply with ducking. For example, if a block is placed on Marios head, he should probably auto duck
and not be able to stand up. When ducked, he must be able to move so he can't slide into tunnels and get stuck. The original game solved this with a quirk in the collision engine
I guess. I might have to implement crawling.

Since all actors will eventually share the collision engine, I'll have to make sure that it runs fast. Right now I'm leaning towards making several hard coded versions of it which characters of different size and ability can use. A dynamic engine with lots of variables will probably be too slow if I'm to simulate all enemies persistently. I'm not sure if I'll be able to do that anyways with my current system. I might have to put enemies far away to sleep.



I found this image. It describes the anti tunneling feature. It enables me to use high velocities without risking cutting though corners or even entire blocks. It's however slower than many other collision systems. I think big Mario now checks the corners pointing in the direction of his velocity, so 5 out of 6 points. I use a fixed point system with a 16bit 'bit shift' (64k).

Today I'll try to implement a water surface smoothing algorithm I think. I tried a simple one yesterday but it made 50% noise surfaces too wavy and jittery. I'm thinking that I can possibly find lateral neigbours with a wider search, then average those a bit... It looked really cute when I made a little sliding water face-hill though.

[ptoing]

I meant running underneath a block. I have not read the whole doc. 

[Arne]

AHA!

I think the core of my problem is that my water quanta are too large. I run my sim every 8th frame now to prevent if from being too fast and jittery. At the same time I have the problem of water chunks being too large and boolean.

What if each cell had like a water mass of 0-3? Then the simulation could run more often (affordable), but leak smaller packages of water.



This would mean that I'd have to draw an absolutely enormous water tile table though. Too large with 4...5, 9 whatever cells and 4 water volumes. There might be a way to generate blobs on the fly. That, or I can keep all flying water chunks spherical (disregarding neighbor situations), and just do a more detailed test for obvious lateral water surfaces, if possible. Whenever I try a solution there's always some quirk I didn't think of.

I might do something else now though. Water is functionally there, it just doesn't look too hot.

I'm using BlitzMax.

[Arne]

Here's an idea that pooped up. Because water evens out, this kind of solution might only look square for a little while. SMB isn't too bothered by square either. Later the difference in height (1/16th tile) will be so small that the surface will looked smoothed out.



Also, this way I can do rain with small droplets.

Edit: It worked. Now in the game!



Some jaggies but they disappear very quickly as the water evens out. I also animate the surface with gliding waves (4 frames).

[Arne]

New build (0.07a). Might be a little slow up in the night sky area. I haven't optimized drawing yet. Water... kind of works. but I really need a pressure/push system to prevent it from piling up. Averaging only helps a little. Alternatively I could try some method of rushing water laterally until it's no longer downhill.

Edit: And some pixel  stuff from yesterday. I don't think I'll do much crossover stuff, as it hurts the solidity of the universe. Failed to do thrones/bases. I'll use my chozoroom-bot instead.

[The KKM]

I just wanna say that while I've been loving your work here, the fact you made Megaman bulkier than Samus in her suit confuses me.

[Conzeit]

I think..water should always run unless it's leveled.
I flood randomly and get a pile of water on one side but none on the other...what's up with that?
this is exactly what shouldnt happen,the water to the right of the actor should be at the same level as the water to the left. Theoretically the actor should have some air over his head, but if you have to chose between that and evening the water at the two sides, but if you have to chose between that and evening out the water eliminate the air pocket...it's just incredibly unintuitive now. (I'm sure I've seen a blog discussing it somewhere...maybe it was wolfire's?)

I dont think this souldnt be drawn with tiles, I mean with something like Pixeljunk shooter out there I see little point to doing this if you cant do it at their level.  Are you posting this at any straight coder board? I dont think we have much of use to say here, if you do maybe you can recruit someone who can code fluids.