Skip to main content

It was fun to try and solve today's #LoveByteTCC without a means to peek/poke at the framebuffer. I mean, I could add a .Screen/peek port, but where's the fun in that. Instead, I've drawn a texture in memory and repaint in on change. 118 bytes without the sin table.

https://tcc.lovebyte.party/day9/

The Ninth Day of Tiny Code

Tiny Code Christmas - Day 9 Welcome to Day 9 of Tiny Code Christmas! If you’re just joining us don’t forget to check out the overview, and start at Day 1! You can start whenever you like, there are no deadlines! Today we’re look at a classic shadebob…
Tiny Code Christmas
#lovebytetcc
in reply to Devine Lu Linvega

Andy Alderwick
Andy Alderwick
• •
haha, that's the first time I've seen an oldskool demo where the mouse pointer comes in and draws a cheeky doodle :flan_writing:
in reply to Devine Lu Linvega

floatvoid
floatvoid
• •
I was thinking about recently, how the system could use a path for an external graphics device. Something like a PPU or vector display. A standard for emulators to add 'native' extensions on the host side.
in reply to floatvoid

Devine Lu Linvega
Devine Lu Linvega
• •
@floatvoid are you familiar with the DEI/DEO opcodes and Varvara devices? Someone could connect a full color display to it if they need yeah 😀
http://wiki.xxiivv.com/site/varvara.html

XXIIVV — varvara

wiki.xxiivv.com
@floatvoid
in reply to floatvoid

floatvoid
floatvoid
• •
in fact,

I modified moogle.c to take drawing commands from stdin

MOVE 2 4
COLOR 3
SPHERE 30 10 2

so you can read a file on launch or pipe a stream and have an animation. I could imagine some route to passing that buffer back with a file the varvara system to.
in reply to floatvoid

Devine Lu Linvega
Devine Lu Linvega
• •
@floatvoid ah yes, varvara uses the console/read port for that 😀 It's also how I send event from orca to a second program that translates to midi.
https://git.sr.ht/~rabbits/shim

~rabbits/shim - sourcehut git

git.sr.ht
@floatvoid
in reply to Devine Lu Linvega

Albert
Albert
• •
have you considered adding a way to point the screen to a memory address (for the whole frame)? Or is that how you do the repaint already?
in reply to Devine Lu Linvega

Albert
Albert
• •
nice! Sounds like you created your own framebuffer then. (:
in reply to Albert

Devine Lu Linvega
Devine Lu Linvega
• •
@albert yup, there's a limit to the screen size I can keep in memory tho, but 2-bit pixels in 64kb can store quite a lot 😁
@Albert
in reply to Devine Lu Linvega

Albert
Albert
• •
ha, nice! What's the maximum output resolution of the VM?
in reply to Devine Lu Linvega

Albert
Albert
• •
ahh, I meant screen size. Since 64KiB @ 2 bits per-pixel, would be something like 512x512 framebuffer, which sounds pretty decent. Although I guess most programs wouldn't want to spend all available memory on that. (:
in reply to Albert

Devine Lu Linvega
Devine Lu Linvega
• •
@albert Oh maximum framebuffer size, yes. But I also think in most cases it wouldn't need a whole screen's data. Maybe just like the viewport or something, but yes, it does take away lots of space for the actual program. For demoscene stuff like this tho, it's perfect.
@Albert
in reply to Devine Lu Linvega

Lovebyte Demoparty
Lovebyte Demoparty
• •
Really cool approach (as usual, but as long as you keep doing cool stuff we have to keep telling you). 🤩

Lo, thar be cookies on this site to keep track of your login. By clicking 'okay', you are CONSENTING to this.

⇧