Yet Another (Online) Playfield Editor

[NoLand]

I've devised a tiny playfield editor, which should support most needs. It supports symmetric and asymmetric playfields, repeated and mirrored mode (for both types) and generates assembler code in realtime. Correspondingly, the editor takes assembler code or simple lists of byte values as an input. Moreover, you may adjust the total number of scanlines for the kernel and the vertical resolution. The Interface is intentionally kept simple (or, at least, meant to be so). Mind that there's no support for color codes or row-repeat counts, confidently assuming you may be able to add them on your own. (Also, there isn't really a standard format for this.)

 

https://www.masswerk.at/vcs-tools/TinyPlayfieldEditor/

 

I also collected a few other tools for player graphics / sprites and sound under a common landing page: https://www.masswerk.at/vcs-tools/

 

Have fun!

 

 

Update: (Apr. 27, 2020)

The editor now supports code ordered by rows (PF0, PF1, PF2 alternating) as well ass code ordered by PF-registers (one array per PF register), both for import and the realtime generated code output.

 

On import, any consecutive stream of bytes (either bare values or assembler constructs like ".byte") will be interpreted as ordered by rows (alternating values for each of the PF-registers, as in "PF0, PF1, PF2, PF0, PF1,..."). If there are, however, separating labels found (anything beginning with a letter character or underscore and continuing with letters, numbers, or underscores at the start of a line) the imported code will be considered to be ordered by PF-register. In this case, an additional prompt will ask you to map the labels to the respective registers (defaulting to the order found in the imported code — no attempt is made to interpret the semantics of labels). The pop-up menus used for this also include an option to override the data and set all values to zero (which may be useful, if there are less than three arrays of PF-data or one of them is meant for color codes). Moreover, the line-height will be automatically adjusted to the length of the imported data stream(s).

 

Automatic code generation defaults to ordered by rows, but may be switched anytime. (Mind that automatic generated comments with picture strings and row numbers are only available for the ordered-by-rows mode, while any output ordered by PF registers uses a more compact format of 8 bytes per line.) The output format also adjusts automatically to the last import format used, reusing any labels found in the imported code. Labels will be reset to generic ones, if you clear the playfield editor.

As before, the byte order of the generated code may be switched any time. (You may also chose to import any code either in the existing order, or to import data bottom-up. This state will be honored as a default in the generated code output.)

 

By this, the editor may be also a viable tool for interpreting playfield data or even for converting code formats.

 

While this may sound a bit complex or even complicated, it really just describes a behavior, which should effortless adjust to your needs. :-)

Edited April 27, 2020 by NoLand
Update

[+Karl G]

This looks quite promising! Playing with it for a bit, the only thing I was wishing I had was some kind of line marker or shading to show where the PF regions begin/end. But it's completely usable without that, too.

[NoLand]

27 minutes ago, Karl G said:

Playing with it for a bit, the only thing I was wishing I had was some kind of line marker or shading to show where the PF regions begin/end.

Actually, there are, but they are rather subtle. You probably have to know that they are there, in order to notice them. They also adjust to the kind of playfield repeat on the right side. (I found it hard to decide, if they were more distracting than useful, if more accentuated.)

 

Edit: It's a bit like with the mash lines on the Trinitron monitors, once you've seen them, you can't unsee the PF-register dividers.

Edited April 21, 2020 by NoLand

[NoLand]

Small update: The principal settings, like symmetry, repeat and line-height are now annotated in an additional comment in the assembler code generated by the editor, which is also used for adjusting these settings on data import.

 

(These settings may appear in any order in a comment starting with "mode", using any kind of separator.)

Edited April 24, 2020 by NoLand

[+splendidnut]

Just took a look at this today.  Very nice!

 

Suggestions:

  * Add line by line color (you already mentioned)

  * Add option to output code into separate playfield arrays.  i.e.  Values for PF0, then values for PF1... etc.

 

Also, really enjoy Studio2600... It's great for finding sounds quickly

[NoLand]

3 hours ago, splendidnut said:

Add option to output code into separate playfield arrays.  i.e.  Values for PF0, then values for PF1... etc.

This may be interesting!

However, it comes with a few complications, since as-is the editor takes just any stream of bytes in whatever notation as an input. With alternative sequences things are not that clear and we've got to come up with an arbitrary convention.

Any suggestions? (E.g., just any label, or any including the string "PF", as a prefix to a stream of bytes?)

 

Edit: The same is also true for color.

E.g., inside the editor, we could set row colors by presenting a color picker on a right click.

But, are there any conventional code formats for export and import? (Prefix the color as the first item? Have a separate label and stream for colors? Accept any label starting with "C" as a stream of color codes?)

 

Any suggestions are welcome!

 

The principal idea is to facilitate working directly with assembler code. (Which may be of use for interpreting any existing playfield definitions, e.g., for disassemblies, mods, etc, as well.) So what are common formats?

Edited April 24, 2020 by NoLand

[+splendidnut]

For one of my projects, I used the following (Note this does not use PF0... but does use color):

mountainsColors:
    .byte $4E,$4E,$0F,$0F,$0F,$4E,$0F,$0E
    .byte $0C,$0E,$0E,$0C,$0E,$0F,$30,$42
    .byte $34,$30,$42,$34,$42,$34,$46,$34
    .byte $32,$42,$34,$42,$34,$46,$34,$32
