Asymmetric background editor?

[+johnnywc]

Hello all,

 

Is there a tool out there that can be used to design asymetrical background images using the PF graphics? Specifically, one that will output the left and right half values to a text file (or cut and paste) to include in a dasm listing?

 

Any help is greatly appreciated!

 

Thanks,

[vdub_bobby]

Hello all,

 

Is there a tool out there that can be used to design asymetrical background images using the PF graphics?  Specifically, one that will output the left and right half values to a text file (or cut and paste) to include in a dasm listing?

 

Any help is greatly appreciated!

 

Thanks,

931225[/snapback]

I don't think so; the best tool that I'm aware of is Kirk Israel's PlayfieldPal.

 

It won't do asymmetrical playfields, though, and the PF pixels are the wrong size.

[Cybergoth]

Hi there!

 

khryssuns TIA Playfield Painter let's you design any kind of playfield

 

Greetings,

Manuel

[+johnnywc]

That's awesome!!

 

Thanks!

 

Hi there!

 

khryssuns TIA Playfield Painter let's you design any kind of playfield

 

Greetings,

Manuel

931280[/snapback]

[Emehr]

For Classic MacOS users (anyone? LOL) I have PF Painter (formerly Stella Playfield Editor). It doesn't have any shape drawing capabilities and is still a work in progress but it gets the job done. Also, I fixed the click 'n' drag so it doesn't skip pixels no matter how fast you move the mouse.

 

- Jason

PFPainter.zip

[supercat]

Is there a tool out there that can be used to design asymetrical background images using the PF graphics?  Specifically, one that will output the left and right half values to a text file (or cut and paste) to include in a dasm listing?

931225[/snapback]

 

I use QBASIC and text editors for my miscellaneous graphic editing needs. Does that make me weird?

[djmips]

Is there a tool out there that can be used to design asymetrical background images using the PF graphics?  Specifically, one that will output the left and right half values to a text file (or cut and paste) to include in a dasm listing?

931225[/snapback]

 

I use QBASIC and text editors for my miscellaneous graphic editing needs. Does that make me weird?

931644[/snapback]

 

No... it's not that what makes you weird....

 

 

 

 

 

 

 

 

 

 

 

 

 

(it's the programming the 2600 that's what)

Edited September 15, 2005 by djmips

[Cybergoth]

Hi there!

 

I use Paint Shop Pro and then just let Eckhard Stolbergs PCX2GRP tool convert everything.

 

Greetings,

Manuel

[brpocock]

For Linux/Unix users (or those with access to a Linux/Unix box) the following Perl script can handle conversion of 8px, 16px, 20px, or 40px wide monochrome PNG's (white and black only, sorry...) into dasm-compatible data listings. The artwork is stored top-down, though, so if you reverse your scanlines to count down, you'll want to flip the images vertically to match.

 

It sorts pixels in the PNG based on brightness, drawing in black and white is recommended for reliable results though.

 

Just for human readability it also adds comments with "undumped" copies of the artwork.

 

I use Gimp to draw out the artwork and keep the .png's in the project directory for editing, and then use a rule like this in my Makefile:

 

gen/%.s:   art/%.png
       tools/mkart $< > [email protected]

obj/art.o:   src/art.s gen/something.s gen/somethingelse.s gen/anotherthing.s
       $(AS) src/art.s -oobj/art.o

 

...and then have "art.s" as nothing but:

 

       seg rom
      org $f800; or whatever
      include "../gen/something.s"
      include "../gen/somethingelse.s"
      include "../gen/anotherthing.s"

 

It's probably overkill for the 2600 but it means I never have to worry about the ROM image coming out with different artwork than I last doodled in Gimp, since Make will take care of it all for me.

 

I have half a mind that I should be generating the "src/art.s" file and the Makefile rule for it automatically, but I haven't been doing that yet. In fact... I'm still working on my first real and true project. (I'm a strong believer in making the computer do as much work for me as possible)

[tmont]

I want to join the party! I wrote another crappy (maybe not?) little applet a while ago to accomplish this:

 

Warning! Math major trying to do computer science!

 

http://www.wou.edu/~tmontg1/atari/PlayFiel...ieldEditor.html

[+johnnywc]

I want to join the party!  I wrote another crappy (maybe not?) little applet a while ago to accomplish this:

 

Warning! Math major trying to do computer science!

 

http://www.wou.edu/~tmontg1/atari/PlayFiel...ieldEditor.html

1001719[/snapback]

Great job on this! Very easy to use and the best part is that if you choose a pixel height > 1, it automatically lines up the pixels on the proper vertical boundary. The other editor doesn't do this and makes drawing mazes, etc. very difficult to do.

 

EDIT: Wow - you even support asymetrical / reflect mode! I could of really used this tool when doing my re-write of Caverns of Mars!

 

Thanks!

 

 

-

Edited January 17, 2006 by johnnywc

[djmips]

That's real fun, HeckYesYouDid. How about sharing the source? And could you make it so that the editor had the same aspect ratio (or close) to the TV screen?

[vdub_bobby]

EDIT: Wow - you even support asymetrical / reflect mode!  I could of really used this tool when doing my re-write of Caverns of Mars! 

That's cuz he designed it to my specs.

[tmont]

That's real fun, HeckYesYouDid. How about sharing the source? And could you make it so that the editor had the same aspect ratio (or close) to the TV screen?

1002051[/snapback]

 

Source, although it was several months ago, and no doubt hideous: http://www.wou.edu/~tmontg1/atari/PlayFieldEditor/Source/

 

I had five classes: one for the main applet, one for the import window, one for the code window, one for the color window, and one for the help window. For real giggles, check out the giant, disgusting method I wrote for the import function. Whoever can decipher that madness gets a very big cookie.

 

Aspect ratio... I know very little about programming (just enough from vdub_bobby so that I could write this thing), so I'm going to need more elaboration. Sorry.

Edited January 18, 2006 by HeckYesIDid

[supercat]

I want to join the party!  I wrote another crappy (maybe not?) little applet a while ago to accomplish this:

http://www.wou.edu/~tmontg1/atari/PlayFiel...ieldEditor.html

1001719[/snapback]

 

Looks pretty good. A few suggestions:

 

-1- Sometimes it can be useful to have the tables for each column defined as a macro. This allows for the background data for the whole screen to be in one file, and yet for the different columns of data to be stored at different spots in the code (may be necessary when working around page restrictions, etc.)

 

-2- Some applications may need data in row-major rather than column-major order. Adventure comes to mind, but there are others.

 

-3- Not sure how best to implement this, but it might be nice to support variable-resolution kernels like the one in Nukey's adventure hack. Producing screens for that by editing the hex requires constant testing to see if everything is as it should be; having controls to the left of each row to split and join rows might be useful.