This is cool software. However I'm concerning over the practicality of this. Don't get me wrong I would love to use this in my games. I think the effect of dynamic lighting like this is gorgeous and adds depths. BUT.

1. This is PC only tool. The result is 4 images per frame of any given sprite. 1 Diffuse and 3 Maps base on the light system. I have a demo game that has the PC where one animation has 60frames. That's 240 frames with SpriteLamp. memory and storage wise this is shot.

2. Developer needs to create the base light maps to be processed. The guide shows that while it exports 3 maps it needs 2 to 5 light inputs. Again that's going to be for just one animation 60 frams where I need to create these light inputs. Can't imagine what this would be like over the entire characters animation.

3. This seems impracticale due too number 2. HOWEVER this would work SUPER well for static parts of the level. Wich means that use of spritelamp only works best in games where light moves. Which is often dungeon games, dark exploration games where the ligth source is carried by the player.. though shooting blasters would look super cool too :D. But again only the terrain gets' the beenfit.

4. The Only practical way to make this work for moving characters is to use Spriter/Flash like tween based animation. That's why dynamic lighting works for 3D models. 1 Light map and it's MAPPED over the 3D model. Spriter based animation would still require more. but at least it's not based on the sprite's angle an not per frame.

BUT OH WOW. I would love this in my games.... super coool. WANT WANT WANt.

Anyway to remove this start up screen completelt. I thought the purpose of "Use loader layout" was to have out own custom screen asap. However for larger projects that start up C2 screen(I know I can change the icon) can sit up on the screen for 2 minutes waiting for the game to load. THEN it switches over the the loader layout for another 2 minutes.

Half the time is spent on the screen which I would have thought only needed for c2runtime.js and the first layout assets. But it really seems half the game is spent on the preloader.

AnD4D

because dt is still based on a millisecond clock. C2 uses dt based on a 60fps millisecond clock. So when you use dt your trying to create a universal math and multiplied value. The reason and it's just suspect reason that the 30fps dt isn't the same due to the idea that yoru also only processing logic at 30fps rather than continuing to handle logic at 60fps.

Not that I would associate logic to FPS at all. I'm just using that as an anology.

So on

PC, box.ImpulseAngle(0, 100 * dt)

iPAd, box.ImpulseAngle(0, 100 * dt)

In theory tries to unify the the force based on the clock. So results should be similar.

How physics works is that Box2D uses a time step.

Each time step consists of 2 primary values.*

* Step

Step is the amount of px the objects moves per itteration. Large steps allow for farther movement. but this reduces accuracy for collision detection. This can lead bullets to shoot through objects.

*Itteration

The number of times the physics shuold take 1 step(above). The more itterations a Physics.Render will call step.

Now when a programmer makes the basic timestep. it tries to take into account the difference of time from last frame render and how many Itterations shuold be called. However this usually works best for FASTER computers and often the basic time step doesn't do very well on slower than the primary development computer.

This is the problem that's happening hear. Your slower computer can't keep up with out something to fix the speed value.

Now how does dt come into this.

Well keep in mind that the dt is a reference time between. 0.0 to 1.0. On a faster computer the dt is much smaller due to the fact that it does everything faster. Where as a slower computer dt is a larger number to compensate for the difference in time.

