Tuesday, September 08
- Chrome just crashed, take the entire Daily News Stuff with it. Yay. It did save the title. Thanks Chrome.
- QB64 is an open-source QBasic-compatible compiler for Windows, Mac, and Linux. (QB64.org)
It looks pretty good. Only major weirdness is that to maintain strict compatibility all the extension commands start with _.
This looks like the perfect place to start with Imagine Basic. Write a compiler that supports a subset of QB64, written only in that subset, and targeting Imagine assembler. Write an Imagine assembler in that same subset. Just like that, I'll have a self-hosting compiler.
Anyone got a good Write your own Basic compiler in Basic guide? The assembler I can handle.
- Civilisation* has been announced for the Imagine!
By pure serendipity this tileset was released today. (Itch.io)
It's part of a bundle that includes all kinds of neat stuff and which I immediately purchased. I also tried to support the designer on Patreon but Patreon won't let me log in because they're retarded.
Other titles announced for the Imagine include CitySim:
I don't know how well these will fit into 128k of RAM. The original SimCity did come out on the Commodore 64, so that's a datapoint. I may have to lose the unit and water animations unless you have the Imagine 1000D model with 256k; it will be interesting to find out.
These tilesets are nice because they are complete; they provide all the graphics you need including things like leader avatars and UI frames. A lot of the graphics sets on Itch.io provide one thing only - here's a forest, good luck with the rest of your game. The other notable exception to this is if you buy the complete Time Fantasy bundle which contains about twenty compatible tilesets, plus objects, plus dozens of animated sprites for heroes, NPCs, and monsters.
Graphics on the Imagine should look much like that
though only about half that height - those screenshots are 512x512 and the Imagine runs at 480x270well what do you know: Graphics on the Imagine should look about twice that good. I took one of those images, zoomed in, and added some 1x1 pixel dots just to confirm what my eyes were saying, and those screenshots are zoomed in at 2x at the pixel level (plus whatever your browser does to make them big enough to see).
So those sample screenshots represent roughly half an Imagine screen. That's pretty good; I can certainly see a game being enjoyable at that scale. (And after all, Kairosoft games run at 320x200 and I've played the hell out of those the last few years.)
* Any similarities to games spelled with a Z are purely coincidental.
Speaking of Imagine graphics I added another graphics mode that I thought up when I was looking at doing this in hardware on an embedded Arm chip.
Basically it's half-resolution - 240x270 - in 512 direct colours. That uses 9 bits from our 10 bit byte, so if you set the 10th bit to 1 it splits the pixel into two 16 colour full-resolution pixels. You can freely mix low resolution in full colour with high resolution in limited colour, so for example the ocean in that last screenshot can be shaded exactly how you want.
Update: That leaves 256 values out of 1024 unused. I was wondering what to do with them then realised the simple answer: We have 32 colour registers, so use those for a second palette of 16 colours. 32 total colours in high resolution, and 512 in low resolution, on the same screen. That's a really nice graphics mode if you're working with tiles and sprites, rather than drawing to a bitmap.
Hardware sprites could use exactly the same mode, except that would limit them to 8 pixels wide (instead of 10). There are 10 sprites so you could pair them for 5 16-pixel sprites per scan line, in up to 512 colours.
I'm also looking at efficient ways to handle 8x8 and 16x16 tilesets, as an alternative to bitmap mode. That could help make these games an imaginary reality. With 16x16 tiles we could steal the sprite buffer and load in the tile indexes - once every 16 scanlines - which would leave the full bandwidth available for that 16+16+512 colour mode above. And still have two sprites left for a cursor. That's probably fine for Civilisation or LoreWards - those tilesets are indeed 16x16 and those games are turn-based and don't need a lot of sprites running around.
(And if we're using the sprite buffer as a general-purpose buffer now, I might bump it up to 64 bytes, the same as the audio chip. That will let you load a 30-wide tile map and 4 16-pixel sprites, all in this new 512 colour mode, which is pretty good for 1983.)
The CitySim tileset though is 8x8 - those buildings are composed of lots of tiles stacked together - and you really want to see the cars and trucks running around. That one pretty much has to be bitmapped.
Also working on an RLL-compressed mode for overlays. Let's say you have a 3d-rendered scene from your spaceship cockpit, but the cockpit itself is drawn in 2d and mostly static. You can draw the 3d view directly to one playfield in high resolution 32 colour mode in VRAM (perhaps with fill mode enabled so you don't need to shade the polygons). Then you can have a mostly-static RLL-mode cockpit overlay, in 16 colour RLL mode, in system RAM.
Thanks to the RLL encoding, the transparent window only only uses 1/16th the normal bitmap memory and bandwidth. You can shape and colour the opaque parts any way you like, while the transparent parts (or any solid colour) cause almost no overhead. The RLL parts would be a massive pain to draw arbitrary updates to - totally impractical on a slow CPU - so the sections with lots of controls or displays you'd want to render as uncompressed scanlines. Any pixels where you don't enable RLL it's just a regular bitmap.
Update: Just realised this is also a brilliant way to extend sprites. An empty full-screen RLL overlay uses 4k of system RAM and about 5% of the system bus. You can even use the display list processor to entirely skip the parts where you don't need software sprites. Or, using that mode from before, but with only 16+512 colours, we can get it down to 540 bytes and 0.4% bandwidth use for an empty overlay. Yeah. This is good. This might be better than actual sprites.
Update update: So lets say if you turn off two sprites you can enable another playfield - after all we're saving the sprite pointer and position registers and the sprite buffer. We can say that sprites 0-5 are always sprites, and 6-7 and 8-9 can be switched for additional playfields. With normal pixel modes we could only do that by using half-resolution and saturating both the VRAM and system RAM buses, but with RLL mode we can do whatever the hell we like. The demoscene would go nuts with this.
The Poco X3 NFC is a pretty good phone for €229. (WCCFTech)
In fact it's a pretty good phone regardless. Snapdragon 732G - two A76 cores at 2.3GHz and six A55 cores at 1.8GHz. 6.67" 120Hz 1080p screen. 64Mpx main camera, 20Mpx front camera, and three other little cameras along for the ride.
6GB RAM, 64GB storage (the 128GB model is another €40), USB-C, headphone jack, and microSD slot. The only box it doesn't tick is apparently wireless charging.
On sale tomorrow in Europe, no news yet for the rest of the world.
Magenta doesn't exist. (Medium)
The article discusses impossible colours and even provides examples - though since they're impossible the examples do require you to do the old stare at the X for thirty seconds without blinking trick. If you manage that, though, you get to see a blue that is darker than black and a red that is brighter than white.
Colour is about one third physics, one third biology, and one third bullshit.
Elon Musk's reading list. (Most Recommended Books)
Max Tegmark, who is great, Sean Carroll, who is also great but who blocked me on Twitter when I pointed out he was talking nonsense about events in Portland, Iain M. Banks - several times, Robert Heinlein, Isaac Asimov, Frank Herbert. Also both Adam Smith and Karl Marx, but that's okay so long as your read them both.
- Chrome fixed copying and pasting URLs.
At some point it started turning URLs into URLs in this editor, so you had to go and un-URL them all. Firefox didn't do that. Now it's stopped doing that again.
Posted by: Rick C at Tuesday, September 08 2020 01:56 AM (eqaFC)
Aha, after looking at his bibliography, I've read Consider Phlebas, as well. It wasn't bad.
I guess you can figure out what year I stopped reading him . . .
Posted by: normal at Tuesday, September 08 2020 06:43 AM (obo9H)
a) Start with the expression evaluator. If you can do expressions, then you can pretty much do everything else. b) Decide ahead of time how you will handle spaghetti Gosub/For/Next/Return situations. c) Given the limited memory, you will probably be parsing every line as you execute it, every time you hit it.
Don't neglect the annoyances of managing the program buffer while editing, and of managing variable memory.
Do as much of this on paper as you can, first.
Posted by: kurt duncan at Tuesday, September 08 2020 11:04 PM (7AkDP)
The plan is to make this a single-pass compiler, along the lines of Turbo Pascal. The compiler itself would be in ROM, instead of the usual interpreter, and will be able to steal VRAM as working space, so it should be able to compile fairly large programs by early 80s standards.
I'm also going to support code modules. HP Basic did that in a simple way - you could load and unload files of interpreted or pre-compiled SUB and DEF FN routines. If (when) I run out of space in the ROM the rest of the functions will end up in library modules like that.
It really needs to be a compiler because I want hobby programmers to be able to produce cool stuff on this without jumping through the hoops real programmers had to do back in the day. Me, for example.
Posted by: Pixy Misa at Wednesday, September 09 2020 12:31 AM (PiXy!)
58 queries taking 0.1886 seconds, 323 records returned.
Powered by Minx 1.1.6c-pink.