Updates YOU want to see in Makecode

Forum Feedback
, , , ,
202

image

  1. should be added and support
  2. what is so unreliable because for pixel per frame it would be better for people with better computer to run the game better and pixels per second is super reliable
203

elaborate on no sound and visual updates please, so would it be in the editor where the visuals donā€™t change or, in the simulator they donā€™t change, same with the no sound

1 Like
204

I was just thinking of the editor since you can just hide the sim

1 Like
205

Maybe try turning off your wi-fi? works like a charm for me!

2 Likes
206

the average 2D game engine (and the average retro game that makecode arcade is trying to replicate), uses a pixels per frame velocity system, for good reason.
pixels per second sucks for EVERYTHING. it causes insane inconsistencies with games because of the lack of optimization, and any bit of lag would instantly break the game loop. coneā€™z broken bonez and coneguyā€™s christmas bash, for example run terribly on mobile devices with the player object being sent at unnecessarily high speeds because of the low FPS.
these 2 issues were the only reason coneā€™z broken bonez, alongside AUAPTMR switched engines.
ā€œsuper reliableā€ is not REMOTELY ACCURATE. iā€™ve quit makecode entirely, and every time i think of coming back, i am reminded of the completely unreliable mess that is pixels per second. i had a sonic engine recreation in works, cancelled. i was making an AUAPTMR remaster, cancelled. i was making coneā€™z broken bonez, moved engines.
what iā€™m getting at is : pixels per frame is more reliable than pixels per second in every way.
no, man. people arenā€™t gonna make hyper advanced games with whatever insane deltatime stuff newer games have. weā€™re making the game maker games, the 2D classic ones. you know, the super mario bros and the sonic master systems. this one change could make makecode arcade a much more reliable engine, instead of making itself motivation to make a retro engine in scratch just to work in the same limited conditions, except with significantly better features. yes, i thought of that.

3 Likes
207

Dude, you got em mixed up. P/second does not rely on frame rate. Also, thereā€™s an extension to get the raw delta, decide that by 1000 I think and it gives you seconds since last frame.

2 Likes
208

if you played either CBB or CCB, youā€™d see the results.
pixels per second does get affected by framerate. at slower framerates, the game sends the object at a higher speed to make up for the lost time. and yes, iā€™ve tried the deltatime solution. does not work.
the lone addition of pixels per frame would also allow making the implementation of PPS completely optional, although not necessary.
just add it and make it a toggle. best of both worlds, really. the 2 games iā€™ve mentioned show just how badly this velocity system affects makecode games.

3 Likes
209

Ok, youā€™re clearly better informed than me.

1 Like