So when you set your mobile game to run at 29fps vsync it falls out of sync. And the reason I think this is happening is because yoru logic is now running at 29fps(speculation based on what I'm hearing. In theory with all the exrta time your logic should be able to more than keep up... unless your game logic is throttled.

So this is why I think the current C2 use of 30fps isn't to give developers more logic time for physics and game processing, but instead to slow down the game to run on older devices. So instead of giving you access to all the yummy CPU time. C2 drops everything.

That's all speculation of course. but it's one reason why your game is having troubles with the lower 30fps.. you don't have more CPU time you have less.

AnD4D

That's right. You shouldn't be using dt. I understand the the desire too. but it's a bad idea. Box2D isn't built to work with dt. Box2D has a straight foward information that the results of Physics from Box2D are dependent on the binary being run on. So this means that results will be different from different CPU render levels.

Box2D suggestion is to just use different levels of settings for the devices. This is annoying. Instead there is a way better alternative. There is a high resolution fixed time step for Box2D. but it needs to be programmed in manually to the use of Box2D. The problem is that C2 fixed time step is rudemntary and not advanced enough to handle different platforms. You will need to modify physics timestep option. So every tick you will need t modify how many steps the Physics will use. This will smooth your physics.

Also I want to point out that I'm not convinced that the 30fps implementation in C2 right now is the right implementation. From what was written it sounds like option doesn't limit just FPS rendering to 30FPS, but also your entire game logic. How hard is it to just say. Draw On Time X and to set that time X. I get the feeling this is an entire game slow down :( BUT I could be wrong and we might just need more practice.

—

That's amazing. I was going to make a Vania game some day. but I'll wait until your done :D

DPADS on a touch screen are EASY.

Create 1 sprite with an arrow image.

Create a var in the sprite called DIRECTION

Have for ButtonArrow sprites with direction names for each.

Then

IsTouching ButtonArrow

Function.Call(ButtonArrow.direction)

Then do whatever game logic you want in the function. you can also do without the function. but doing it in the function allows for better future protability of the buttons and easier to integrate with keyboards and gamepads.

Now if you need Analog directional input and not a DPAD. then I have a tutorial in the mobile section that covers the needs. It needs a small update, but the CAPX provided is up to date and shows how to cover pretty much handling all the C2 Touch hurdles.

width: 0

height: 1

depth: 1

Arrays in C2 are wonky. For even a 1D array in C2.

Width represents number of Objects. So you have 0. No objects to start with.

Height/Depth. However you still need the SPOT in the object to actually sore the data. So even a 1D array still needs to define H/D with a 1.

Is loop off?

also you can share a minimum capx would be helpful(I only run stable).

Well in my game all the players are a

SpritePlayer with a PLAYER_ID variable.

I create the player. Set the ID. then create and pin the visual part of the player. If the player is complex with lots of sensors. Then it's a big list of positioning and pinning the sensors to player.

Running at 30fps allows for more visual content packed into the scene.

tomshardware.com/news/30fps-John-Carmack-Next-Generation-Console-Framerate,19864.html

gamespot.com/articles/watch-dogs-runs-at-30fps-on-xbox-one-ps4/1100-6415059

While increasing playability for being steady. Also if you run at 30fps you have more leeway to add visual FPS gauges to add extra effects or not.

Why is always assumed people want it to just run off the idea to make sure it runs on lower end. Even high systems receive a visual performance upgrade for the developer to choose more rendering features over more rendering frames. And you can get more than double the rendering features for half the render frames. Even in 20 years where computers can render real life like visuals. Running at 30fps will still offer more than double the period of time for each 30fps frame to render more detail

But hey. Why not tell the creators of Gears of War 3 there game looks terrible because they wanted more visual candy over 60fps.

"There's a good chance many developers may stick to 30fps just so that more content can be packed into each frame. Epic Games is a good example of that which stuck to 30fps with Gears of War 3. "Our target is, and shall remain, 30fps," former Epic superstar Cliff Bleszinski said in an interview. "When asked about 60 we always respond that we'd rather have the extra juice to put more on screen and stick with 30."

For Gears of War 3, lowering the framerate meant adding multi-layered shadows, wind and particle effects, and levels that changed in real time. Sure, the next-generation hardware will be beefier and likely capable of 60fps, but sticking with 30fps may simply become a choice similar to what Epic Games made."

Joannesalfa

I have a question. I haven't payed much attention to GC lately. Does GC support any memory management?

Roccinio

the problem with your theory is that many PS360 games run at 30fps, not only that there are PS4 One games that will continue to run at 30fps.

it's not about running down on power. No matter HOW much power becomes more at the disposal; saving 30FPS to increase eye candy, improving physics results will have far higher graphical value that just rendering.

While some people are proponenting to run less for syncing developement. t's also possible to use the all that juicy render time to just do BETTER rendering.

Take movies like Beowolf in full 3D render. Those werent rendered and run at real time. To achieve all those effects the computer takes more time. So if we slot 30fps towards more light flare, shaders, bumpmapping, normal mapping lighting, shadows. the game graphics will BURST alive. But beacause we are controlleing are FPS. the FPS is not jumping up and down to break the flow of the game or game play.

There are very good reasons to run at lower FPS than just to make sure weaker hardware can run the game.