Exciting news...
-
It's still a few months away but,
INITIAL TESTS INDICATE
UNIT.. GOOD GRIEF!Not that you really need 10k sprites at 1920x1080 at a nice solid 60 FPS!
-
Amazing news!
-
..................wow!
-
chuckle.... low cackle....hearty laugh....full-on maniacal laugh
-
This is really cool. At least we know performance won't be a big deal for [my] small projects. :D
-
That performance is definitely impressive! The sky's the limit! Is this to say that our code will be compiled instead of interpreted? Or perhaps something on the backend is being compiled instead of interpreted, or maybe I've missed the mark :)
-
Yeah, it world be nice with a short explanation If what this actually means...
Also, how will this affect us users, other than a big performance boost? Will everything be backwards/forwards compatible?
-
Well he said bytecode and that normally means it is compiled but still uses an interpreter. Like Java.
-
AFAIK this will not affect the language so programs should be compatible. Programs that use update() to sync should still run at the same speed they are just more likely to achieve 60fps and can do more work between frames.
-
This is great news for the platform, and good to know that this will be coming our way this year-ish :)
So if we use tiles that are larger than 14x14px we can fill the screen with sprites of them without issues :D@pianofire are you referring to programs that are using update() to prevent errors about too many operations? Or is this a hint about new commands? (I'm assuming the first :P )
-
@PB____ I was just trying to explain that existing programs won't run faster but they may run smoother and in future you will be able to do more without dropping frames. Perhaps I didn't phrase it very well!
-
Oh, that makes sense :) I was just seeking too much behind the mentioning of the syncing mechanism :)
-
60hz is always going to be the top limit, but there’ll be fewer frame drops if you have a lot going on. This is good news for me! How much faster is it than what we have now? What’s the framerate for 10,000 bouncing 80x80 images at 1080p, can anyone test?
-
I've written the code from the video and with that exact code I'm mostly at 20 fps (sometimes dips to 19.9 :) )
-
On the current version, I managed to win up to .5 fps by changing
dx[i] = -dx[i]todx[i] *= -1(it saves one time accessing the array) and doing the same for dy[i]... -
Great work guys (@Luke in particular of course) !!
@toxibunny said in Exciting news...:
60hz is always going to be the top limit, but there’ll be fewer frame drops if you have a lot going on. This is good news for me! How much faster is it than what we have now? What’s the framerate for 10,000 bouncing 80x80 images at 1080p, can anyone test?
Just to quote Jon: "It's still a few months away" - I'm sure more details will follow in due course...
-
Can't wait to try this out on some of my projects.
A few can barely muster 10 fps so hopefully this will speed up the whole code base.
Well done and good luck.
In the mean time I'll try for some more speed the old fashioned way ... -
I know a couple of my games were dropping to 25/26 FPS a large amount of stuff is happening all over in the program so hopefully I can revisit them probably due to the way I was coding it but this will be a good test to see.
-
A few months away gives us time to do good stuff now, and then souped-up sequels later on. New Super Fuzeotron X 3D is going to be epic!
-
To all the team this looks phenomenal.
I remember the change with Amos Compiler at times was insane
