Dungeons & Drawing With xTalk

[xAction]

EDIT 02 20 2024 Changed the thread name as the topic evolved
Edit 02 26 2024 Most Recent Stack moved to first post for easy access, old external C program reliant stack removed.

MazeCollectorv8_pbm_only.oxtStack

(291.57 KiB) Downloaded 11 times

MazeCollectorv8.gif (64.54 KiB) Viewed 123 times

So one day ChatGPT and I wrote some C++ and python and lua and FLTK maze programs, then I forgot all about it.
Today i noodled around with a it bit and made a little faceless app that dumps out some data that I siphon into xTalk.
And get these great mazes.

I have another version of the C++ maze program without the broke 'room' mazes, I probably should default to here. Now that I'm about to upload this version and so tired I can't fee my face I think about that.

Anyway here's this, 'viewer' of mazes for the moment. It has the C++ code to write the little application that should live in the same folder as the stack to be called and make mazes to be siphoned. The handler to use the application is disabled here since I didn't want to bundle .exe files along with this stack. You'll get a message and then access to the code which compiles super fast in gcc if you're a way cool coder from the cyber future with compiler tools.

I stripped data from this version, the c++ program spits out a bunch of files, we are only using one kind for display.

I figure something like this could be used for video games....somehow.

[richmond62]

What would be super would be if those mazes could be exported as PNG images with the black as black, and the white as transparency.

[richmond62]

Something quite different to your work is going on as an OXT stack is ending up with a 'foreign' icon in the corner:
-

SShot 2024-02-16 at 14.12.10.png (14.85 KiB) Viewed 300 times

[richmond62]

ALL the black graphic square generated have the same name.
-

SShot 2024-02-16 at 14.15.42.png (169.89 KiB) Viewed 300 times

-
If they all had different names (and their names were all put into a listField), they could be grouped, and a snapshot of the group either imported or exported as an image with transparency.

The coloured borders need to 'go' for grouping into a 'solid' maze.

[xAction]

good catch.

put "x" & item 1 of xy & "y"& item 2 of xy into tBoxName

was how that was supposed to go

MazeCollector_V4.oxtStack

(586.86 KiB) Downloaded 18 times

Now spams your document folder with exported maze images with alpha channel. Too tired to be clean about it.

export1708087828.png (14.69 KiB) Viewed 296 times

[richmond62]

Well, it would be better if the image was IMPORTed into the stack and called "maze" (earlier versions being deleted), and the coloured borders rounbd the squares HAVE to go.

[tperry2x]

...the coloured borders rounbd the squares HAVE to go.

Without borders:

MazeCollectorv4.5.oxtstack

(588.55 KiB) Downloaded 20 times

[xAction]

I think he means this in the stack scrip:

add 1 to gCurrentColorLine
put line gCurrentColorLine of the colorNames into gCurrentColor
set the colorOverlay of the templateGraphic to false --- << don't know how this keeps turning on by itself!!
set the backgroundColor of the templategraphic to black
set the foregroundColor of the templategraphic to gCurrentColor --- <<< that's your culprit

The colored borders provide the arcade aesthetic, don't you feel like you're in an arcade? Gotta get down in the maze and empathize with the digital people who have to live in these places. A little color goes a long way to improving the quality of their short lives.

Color controls are a feature that could be added of course. I'm thinking:

• draw the whole filled grid once
• maze data toggles graphic color
• allow the whole mess to be clickable for editing
• The colors, patterns, sprites in a graphic can have some code/game level significance like a door, trap, or monster.
• eventually figure out how to move around inside a giant set of data and update the grid, so mazes can be combined into one big data set to create a huge static map and all that changes is line tCurrentStart to tCurrentEnd of the data to flip the graphics on or off.

This was really an experiment in squeezing data out of a tiny C++ program run from within a stack. The trick was to have the application run headless and quit after spitting out some files, xTalk blocked the file write while the program was open with a GUI, which is an issue I think I had with trying to run Lua or Python from a stack.

Have a few things to backtrack and then I'll rework Bitfontmaker2-Like stack to work with 32x32 grids, then arbitrary screen ratios. Feels like a million years since I wrote that stack.

Maybe I'll figure out Builder.

[OpenXTalkPaul]

You should REALLY Look at the NetPBM's Wikipedia page: https://en.wikipedia.org/wiki/Netpbm

