#242
Posted 08 October 2015 - 01:26 AM
#243
Posted 08 October 2015 - 02:30 AM
dan200, on 08 October 2015 - 01:11 AM, said:
Oh yeah, I completely agree, although we've already done that really. But hey, let's wait and see.
#245
#248
#249
Posted 08 October 2015 - 04:09 PM
dan200, on 08 October 2015 - 01:11 AM, said:
I know everyone including dan has been talking/hinting about this not being another minecraft mod, but having different tier displays on anything but, wouldn't really make any sense.
Personally I would like to see something on the raspberry pi, but just in case this happens to be minecraft related, i've already made something similar for my raspberry pi 2 with cython and lua bindings.
I'll leave that to your imagination though as I don't want to advert anything on dan's forums.
Edited by Xenthera, 08 October 2015 - 05:29 PM.
#250
Posted 08 October 2015 - 09:50 PM
Xenthera, on 08 October 2015 - 04:09 PM, said:
There are quite a few possibilities as to how it could fit. One of the simpler ones is to think in terms of display modes, which could be changed with a function call - eg.
Back in the day, even if your system supported a decent colour depth, that didn't mean it had enough display memory to implement it alongside a decent screen resolution. And if you wanted to take advantage of display pages (buffers stored in VRAM), then you typically had to cut down on both.
#251
Posted 08 October 2015 - 10:02 PM
#252
Posted 09 October 2015 - 09:21 AM
#253
Posted 09 October 2015 - 11:08 AM
#254
Posted 09 October 2015 - 12:42 PM
I feel like you're making some sort of joke rather than asking for an actual explanation; but I can't tell what the punchline might be.
Edited by Bomb Bloke, 09 October 2015 - 12:43 PM.
#255
Posted 09 October 2015 - 12:43 PM
Creator, on 09 October 2015 - 11:08 AM, said:
There was a suggestion a while ago about keeping the same 16 color system, but allowing those colors to be changed. So one could change blue to be a lighter shade - it would then replace the blue color. This way you wouldn't need to send more packets for different colors, just one packet to tell the client what the color "bindings" are.
#256
Posted 09 October 2015 - 01:11 PM
Annnyway... mmm.
Ben and I have some ideas for something like this... Put it this way, Dan you might have some competition
#257
Posted 09 October 2015 - 01:16 PM
#258
Posted 09 October 2015 - 01:34 PM
Say you're dedicating four bits of memory for every pixel on your display. That allows you to store a fair number of pixels in RAM, but the catch is that four bits only offers 16 combinations per pixel. You can't really define any decent colours with such a small range.
So, you define a separate array which holds your actual colours. Here you use a decent number of bits per value - say 24 - allowing a much larger range of combinations. By using your pixel data as indexes into this array, you've greatly expanded the number of colours you can put on the screen, while still only dedicating four bits per pixel (plus an extra bit of memory for your array of colours - your palette).
ComputerCraft uses four bits for the text colour of a given character, and four bits for the background colour of a given character - eight bits in total. These two values index into a 16 colour palette, which we can't change.
A palette editor makes it possible to use a great deal more colours than is possible within ComputerCraft (somewhere around 16mill, in the case of Dan's 24 bit implementation). Catch is, you can still only use 16 unique colours at a time - as that's the size of the palette.
Back in the day, animations were often produced by drawing a static image, and then simply changing the palette stored in the display card's memory. By cycling the colours that certain indexes referred to, you could, for example, produce a simple series of waves going across an ocean surface, without actually having to directly request that new pixels on the screen be drawn.
#259
Posted 09 October 2015 - 09:11 PM
- File extensions! Programs end in .lua, the palette ends in .pal, and...
- Zip archives! (.zip file visible in the screencap) I'm guessing that this means that he has implemented a way for us to use zip archives, which will be pretty neat!
- Revamped editor - the default "edit" program has a new UI and also seems to be able to edit palette files instead of just text now.
- boot.lua - new on-startup script?
- foo.image and alan.image - extensions for paint files? Or maybe a new format entirely?
Edit: Forgot these
- Improved multishell - edit program shows filename instead of "edit" in taskbar, an "X" button in the top right corner...
- Low-resolution, non standard mouse pointer, that looks like it's part of the system running in the video. Evidence that it's a separate project from CC?
- File named "google", without an extension. Not sure what it could be, maybe a dump of an http request? Possible testing of a better HTTP API?
Edited by apemanzilla, 09 October 2015 - 09:19 PM.
#260
Posted 09 October 2015 - 09:38 PM
apemanzilla, on 09 October 2015 - 09:11 PM, said:
We can do that now (eg, ElvishJerricco implemented this module into GrinGet).
#261
Posted 09 October 2015 - 11:38 PM
2 user(s) are reading this topic
0 members, 2 guests, 0 anonymous users











