798 replies to this topic

[Bomb Bloke]

Heh, I'd had a hunch something was a bit fishy about that image:



I'm looking forward to Redirection, too.

Edited by Bomb Bloke, 10 February 2016 - 11:25 PM.

[apemanzilla]

Bomb Bloke, on 14 October 2015 - 10:18 PM, said:

Heh, I'd had a hunch something was a bit fishy about that image:



I'm looking forward to Redirection, too.

Ahh, so that's what it is! I had inverted the colors but hadn't recognized it

[Zambonie]

apemanzilla, on 14 October 2015 - 10:29 PM, said:

Bomb Bloke, on 14 October 2015 - 10:18 PM, said:

Heh, I'd had a hunch something was a bit fishy about that image:



I'm looking forward to Redirection, too.

Ahh, so that's what it is! I had inverted the colors but hadn't recognized it

May I ask what it is? I still can't reconize what it is lol.

[Bomb Bloke]

Click on it.

[CaosTECH]

xD

[oeed]

I know there's already been a little discussion of the code Dan used in the video, but I wanted to take a look for myself and I might as well post about it anyway; so will probably be some repeated stuff here.

It looks for certain that those 'devices' from the fake bios loading screen are in fact real. He used a GPU, keyboard and speaker. Loading uses this syntax.

gpu = device.get("gpu")

There's also something which puts the program in fullscreen which hides the multishell bar. Not sure how well work that in our operating system, probably ignore it I'd imagine.

window.setFullscreeen(true)

Then the CPU can set a target, which leads me to believe that the GPU isn't actually the thing that is in control of drawing the individual pixels, it's more of a fancy paintuils API.

gpu.setTarget(window.getImage())

There are a ton of GPU functions which I'm not going to look in to much, they're clearly for games, but there are things like image loading and image rotation; so once again it does look like it's a bit like paintutils. It looks like it can load spritesheets too which is nice for games.

One of the best things I noticed was the minimum timer time looks like it's 1 / 60, meaning 60 FPS is theoretically possible. I tweaked our emulator and tried it with Silica. Animations are certainly smoother. It can maintain 60 frames per second when idle, but duration animation it was dipping between about 35 and 25. Hopefully we'll be able to speed that up, and it might be a ton quicker if CraftOS 2.0 uses LuaJIT or something that's not LuaJ.

os.startTimer(1/60)

We've got key checking, as was requested a little earlier, which is a good sign for games. I'm hoping/praying that Dan has a similar thing for the mouse so we can have mouse hovering interactions (I need to hide those close buttons until needed Dan! )

if keyboard.getKey(keys.q) then

And obviously we've got sounds! I'm really hoping that this will let us do more than just play single sound effects. I'm planning to make a music player that will hopefully be able to play reasonable quality songs, although I know pretty much zero about sound, so all those attack, vibrato stuff is completly foreign to me.... fingers crossed. Here's a sneak peak of a serverly under-baked mock up...

speaker.play(sfx)

And there's a colour mapping function which I think was discussed a little earlier, but seems a little bizzare... jury is still out on that one.

Edited by oeed, 19 October 2015 - 11:39 AM.

[LDDestroier]

Sprite sheets? Potential 60 FPS? GPU functions?

Does that mean that FCEUX can be ported to CC in the future?

[MKlegoman357]

oeed, on 19 October 2015 - 11:39 AM, said:

One of the best things I noticed was the minimum timer time looks like it's 1 / 60, meaning 60 FPS is theoretically possible. I tweaked our emulator and tried it with Silica. Animations are certainly smoother. It can maintain 60 frames per second when idle, but duration animation it was dipping between about 35 and 25. Hopefully we'll be able to speed that up, and it might be a ton quicker if CraftOS 2.0 uses LuaJIT or something that's not LuaJ.

os.startTimer(1/60)

While watching the video I came to the conclusion that there is no limit, as there shouldn't be. So if you optimize your game enough then it should run on a few hundred or even thousand FPS, depending on your computer.

[Bomb Bloke]

... if you optimise enough, then the draws per second should go down to match the rate of the actual changes you need to draw on screen. 60FPS when "idle" explains why you might only be getting ~30 when things are "animating": you're wasting time by re-processing stuff that's already on the screen.

Any program doing a few thousand FPS is massively inefficient; sure, with some (eg 3D engines - not OSes!) it's impractical to keep track of what needs to be drawn and what doesn't, but even those apply frame rate limiters if their developers have an ounce of sanity. There's no benefit in cranking frame output way past the refresh rate of any monitor, not unless you want to use your computer as a foot-warmer or something.

Speaking of which, it annoys the heck out of me how gamers tend to confuse FPS stutter with "lag". But I digress...

[CraftedCart]

Here's a concise roundup of everything so far
(Still WIP, comment stuff that you want to add)
https://docs.google....dit?usp=sharing

[Konlab]

If your minecraft is running at 20FPS constantly any chance to get 60 FPS from computers?

[Bomb Bloke]

CraftedCart, where are you getting a resolution of 280px x 175px from? I still say it's effectively 320x200, and Dan's comment here strongly supports that.

Edit:

Actually, I've gone and linked to me quoting where you got those figures from. Go figure.

Edited by Bomb Bloke, 19 October 2015 - 02:39 PM.

[CraftedCart]

Bomb Bloke, on 19 October 2015 - 02:36 PM, said:

CraftedCart, where are you getting a resolution of 280px x 175px from? I still say it's effectively 320x200, and Dan's comment here strongly supports that.

Oh, I just did a search through the topic and 280x175 was one of the things I saw...

[oeed]

Bomb Bloke, on 19 October 2015 - 02:09 PM, said:

... if you optimise enough, then the draws per second should go down to match the rate of the actual changes you need to draw on screen. 60FPS when "idle" explains why you might only be getting ~30 when things are "animating": you're wasting time by re-processing stuff that's already on the screen.

The way Ben made the animation system was to have it update once a frame, so as often as possible. We've basically got it redrawing whenever something changes, so that's why it's fine when idle. The FPS is capped at 60, it could probably be a ton faster. We'll look in to minimising the processing though.

[Waitdev_]

hmm... HD nyan cat at 60fps.

Konlab, on 19 October 2015 - 02:34 PM, said:

If your minecraft is running at 20FPS constantly any chance to get 60 FPS from computers?

what if its not minecraft though?

[Konlab]

Wait_, on 20 October 2015 - 10:28 AM, said:

hmm... HD nyan cat at 60fps.

Konlab, on 19 October 2015 - 02:34 PM, said:

If your minecraft is running at 20FPS constantly any chance to get 60 FPS from computers?

what if its not minecraft though?

I heard that It's not minecraft
But what is it then? A real OS?

[LeDark Lua]

Real os: YAY!
Standalone program: YAY!
Mod: Not so much YAY.

[Creator]

It is not a real OS since Dan was running it on an Apple computer.

[LeDark Lua]

Or In an emulator for OS You will never know.

EDIT: Actually you will know, when he releases it

Edited by LeDark Lua, 21 October 2015 - 05:32 PM.

[Creator]

Pretty sure it is a standalone program.