It would probably work on a high end computor/simulator or hardware, but thats the fastest I can do without lagging and freezing on my pc. This is kinda what I meant, just not the best.
2 Likes
It’s not very functional though…
It would be really cool if you could have a sprite pallet and a tilemap palette, so when it draws the tilemap and background, it uses the one palette, but immediately switches to the sprite palette, and draws the sprites in that palette. But as you said, this probably isn’t easily possible to achieve without reworking the Arcade rendering engine…
How I assume the renderer works though (take this with a grain of salt), is that Arcade draws the values all sprites and the tilemap/background to a matrix (a 2d array) of hex values to make a scene, and the final step for rendering is putting that matrix on the screen using the current palette. This would mean that adding any other colors in a frame would require extra data, taking extra memory, and making less memory for game mechanics, especially for hardware. This is just a guess on how Arcade’s renderer works, bc I haven’t looked at the code at all, so @richard plz tell me if I’m right lol!
Yeh, my pc starts bugging out after 19 ms, pretty much anyone elses pc would do better probably lol
My iPad started getting really hot…
1 Like
Preparing for takeoff
GTX 1650 SUPER + Ryzen 5 2nd gen w/ 16GB of ram and it’s still bugging out. I don’t think it’s a performance issue
Yeh, the idea was a bit farfetched to begin with…
that’s basically right! the screen isn’t a 2d array though, it’s a buffer where each pixel is represented with 4 bits, so each byte contains the data for 2 pixels. Using 4 bits means you have at most 2 ^ 4 colors, hence the 16 color limit.
we actually double buffer the screen to make drawing smoother and prevent tearing, so there are two screens floating around at any given time: the screen that is actually being drawn and the one that the screen variable is pointing to. since each screen is 160x120 pixels, that means the total number of bytes per screen is 160 * 120 / 2 = 9600 bytes or roughly 10kb.
If we look at the meowbit, it uses the STM32F401RET6 processor which has 96kb of RAM available. With two screens, we’re already using about 20kb of that and the rest goes to CODAL (basically the “OS” we use) and the user’s code.
If we wanted to support more colors, we could, say, use 1 byte for each pixel instead which would give us 255 colors. However, that would cause us to use twice as much memory and leave very, very little left over for the user’s program.
2 Likes
also worth mentioning that tilemaps use 12 bits for each tile location. That means you can have up to 255 different tiles in a map (the other 4 bits are used for metadata like if a location is a wall or not).
this is okay, though, because tilemaps are usually much smaller than 160x120 and also usually aren’t edited at runtime. if you never edit a tilemap or image at runtime, it never gets loaded into memory. instead its value is read from the same place the code is read from. the second you set a pixel or change a tile, however, the tilemap/image gets copied into memory and starts counting towards your total space.
2 Likes
and sample sound effects
It’s just something I think would be a good idea to make a mode where makecode is 16 bit where the screen size is double and there are 256 including transparency colors it could make for some nice games.
yeh, i manually set it to 19 ms, if you want you can try get it lower; whenever I go lower, the simulator just wants to lock onto the steampunk colours for a while before going again
So, if we have two buffers, what would be stopping us from having the buffers use different palettes? Then the different buffers have ‘gaps’ in them, where the other buffer fills with a new colour. The fact that palette changes are possible to begin with implies the hardwares screen itself is not limited to 15 colours, but can the screen actually show more than 15 if we were to remove the hardcoded limit or are they custom screens with this limitation in place?
The hardware is fully capable of displaying full 16(*?) bit color images, except that MakeCode has an artificial limitation that will most likely not change, for performance reasons. If you use a different programming language such as CircuitPython or Arduino or something else, they can draw any color bitmaps to the screen.
* I do not remember if the screens used support 16 bits or more. Either way, it is much more than 16 is supported.
… So what file blocks the colour limit? In the explorer, I mean?
that’s a complicated question… there isn’t one file that has a variable like const maxColors = 16. supporting more colors would involve huge changes to arcade in many different files throughout the screen and game libraries.
I will take the challenge
2 Likes
if you do it I will try to make earthbound