kisrael

(minor improvement: replaced "show what color you're hovering over" with an eyedropper tool. That more closely matched an early suggestion, and in practice feels better) Be sure to hit shift-reload if you've been playing with earlier versions.)

NEW FEATURE: batari BASIC DPC+ mode now lets you paint the background separately from the PF. So the BB DPC+ kernel has always allowed you to set the color of each line's background, and then do a different color for the PF... now you can edit that

NEW FEATURE: batari BASIC DPC+ mode now lets you paint the background separately from the PF. So the BB DPC+ kernel has always allowed you to set the color of each line's background, and then do a different color for the PF... now you can edit that

Thanks for the kind words! Yeah, painting with a canvas is a lot more pleasant than typing all the . and X (and boy are . and X easier to read than 0 and 1!) bBPF will be partially retired. Definitely that one and the DPC+ flavor were self-inspirations for what I'm doing with splash-o-matic.

https://alienbill.com/2600/splash-o-matic/ - minor update. Tweaked the auto-contrast on the image import, still playing with the UI arrangement, and added the first PF assembly kernel (still working out some details at 192px, single scanline kernels, so the max is 110 for now) Also some some internal improvements so adding new kernels should be easier for me- can just tell it where those tricky PF bits go Oh and fixed the bug where if you were using the color tool, clicking on another tool might register as color clicks

https://alienbill.com/2600/splash-o-matic/ - minor update. Tweaked the auto-contrast on the image import, still playing with the UI arrangement, and added the first PF assembly kernel (still working out some details at 192px, single scanline kernels, so the max is 110 for now) Also some some internal improvements so adding new kernels should be easier for me- can just tell it where those tricky PF bits go Oh and fixed the bug where if you were using the color tool, clicking on another tool might register as color clicks

I'd ignore a person who is saying nice things about my program and making really nice art with it and pointing out possible problems in the UI (like not being clear enough about the modes) at my peril Definitely not optimized for mobile I'm working hard enough to make a easy to understand UI on desktop / laptop. And definitely it's been growing... at first I wasn't sure if it would grow beyond 48px, but I'm making a system that's pretty flexible. I'm not sure I'll get to it but I'd like to support all the major bB kernels that do stuff w/ PFs.

What I'm trying to say is IT ALREADY IS A DPC+ BB EXPORTER!!! go down to mode/output kernal - "select bB DPC+ color PF" - then it gives you bB DPC+ code w/o a separate kernel, and the PF editor changes shape a bit

Yeah. Over all I mean to put more explaining of some things. So I'm still working on some of the assembly PF editors - but did you know it already has a DPC+ editor mode? https://alienbill.com/2600/splash-o-matic/ (The one thing it doesn't do is let you edit the background per scanline as well as the PF color per scanline, I realized I have to build that in) Is that what you were looking for? If not, could you describe what you're hoping for, and if so, maybe I need to explain more clearly how this is for 48px AND various other Playfield things??

And image importing works better than I thought it would at least for some images.

Thanks for the kind words! pretty screen! you remind me that I should add a thing to allow separate background and playfield colors in DPC+ kernels. there's absolutely bugs running around this thing Best things to do are do "steps to reproduce" and then what you saw vs what you expected to see In this case I'm able to reproduce the problem and I think I know the cause and fix, having to do with how I changed dealing with "out of bound" clicks.

Improved Import -- now it autoadjusts the initial contrast by trying 5 values and picking which one has the best balance of on/off pixels... that's not always the best aesthetically, so you can play with the slider, but it's better than the first load being all dark or all light..

Improved Image Import - now when you load an image it samples at 5 different contrast levels and picks one that has a good balance of pixels on to pixels off (which might not be what a human thinks is best, you can still fiddle with the slider for that, but it prevents an image from being all black or all white from the outset)

Progress continues! Now it supports bB PFs (regular pfcolors kernel and DPC+ w/ much higher resolution) (Seems like there might be a slight bug for image import w/ the new kernels... like it works if I load the image while still doing a 48px kernel, and then switch over? Odd.) Oh and I poked at Nativefier... works pretty well. I guess it makes it feel like more of a "thing" people own, then downloading and opening up an index.html, maybe I should "release" it as an app once it's more stable.

Progress continues! Now it supports bB PFs (regular pfcolors kernel and DPC+ w/ much higher resolution) (Seems like there might be a slight bug for image import w/ the new kernels... like it works if I load the image while still doing a 48px kernel, and then switch over? Odd.)

yeah absolutely. While some of my editors are works in progress, I usually work hard to fight link rot, with at least a redirect as needed.

Yup! browser is just an easy way to get multiplatform, windows/mac and presumably linux And beyond just license and open source... how esoteric/common and/or easy to learn is the technology used? PlayerPal is ancient vanilla javascript. atari-sound-forger is also vanilla. atari-riff-machine is react (probably a mistake on my part in retrospect) and spash-o-matic is p5, but mostly vanilla js... some other one off PF editors are p5. But there are some projects that don't explain their build process very well, and raise the barrier to a new coder stepping in. PlayerPal had the equivalent of a Pull Request, which is some of what got me moving on this project - hearing people ask for PlayerPal to better handle 48px sprites made me think.. there's gotta be a better way

Yeah. Online isn't enough - like we can't trust tools with a server side part to stay around, unless they are both open-source and have a well-understood build process. But all my tools are either in github or are like single-files or have no build or both. If I get hit by a bus, it wouldn't be too tough for a skillful javascript coder to carry on. (on the other hand... a fully online, server IDE could have bB and DASM... that would be interesting. But I haven't seen many rich in-browser code editors) Interesting point about your wariness of ADS. It doesn't make me nervous as VBB- or maybe that's why you are nervous, because you've lived through so much software you dig being so abandoned. But, like, it would be a lot easier to build a tutorial that explains "here's how you would get by without ADS" than the same for VBB - like download bB and DASM and you should be ok as long as you know how to use a command line a bit. ADS doesn't DO that much, so it's kind of transparent, but like I've said before, VBB and its options to drag and drop things and what not... it takes a new dev further away from the truth that "your game is basically all made by a big text file" it's been interesting thinking about the text features you like, and what workarounds I'm comfortable with as a fulltime programmer. (like Add Bookmark I just "add a comment I can ctrl-F find later", Flip Text I would use a different tool etc,) of course other stuff is not so easy to externalize.

Yeah. that PDF tries to be friendly, but it's a complex subject w/ all those little files! Of course looking at it... one of the differences between player-pal and splash-o-matic was the latter didn't have to worry about frames of animation. But maybe I'll support that as well, rather than make people build up spritesheets. Maybe splash-o-matic can "eat" player-pal (and THEN what do I name things )

I will never stop giving vbB props - for over a decade it really made a cool ramp for lots of people to get started. But that said, I've always found it overwhelming, hard to setup properly, hard to understand, and Windows-only. And not supported for a long while now. So I'd love to build browser-based/cross-platform tools, all of which spit out runnable demo code, and between my tools and Atari Dev Studio, really eliminate the need for VbB. Maybe I can even make a play to get my tools embedded in Atari Dev Studio I'd love to to be the go-to for both bB and ASM coders. But because I never got a long with vbb, I don't know what it offers that my tools don't (yet). @Random Terrain has a list. There are parts in the code compleition etc I wonder if Atari Dev Studio could do better... shoulda paid more attention as I built Sisyphus

Great! yeah, that's what I was thinking of! So basically it's learning how to generate those .asm files? The `48x2_5_image.asm` and what not? If you're willing to how me think through it (and I'm moving in a few weeks and I think my ancient windows laptop is packed), help me set up the templates and how to fill them, I'd be happy to give it a shot. Looks like it's mostly doing the work of Img2Code Oh wait... 96x2?? Wow, is that DPC+ or closer to vanilla? (heh just thought of another nice-to-have for splash-o-matic: just mentioning how many bytes of data we've made (no promises about how much is left in the actual code, jsut how much raw graphics data we're talking so far)

Thanks for your kernel! (I might hit you up later for some more vanilla kernels for PFs, if you're willing to collaborate??) Some of those I'm just being intellectually lazy - like once you get the bit order right, one color per line PF kernels aren't THAT hard, but I am SO rusty with everything in assembly. Also for bB, I should look at some of the best practices for partial kernels or what not, like if you can have a graphic kernel combined with more regular stuff on other parts of the screen.

Hah Ha, sorry, shoulda mentioned everyone who uses it now is my beta tester In this case the first issue is I guess it only works with "web" formats - png, gif(?), jpg... second issue is, after I changed it to PNG but didn't change the height, the default contrast made it like all black but once I made sure the height of in the editor matched the height of the png, it came out great. So the core more or less works, but it needs to be better documented about file format, should be more clear on errors and progress, and maybe even "auto adjust" contrast the first time to maximize the number of pixels shown! thanks for trying it out, and sorry it's still rough

Now with import from image file! Everything is still handled in the browser... it stretches the image to be the full "screen", then breaks into black and white, you can fiddle with the contrast:

Now with import from image file! Everything is still handled in the browser... it stretches the image to be the full "screen", then breaks into black and white, you can fiddle with the contrast: