Conversation

Notices

1. Foone🏳️‍⚧️ (foone@digipres.club)'s status on Thursday, 09-Nov-2023 06:20:00 JST Foone🏳️‍⚧️

   so given that my "write a bison/flex parser for a flag DSL" project has stalled, I think I'm gonna cheat and start with the bytecode for it first.

   • Foone🏳️‍⚧️ (foone@digipres.club)'s status on Thursday, 09-Nov-2023 06:22:33 JST Foone🏳️‍⚧️

     in reply to

     it's surprisingly simple. You've got a Command, which is one of the following opcodes:
     Rectangle, Triangle, Quad, Ellipse, Polygon, PolygonOutline, ThickPolygonOutline, Lines, ThickLines, Star, VGAPlane, Palette, EndCommandList.

   • Foone🏳️‍⚧️ (foone@digipres.club)'s status on Thursday, 09-Nov-2023 06:25:26 JST Foone🏳️‍⚧️

     in reply to

     they mostly have simple fixed lengths. like Rectangle is followed by two Points and a Color.

     A color is a 3-byte RGB value, a point is two 16-bit integers.

   • Foone🏳️‍⚧️ (foone@digipres.club)'s status on Thursday, 09-Nov-2023 06:27:47 JST Foone🏳️‍⚧️

     in reply to

     the only tricky ones are the Polygon ones, which take a color and then a list of points. As currently written in the code that's just "read until you find a point that's (-1,-1)". I may switch that to having a length value in the bytecode, to make the format nicer

   • Foone🏳️‍⚧️ (foone@digipres.club)'s status on Thursday, 09-Nov-2023 06:30:22 JST Foone🏳️‍⚧️

     in reply to

     and then the file will need a metadata section. Basically just a couple of key-value pairs, which are all ASCII strings, plus some optional data: text size, text layout (a 3-way enum), and text color.

   • Foone🏳️‍⚧️ (foone@digipres.club)'s status on Thursday, 09-Nov-2023 06:32:43 JST Foone🏳️‍⚧️

     in reply to

     maybe just make new commands for that?
     like TEXT_LAYOUT/TEXT_SIZE commands that take integers, and a TEXT_COLOR command that takes a color.
     Then a METADATA command that takes an integer (to select what kind of metadata it is, out of shortname/name/credit/aliases), and then a string. stick a length byte on that one, too.

   • Foone🏳️‍⚧️ (foone@digipres.club)'s status on Thursday, 09-Nov-2023 06:36:33 JST Foone🏳️‍⚧️

     in reply to

     This'd let me write a simpler parser that runs on modern systems and compiles to the bytecode which I can then run on DOS, and later get around to writing a native parser.

   • Foone🏳️‍⚧️ (foone@digipres.club)'s status on Thursday, 09-Nov-2023 06:39:31 JST Foone🏳️‍⚧️

     in reply to

     this also uplifts some of the "tricky bits" to the bytecode compiler: The points in the commands aren't given simply, they're a weird format that takes a direction, an index, and a number, like "Left(1,4)"
     This means (0,120)

   • Foone🏳️‍⚧️ (foone@digipres.club)'s status on Thursday, 09-Nov-2023 06:42:11 JST Foone🏳️‍⚧️

     in reply to

     The way it works is that you're picking a side (left in this case, so the x coord is 0), and then saying item 1 out of the screen divided into 4 parts.

     Since the screen is 640x480, that means a y coord of 120

   • Foone🏳️‍⚧️ (foone@digipres.club)'s status on Thursday, 09-Nov-2023 06:43:51 JST Foone🏳️‍⚧️

     in reply to

     this makes sense when a human is writing flag definitions:
     You're saying "out of a 4-stripe flag, give me the x,y coordinate of the top of stripe 1"

   • Foone🏳️‍⚧️ (foone@digipres.club)'s status on Thursday, 09-Nov-2023 06:45:05 JST Foone🏳️‍⚧️

     in reply to

     but in the bytecode, none of that matters. it can just hardcode (0,120), because our resolution is 640x480 and always will be.

   • Foone🏳️‍⚧️ (foone@digipres.club)'s status on Thursday, 09-Nov-2023 06:46:41 JST Foone🏳️‍⚧️

     in reply to

     and when I eventually build SVGAPride or something, I'll be able to reprocess the DSL source to generate different bytecode, so there's no reason to overly future-proof it at this point.

   • Foone🏳️‍⚧️ (foone@digipres.club)'s status on Thursday, 09-Nov-2023 06:49:59 JST Foone🏳️‍⚧️

     in reply to

     even though the "future" I'm talking about is like 1988.

   • Foone🏳️‍⚧️ (foone@digipres.club)'s status on Thursday, 09-Nov-2023 06:54:13 JST Foone🏳️‍⚧️

     in reply to

     • Jeremy Nickurak

     @atrus you wanna try to render that in a 640x480 at 16 color display?!

   • Jeremy Nickurak (atrus@toot.cafe)'s status on Thursday, 09-Nov-2023 06:54:14 JST Jeremy Nickurak

     in reply to

     @foone and give up the potential for infinitely-sided polygons? 😂

   • Foone🏳️‍⚧️ (foone@digipres.club)'s status on Thursday, 09-Nov-2023 06:59:17 JST Foone🏳️‍⚧️

     in reply to

     this kind of decoupling will also make it easier to experiment with more smarts in the compiler. Instead of having to copy-paste some values, what if a flag was defined like:

     HorizontalStripes{
     RGB( 91,206,250)
     RGB(245,160,194)
     RGB(255,255,255)
     RGB(245,160,194)
     RGB( 91,206,250)
     }

   • Foone🏳️‍⚧️ (foone@digipres.club)'s status on Thursday, 09-Nov-2023 07:03:25 JST Foone🏳️‍⚧️

     in reply to

     how many stripes? the compiler can count. How wide are the stripes? the screen height divided by the number. They're horizontal. You just tell it the colors. Bam, trans flag.

   • Foone🏳️‍⚧️ (foone@digipres.club)'s status on Thursday, 09-Nov-2023 07:05:51 JST Foone🏳️‍⚧️

     in reply to

     this division also makes it easier to do, like, symbolic naming. So the above could be even simpler:

     boy=RGB(91,206,250)
     girl=RGB(245,160,194)
     other=WHITE
     HorizontalStripes{
     boy
     girl
     other
     girl
     boy
     }

   • Foone🏳️‍⚧️ (foone@digipres.club)'s status on Thursday, 09-Nov-2023 07:34:03 JST Foone🏳️‍⚧️

     in reply to

     • cliffordheath

     @cliffordheath yeah I need SVG but optimized for size (I need my whole program under like 300kb) and to compile for DOS, using Borland Turbo C++ 3.x

   • cliffordheath (cliffordheath@mastodon.social)'s status on Thursday, 09-Nov-2023 07:34:04 JST cliffordheath

     in reply to

     @foone You seem to be trying to reinvent SVG. Would you like some help with that?

   • cliffordheath (cliffordheath@mastodon.social)'s status on Thursday, 09-Nov-2023 08:19:35 JST cliffordheath

     in reply to

     @foone I implemented basically that, in 1994 as part of OpenUI, which ran (e.g. the NASDAQ trading system) on 486 DX2's with 8MB and Windows 3.1

   • Foone🏳️‍⚧️ (foone@digipres.club)'s status on Thursday, 09-Nov-2023 08:19:35 JST Foone🏳️‍⚧️

     in reply to

     • cliffordheath

     @cliffordheath very cool! right now I'm just hardcoding it as C++ source, but as this thread explans, moving it to a bytecode/DSL is what I'm working on right now

   • Foone🏳️‍⚧️ (foone@digipres.club)'s status on Friday, 10-Nov-2023 07:44:50 JST Foone🏳️‍⚧️

     in reply to

     • Peaceful Assembly Robot

     @StompyRobot color first makes sense.
     As for fill/stroke, I handled that by having two different commands for the one shape where I need both styles

   • Peaceful Assembly Robot (stompyrobot@mastodon.gamedev.place)'s status on Friday, 10-Nov-2023 07:44:51 JST Peaceful Assembly Robot

     in reply to

     @foone recommend taking the color first in all commands.

     Also, do you have "stroke" versus "fill" options? Or are they always filled with no strokes?