MOM, that wouldn't be the issue. Even I don't have those header files somewhere special. They're in the project folder under "3include" and "3lib" with settings to look in those directories as well as the MinGW ones which is why you were able to compile yesterday with vanilla Code::Blocks.

And yes, those linker settings should already be there. I don't know too much about Linux-compiling, but I'll make sure to get MOM to compile it before I upload the next one.

The linker settings in the last one I looked at weren't 100% Linux-compatible, which is why I said that. Good point about the 3include; for some reason that slipped my mind. You'll still need the 32-bit Linux static libraries, though, which you'll get from the SDL_(whatever) runtimes. Those should be fairly easy to find.

See, I TOLD you guys I was working on something. Sheesh!

Just posting the newest upload. I named the new engine Fox (isn't it cute?). It's basically a modified, sleeker version of the old one. I scrapped the idea I had for the structure of the program and started focusing on the player. Before we get menus, fancy animations, or good visuals we need some form of gameplay.

In this version (first release of the new engine) much was scrapped (although it was mainly all under the hood) and the player object was brought back. The first thing I did was create player states, allowing a single visual (or set of visuals) to be shown per state, such as is shown. Pressing the a,d keys will move it left or right (and change the visual according to the state). More states (such as walkLeft or jumpRight) are there already but I have yet to represent them. I'll try to do that with the next version.

Download Link

It also includes data in the titlebar of the window regarding framerate and speed. The minimum framerate is set to 60 fps (this is changeable). Pressing the number buttons will change the player movement speed. Personally, I like speed 1 the best, allowing for more customization with equipment and such, but if it seems a little slow, we can make it faster. Just let me know what speed you like.

Nice. I also like speed 1 best, 2 is a bit too fast, but I think something like 1.5 would be right on the mark.

Sweet! I agree with Puggsoy that 1 is best. Only one thing: once animations are working (I don't know if they are), we should point each state to an animation file rather than a hardcoded image. It will make it easier to change.

How about one file containing all states, and frames for those states? A lot of games like Braid do that.

Or were is that what you meant? It sounded like you meant one file for each state.

@AP: Exactly what I was going for. Each state is currently represented by a surface. Once animations are fully implemented the surface can hold each frame of the animation.

@puggsoy: It doesn't really matter too much. Extra files will mean less than a byte extra of file size.

EDIT: Something I just noticed. Setting the speed to 1.5 causes tearing in the image. It's also very hard to distinguish the difference between it and 1.

So speed 1 then?

Actually...

Considering you're using PNG images, and a PNG header is 8 bytes, so if you have a million images in the final game and you condense them into one image, you'll save nearly 8 megabytes of data... yah, forget it. Do whatever's easiest. Sometimes animations are easier to have in a single file, sometimes it's easier to have multiple files, depends on how you set the engine up. Though LZMA compression does look for repetitive patterns of pixels, so if you have several frames in one file, it probably will be able to compress it more. ^.^

</tmi>

If the engine supports it, I'm voting for a single image per character (or character form, or character base, or whatever). This'll make it easier to organize, and generally manage, imo.

I'd say one image per animation, it may be better for organisation.

Meh. Whatever Red finds easiest to implement. It's just that most games have one image for each character, so I thought it'd be an kind of convention or something.

1.5 is a good speed.

@kirdneh: See my post above about tearing.

@everyone: I did the example animations and the player-states image as sprite sheets. I think that'd be easiest to implement, honestly.

i saw it before; it is just that, if it was possible, it would be a good speed; i think 2 would be good to use. I hate it in games when the character walks too slow.

Oh I got it working. Two things: I was using integers so a ".5" wouldn't affect the speed, and I set SDL_Doublebuf to true. This should prevent tearing.

Alright, 1.5 looks good. I'm sticking to it as a base speed. We can have status effects that alter the speed later on maybe.

I'll post an update later this week.

Sprite sheets for sure. But so we're having one sheet per state of character? That is, one sheet for walking, one for jumping, one for idle, etc?

And will there be an animation manifest file, like you mentioned before, for each one?

Just out of curiosity, will the game engine have physics lige gravity and friction? Well, of course, but will it be used for the gameplay? What is the innovative caracteristic in the gameplay?

This is what I know/think:

Simple, mandatory stuff like gravity and ground/air/ice friction will be included, of course. It's possible that some stuff like dynamic boxes and other objects will have realistic physics too.

However, it won't be a physics-based game, nothing over-the-top like Crayon Physics or Garry's Mod. The innovative bit, as far as I know, will be the unique side-scrolling RPG mash up. I think the battle style will also be different than most, I'm not sure if we'll have a battle mode (i.e. not real-time), but it won't be turn-based. We'll probably find some unique touches to stuff in along the way, I'll see if I can fit anything in the story that hasn't been done before.

That's what I think, but we've talked about some of this earlier on, so it's not just a wild guess.

It would be nice to include Box2D, so that we could use some physics without too much coding. Boxes and the like.

We've definitely talked about this before. I think Red decided to use Box2D for physics once the basic engine is done.

I did get farther than I thought I would on the physics engine. I have timers and everything set up so basic gravity (falling velocity changing over time) is working. (EDIT: I'll continue with my own engine, Box2D would take just as long to learn how to use)

On the other side of the conversation, player states should be separate files. Animations themselves (the way I set them up) run as separate files for different surfaces. Keeping different surfaces for different states is much easier to implement. As for sheets, only one image can be imported for a singular animation but box sizes and whatnot are infinite. A single image can be used for multiple animations, but an animation can not use more than one image.

New update: Basic gravity implemented (my own recipe)

Press 'z' to toggle onground, allowing gravity to take its course. To make sure you don't fall off the bottom, be sure you have onground enabled, and press space to jump. At the peak of the jump you can re-enable onground to keep the new height as the new y_pos for the player.

Download Link

Nice, jumping looks good.

If that's the case, then I don't see why we can't have one sheet for all/most animations.

the run and jump thing feels natural; good distance, not too floaty.

I think he meant a separate animation XML file for each state, which we could point at whatever image we wanted.

And it looks good, Red. I agree with Kirdneh, the jump feels nice.

EDIT: But I'd say use Box2D rather than reinventing the wheel. If, say, we want to have dynamic objects that are polygons, doing rigid-body collisions from scratch is a real pain.

I lol'd.

When I added Box2D to my engine, it took me about two days, then I was off adding new features galore. And I can guarantee my engine was about a thousand times more complex than what you have here. Box2D is really simple. Ultimately, though, it's your call. I don't think we'll need complex physics from what everyone's described so far.

*cough cough* More like impossible. I've had a full year of college-level physics, and have barely scratched the surface of rigid bodies. Haven't even had enough physics to determine rigid body rotation. Not to mention the trig involved in determining if a rectangle is colliding with a circle was what made me look at Box2D in the first place. Rectangle/rectangle collisions are easy enough to compute, but when you start adding polygons, lines, rotated rectangles... yeah, it gets very complex very fast. Basic physics (i.e. gravity, not falling through the floor, and colliding with objects) is pretty easy to code by yourself, so if that's all we need, no need for Box2D and bla bla bla I've said all this already, haven't I?

Yeah, I have no idea how I'd even start to program an arbitrary polygon-polygon collision. I was just referring to rectangles (say, a wooden crate and the ground), which would be more than hard enough.

Can't we look at what they did with crayon physics? I mean if we ever needed arbitrary polygon to polygon collision...
Also, I don't think sidescrolling/rpg should be the only gameplay innovation. Is it gonna be more fighting or more puzzly?

I think it's gonna be a comfortable mixture fighting (hopefully with some new, innovative system) and clever puzzles. In any case, this is gonna have way more new mechanics than Cave Story.

I don't get the Crayon Physics mentioning. I'm pretty sure that used the AS3 port of Box2D or another AS3 physics engine like APE.