example:
A simple example of the PBM format is as follows. (Not shown are the newline character(s) at the end of each line.):

Code: Select all

P1
# This is an example bitmap of the letter "J"
6 10
0 0 0 0 1 0
0 0 0 0 1 0
0 0 0 0 1 0
0 0 0 0 1 0
0 0 0 0 1 0
0 0 0 0 1 0
1 0 0 0 1 0
0 1 1 1 0 0
0 0 0 0 0 0
0 0 0 0 0 0

It's an ancient leftover graphics file format from the dank days when there was only BBSes, Email, Usenet, FTP, Gofer

The Image control DOES support this format, so if you 'set the text of image 1 to fld..." a field with a that quoted text.
You will get an image of the letter J that is 6 pixels x 10pixels, then you can change the image control size to whatever size in order to scale the image if you need to (you might want to stick with even multiples to avoid any sub-pixel rendering or anti-aliasing by the rendering engine (which in this case is the Cairo graphics lib https://www.cairographics.org ).

If you save that ASCII text as a file with the .ppm filename extension, the macOS Finder immediately gives it a pixel image preview icon and you can open it in Preview.app as an image.

This ASCII Text version of the file format is certainly not a good format for storing an image on disk because when compared the binary a 1-bit image format, but looking at is as 1s, 0s characters like this makes the structure of the file format fairly self explanatory.

I spent some time experimenting with this to make a piano-roll style display for MIDI musical notes (if you've ever seen GarageBand or similar software you've seen piano roll, I'm talking about. I had to scale it up because 127pixel image is hard to see on todays higher resolution monitors, but it did so fairly quickly. I could add rows of these text 'pixels' to it and set the image text again and again on a timer loop. I was basically created a graphical MIDI music step writer with it, oe that could output a music sequence as an 'image' and read back in the image and play it as music! (127 notes pitches mapped to 127 rows of 'pixels').

Anyway, I had also thought this would be perfect to use for writing an xTalk / LC answer to the RosettaCode.org Random Maze generator challenge, but I never got around to writing it. I was going to translate the Lua version:
https://rosettacode.org/wiki/Maze_generation#Lua

I expect that using this format/technique to render your maze as an image would likely be much easier on the rendering engine than a whole lot of separate graphic controls and easy to analyze with or map it with xTalk's chunk expressions (each 'pixel' can be referenced something like 'if word pPixelColumn of line tPixelRow' is "1" then -- a hit test for a 'wall' 'pixel')

[OpenXTalkPaul]

The Image control DOES support this format, so if you 'set the text of image 1 to fld..." a field with a that quoted text.,

Better yet, DON'T put those 1s. spaces, and 0s characters text in a field at all. Instead keep that ascii text version in a global variable in memory or something that doesn't need to be rendered until you want it to be rendered (perhaps on a 120 bpm timer loop ).

Rendering just text in a field is still a bunch of rendering, even if you're only updating changed areas of the drawing surface. it's an unnecessary, costly use of CPU (or GPU?) cycles. Instead only render it as the image version. You can save the text version when you're done generating 'pixel' data if you want to save that for further manipulation later.

That's mostly only relevant if you care about changing and rendering it in realtime or close to it (like my piano-roll/sequencer experiments, or like a heart monitor, or some timing based drawing like that).

[OpenXTalkPaul]

The Text shaping with the harfbuzz (I love that name for some strange reason) https://harfbuzz.github.io/what-is-harfbuzz.html properly eats up quite a few clock cycles when putting together lots of text to render in a field that possibly has it's own text formatting properties like 'Fixed Line Height' so that's like why updating a fields text is so costly. Lock Screen can help prevent unneeded screen updating, but it's likely still going to do those text shaping / positioning calculations when ever you change the contents of the text of a field. https://harfbuzz.github.io/what-is-harf ... xt-shaping.

[xAction]

You should REALLY Look at the NetPBM's Wikipedia page: https://en.wikipedia.org/wiki/Netpbm

example:
A simple example of the PBM format is as follows. (Not shown are the newline character(s) at the end of each line.):

Code: Select all

P1
# This is an example bitmap of the letter "J"
6 10
0 0 0 0 1 0
0 0 0 0 1 0
0 0 0 0 1 0
0 0 0 0 1 0
0 0 0 0 1 0
0 0 0 0 1 0
1 0 0 0 1 0
0 1 1 1 0 0
0 0 0 0 0 0
0 0 0 0 0 0

It's an ancient leftover graphics file format from the dank days when there was only BBSes, Email, Usenet, FTP, Gofer

So your're saying use the simple binary text version to create the data for any image at any size rather than export an image of the stack elements, which is crazy slow. Gotcha. On it.

[xAction]

MazeCollectorv6.5_ViewOrGen.oxtStack

(369.91 KiB) Downloaded 19 times

<<< version 2!
This stack does a good job without the C++ stuff.

Mouse click, arrow keys, or scroll wheel will either generate a new maze (if at the end of maze list) or move through the maze list to review what is stored in the stack , 68 mazes right now.

Right click will popup a menu with some export options and the old "about" nonsense, which probably needs updating.
The exports go to their specific folders in your "Documents" folder

It's only using the binary 0s and 1s string data so blowing it up to PBM in the next step should be easy enough.

Probably will abandon this thread to focus on an entirely xTalk solution unless some other C++ and mazes thing something comes up.

Hrmm, stack is just constantly generating more mazes instead of reviewing the old ones. I'll look back into this in a bit...

Fixed...doesn't generate new maze on arrow key, only mouse clicks.

Stumped on how to get it to make a new maze at the end of it's list, then show the maze. Global seems to get stuck even though things are updating it before the new data is required.

[xAction]

MazeCollectorv7_pbm.oxtStack

(372.88 KiB) Downloaded 21 times

This version's stack script contains the command : MazeToPBM which spits out a big old PBM file of 1059x1024 pixels at about a megabyte. However, that image is just a ghost when reimported to the IDE. Gimp etc see the file as intended.
I thought we could import to an image, export it as PNG but that didn't work.

These files are big and weird, thats why I didn't chase them too much years ago. What did you have in mind for them?

Here's the new Handler it expects binary text pWidth characters per line and pHeight lines.
It produces a PBM file by placing 32x32 character blocks of text for each 1 or 0 in the string.
If you open the resulting PBM file in a text editor without word wrap and shrink your font size you'll see the whole maze.

oh all the arguments in the handler open are being ignored or over written at the moment,

on MazeToPBM pWidth,pHeight,pFinalWidth,pFinalHeight,tName,tMazeData
put 32 into pWidth --- number of characters per line of origin data
put 32 into pHeight --- number of lines of the origin data
--- pFinalWidth --- the total characters per line after 'scale' padding
--- pFinalHeight --- the lines of characters after 'scale' padding

--- get the data from somewhere
--put line 1 to -1 of field 1 into pMazeData
put getMazeAsString() into pMazeData

--- create the bit brushes
put "0" into gWhitePixel
repeat pWidth times
put "0" after gWhitePixel
end repeat
put "1" into gBlackPixel
repeat pWidth times
put "1" after gBlackPixel
end repeat

--- scale the image data PBM style
put empty into tScaledPBMImageBits

--- iterate over each line of the origin data
repeat with y = 1 to pHeight
put empty into tScaledCharacterLineData

--- iterate over each character of each line
repeat with x = 1 to pWidth
put char x of line y of pMazeData into tCurrentPixel
--- add a string of 0 characters or 1 characters to the paint string for each 1 or 0
if tCurrentPixel is "0" then
put gWhitePixel after tScaledCharacterLineData
else
put gBlackPixel after tScaledCharacterLineData
end if
end repeat

--- duplicate the paint string to create the whole scaled area of image
--- for every 1 pixel, there are now 32
repeat with repeatY = 1 to 32
put tScaledCharacterLineData & cr after tScaledPBMImageBits
end repeat
end repeat

--- for every 1 pixel, there are now 1024!!

--- these values are important for the PBM file to accurately display the data
put number of characters of line 1 of tScaledPBMImageBits into pFinalWidth
put number of lines of tScaledPBMImageBits into pFinalHeight

--- save the files to Maze_PBM folder in the local Documents directory
put specialFolderPath("Documents") & "/Maze_PBM" into tPBMPath
if there is not a folder tPBMPath then create folder tPBMPath
put tPBMPath & "/maze_"&the seconds& ".pbm" into pFileName
put "P1" & cr & pFinalWidth & " " & pFinalHeight & cr & tScaledPBMImageBits into url("file:" & pFileName)
end MazeToPBM

[xAction]

Okay so apparently there is a PBM binary format, and I'm writing ASCII.
So my brain is hurting. And ChatGPT is worthless.
We get to this point in my code for making the scaled graphics

if tCurrentPixel is "0" then
put gWhitePixel after tScaledCharacterLineData
else
put gBlackPixel after tScaledCharacterLineData
end if
end repeat

We know 32 'pixels' are being placed into the image representing a line of black or white.
we know 32 pixels below those 32 pixels will be the same value

The binary data of a PBM is written in 8 bit chunks.
Each unit of our "grid" is 32 bit chunks when we blow it up for this big old PBM file.

so every time we add gWhitePixel or gBlackPixel our big ASCII line
we add 8 numtochar(255) or 8 numtochar(0) to our binary Line?
repeat that line 7 more times per line of the original data.

Is that how this works?

[richmond62]

My Granny used to say that a picture was worth a thousand words:
-

Screenshot 2024-02-17 at 12.50.57.png (102.29 KiB) Viewed 231 times

-

Code: Select all

on mouseUp
   if exists(img "FANCY_THAT") then
      delete img "FANCY_THAT"
      wait 10 ticks
   end if
   import snapshot from group "GROOP"
   set the name of the last image to "FANCY_THAT"
end mouseUp

[xAction]

Stack is already doing the group export thing.
Now what we want to do is take the basic data
001100
110011
001100

for quick example, if we start with data that is this

exampledata1.png (153 Bytes) Viewed 229 times

we can make this

exampledata64.png (172 Bytes) Viewed 229 times

programmatically and instantly into an image without making 1024 graphics objects to do it.

The PBM ASCII data is doing the job but the IDE doesn't read the ASCII image as anything visible, so we need to write the binary version, somehow.

[richmond62]

Dunno . . . round these parts I have always felt the 'Hypercard heritage' (and there's a very corny phrase) was to do things as simply as possible, avoiding the abstruse gunk I, at least, encountered when 'down-and-dirty' in the 1970-1980s with such 'nasties' as FORTRAN & PASCAL.

Generate a maze from square graphics, group the thing, and import the group as an image: set the image name to some predefined name (we could be "original" and call it 'maze'): in this way, Chummy can have a different maze to steer his ant through every time.

[OpenXTalkPaul]

--- for every 1 pixel, there are now 1024!!

Wait...WHAT? For every space character & "1" character, there should be 1 pixel.

Don't scale the ascii text version of the 1-bit image with some duplicating of 'pixels', lock the resizable of an image control to the size you want it and then set the image text and the engine will create a small image and scale the small image to fit whatever the width & height you set the image control to, the image data remains tiny. What I'm saying is stop using those graphics object squares as if they were pixels, it's very tough on the engine. Using buttons to make a grid might be even worse. Trust me I know, I've been out to build a Piano-roll style MIDI-DataGrid sort of things for quite some time. In fact I did use the DataGrid API that comes with the API to do it at one point (which it seems like that method worked a little better, worked well with touch input on Android).

Once you get above a certain amount of objects on a card it will lag out badly. Using only some text in memory and a small image (could also be stored in memory), and then letting the engine scale it to fit an image control should work better. This works fine for me on MacOS, I would think it should work on Linux too (if not maybe I could wrap NetPBM library with Extension Builder). Maybe NetPBM is a package that wasn't installed in you Linux OS but needs to be for this to work? I'm not sure.

I'm looking for those stacks I made that to show what I'm talking about in action.
It would be great to add xTalk entrees for those Maze Generator and Maze Solver challenges on ResoettaCode.org

[OpenXTalkPaul]

I'm looking for those stacks I made that to show what I'm talking about in action.

PBMtextToImageDemo.jpg (99.25 KiB) Viewed 222 times

Try deleting some of the first lines of 0s and 1s in that text field then hit the "BitsToBitmapImage" button
You should see the image inside the scrolling group update its contents.
The image is only 127 pixels wide by (the number of lines of that text field) pixels in height.
The rendering engine scales the small image to fit the width of my Image Control because that has its resizable property locked. The result is the my image's square pixels are being stretched (by the Cairo Graphics Lib based rendering engine) to fit the width that I desired. Which in my case was a width that matched the width of A Piano Widget control, which most of you guys won't have installed unless you're running OpenXTalk DPE, so I took the widget off the card for the purpose of this demo stack.