Reading the last few posts above could possibly help find the answer to that question. Unless you're asking in general, in which case you should read the original post on the 1st page.

Yeah, that'd be good. Because if you're surrounded by like 5 enemies at once, the last thing you want is falling down or knock-back.

knock-back

EDIT: Ah, I gotcha now. You're replying to billy's post.

so.. knock back scenario question decided?

I guess so. For actual gameplay, I'm still working, and that's far off. I'll post here when there's another build.

Build 004

-player entity created (defined as layer of depth '5555')
-internal work on physics
-player can be moved with arrows (hspeed defined by pressing the number keys)

Another big question: What should our max framerate be? I have a cap set up, but for some reason if it goes too low, a runtime error will come up. I'm estimating that it should be at least 60. The way I've done it will make it so that when a computer lags, frames will be skipped rather than slowed down. At least this way, the game's actual speed won't slow down.

next build: jumping.
how high should the player jump? how far? how long?
To achieve: is it possible to have something on the bottom that is adjustable? like 1-10? if you could have three of those, we can adjust the jump.

I need to implement physics first. Discuss the matters at hand before going into things like jumping, please. Also let me know what preference you have to hspeed and player size.

sorry. i mean for later, when physics is done.
i liked speed 7 and 8. i hate it when your character moves too slow. I liked the 2nd smallest size.

Hmm, for some reason this game runs REALLY slow on my laptop. Like only a few fps. Anybody else have the same issue? It is kind of a low-end PC, but SDL applications generally run with fairly reasonable speeds. Mind if I take a look at the code, Red, and see if I can figure out what's going on?

Did you set it to a low speed? Try pressing different number keys. If you still have problems, talk to me on Skype for the code.

In case someone was wondering, the number you press is setting the speed to X pixels per frame. This build was before I set the frame cap, so I can't give you an estimate on how fast it would be yet. (the speed varies on the amount of memory your cpu will allocate to the program; computers with cpus that aren't being used up by other processes will play it faster than others) I'll likely update the build once I'm done with gravity. Maybe a few days.

I think the framerate should be, as you said, around 60. It should be changeable, even though it automatically sets it lower when needed.

I think I'm getting the same as MOM. The cursor is lagging a slightly, not greatly, but noticeably. That being said, the player movement is pretty good.

Nope, MOM pointed something out to me yesterday on Steam. My code has a delay loop, meaning it tries to draw 10000 images each frame (depth). This causes it to have slight delay whenever anything else happens, so moving the mouse is slow, moving the player is slow, and moving them at the same time will cause lag.

I'll fix this in the next build.

Ah, OK, good to know.

Yep. I took it out as a test, and it's a lot faster. But let me know if there's similar problems down the road. Sometimes stuff like this is hard to track down. Other than that, good work. I can see you're setting stuff up pretty nicely, and hopefully it'll be easy to code off what you have so far without coding yourself into a corner. Good show, old chum.

Why thank you! Actually, I am clueless about STL, so could you give me your modified version?

Hmm, I didn't really IMPLEMENT STL per se, just took out all the drawing code and it was faster. I'll see what I can do, though. I'll be busy for a couple days, but I'll try to tear myself away from my own programming when I can.

Basically, you want a

list<SDL_Surface*> queue;

for(list<SDL_Surface*>::iterator i = queue.begin(); i != queue.end(); i++)
{
  SDL_BlitSurface(screen, dstrect, *i, srcrect);
}

Ah okay. The tutorials I found are just awkwardly written.

The arrays are: 10000 surfaces (the images), 10000 rects (the locations on-screen), 10000 rects (the images' rectangles). The xml-parsing function looks for <image> elements and changes the attributes for the surface[depth], rect[depth], etc.

If you have STL, isn't "queue" a keyword?

It's actually "image_queue", "queue_imagerect", and "queue_screenrect".

I was referring to MOM4Evr's code.

Oh, that was just an example. Because I have 3 queues.

Ah. Okay. Just checking. MinGW's error message is really obscure for me (something like "No match found for queue; matches are queue&lb;T&gb;string/int/char..."), and have messed up lots of my programs.

Just by using "queue" as a name?

By the way, you said something about having problems with SDL. Maybe post your code?

@AP: I think it's ok to name an array "queue". At least it worked ok for me. "queue" isn't a keyword or anything, just a class name like anything else, so you'll only run into issues if you #include <queue> and using namespace std;. At least that's to the best of my knowledge.

@Red: Are you asking AP or me to post the code from having SDL troubles?

Anyway, I'll look at the code rite nao and see if I can get an STL thingy working...

I can try. Thanks.

I was talking to AP.

Oh. I thought it got included automatically, in which case it would cause a conflict (just like I can't call my array char or int).

The problem for me is getting the includes to work, it's the code from the beginners tutorial. I think it has to do with where I installed msys, I'll post specifics tomorrow.

Sorry, I got fussed at for being on the computer too long when I was working on the code and I abruptly quit. I'm probably not going to get back to it, either.

But basically what you may want to do is make a generic sort of "Image" class or something that has a position, an SDL_Surface*, and a depth, so you can call a "Draw()" function or something like that and draw it onto the screen in one pass. Then at drawing time, you can just loop through a list and draw each one, rather than having three different arrays for drawing each image.

It's not entirely necessary at this point, but it would make the game run a lot faster to not have a delay loop.

Hi, I think I can help write music to this! It all sounds Epic and Awesome and my music could match! But if anyone hasn't suggested this I have some ideas for the game itself:

1.Could you perhaps have certain parts of the cave or place (whatever it happens to be) have booby traps that could seriously injure the player? And he'd need certain skills or spells or something to get past them. (eg. walking along and a giant rolling pin shaped rock slides out of the cieling and starts smashing you)

2. Not too much realism in case of blood and gore or at least an option to turn that off or else things could get disgusting...

3. That occasionally we have intense rock music that kicks in for intense scenes and battles (Not too often or I'll run out of ideas!)

Please let me know what you think! I'll be posting samples of my music on the site soon (somewhere) so everyone can get an idea of how I write!