[dust hill resident]

Hello everyone,

I just recently started getting interested in programming. I've always wanted to program, but never really had the talent for it. But lately, an online friend started teaching me, and thanks to him I started making progress. Now, here's a simple program I made using C/C++ and the Allegro library.

Youtube video:


Source files:
http://dl.dropbox.co...4076/grobin.zip

At the moment it's very basic and most certainly poorly designed and written. And if you look at the source, you'll see I copied parts from existing tutorials and examples. There are also some bugs, for example the jump doesn't always work properly. Anyway, my aim is to eventually expand this into a fully fledged game.

Do you have any comments or suggestions?

[Chimera]

Well, for one, if you add anything related to dicks to your game I'll believe that to be expected and reason to not respect you...

Second, I'd love to give some imput but I sadly don't know what you're trying to do :/ (Like, are you making a basic blocky platformer? Something like that?)

[dust hill resident]

Well right now, it's nothing more than a test. I'm really amazed that it works at all, since I barely knew any programming until a month ago. If I were to ask for something, I guess I'd ask for people to examine the code and give comments, suggest improvements, or let me know what I'm doing wrong or right, stuff like that.

But yeah, once I start really seriously working on this, I'm thinking of making a game that's a cross between Sonic, Mario, and Megaman.

This post has been edited by dust hill resident: 15 November 2011 - 09:44 PM

[Sik]

First of all, be aware that this is classic Allegro. It isn't bad, but it's pretty much deprecated and won't get any more updates except for serious bugfixes. Modern Allegro (I.e. Allegro 5) is a completely different thing though, it should have been given a new name...

Anyways:

• If you want to make the player jump only when it's on the floor, change the check for the jump key to also look for that - I.e. instead of key[KEY_UP] do key[KEY_UP] && onsurface. Also may want to just set the vertical momentum directly on jump (e.g. just do momentum_v=-jump_val).
  
• Is momentum_v reset when on the surface? You should reset it to 0 when that happens. You'll need this later when doing more complex collision.
  
