Jump to content
IGNORED

TOOL UPDATE: PlayerPal 2.2


kisrael

Recommended Posts

https://alienbill.com/2600/playerpalnext.html 
Maybe the oldest continuous running browser based tool for the Atari? A fairly decent little 2600 multicolor sprite editor that spits out ready to run ASM and Batari BASIC sample programs! Recently updated by Oliver Gross, who improved the round trip for putting ASM back into it (the code used comments to store color data on export, which is what the import relies on). Also it's a little smart about resizing players on import as well. 

Let me know what you think! Like I know some folks prefer Visual bB (oof) or that editor builtinto Atari Dev Studio... and this guy's interface is pretty clunky!
If I get some enthusiastic feedback I might consider putting in roudtripping batariBASIC code as well...

  • Like 6
Link to comment
Share on other sites

This is my 2600 sprite editor of choice, and I'm quite glad that it exists. I'm not sure I'm understanding what the update is, though? Do you mean that it can now import sprites from complete ASM programs? I've done import of ASM data to make adjustments to my sprites many times.

Link to comment
Share on other sites

No, the import is (as that like 13 year old comment still implies) still quite primitive! :-D

 

Basically it can read the same kind code "generate ASM data" spits out. So if this was your only graphics editor, and you didn't have to bang too much on the data to code it up, you can do round trips. But since there's no singular way of encoding color data for a player, there's no simple way of extracting color data either.


I imagine people who do 2600 hacks have good sprite rippers? If someone was interested in that as a project I'd be willing to try and hack a bridge between what those sprite rippers put out and PlayerPal... but it gets fiddly. Almost like primitive AI needed to guess what format a sprite is in.

But glad you like it! W/ more encouragement I might try to round off some of its harsher edges w/o losing its simplistic charm :-D 

 

 

Link to comment
Share on other sites

Good news! I use this tool all the time to design my sprites. The sprites in Amoeba Jump and Tower of Rubble were all created in this tool.

 

Feature request: it would be nice to be able to optionally remove the padding between the 10 different sprites. Reason: I also use this tool to create 48-pixel sprites, and it would be great if I can see the resulting "big sprite" without these paddings.

 

And I noticed that in the resulting generated code, all bytes have the # character in front of them, which I always remove. Maybe that # has some meaning in bB? (I only do asm).

 

  • Like 1
Link to comment
Share on other sites

1 hour ago, Dionoid said:

Good news! I use this tool all the time to design my sprites. The sprites in Amoeba Jump and Tower of Rubble were all created in this tool.

 

Feature request: it would be nice to be able to optionally remove the padding between the 10 different sprites. Reason: I also use this tool to create 48-pixel sprites, and it would be great if I can see the resulting "big sprite" without these paddings.

 

And I noticed that in the resulting generated code, all bytes have the # character in front of them, which I always remove. Maybe that # has some meaning in bB? (I only do asm).

 

Heh, so I whipped up https://alienbill.com/2600/playerpalnextwide.html -- I was just going to include it as a feature but then I noticed it was messing up the animations. I might go back and try and fix that and icorporate it properly, but for now see if this works for you

 

Does the # sign mess up DASM or whatever, or do you just not like it? I don't think it hurts anything (though its been a while since I've actually run the generated code)

Link to comment
Share on other sites

1 hour ago, Dionoid said:

Good news! I use this tool all the time to design my sprites. The sprites in Amoeba Jump and Tower of Rubble were all created in this tool.

 

Feature request: it would be nice to be able to optionally remove the padding between the 10 different sprites. Reason: I also use this tool to create 48-pixel sprites, and it would be great if I can see the resulting "big sprite" without these paddings.

 

And I noticed that in the resulting generated code, all bytes have the # character in front of them, which I always remove. Maybe that # has some meaning in bB? (I only do asm).

 

I concur with both of these, and I have also used the editor to produce 48-pixel sprites. In fact, I give it as a suggestion for the 48-pixel tutorial I wrote.

Link to comment
Share on other sites

2 minutes ago, kisrael said:

Does the # sign mess up DASM or whatever, or do you just not like it? I don't think it hurts anything (though its been a while since I've actually run the generated code)

It doesn't hurt anything, but it is just redundant. It would just be a little prettier if it didn't generate the data with this, or expect it on import. ? 

Link to comment
Share on other sites

  • 1 year later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...