xAction wrote: ↑Sat Feb 17, 2024 9:52 pm
Well that was easy. Would never even have thought of setting the 'text' of an image.
MazeCollectorv8_pbm_only.oxtStack
THISFILE.png
New version retains the old scripts, but generates everything on the fly to PBM data, no graphics generated.
Right click to export your PNG.
Nice! Much shorter times for rendering the mazes using pixels.
The idea behind the graphics objects is they are scriptable.
Slap a script into them
bump into them with an object
something happens, a door opens, a trap is sprung, etc.
A glow effect is applied, a single pixel around the border changes, etc.
Well there's probably 100s of ways you could go with these concepts, and probably many optimizations that could be done to speed them up further.
For my plans for the MIDI Piano Roll view controller thing I was working on, in addition to using the X plane coordinate as MIDI note number, I would use levels of opacity of the line as the Velocity Parameter for NoteOn messages (Range 0-127).
MIDI note messages has three parameters: Channel, Note or Pitch, and Velocity. Velocity is equates to 'how hard the note was pressed or plucked'. The first parameter of a MIDI NoteOn is channel, which (typically) has a range 1-9,11-16 (10 is reserved for drums in MIDI), I was thinking I can map those numbers to color, so channel 1 might be Blue, 2 orange, 3 magenta, etc. Ultimately the goal is to be able to layer these 16 'bitmaps' to get a composite image for a graphical representation that shows all the Notes of a sequence on all 16 channels (with liminosity or opacity levels as 'velocity').
I could even do that in this semi-human readable PBM text-fake binary format. Look at the Wikipedia article and the other format options available to use:
PGM example
The PGM and PPM formats (both ASCII and binary versions) have an additional parameter for the maximum value (numbers of grey between black and white) after the X and Y dimensions and before the actual pixel data. Black is 0 and max value is white. (Not shown are the newline character(s) at the end of each line.)
Example (magnified)
Code: Select all
P2
# Shows the word "FEEP"
24 7
15
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 3 3 3 3 0 0 7 7 7 7 0 0 11 11 11 11 0 0 15 15 15 15 0
0 3 0 0 0 0 0 7 0 0 0 0 0 11 0 0 0 0 0 15 0 0 15 0
0 3 3 3 0 0 0 7 7 7 0 0 0 11 11 11 0 0 0 15 15 15 15 0
0 3 0 0 0 0 0 7 0 0 0 0 0 11 0 0 0 0 0 15 0 0 0 0
0 3 0 0 0 0 0 7 7 7 7 0 0 11 11 11 11 0 0 15 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
PPM example
This is an example of a color RGB image stored in PPM format. (Not shown are the newline character(s) at the end of each line.)
Image
Code: Select all
P3
# "P3" means this is a RGB color image in ASCII
# "3 2" is the width and height of the image in pixels
# "255" is the maximum value for each color
# This, up through the "255" line below are the header.
# Everything after that is the image data: RGB triplets.
# In order: red, green, blue, yellow, white, and black.
3 2
255
255 0 0
0 255 0
0 0 255
255 255 0
255 255 255
0 0 0
Of course it is probably more efficient to use one of the binary format and set the bits/bytes in a variable or custom property that holds the collection of 'pixels'. A graphical rendering provides the same info as the text version of the sequence, so I only need to look at the textual-numeric version while I'm debugging.
On the other side, storing the text-numbered version in a some non-visible container but NOT rendering it on screen in anyway, allows me to keep track of the 'behind the scenes' thing quickly and I can still 'put' that data into a field when I do want to look at all of the underlying numbers, quickly and easily compared to using binary data where I would first have to read bits or (single or triplets) bytes of data and convert to integer numbers that are humans can make some sense of (ie. 0 -255 number)
Or you can click on one and get some data from them like "Is this a door or a monster?"
Or put images in them...which I can't image writing with PBM data, yikes.
Tracking everything in virtual number space is a bit inhuman.
So my thinking about this format as it relates to mazes generation, solving mazes, and/or walking a 'character' around inside the maze, etc. is largely inspired by an ancient (and rather obscure it seems) HyperCard XFCN (an external function) thing that was simply called "Basic 3D View", that did a fake 3D 'rooms' ( more like hallways ) that rendered based on a text-based map info that you could pass to the external as parameter. That is the XTernal that I want to recreate (but better) for our engine:
- Basic3DviewXternalViewjpg.jpg (83.96 KiB) Viewed 321 times
So in that the 'W' character for wall, another character for open area. Characters being used to keep track of position and view to render that is front view of the 'first-person player'. A similar methods could be developed with NetPBM that used number pixel values to indicate different things within the maze, like in only the grayscale version of PBM 'image' a 50% grey pixel (127) could be your 'player', and maybe some other shade of pixel (lets say 64) represents a 'key' item to find, and another that represents a door, another for traps, or a few 'monsters' that are also moving around inside the map, or whatever else you can think of. Because we would be using a text field, all of these values can be treated 'word' chunks, so we can scan through lines of this 'level map' grid using xTalk chunk expressions, and also use it to quickly generate a graphical 'god mode' representation we can quickly peek at (my goal for this is recreating something like Atari 2600 game called Tunnel Runner, which is still fun to play IMO
https://www.youtube.com/watch?v=xX0DoIp ... eRefresh=1). It would probably be MUCH faster, but perhaps even less human-friendly, to store this map as multidimensional array in memory (which you could the add attribute keys like 'monster power level' to), so any optimization like that could come later in the development process, after the logic and the rest of the game is worked out.
Keeping track of everything as 'word' values in a text field, we can do text/font things like click on words by make every word in the field be an underlined
link styled text so you can them with an 'on linkClicked' handler, you could use find/replace to quickly alter your map, you could use the syntax 'set the imageSource of character to {imageID | imageName | imageURL |empty}' to alter the way characters are display in the field (for example you could use a smiley face emoji to replace your special 'player' character within the text field that's displaying your map/level, ...just a few ideas.
- ATRITUNNELRUNNER.jpg (47 KiB) Viewed 320 times
It was sort of like you were reading my mind, very wild.