mountainsPF1:
    .byte $00,$00,$00,$00,$00,$00,$00,$00
    .byte $01,$01,$01,$01,$01,$03,$03,$03
    .byte $03,$03,$07,$03,$07,$07,$07,$07
    .byte $07,$0F,$07,$0f,$0f,$0f,$0f,$0f
mountainsPF2:
    .byte $02,$02,$06,$06,$0F,$0F,$0F,$1F
    .byte $1F,$1F,$1F,$1F,$1F,$1F,$1F,$3F
    .byte $1F,$3F,$3F,$3F,$3F,$3F,$3F,$7F
    .byte $3F,$7F,$3F,$7F,$7F,$7F,$7F,$7F

I laid out the graphics this way so that it's faster in code.   I only had to increment the array index once per line instead of once per byte (which would be 3 times per line).  Depending on how flexible your want your tool to be, you could pursue doing some sort of mapper which would let the user choose which array was which by the labels.

 

As for other common formats... you might want to look at into adding support for Batari Basic input/output.

[NoLand]

In honor of your mountain theme and to quote Kant, "where others may see flat footpaths, I do see Alps" (or whatever is the common English translation).

 

How may we generalize on this? (E.g., there are just 3 streams, but one label includes "color" – easy enough to recognize by a regular expression –, so one stream is missing. Assume it's all zeros? Assume it's probably PF0, or do further semantic analysis on the labels?)

 

Edit: Is it a robust assumption that every label for playfield data will include either "PF0", "PF1", or "PF2"? Can we make this a requirement? Or, at least, a viable fallback? (E.g., what about multiple screens and there's a label like "PF2_1"?)

Again, suggestions, opinions, etc, are welcome…

 

P.S.: I've no experience with Batari BASIC and I'm not necessarily inclined to install it. What are the formats used?

Edited April 24, 2020 by NoLand

[+splendidnut]

I was thinking there can be controls on the side of the import box with drop down selections.  When the user pastes into the import box, the labels are detected and the user has to select the mappings.  Something like:

 

Map to PF0

  ( dropdown with labels )    <-- list of labels includes (none)

 

Map to PF1

  ( dropdown with labels )

 

...

 

The labels can be detected either as a line with just an identifier string (alphanumeric, '_')  with a potential '.' as a prefix (DASM local var indicator) and a ':' as an optional suffix (I think the colon is optional in DASM label).

 

For output, it gets a bit tricky... you might need a different control panel to handle the situation of new/first playfield (no mappings set) which has text input fields instead of the dropdowns.

[+splendidnut]

19 minutes ago, NoLand said:

P.S.: I've no experience with Batari BASIC and I'm not necessarily inclined to install it. What are the formats used?

 

I don't really have much experience with Batari Basic either.   So I'll let someone else speak up if they want that. 

[NoLand]

39 minutes ago, splendidnut said:

was thinking there can be controls on the side of the import box with drop down selections.  When the user pastes into the import box, the labels are detected and the user has to select the mappings.  Something like:

 

Map to PF0

  ( dropdown with labels )    <-- list of labels includes (none)

 

Map to PF1

  ( dropdown with labels )

 

...

This seems to be a viable path to go. (Alps or not.  ) We may also try to preselect those semi-intelligently. (E.g., try to identify color, which is probably either the first or the last stream, assume any others are in sequence, only try to identify those, if one is missing.)

Something I'd rather want to avoid is an import Wizard, like those found in Excel and similar applications. Those are generally a pain to work with and do rarely what's expected. (So you need to add a preview for the user to check the results and to evaluate consequences of any adjustments, etc, which is somewhat radically opposed to the idea of keeping things simple.)

 

I think, regarding export, it's easy enough to edit the labels when pasting the code into the source and we may rather go with generic ones (like "DataPF1"). [Edit: If there was a previous import, we may, of course, reuse those labels.]

Regarding output ordered by rows (as-is), we could go with options to put the color either first or last (always to be exported as a hex number).

 

For a bit of background, this really started as a bigger version of the "Tiny Sprite Editor", which I found personally quite useful. Color didn't matter for sprites that much, it's probably in a separate stream and easy enough to edit manually. Most of the effort for the playfield editor went into handling the various playfield modes and doing the required conversions on the fly. (And also, to do it in a way, which allows to switch formats on the fly without losing data and still keeping things internally somewhat simple – read, reasonably responsive.) Color however was still assumed to be handled best separately. But I can see that it does matter for playfields.

 

Regarding Batari Basic, is there a comprehensive documentation on code formats?

Edited April 25, 2020 by NoLand

[NoLand]

So ... we now support byte orders either per row (as before) or by labeled arrays per playfield register, both for import and for export.

 

(Reload) https://www.masswerk.at/vcs-tools/TinyPlayfieldEditor/

 

Not so sure about color. Setting color codes for up to 228 rows each (PAL standard), appears to be pretty exhaustive.

I think, this may be best left to manual editing.

(Even, if we changed the colors for any consecutive rows below as well, there's no reasonable relation of effort and achievement, both for the user and on the programming side of things.)