Jump to content
IGNORED

2600 Sprite Creator(s)


vdub_bobby

Recommended Posts

My brother saw Kirk Israel's PlayerPal ( http://alienbill.com/2600/playerpal.html) and thought he'd try to code something similar in a Java applet. So here it is: http://www.wou.edu/~tmontg1/atari/SpriteCr...iteCreator.html

 

It is pretty cool, if I do say so myself: you can edit up to 12 frames at once, change colors line-by-line, animate at a wide variety of speeds, generate data, import data, and switch between single-, double-, and quadruple-width players. It also uses the (approximately) correct NTSC pixel ratio and uses the NTSC palette.

 

It also allows click-and-drag editing.

 

Pretty similar to Kirk's new PlayerPal (here: http://alienbill.com/2600/playerpalnext.html), but just different enough that it's probably worth knowing about both. I'll probably use both in the future.

Link to comment
Share on other sites

My brother saw Kirk Israel's PlayerPal ( http://alienbill.com/2600/playerpal.html) and thought he'd try to code something similar in a Java applet.  So here it is:  http://www.wou.edu/~tmontg1/atari/SpriteCr...iteCreator.html

858148[/snapback]

 

It looks very promising. Is there any chance of him releasing a standalone Java application version which would allow you to load/save sprite data from/to files?

 

Chris

Link to comment
Share on other sites

My brother saw Kirk Israel's PlayerPal ( http://alienbill.com/2600/playerpal.html) and thought he'd try to code something similar in a Java applet.  So here it is:  http://www.wou.edu/~tmontg1/atari/SpriteCr...iteCreator.html

858148[/snapback]

 

It looks very promising. Is there any chance of him releasing a standalone Java application version which would allow you to load/save sprite data from/to files?

 

Chris

858373[/snapback]

I dunno. I'll ask him if he doesn't pop in here his ownself, which he does do occasionally.

Link to comment
Share on other sites

I'm the one who created this thing, by the way. And just so there's no bad blood, I basically ripped off the idea from Kirk Israel, but I started it like two weeks ago, before he made all the changes. I originally only started making this because his playerPal responded slowly, and the layout was kind of confusing (in my opinion). However, now that he's upgraded substantially, it kind of neutered everything I set out to do. So now mine is more of an alternative to his...

 

It looks very promising. Is there any chance of him releasing a standalone Java application version which would allow you to load/save sprite data from/to files?

 

That was actually my original intent when starting this project, but I kind of got bogged down. Since I know next to nothing about Atari 2600 programming, I was mainly just trying to make everything accurate. In response to your question, I originally had an option to load/save to separate files, but I took them out because 1) they were pissing me off, and 2) because you can just cut and paste your code whever you want, although that's a little inconvenient compared to clicking on a button and finding a file. I'll see if I can incorporate them back in, though. :)

 

And there's still a couple bugs in it. Most noticeably, when you try to change the color, it doesn't always change everything it should. And I need tweak the code input/output a little bit, too.

 

Thanks for the feedback!

Link to comment
Share on other sites

Here's more idea on New DK with the playing feild. Again Im not a real game programer but Im good in art^_^

858509[/snapback]

Heh -- I should have the editor come up with slogans like "just you can paint it as a player don't mean it's gonna be easy to make it run on an atari" ;-)

 

(specifically, it would be tough to get a girder made out of a player graphic, it pretty much needs to be a playfield...)

Link to comment
Share on other sites

Hey, not bad....though I think it's really tough to get the colors going...and why is the Animate button always greyed out?

 

http://alienbill.com/2600/playerpalnext.html - it's limping along. Actually it's pretty much fully functional except for importing source code, and a few minor tweaks....well, you can see the "ToDo" tab. My Animate feature works but it doesn't put all the sqaures back so I probably need to redo it.

Edited by kisrael
Link to comment
Share on other sites

Hey, not bad....though I think it's really tough to get the colors going...and why is the Animate button always greyed out?

You have to change the number in the text box (next to the Animate button) to a number greater than zero and then press ENTER (in the text box).

 

Also, just thought I'd point out what I think is the coolest part about this sprite creator: the ability to edit 16-, 24-, 32-, 40-, or 48-pixel-wide sprites as single giant sprites and then get outputted data separated into the 8-pixel widths that the Atari can handle.

 

I just think this is really neat. I am biased, though, since I did specifically request this :D

Link to comment
Share on other sites

Hi there!

 

Also, just thought I'd point out what I think is the coolest part about this sprite creator: the ability to edit 16-, 24-, 32-, 40-, or 48-pixel-wide sprites as single giant sprites and then get outputted data separated into the 8-pixel widths that the Atari can handle.

861591[/snapback]

 

I use Paintshop Pro for this. There's Eckhards wonderful PCX2GRP tool available, which'll convert everything to usable data.

 