• I would use rest(0) instead of rest(10). The former tells Allegro it should give up CPU time (so it doesn't eat up 100%), but it doesn't impose a minimum delay like the latter. This is very important, remember that at 60 FPS one frame lasts 16.67ms =P
  
• Yes, rest() gives the minimum delay. The OS may decide to make the program wait longer than that. So, that's even more of a reason to avoid using it for timing purposes. Use it only to prevent 100% CPU usage.
  
• I'd also take the rest() away from that while loop. I'd put the call to rest() before or after it (normally I'd put it right after blitting the graphics to screen). This way, if there's framedrop, it'll run the logic for all the frames that need to be drawn without giving up CPU time (otherwise you'll never catch up).
  
• If the framedrop is too big and the game logic is the bottleneck, you may want to cap it, e.g. limit it to 4 or 5 frames or so (a maximum of 5 frames would give you 60 FPS ÷ 5 =12 FPS before it starts slowing down). Besides preventing the game from locking up, it's also useful because skipping so many frames may make the game unplayable anyways.

[Chilly Willy]

Sik, on 15 November 2011 - 10:05 PM, said:

First of all, be aware that this is classic Allegro. It isn't bad, but it's pretty much deprecated and won't get any more updates except for serious bugfixes. Modern Allegro (I.e. Allegro 5) is a completely different thing though, it should have been given a new name...

I have an issue with Allegro 5 - they've dropped support for CPUs without an FPU. They made lots of excuses for why, but it comes down to them not wanting to have to deal with older systems/consoles. So if you wish to work on Allegro for something like the Saturn, you're stuck with Allegro 4. Fixed point math is a big part of Allegro 4, and deprecated in Allegro 5. While you could use software floating point on an older system, fp is so pervasive in Allegro 5 that it will run like a dog.

[dust hill resident]

Thanks for the replies, and thanks very much Sik for the information and suggestions.

I've been working on it a bit more, and I added an extra surface to stand on. I also changed a few of the behaviors and added some of Sik's suggestions.

Here's a video:

And the updated .c file:
http://dl.dropbox.co...14076/pennis5.c

It has some problems. Most noticeably, you can fall through the floor if you're moving fast enough. I think I know why it happens, but I haven't though of a solution to the problem yet.

This post has been edited by dust hill resident: 16 November 2011 - 02:57 PM

[Sik]

Chilly Willy, on 15 November 2011 - 11:58 PM, said:

I have an issue with Allegro 5 - they've dropped support for CPUs without an FPU.

Worse actually, they outright dropped support for anything that doesn't use Direct3D or OpenGL. Bitmap support is a joke, without a GPU forget about drawing. There's software rendering, but it's laughable. Ever checked the software blit command? It goes through the blitter with blending, which in turn goes through the one that does scaling, which in turn goes through one that also does rotation, which in turn goes through a rendered that transforms every pixel through a 4×4 matrix. It's literally trying to emulate a GPU.

dust hill resident, on 16 November 2011 - 02:57 PM, said:

It has some problems. Most noticeably, you can fall through the floor if you're moving fast enough. I think I know why it happens, but I haven't though of a solution to the problem yet.

Without even looking at the code, let me guess: it moves so fast that it outright goes past the rectangle in a single frame. There are several ways to work around this:

• Give the player a collision box instead of just a point. In other words, you'd be checking if two boxes intersect now.
  
• Trace a line between the old and new vertical positions, and check if the box intersects it (note the line is always aligned to the Y axis, I.e. the X position is the same for both points).
  
• Check every pixel the player goes through the fall =P (inefficient though)

This post has been edited by Sik: 16 November 2011 - 04:04 PM

[Chilly Willy]

Sik, on 16 November 2011 - 04:02 PM, said:

Chilly Willy, on 15 November 2011 - 11:58 PM, said:

I have an issue with Allegro 5 - they've dropped support for CPUs without an FPU.

Worse actually, they outright dropped support for anything that doesn't use Direct3D or OpenGL.

Yeah, that was the main reason they gave for going to FP - it made switching completely to OpenGL/DirectX easier.

Quote

Bitmap support is a joke, without a GPU forget about drawing. There's software rendering, but it's laughable. Ever checked the software blit command? It goes through the blitter with blending, which in turn goes through the one that does scaling, which in turn goes through one that also does rotation, which in turn goes through a rendered that transforms every pixel through a 4×4 matrix. It's literally trying to emulate a GPU.

DAMN! That's ridiculous. Yeah, forget about 4.5 if you aren't BOTH on a new/fast CPU AND also have a hardware accelerated video driver. That might be why the new version of MEKA is so slow on my CoreDuo/i945GM system - the author recently switched to allegro 4.5.

[Sik]

Chilly Willy, on 16 November 2011 - 04:41 PM, said:

DAMN! That's ridiculous. Yeah, forget about 4.5 if you aren't BOTH on a new/fast CPU AND also have a hardware accelerated video driver. That might be why the new version of MEKA is so slow on my CoreDuo/i945GM system - the author recently switched to allegro 4.5.

To be fair, the GPU code isn't that bad. Sure, it's technically emulated by the driver since it's trying to use the fixed pipeline (modern and not-so-modern GPUs completely lack it besides the rasterizer), but the amount of draw calls is minimal compared to 3D heavy games that need to get the most out of it to avoid slow down. I guess MEKA is trying to handle the bitmaps like in classic Allegro, which obviously GPUs (and especially the VRAM bus) don't like at all.

This is also the main thing holding me back for some PC game. Classic Allegro is officially dead and unsupported, but modern Allegro is an abomination for what I need. SDL 1.2 is officially dead too, though personally I like SDL 1.3 much better... but development for 1.3 is also in a standstill >_< Not to mention it's still called libsdl despite not being backwards compatible (I couldn't build 1.2 programs with it). All other frameworks I know of are like modern Allegro, except much worse (e.g. I can't believe people like SFML when it's such a piece of shit, it can't even handle all the keyboard keys properly).

[dust hill resident]

You were right, Sik, that was the problem. I've adjusted the collision detection to check the horizontal sides as well as the vertical ones. And at the suggestion of my friend, I slowed the animations increased the frame rate. It works a lot better now.

Since then, there have been some new changes added, such as screen scrolling.
A video:

The updated code:
http://dl.dropbox.co...4076/pennisX2.c

[Chilly Willy]

Much better, but a couple places in the video at the end, it looked like you did double-jumps - jumping again while in mid-air.

[Sik]

If you feel OK with this you may want to start working on tilemaps. Will make your life much easier when you have to handle real levels with complex shapes.

Wasn't 60 FPS high enough though...?

Chilly Willy, on 18 November 2011 - 12:57 PM, said:

Much better, but a couple places in the video at the end, it looked like you did double-jumps - jumping again while in mid-air.

No, that's just shitty framerate not showing him touching the floor. The real problem is that he jumps as long as the button is held down, rather than just the first frame it goes down, but that's a separate issue that can be dealt with later, really.

[Chilly Willy]

Sik, on 18 November 2011 - 02:52 PM, said:

Chilly Willy, on 18 November 2011 - 12:57 PM, said:

Much better, but a couple places in the video at the end, it looked like you did double-jumps - jumping again while in mid-air.

No, that's just shitty framerate not showing him touching the floor. The real problem is that he jumps as long as the button is held down, rather than just the first frame it goes down, but that's a separate issue that can be dealt with later, really.

I'd swear there was one point there where he jumped AWAY from the platforms, and then jumped up and toward the platforms. Maybe that was just the "jump as long as button held" issue combined with the clear "you can change directions in the air" issue it also has. Being able to change directions after jumping is a problem many platformers have.

[Sik]

Chilly Willy, on 18 November 2011 - 03:29 PM, said:

Being able to change directions after jumping is a problem many platformers have.

Yet those that don't allow it are prone to disaster jumps... (though most platformers impose extra horizontal inertia while jumping)

[Dario FF]

Sik, on 16 November 2011 - 05:36 PM, said:

This is also the main thing holding me back for some PC game. Classic Allegro is officially dead and unsupported, but modern Allegro is an abomination for what I need.

How can it be an abomination for what you need?

If you don't like any of the drawing routines, just force the OpenGL driver(if you want cross platform compatibility), and start drawing stuff with your own calls. Or even 3D rendering(heck, you can even use Ogre3D with it).