I'm working on a Scorched Earth clone using xLIBC. Screenies so far (the square pixels are 'tanks'):






Note that this code is mostly untouched from the state it was in last night at 11:00 pm (I've been getting tired as early as 9 lately for some reason, so that was about the point where I started losing the ability to form coherent sentences), and as such it's preeeetty badly written. I'm working on optimizing it, but until that's done I've commented it so you guys can read it and hopefully (please?) help me out. Tank generation is the main thing that needs fixing; while I'm mostly happy with the results it produces, it takes 5-10 seconds on my CSE (depending on terrain) to generate positions, which is way too long for my liking-- I thought about calculating all values before the program starts, but that wouldn't work very well considering that terrain values (and thus, indirectly, tank positions) depend on user input at the beginning. So really, my only option here is to find a way to optimize it.

Anyway, enough rambling Here's the code, fully commented:

Code:

edits: clarified code some more | added screenies |

Some updates--

-I originally had it only calculate up to 80 (and draw 2px rectangles) to save speed; however, I've found that it's actually not that much slower to calculate all the way to the full screen width, being 160. The only thing it wastes is RAM, which hopefully shouldn't be too much of an issue as I'll delete the offending lists once map drawing/tank placement is done. Later today I'll update the OP with the new code.

-Tank placement is still too slow, and needs to be either fixed or scrapped entirely. I haven't looked at how Scarth does it yet, but it looks like it just picks a random place on the map- which I was trying to avoid because sometimes the map goes offscreen (so if a tank lands on an offscreen part it'll be impossible for it to move; my current code's purpose is to find the lowest points on the map for the tanks to be), but it looks like I'll have to do it anyway. Scarth also finds a way to stop the map from going offscreen, so I'll take a look at that.

Why do you need to store it at all? In Scarth, I use the fact that I can pixel-test the screen to determine where the ground is. GetPixelA and GetPixelB in xLIBC do the same thing.

Picks a random spot, then pxl-Test(s downwards until it finds the ground.

One of the map invariants Scarth uses is that at least the bottom pixel of the screen must be colored at all times. Algorithmically-speaking, this is pretty easy. Scarth's terrain-rendering algorithm has three values: the Y position, the Y velocity, and the Y acceleration, which all do what they sound like. The acceleration is changed randomly based on which terrain type has been selected, and I believe the position, velocity, and acceleration are all truncated. That is, if the position is less than 164, it is repeatedly returned to 164 (and is capped on the lower end around 20 or 30, probably, to leave room for a tank on top). If the velocity is larger than Vmax or smaller than -Vmax, it is truncated to that value. I believe the acceleration is also truncated, and perhaps when the position is at the max or min Y value, it also resets the velocity and acceleration to 0.

I'm already using getPixel for tank gravity (it's very rudimentary so I'm not going to share anything just yet).
I actually thought that I'd explained why I iterate through the whole terrain list, but looking through the thread I guess I forgot to save that edit or something, so it's basically this bit of code from the OP:

Code:

My reasoning for doing this is that sometimes the terrain generation [being cumSum(randInt(-X,X,160] goes off the top of the screen, so this code ensures that low-down areas get tanks first. I just realized, though (see last paragraph) that I could probably just scrap this altogether if I do the calculations inside the For() loop directly.


That's what I figured. See above for why I'm doing it differently.



Wow, that's way more complicated than mine! I just do cumSum(randInt(-X,X,160)) to generate terrain values, although this has the disadvantage of taking RAM and time to compute. If I end up deciding to get rid of the whole valley-finder-algorithm, which is very likely at this point, I'll be able to do these calculations directly inside the For() loop to both save space and allow bounds checking.

Edit: sister says that this is calculus/derivatives, which piqued my interest a lot-- if you don't mind, could you do a quick rundown on why/how it works and why it's a better option (if it is) than what I did? I'm nowhere near calculus in math yet.