So for example I could draw all Seawolf sprites at once in Paintshop, then converting them all with a single comand.

 

It's very cool to work like that, because in Paintshop you can already import everything, MAME screenshots, C64 or A800 screenshots, whatever and just compose your final image.

 

The title screen of Crazy Balloon for example. mojofltr posted a small GIF image here in the homebrew section, I simply converted it to PCX and in less than a minute I had it included in the game.

 

PCX2GRP is very mighty, here's a manual excerpt:

 

PCX2GRP [flags] PCXFILE.PCX DATAFILE.ASM

 

The flags that you can specify are:

 

-x## Number of objects per row. Player objects on the VCS are always

8 pixels wide and PCX2GRP starts scanning in the top left corner

of the graphics file, so align your objects accordingly. Since

the graphics file is 320 pixels wide and the player objects are

at least 8 pixels wide each, this number can be a maximum of 40.

 

-y### Number of objects per collumn. Player objects on the VCS can have

any height up to the screen size. Since the graphics file must be

200 pixels height, this value can be a maximum of 200.

 

-h### Height of one object. Due to the format restrictions for PCX files,

this value can be a maximum of 200.

 

-r# Number of pixels in the graphics file per object pixel. The

horizontal resolution of the VCS is 160 pixels. To be able to

see the player objects in the original proportion while editing

you might want to use two pixels in the PCX file to represent

one pixel of the object. Also the VCS allows the programmer to

double or quadrouple the size of the object pixels. To allow you

to edit the objects in the same fashion, this flag lets you skip

every so many pixels while scanning the PCX file.

 

-d Skip every other line. Many VCS games use a double scanline

resolution to get enough cycles to update all the graphics. If

you want to edit your player objects this way, you can tell PCX2GRP

to skip every other scanline while scanning the graphics file.

 

-c Suppress the generation of colour data. By default PCX2GRP creates

one table per object for the shape and one for the colour information.

If you want to use only monochrome objects, you can use this flag.

 

-o Scan top-down instead of bottom-up. Most programs count down the

index pointer into the graphics data as the display advances.

Therefore PCX2GRP generates the graphics table from the last line

to the first. If your program has to count up the index pointer, you

can use this flag.

 

-p Align data on page boundaries. The 6507 processor in the VCS takes

an extra cycle, if an indexed access to a data table crosses a 256

byte page boundary. If you have a lot of graphics data and want to

make sure that no access to it has to go across a page boundary,

use this flag. Then the data table will be filled up with zeros, if

the data for a new object would cross a page boundary.

 

-a Generate data for the ASM6502 assembler instead of the DASM

assembler. ASM6502 is an old assembler that I used before I found

DASM. It requires to define bytes in a different way. This flag

is only left in for historic reasons.

 

-l Interpret colours values between 128 and 255 as object pixels and

colour values between 0 and 127 as background pixels. If for some

reason your preferred painting program makes it easier to create

the graphics with this setup, use this flag.

 

Greetings,

Manuel

Link to comment
Share on other sites

That sounds like the best option for importing graphics; I guess I should scale my ambition for PlayerPal to be the best option for doodling up original graphics...

 

Is there a PCX2GRP for Playfield Graphics? I think that could be more blatantly useful than for player graphics...

 

In terms of multiwidth graphics...hmm, perhaps I could look into an option to display all the frames right next to each other with no breaks; that would have the same effect I think. I don't think I'll be outputting code to display it that way though.

Link to comment
Share on other sites

Hi there!

 

Also, just thought I'd point out what I think is the coolest part about this sprite creator: the ability to edit 16-, 24-, 32-, 40-, or 48-pixel-wide sprites as single giant sprites and then get outputted data separated into the 8-pixel widths that the Atari can handle.

861591[/snapback]

 

I use Paintshop Pro for this. There's Eckhards wonderful PCX2GRP tool available, which'll convert everything to usable data.

 

So for example I could draw all Seawolf sprites at once in Paintshop, then converting them all with a single comand.

That's cool, and good to know about. But the java sprite creator will animate the large sprites for you and the entire process (drawing to usable data) is probably less complicated (no command line, only one application). Add in the (NTSC) aspect ratio, NTSC palette, and the ease of creating double-/quadruple-width sprites (all found in Kirk's and Tommy's sprite creators) and I think there are uses for all.

 

Plus I'm poor/cheap and I don't own a good paint program, though for something like this MS Paint is probably good enough. :D

 

The more tools, the better!

Link to comment
Share on other sites

Hi there!

 

Is there a PCX2GRP for Playfield Graphics?  I think that could be more blatantly useful than for player graphics...

861687[/snapback]

 

It works for the playfield as well. You just need to mirror every other column (easy task in paintshop). That's how I converted 40+ Jumpman levels. Basically I just downsized A800 screenshots and ran the tool over it :)

 

Greetings,

Manuel

Link to comment
Share on other sites

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...