MakeCode Arcade demoscene?

Arcade
, , ,
61

@Astronomicality22 afraid not! only 16 colors can be on screen at any given time

2 Likes
62

Why’s that?

1 Like
63

Is it because it takes too much memory to have different palettes at once?

1 Like
64

@Astronomicality22 yup, it’s memory once again! Specifically, arcade works by keeping two copies of the screen image in memory at all times. One screen is used for running the actual hardware screen (let’s call this the background screen image) and the other is used for drawing to (let’s call this the render screen image).

Every frame of a game, we first run physics, game code, controls, etc. (detailed docs here). Then, all the sprites get drawn to the render screen. Finally, we swap the render screen with the background screen and the process starts over again.

The reason we do it this way is to make the screen update smoothly. The screen refreshes very quickly, so we can’t guarantee each frame that we will have finished rendering all of the sprites to the screen before it comes time to draw to the hardware screen again. Having a background screen makes it so that we have something to draw to the hardware screen while the render for the current frame is still incomplete. This is called double buffering and is a very common practice for driving hardware screens.

One side effect of this, though, is that we can’t keep around any special information like which region of the screen should be drawn with which palette. At the end of the day the background screen is an image with 16 colors just like every other image in arcade. If we wanted to store extra color information we would have to double it at least, and that would be an extra 20kb of memory gone.

2 Likes
65

But, is it possible to make a layering system to work on the hardware? So, say, if i had turquoise and green, I could layer, and make the colors intentionally clash, making a greener shade of turquoise?

1 Like
66

I agree, so i’m not limited to my singular 16-color palette if I want to make a demo, so I could have 64 colors on screen, but it would just depend on the scan-line.

1 Like
67

Wait, so it registers code on a set amount of cycles, then all the video and sound data get rendered in another set amount of cycles? Wouldn’t it be more efficient to combine the video and audio data and code for a character into one cycle, separately? Or, just have the screen not refresh so fast, but at a consistent enough speed?

1 Like
68

Wait, so it registers code on a set amount of cycles, then all the video and sound data get rendered in another set amount of cycles? Wouldn’t it be more efficient to combine the video and audio data and code for a character into one cycle, separately?

I’m not exactly sure what you mean by this, but I can say that partially redrawing the screen instead of double buffering is much less efficient and more complicated to implement. Double buffering is what everyone does.

Also, we don’t really control the screen refresh rate, it’s set by the hardware itself. Arcade games do run at a variable frame rate, but that is independent of the screen refresh rate.

1 Like
69

Oh. So, say, an extension that throws an error if you run it on hardware, can add extra video and audio capabilities is more what I’m needing?

1 Like
70

@Astronomicality22 theoretically we could make that happen, but it would be a lot of work. We try to keep all the code that runs on hardware/browser the same as much as possible, so a lot of arcade is pretty hard coded with 16 colors in mind. I don’t see us changing that anytime soon.

Something like what @Brohann is proposing would be easier to implement, but you couldn’t do it in an extension today. We’d have to add support in the simulator. Feel free to open an issue for this on https://github.com/microsoft/pxt-arcade

I will say, though, that power-user only features like this are usually lower on our list of priorities. I’m not saying that it will never happen, just that we have a lot of stuff that we’re trying to pack into the next release!

1 Like
71

For now, though, I will use my ega color palette, and if someone sees a game with an ega color palette, they’ll figure out who did it.

1 Like
72

Wait, was it premature to start holding my breath for this?… :wink:

2 Likes
73

hehe your fake wireframe demo has nothing on me

4 Likes
74

Wireframe is just the basic lines of a 3d polygonal shape, not an actual 3d model.

2 Likes
75

umm… no

wireframe is a skeletal three-dimensional model in which only lines and vertices are represented.

2 Likes
76

Well, actually…a wireframe can be either. It’s also evolved to mean “a simplified version” of anything. You’re both correct. Conversation over.

3 Likes
77

Nice, @Brohann!

With all the great stuff/snippets around on the forum, aren’t you gues really pretty close to compiling a demo soon and making a first competition entry for MakeCode in a demo party?

Just to rattle the usual crowd, I was hoping @richard, who clearly also is interested in the subject, would make a contribution, too, so that we could have an official Microsoft representative in a cool scroller text, which might also be “a first”?

2 Likes
78

Someone can make the spinning rat meme with this

2 Likes
79

Giant leaps in voice synthesizing, which could be great for a demo!:

Courtesy of a new legend: @chembot

1 Like
80

Very fair; you see this with minecraft updates. The redstone (ingame programming) community is always begging for HUGE overhauls that would remove the biggest challenges, but that isn’t necessarily the best update!
Limitations drive creativity. Implementing an asset manager to change colors inspired innovation in a way that destroying the 16-color system never would. Props to the team!

2 Likes