- should be added and support
- 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
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
I was just thinking of the editor since you can just hide the sim
1 Like
Maybe try turning off your wi-fi? works like a charm for me!
2 Likes
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
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
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
Ok, youāre clearly better informed than me.
1 Like
A feature that Iāve recently been thinking about is the fullscreen simulator.
I think it would be nice to have an option to hide the controls and make the actual game take up the screen.
Unless that already existsā¦
3 Likes
I think that thereās a setting under the little window on the far left of the site in the editor for a full fullscreen.
1 Like
Try this
this should work
3 Likes
True Multiplayer not splitscreen. (This one probably will be hard to implement right now)
2 Likes
Uh, maybe like soft bodies or something, specifically for moving platforms and such.
And especially with separate player cameras
a repeat until block would be so useful
1 Like
is that not a while loop?
4 Likes
A (number) to (number) block too! (Not pick random!)
yes, but up until quite recently (sometime last year) I didnāt know how to use that properly, so I thought about it for quite a while, and I feel like some people new to makecode wouldnāt know that.
2 Likes
cloud variables so i can make a global leaderboard for my school project
3 Likes
I dont expect this to be seen considering how late i am but an āon song finishā block, i dont want to be forced to put an entire song into 1 code block as its harder for me to edit
1 Like