gamecreator

910 score but I stopped playing at that point. That's also when it finally gave me a blue after only giving me the other 3. Which made think: should it be coded in that if a color isn't picked after a certain number of steps that it's automatically added? Probably. Maybe even that a color won't come up more than 3 or so times in a row. Things you wouldn't immediately think about. Want to get even more crazy? Factor in how simple the pattern is for the score. For example, it it was 5 blues then 5 reds, that's worth less than 10 "more random" colors because it's easier to remember, no? But that's just a silly idea and I probably wouldn't implement it myself.

I wrote the code to only include loaded models (not Sleep). This is what I got: models - fps - time 0 - 1080 - 8169 25 - 189 - 8216 50 - 100 - 8265 75 - 68 - 8326 100 - 51 - 8376 150 - 34 - 8476 200 - 26 - 8560 300 - 17 - 8756 500 - 10 - 9182 If you do the conversion between these results and the results in the first post, you'll find they're actually pretty close and linear (though I did my bit of rounding so this is hardly exact). For example, the 10 frames per second with a heavy model load brought the result time to 9,182ms whereas above, with a 100ms Sleep (also 10fps), the time was 9,322. Does this mean that AppSpeed can't be relied upon to give you the same results on two different computers?

Fair enough. Would this be better tested by decreasing the frame rate by putting a lot of triangles on the screen?

I was testing my program to see how it would behave on slower computers, by adding various Sleep amounts in my code. To my surprise, the program didn't act as I expected. So, I decided to write a simple test program to see why this was the case. Here is the relevant part: float x=0.0; double t1, t2; t1=t2=timeGetTime(); while(!KeyHit(KEY_ESCAPE)) { Sleep(1); x+=0.01*AppSpeed(); if(x>5) { t2=timeGetTime(); x=-10000.0; } UpdateFramework(); RenderFramework(); DrawText(0,20,"x: %f",x); DrawText(0,40,"AppSpeed: %f",AppSpeed()); DrawText(0,60,"time: %f",t2-t1); Flip(0); } I noticed that as I increased the Sleep amount, the time it took x to go from 0 to 5 took longer and longer. Sleep(amount): time 1: 8185ms 10: 8295ms 50: 8757ms 100: 9322ms Is this difference expected? I get that we're talking milliseconds here but this could be the difference between making a jump and missing a cliff, especially if the fps drops in certain scenes.

Thank you for taking the time to consider it and explain the difficulties. Some of this is over my head (I don't know what virtual functions are, for example) but I get most of it. Too bad. Maybe the character controller could be more robust and controllable instead.

I appreciate the engine taking care of collision declarations and other assumable information. I'm hoping that with this version of the engine, you can make it so we can do something like this, any time we want: AreEntitiesColliding(entity1,entity2);

It's always downloaded every file for me in the past and Josh said that's normal when I asked. Are you saying that's been fixed in this version?

I'd like to see it without the cell filter but with the color correction. The color correction definitely makes it look more vivid. Without it and without the cell, it looks a little flat or low contrast or something. Not sure what the right term is.

I would too but I'm saving my pennies for it. That said, as an owner of the current engine, you'll get a discount on the new one (I believe) so you'll be ok. That and Josh seems pretty in tune with what most people could afford and where it's fair to price. And agreed with Roland. This stuff's pretty powerful.

Looks very stylish and complete (to my untrained eye). I'm sure the shader has a little to do with it but props to your artist(s).

Rick, this is the next line for me: 22:33 on first run. Very impressive. I'm also a little jealous because I'm trying to make a platformer but I work very slowly. Gonna PM you some questions, if you don't mind. Some notes: More enemy types would be fun but I'd guess you're working on that. Loved the wall jump and wall climb features. Same goes for the switch puzzles. Levels may be a bit long. I like the exploration aspect but sometimes I got a bit impatient. Maybe include some shorter levels with larger energy balls that count as 5 instead of 1. I like the keys as most indie platformers have a similar setup and it's natural for me. Wall jump could still use a little tweaking but pretty smooth and natural for the most part. You already noted similar but sometimes the character hangs in the air (next to a ledge). Very well done!!

Ha, yeah, C4 may have some strengths but simplicity is not it. When I was looking around at engines, that character code is the very thing that made me realize C4 is not for me.

I seem to repeat myself a lot with you but I'll do it again anyway: very nice! I've gotta say that if this works properly, this will be the top 5 features I would buy Leadwerks3D for (though I'm still hoping to make my dream platformer first). Hoped-for sub-features: 1. Most games have enemies that stop chasing the player after a while and return to their original position. This is usually done in one of three situations: a. The distance between the player and the enemy is great enough. b. The distance between the enemy and its original position is great enough c. Player enters a safe area. 2. Enemies following at different speeds (I'm sure this is a given, though it's worth mentioning). 3. And here's the big one: enemies that can go where other enemies can't. Like fire enemies that can't cross water. I suspect this would require a separate nav-mesh (or whatever it's called). I don't know if Leadwerks3D could use more than one nav-mesh at a time and have two entities assigned different ones. Or can tiles be given characteristics? The simplest way would be to just change a tile's characteristic in the editor. Though I admit I don't know anyone who would use this just yet. I'm sure it could be done down the line should it become a popular request. I'm as excited about this as you are. I didn't really realize how much I missed this feature until I saw your videos and those of others trying to implement this.

Sweet!

On the first example, it makes sense to me that it didn't go straight down because it won't enter segmented tiles (it considers them walls). Because you had a dark green and a light green segmented tile "blocking the path" (I get that that wasn't the intent), it considered that a full wall and so it went around. It went straight exactly until you hit (or crossed) one of the green tiles. This also relates to most (but not all) of your corner issues. It simply won't enter segmented tiles so it goes around them. Though starting around the 2:20 mark it snagged the corners on normal tiles that it really shouldn't have.

Did you already try setting DebugPhysics(1); to see what's going on? After that, just to test it, I would temporarily make the wall body much thicker than it should be and see if the same thing still happens.

I don't know Lua but thank you very much for sharing this regardless.

Sweet! My friend bought an Android phone today and I told him I will be able to code for it with Leadwerks3D one day. That means I'll have to buy an Android too but small price to pay, especially since my phone is so dated (it doesn't even have a camera!). A quick search seems to show that the touch amount is limited by the hardware. http://stackoverflow.com/questions/4397249/using-ipad-with-11-fingers-extend-androids-limit-in-code but I wouldn't rely too much on just that link alone. Also, it seems like this is already covered but is the device smart enough to know if a finger left the screen? In other words, say you're zooming with two fingers and you put a third on the screen and you remove the second. What happens? I guess this depends on the user's code. You'd have to make sure the third finger stays the third, even when the second leaves. You'd have to reset the zoom distance to start from between the first and third finger, I guess.

Ah, I misunderstood. Maybe you could generate LE terrain instead but I have nothing other than that.

I admit I haven't done this yet but have you already tried generating an alphamap, saving it, then loading it with LoadTerrainAlphamap? BlendTerrainTexture might be helpful too.

Seconded. Thank you!

Congrats!!

I would strongly suggest keeping the 5 or 10-line examples (those that don't overlap, at least). It's very valuable to have quick function information at my fingertips and to not have to wade through dozens of lines of unrelated code and documentation just to (hopefully) find and understand how a function is used. The more information that's presented, the more likely it is to not be understood. That said, I'm sure I and others will find the comprehensive examples informative and helpful as well.

Ah, great news. All the best with that too then.

Just realized this... Does this mean you know how to do water/ocean/river like you want to???? Because I think that was an unresolved challenge some months back, if I remember right and caught all the news. Also, Rick, good point. Some things are simply expected of games, just as they are of engines. People don't notice if they work but they definitely notice if they don't.