6.7v2.1 720 HD release Bugs Fixed!

I made a hd version of LR, it runs at 60 fps and has a 720 resolution. PLease tell me if the physics are different.

Bugs Fixed ---> http://www.mediafire.com/?i3d50mcmf5h9mxh

BTW, the slowmo is boss!

Kevan for LRL plz.

No joke

This is amazing

Kramwood wrote: One Quick thing, The slow motion button isn't working for me ._.

ooooh snap, Kram is right.

I take that LRL thing back until that's fixed.

But it's sped up... It's the same physics, but everything is 1.5x faster.

Thanks for pointing out the problems, I'll fix them asap.

Now I'm confused by the flag button getting moved. ;__;

That's awesome dude!

ye a working slomo button would be nice

also bring it back to 40 fps (YT can't handle 60fps videos anyway) so it'd be nice to see everything at the same speed as before

also also can we have a pause/rewind button?

Well 60fps running at the same speed will in theory create extra frames to a 40fps track.

I approve. This version is purtty awesome.

Oh wow, lag is reduced in scenery tracks o.o

physics seem exact to 6.7, but faster

YT doesn't play 60fps anyway why do we need it?

KillinTime2792 wrote:YT doesn't play 60fps anyway why do we need it?

my tracks work at 80fps for some reason.........

KillinTime2792 wrote:ye a working slomo button would be nice

also bring it back to 40 fps (YT can't handle 60fps videos anyway) so it'd be nice to see everything at the same speed as before

also also can we have a pause/rewind button?

Youtube can indeed handle 60fps... That's the frame rate that hd is.
And the play/rewind thing... Too lazy, honestly, Im going to leave that to mhenr. My goal isn't ro add features, but to make it more, as kram said at elr, "comfortable"

Sheldon wrote:Well 60fps running at the same speed will in theory create extra frames to a 40fps track.

That doesn't see m to happen though...

a1c4s8 wrote:Now I'm confused by the flag button getting moved. ;__;

This was added to eliminate the stop/flag problem. I believe I came up with a better UI.

FIXED EVERYTHING!

http://www.mediafire.com/?i3d50mcmf5h9mxh

kevansevans wrote:

KillinTime2792 wrote:ye a working slomo button would be nice

also bring it back to 40 fps (YT can't handle 60fps videos anyway) so it'd be nice to see everything at the same speed as before

also also can we have a pause/rewind button?

Youtube can indeed handle 60fps... That's the frame rate that hd is.

I remember alot of people from tasvideos.org having issues with getting 60fps videos on YT, it always runs them at 40fps.

The physics are different, it's still too fast (46 fps or something) and the counter and stuff don't adjust with the screen size. Could you fix that?

Rafael wrote:The physics are different, it's still too fast (46 fps or something) and the counter and stuff don't adjust with the screen size. Could you fix that?

Trying my best dude, thanks. But don't expect any miracles.

This made me laugh.

1280(I suppose)x720 initial resolution is a good addition, long requested myself and others.

But the 60fps is a reform way too large for permanent implementation imo. It means it will not be compatible with former tracks. This is pretty obvious because of the increase of 50% frames per second, which would interrupt the track flow. It should be incompatible with most tracks.

If it, in spite of the fps counter, is working with older tracks made with 40fps revisions, the "60fps revision" can not be 60fps, unless it is a track of improbable low density.

So the only logical solution is that it in fact has 50% faster play rate, which is a horrible thing!

I'm not saying that further development of the LR revisions is a negative thing, but bouncing up to 60fps ... no, it's not right. At least, not before a new version is made, like from the evolution from Beta to Beta 2. And that is currently very unlikely to happen.

aspi33 wrote:This made me laugh.

1280(I suppose)x720 initial resolution is a good addition, long requested myself and others.

But the 60fps is a reform way too large for permanent implementation imo. It means it will not be compatible with former tracks. This is pretty obvious because of the increase of 50% frames per second, which would interrupt the track flow. It should be incompatible with most tracks.

If it, in spite of the fps counter, is working with older tracks made with 40fps revisions, the "60fps revision" can not be 60fps, unless it is a track of improbable low density.

So the only logical solution is that it in fact has 50% faster play rate, which is a horrible thing!

I'm not saying that further development of the LR revisions is a negative thing, but bouncing up to 60fps ... no, it's not right. At least, not before a new version is made, like from the evolution from Beta to Beta 2. And that is currently very unlikely to happen.

60 frames per second is fine as long as physics stay the same. Which would be difficult. This toy doesn't seem to run as any other game would, where the only noticeable difference would be how much it lags.

I could be wrong, but the game seems to depend on the frames that it uses in order to determine how the physics would work. Bass-ackward concept if what I say is true.

The only thing that would solve this is, as aspi said, a whole new version that has as much difference as beta 1 had to beta 2.

whatever the case, can we get a 40fps version of this that doesn't mess up tracks?

HG42 wrote:

aspi33 wrote:This made me laugh.

1280(I suppose)x720 initial resolution is a good addition, long requested myself and others.

But the 60fps is a reform way too large for permanent implementation imo. It means it will not be compatible with former tracks. This is pretty obvious because of the increase of 50% frames per second, which would interrupt the track flow. It should be incompatible with most tracks.

If it, in spite of the fps counter, is working with older tracks made with 40fps revisions, the "60fps revision" can not be 60fps, unless it is a track of improbable low density.

So the only logical solution is that it in fact has 50% faster play rate, which is a horrible thing!

I'm not saying that further development of the LR revisions is a negative thing, but bouncing up to 60fps ... no, it's not right. At least, not before a new version is made, like from the evolution from Beta to Beta 2. And that is currently very unlikely to happen.

60 frames per second is fine as long as physics stay the same. Which would be difficult. This toy doesn't seem to run as any other game would, where the only noticeable difference would be how much it lags.

I could be wrong, but the game seems to depend on the frames that it uses in order to determine how the physics would work. Bass-ackward concept if what I say is true.

The only thing that would solve this is, as aspi said, a whole new version that has as much difference as beta 1 had to beta 2.

You are completely right in that the physics relate on the fps. I am not familiar with any other type of physics calculation, so I am not in position to judge the concept at all. But for Beta 2, we should stay for 40fps imo.

Though, thanks to Rafael for clearing this up for me, you can use a/the 60fps version, which currently has 40fps physics (and has 1.5 times faster playback), and then later on record with the 40fps version, but that would one massive disappointment. And recording in 60fps is no good, no good at all, and is what I feared with this version.

Kevan, your development is utterly positive, and I encourage you to keep on developing. But remember to think twice before releasing something, people will use whatever they get in hands (including me, as I know nothing of AS), whether it's buggy, has bad ideas or has corrupting functions. Just as a thing to keep in mind Keep up your work

aspi33 wrote:
You are completely right in that the physics relate on the fps. I am not familiar with any other type of physics calculation, so I am not in position to judge the concept at all. But for Beta 2, we should stay for 40fps imo.

The 60 fps was more of an experiment. Basically throwing it at the wall and seeing what sticks, and that method always works best for me. Basically the v2 series were only tests, some were happy, but not satisfied. Doing this has given me a better comprehension of the code, which as I've said over and over, is around 2900 lines of code, not including the separate files for line types, scarf, and other stuff.

aspi33 wrote:
Though, thanks to Rafael for clearing this up for me, you can use a/the 60fps version, which currently has 40fps physics (and has 1.5 times faster playback), and then later on record with the 40fps version, but that would one massive disappointment. And recording in 60fps is no good, no good at all, and is what I feared with this version.

again, throwing stuff at the wall. but the original idea of the 60 fps was to create a new set of physics, making it more difficult to run. (more frame positions means highly sensitive contact points) This was supposed to be dubbed "Expert Mode", but the physics stayed exactly the same. It was fairly difficult finding the EXACT number, the one that controls how fast bosh rides, was to be. so hence the 1.5 speed up.... because that was the closest I could get it.

aspi33 wrote:
Kevan, your development is utterly positive, and I encourage you to keep on developing. But remember to think twice before releasing something, people will use whatever they get in hands (including me, as I know nothing of AS), whether it's buggy, has bad ideas or has corrupting functions. Just as a thing to keep in mind Keep up your work

Well thanks dude, and I do think twice before releasing. I try to test these as much as I can by my self, then release a beta to others, fix, test, repeat a few times, then release.

Spoiler: