Hi Michael
Great! Yes I think it is pretty straight forward to implement it.
Been looking at your code to see if I could implement it myself,
but it will probably be better if you do it, since you know your code much better than I do.
Thanks.
This is one of those features with the potential to bloom into many additional features. The more I think of it, the more potential I see. For example, with the way the lighting system works, each sprite is aware of the lights shining on it- and the sources of those lights. You can do so much with that information! This is easily folded into a line-of-sight detection feature.
Lights don’t have to be 360 degrees. You can define light arches, or you can specify individual rays to be cast out in a specific direction. Again, a ray cast by an object contains that object’s ID, and so anything illuminated by that ray knows precisely what cast it.
I hadn’t even thought of using masks, but that should be simple enough as well. A mask at least would be relatively inexpensive to add to the lighting stack. In fact a mask might be used in place of a dynamic light source when reacting to the map is not needed.
It has huge potential!
Out of interest, how flexible are the graphics 2.0 features when integrated with MTE? Have you had a chance to see what is possible?
I am particularly interested in the normal mapping feature, but slightly apprehensive it may not offer what I hope. I am a compositor by trade and I use 2d normal re-lighting fx all the time, it is an incredibly powerful tool, but as I am not yet a pro user I haven’t had access to the feature in corona yet to test out the limitations and flexibility.
This idea came to mind when looking at your latest lighting examples. To be able to reference a normal map version of the tilesets for relighting purposes, would be an incredible addition.
Here is an example of what I mean, a 2d sprite image re-lit with normal map effect: http://www.mattgreer.org/media/lightingShadows/pixel_shading.gif
Michael/all
How does MTE/Corona perform in terms of the various versions of iPhones? Just wondering for example is it a given that a complex game with MTE, physics etc, with Corona might need and iphone 5+ to be snappy?
Any tried a complex physics / MTE game on an iphone 4? An iphone 3s?
Ultimately wondering if a game is sluggish on an iphone 4 is sluggish, is this kind of normal or not. Eg if not is this a sign you need to do some more optimization your code?
I have been doing a few experiments with G2.0, but not with MTE itself due to the potential time demands of converting the engine to the new API- I’ve been busy working on MTE’s features. Initial tests suggest that a certain G2.0 feature may radically improve the performance of MTE’s tiling system, allowing for screens filled with many,many more tiles than possible now.
I’ll whip up a test of normal mapping and see how it applies to tile systems.
Dyson,
Thanks for a thorough answer, it belongs in an FAQ for MTE in my opinion.
Where do you want bug reports?
BUG:
Loading tilesets with spacing fails with an error like this: “mte.lua:6365: Incorrect number of frames (w,h) = (32,32) with border (1) in texture (w,h) = (256,256). Failed after frame 50 out of 56.”
FIX:
Change line 6344 to:
map.numFrames[index] = math.floor(map.tilesets[index].imagewidth / tempTileWidth) * math.floor(map.tilesets[index].imageheight / tempTileHeight)
Just as an FYI to everyone, I know a lot of you do your programming work on the weekends, but for me it is the opposite. I work on MTE during the week, and I’m usually unavailable on the weekends. Now that I’m back to work I’ll start working through the backlog of emails and questions I’ve received since Friday. I don’t mind getting questions and emails on the weekend at all, just be aware that I may not get to them until the start of the following week.
Sorry for the delay, greg886.
Unfortunately my iPhone3GS has refused to install new apps as of late, but I did do some tests with my iPhone4 and Platformer - Angled PHYSICS 0v918, which has a few dozen physics objects and potential for some quick movement if you get the player up to speed. What I found is that the iPhone 4 is beginning to show its age. If you increase blockScale to 80 from 72 (thereby decreasing the number of onscreen tiles) and set the default fps to 30, it will just about hold this speed. Then again, the iPhone 4 is the last of Apple’s single-core phones.
Simple maps with no physics will of course work smoothly across all devices, but I think it’s safe to say you’ll want to target the iPhone 4S as the minimum if your thinking of doing something complex with a lot of physics.
Thanks. Makes me feel more comfortable 
One thing I’ve been pondering is how do you measure “snappyness”. Like, if the app can maintain 30fps than doesn’t this imply it should work well? Ie why would a game maintaining 30fps on an iphone 4 and iphone 5 not appear to be just as good? And then whatever the answer is to this, how would you measure it?
Thanks arman7,
I’ll fold that fix into the next MTE release. It’s always nice to see people coming forward with solutions to bugs they encounter! You can post bug reports in this thread, particularly if you’ve already found a solution, but if you have open questions or need help with something it’d be best if you started a new thread. You can also PM me if you like. I’ll respond to emails as well, though I prefer to keep customer service here on the forum so others can benefit from answered questions.
Good question…
Frames per second is inherently an averaged value. At 30 frames per second, each frame should take 33.3 milliseconds. If your FPS drops to 28, it can mean a couple different things. It may mean that each frame is taking 35.7 ms instead of 33.3. This would still appear smooth and snappy because it is consistent. But in reality, you are far more likely to encounter a situation in which most of your frames are taking 33.3 ms, but a few here and there are taking much longer. These longer frames will occur when a lot of action is happening onscreen, filling the user experience with very short but noticeable slowdowns.
So, Im thinking a good definition of snappiness would be “having a consistent framerate.” A good way to measure snappiness would be to output the longest frame per second. If it often strays from 33.3 milliseconds, the experience probably isn’t snappy. I haven’t tested this myself, though, so snappiness may have to do with other factors as well.
It’d be simple enough to modify MTE’s debug output to do this. It might actually be more useful to print each frame’s duration to the console so you can scroll back through and look for spots where it changes.
excellent - thanks for helping me understand
Regarding the error I have been experiencing with the TMX maps, I have made a simple demo map separate from my project but also has the same error, the map is very simple and the main file just loads it, just a simple change from .json to .tmx will produce this error.
Thanks Abiz, that was very helpful.
At the moment only XML encoding is supported. Your map’s layer data is encoded in base64. I’m working on adding additional encoding support in the near future.
Ahh I see, thanks for telling me that, it wasn’t obvious to me. Everything is working now.
I’ve added base64(uncompressed) and CSV support to the TMX parser, and I’ve improved the performance of the XML parser. Unless there are other factors I’m not aware of, using CSV layer data in your TMX maps would seem to be the best choice. The resulting files are a similar size to Json exports and load almost as quickly.
The test map is a 100x100 map with 9 layers, completely filled with tiles. Tests were run in the simulator.
Type: Size: Loading Time:
Json 273 KB 103ms
CSV 182 KB 126ms
XML 1.7 MB 264ms
base64 482 KB 383ms
Tomorrow I’ll be finishing up the current work on TMX support and moving on to PhysicsEditor support.
Hopefully this isn’t a terrible question but I am just now getting into the engine and I am still relatively new to Corona.
I know that with the Sonic and Basic project’s your player is constrained to only jumping once etc. based on isJumping I believe (Sorry from memory, looked today). In the Basic (and Angled) physics examples, the player’s can jump over and over again.
I am interested in making a side scrolling game similar to Zelda 2 where velocity is constrained after an initial pace with the camera in a fixed position following the player. My problem so far with understanding the examples is mainly how the physics examples could be modified to only allow the character to jump once while also constraining the velocity etc… Just a little lost here
Does it even make sense to use Physics in a game like that? - the non-physics examples seem to perform much more closely to that type of game but there seems to be a lot more to consider when not using physics.
Hopefully those aren’t stupid questions but I am still learning and want to get past the roadblocks
Thanks!
Physics goes so very far and asks so little of developers who use it, provided they can bend its mysterious black-box simulation to their will. It’s plain to see how very complicated 2D platforming movement can be to code on your own, and you have to take into account the possible need to add more functionality in the future. The Sonic Finale example has no wall collisions, for example, and you would have to code those in yourself. It is not a trivial task. Hand-coded physics can run a lot faster than using Corona’s Physics implementation, but that is a benefit you have to weigh against the difficulty of programming your own system.
I did some tinkering today and came up with two ways to constrain the movement speed of a physics body. The first is to set the body’s linearDamping property to something other than zero. Higher values cap the sprite at a lower top speed. The downside of this is that the vertical (jump/fall) speed is also constrained, so it isn’t quite ideal.
A better solution is to check the linear velocity of the sprite, compare it to a user-defined limit, and set it to the limit if the sprite is moving too quickly.
Generally, preventing the player from jumping repeatedly in mid air requires that you detect when he is standing on the ground. There are probably many ways to do this, but the one I threw together works by calling the Physics’s queryRegion function and testing a region encompassing the bottom (but not sides or top) of the player. That is to say, checking for objects inside a box not as tall or as wide as the player, positions against the bottom of the player’s physics body. You then iterate through the objects inside the box, ignoring your player object, and if any are present your player is probably standing on something.
You can modify Platformer - Angled PHYSICS thusly to try these out yourself.
local grounded = false local jump = function(event) if event.phase == "began" then display.getCurrentStage():setFocus(event.target, event.id) event.target.isFocus = true if grounded then player:applyLinearImpulse(0, -500, player.x, player.y) end end if event.phase == "ended" or event.phase == "cancelled" then display.getCurrentStage():setFocus( event.target, nil ) event.target.isFocus = false end return true end --ENTERFRAME---------------------------------------------------------------------------- local gameLoop = function(event) local hits = mte.physics.queryRegion(player.x + blockScale / -2 + 8, player.y, player.x + blockScale / 2 - 8, player.y + blockScale) if hits then for i = 1, #hits, 1 do if hits[i] ~= player then grounded = true elseif #hits == 1 then grounded = false end end end local limit = 1000 local velocityX, velocityY = player:getLinearVelocity() if velocityX \> limit then player:setLinearVelocity(limit, velocityY) elseif velocityX \< limit \* -1 then player:setLinearVelocity(limit \* -1, velocityY) end mte.debug() mte.update() player:applyForce(acc \* 2400, 0, player.x, player.y) endWe do this for our game
Just as dyson said, you can use acceleration and then set the linear velocity after some threshold. One thing you might want to look at is old interviews and documentation about super Mario brothers on the nes by Shigeru Miyamoto. He goes to great length how they spent the most time getting the player/camera/controls to work and **feel good**.
One thing we did in our game was to completely separate the camera entity from the player entity. Doing this allows the camera to react to the player movements and perform its own movements. We found, once we did this, all camera and player movements felt more natural and responsive
Wow, thank you dyson for that explanation and example! It works like a charm in the Angled Physics example and I tested it out and it works perfectly - thank you for taking the time to put that together!
jqualls, thank you too. You mentioned separating the camera from the player entity. I am guessing that you would set the camera’s initial position and when the player entity moved you would move the camera based on some rules inside the game loop? For example, when the scene loads the camera and player are set at specific positions in the map. Then, when the player moves say to the right, the game loop could recognize this and say delay a second before adjusting to the player’s movement?
Thank you both for your help - There really is a lot to take in with Physics and you have been very helpful!