Apologies for slow reply - I broke the code last night while trying to fix the corner sticking problem that I mentioned earlier ("My only problem is that a fix to edge collisions so that a character standing precariously on the edge of a platform does the expected platform game thing causes some weird effects.") and for the sake of simplicity have made changes to the level format so that shared vertices are explicitly shared. Which has obviously meant code fixes and to make everything clearer I've broken Level.c in two and taken the opportunity to adjust a lot of the structures in Level.h for readability. And they now live in QuadTrees.h.

Anyway, things are 'pretty much' working again (some slight adjustments left) and better than ever!

I'm going to get it going in the game engine and see how it looks. My imagination is too flawed to respond otherwise!

My efforts are attached. I apologise for the weird jumping behaviour. I'm still trying to determine how that should work with respect to 'real' physics versus a game characters ability to control their jump height long after leaving the ground.

The sprite looks a bit odd at times, especially while flying through the air, an action for which I've simply halted the animation. Also I need to stop modelling the main character as completely square - try walking slowly off one of the two flat edges to see what I mean!

Otherwise I'm going to play around with it for a bit and see how it grows on me. As this is meant to be a community collaboration for commitment back to the community, comments are invited!

EDIT: play around with line 294 of Main.c to try different resolutions/colour depths and to switch full screen/windowed modes. Obviously some sort of menu will give the user these options before it is submitted as a potential demo game.

you seem to have forgotten to include stdio.h again

very nice, but i did notice the following:
1. the sprite renders very badly on the rotate, half the black pixels round the outside disappear like a sort of dashed line.
2. pressing jump make it jump far too much unrealistically from what i remember from the square block from yesterday.

Nei.

Anyone got any ideas about this? I guess the 'smart' thing to do would be to pre-rotate the sprite to about 8 variations, clean those up then just use the software rotate from the closest match at runtime. But we don't really have time for that.

Do you release jump or keep it pressed? If you're releasing it 'early' then you're encountering my messed up attempt at that platform game jump staple: holding jump for a longer time to jump a greater distance.

I guess one for jumping, one for collecting a fruit item (or even five different sounds if you like as there are five different items - cherries, bananas, a wrapped sweet an orange and an ice cream cone), an end of level sound (although I'm not really sure how one ends the level yet) and possibly some thuds of different degrees depending on how hard the character hits the floor.

I guess if we're trying to show Allegro off then some music is required also.

It sounds good to me...
</quote>I don't really know what theme your demo game is "going for" . . .</quote>
No, me neither. The target is: "something fun"

This is explicitly meant to be impossible. I have adopted a 'continuous' time type simulation (as opposed to a discrete stepping thing) and have even included rounding error fixes. So I'm annoyed. Are you aware of roughly whereabouts in the halfpip you managed this?

krajzega > you're going to hate me, as I've changed my mind entirely about the main sprite.

The code and algorithms contained therein are based around a simple premise: that the main character is an exact square.

My intention was (or possibly is) that I would fix this to make the collision object a rectangle rather than a square by supporting a simple distortion of space. All collision geometry would be rotated relative to the player then scaled in one dimension or the other so that in that window into space the player rectangle looks like a square.

This affects all of the precalculated stuff such as surface normals but in a predictable fashion. We can just apply the inverse of the scaling to the normal to get a new valid surface normal. Since that part of the code doesn't require normals to be unit length there is no problem with that.

The problem is the complexity this adds to the code. For various reasons I do not believe that the necessary adjustments can be justified.

Firstly there is the simple matter of the intended audience for the game. The main intention must always be to provide something that shows Allegro off while also followable code. More complicated code is harder to follow.

Making those adjustments to code would also take me a few days. Evert has given us an implied slight time extension but we otherwise have to assume that the whole project must be complete in 10 days total. I therefore do not wish to expend this time when I could probably conclude the entire project coding in the same period.

What I would like to do instead is a classic hiding of the engine restrictions through art. Specifically, I want to put the main character on a skateboard. This not only gives a good flat base to the sprite explaining its behaviour on edges but also provides an excuse for the high flying behaviour of the main character and partly explains why the game is more of a racing thing than a traditional enemy bound platformer.

Would this be acceptable? Have I messed up your potential contributions and wasted your time?

I guess him balancing with arms out, pushing forwards with his feet (as if attempting to speed up), leaning back so as to apply the brakes and maybe sort of holding on to the board while flying a great distance through the air? Although I'm not so sure about the last one.

That's cool. It doesn't really matter if it doesn't exactly line up. My main concern is covering the bottom edge and more or less meeting up with the left and right (so that 'pushing' against a wall doesn't look too odd).

I think he looks pretty cool. If there weren't already a game with the name, I'd suggest Rad Gravity for this project!

I've never played it. I don't know exactly, but I believe it came out after my Playstation died and the only replacement I could afford - a second hand Saturn - has never seen a version.

I think what I need to get on with now is some sort of full size level. I'm a bit concerned about that and may extend the file format in a few simple ways so that its easy to hand duplicate things and write some code to spit out some nice shapes.

If anybody felt like writing or adapting an existing level editor, I'd be very supportive!

Suggestion: Put Alex on the skateboard. The current character is cool, but you can't deny the Allegator's marketing potential. It would be nice to acknowledge a mascot, too.

Personally, I consider Alex a bit of a gimmick. Something which hints at Allegro without being too blunt, but maybe that's because he's shipped as alex.xpm with Allegro and is the default icon under X11 (which maybe we could/should replace with the icon Matthew uses for Allegro.cc). Personally, I certainly have none of the negative conotations with the term `mascot'. Maybe `mascot' is also too big a word in this case. It would perhaps be better to call him an Allegro Icon, just as Mario is a Nintendo Icon. I'll fully admit I find Mario too childish though.

There is also no reason why you cannot feature a graphically enhanced cool-looking Alex, if the console-feel he represents is bothersome.

All that said, Thomas, this is still your game, never mind if it ends up under Allegro's license or not, your opinion is certainly a valid (and as always valuable) one, especially when it comes to what happens with the demo game you create.

I think it would bring some sense of familiarity to the game if it featured Alex in some way, but I don't feel that he should nescessarily be in it. This is, after all, an Allegro Demo game, not Alex the Allegator 5. And that's not what it should try to be either.

The Allegro logo is a requirement at the start of the demo, as is Shawn's `Welcome to Allegro' at some point (maybe the start of the level?). That's it as far as artistic requirements are concerned.

I think you're exaggerating a little. You just gave me very vague directions ("soil texture", "ice texture", "texture that would resemble water", "some sort of fruit/coin", "character sprite"...), so I just went with what I felt would look the best. If you would've said "I want the main character to be a red possum on a yellow modded-up rocket skateboard", I'd even look up "possum" in the dictionary . Just share your vision with me .

On the topic of Alex: First of all, all available images of Alex that I'm aware of are suited for 320x240. So, at the very least, the sprite would have to be rescaled and then hand enhanced, which is tiresome. Even after I'm done with that, I would still have to put him on a skateboard, make him look reasonable on it, and animate him, which I would probably fail at.

However, if Thomas/community/whoever really wants Alex, I can try and draw him. But it's ten times more fun to pixel your own character than to copy someone else's .

[EDIT]

I just remembered:

I tried to draw the new sprite without using black edges and relying on one-pixel lines, so this one should look better when rotated. At least I hope so .

I skipped most of this thread , but:

It IS Allegro afterall, you shoudl be using PACKFILE *'s .

Looking at what you have so far I'd be tempted to make the main character a ball or marble and have levels filled with half pipes, tunnels, loops and ramps. The idea being you move the marble to create momentum to get around the level. Remember those marble contraptions you could build and run marbles around Thomas?

I think that would be quite fun with some elaborate level sets with collection of fruit too.

I attached some sound effects to my second post as well, [url http://www.allegro.cc/forums/view_thread.php?_id=500102#target]. They're from BlitzHack though, so I'm sure Goodbytes has them as well.