Jump to content
IGNORED

Image Tools


GadgetUK

Recommended Posts

What image editing software do you guys use that works with sprpck and CC65? Ive been getting wierd stuff when using Paint Shop Pro and Fireworks. If I load the images in any gfx package they look OK, yet on the Lynx or in Handy the are completely wrong palette wise. The generated .pal files look OK and ive set the palette according to the palette in the .pal file, having seperated the green byte first into the first 16 bytes of the palette char array. This was fine with the old palette I first tested the process with but now doesnt seem to be working.

  • Like 1
Link to comment
Share on other sites

The problem with Gimp is I cannot see how to save as a bitmap...

 

is this correct:-

 

//my palette as defined from the .pal file at the bottom

char titlepal[]={0x00,0x00,0x00,0x08,0x09,0x08,0x08,0x08,0x0C,0x00,0x00,0x0C,0x0A,0x0F,0x0F,0x0F,

0x00,0x08,0x80,0x00,0x5D,0x80,0x08,0x88,0xCC,0x0F,0xF0,0x00,0x1F,0xF0,0x0F,0xFF};

 

Output in the .pal file:-

redir: dc.b $01,$23,$45,$67,$89,$AB,$CD,$EF

pal: DP 000,008,080,800,95D,880,808,888,CCC,00F,0F0,C00,A1F,FF0,F0F,FFF

And what purpose does 'redir' serve?

Link to comment
Share on other sites

I used MS Paint in the past; it was very good (because of its simplicity) for low res bitmaps like for Lynx. Sadly the program has been crappified for Windows 7, handling has gotten more complicated and it frequently destroyed colors every other program could handle when saving.

 

I second matashen's recommendation of ProMotion, it's good; you can test it for free 30 days.

 

Right now I am using Gimp. To be honest, Gimp is not very intuitive, and not really comfortable to work with for pixel graphics, but i will do. It's good for rearranging palettes and fixing colors though. For actually pixeling you'll probably find better freeware alternatives than Gimp ifyou look though.

Link to comment
Share on other sites

The problem with Gimp is I cannot see how to save as a bitmap...

 

is this correct:-

 

//my palette as defined from the .pal file at the bottom

char titlepal[]={0x00,0x00,0x00,0x08,0x09,0x08,0x08,0x08,0x0C,0x00,0x00,0x0C,0x0A,0x0F,0x0F,0x0F,

0x00,0x08,0x80,0x00,0x5D,0x80,0x08,0x88,0xCC,0x0F,0xF0,0x00,0x1F,0xF0,0x0F,0xFF};

 

Output in the .pal file:-

redir: dc.b $01,$23,$45,$67,$89,$AB,$CD,$EF

pal: DP 000,008,080,800,95D,880,808,888,CCC,00F,0F0,C00,A1F,FF0,F0F,FFF

 

And what purpose does 'redir' serve?

 

To save as a bitmap you just chose File->Save and give a name like Tree.pcx or Tree.bmp. Gimp will automatically pick the format depending on your extension.

 

The redir is thought as the penindex for this sprite. You may give a penindex area after the sprite where you can map the sprite pixel number to any real color number by defining the mapping in the penindex.

 

So if you have a binary sprite that has only 1 bit per pixel then you can add a penindex that maps this color to anything from the palette.

 

Like:

typedef struct {
 SCB_REHV sprite;
 PENPAL_1;
} sprite_t;

sprite_t LeftPaddle = {
 {
   BPP_1 | TYPE_NORMAL,
   LITERAL | REHV,
   1,
   0,
   paddle,
   10, 73, 256, 256
 },
 {COLOR_GREY}
};

 

In reality the COLOR_GRAY is 4 so the penindex is 0x04. This means that the pixel value 0 becomes 0 and the pixel value 1 becomes 4.

Link to comment
Share on other sites

OK, thanks for clearing that up! I am still having an issue relate to the palette that's driving me mad...

 

I've started using Gimp! I create a bitmap, 160 x 102, created a 16 colour palette, saved it (not using RLE so sprpck doesnt complain) and when I run it through sprpck its fine but my palette shows like this:-

 

redir: dc.b $01,$23,$45,$67,$89,$AB,$CD,$EF

pal: DP 445,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000

 

Yet when I open the bitmap with any graphics package I can see the image correctly and the palette is still there - 4bit, 16 colours with the same colours mapped to the bitmap.

 

What is going on here, am I using a buggy version of sprpck or something? Date Modified 09/04/2003 @ 09:42.

Edited by GadgetUK
  • Like 1
Link to comment
Share on other sites

For clarity, here's the switches I am using with sprpck:-

 

-t6 -p2

 

And here's the image. The actual image is messed up colour wise, its long since lost how its supposed to look, all I am trying to do is get ANY bitmap showing on the Lynx with the correct palette assigned to the bitmap.

 

http://www.c5softwar...titlescreen.bmp

 

Incidentally, I won't be doing the title screen as a full screen image, it makes more sense to blit seperate sprites to avoid lots of wasted ROM etc. I just need to try and work out why sprpck is now giving me all zeros on the .pal file.

 

Previously (and I dont know how...) I used the same looking image through sprpck last week and it gave me a proper .pal file, and when I move the green byte to the first 16 entries in the array everything displayed properly.

Edited by GadgetUK
Link to comment
Share on other sites

Arghhhh!! I though I had sorted it. If you untick the 'Include Colour Space Information' in Gimp when exporting you get this instead:-

 

redir: dc.b $01,$23,$45,$67,$89,$AB,$CD,$EF

pal: DP 000,008,080,800,95D,880,808,888,CCC,00F,0F0,C00,A1F,FF0,F0F,FFF

 

Which ive changed to:-

 

char titlepal[]={0x00,0x00,0x00,0x08,0x09,0x08,0x08,0x08,0x0C,0x00,0x00,0x0C,0x0A,0x0F,0x0F,0x0F,

0x00,0x08,0x80,0x00,0x5D,0x80,0x08,0x88,0xCC,0x0F,0xF0,0x00,0x1F,0xF0,0x0F,0xFF};

 

 

Yet is shows like this (after loading that palette):-

 

 

wierd.png

 

 

 

I thought this was going to be fun and easy lol. iPhone development was the toughest thing ive had to get my head round, and this is more frustrating than iphone development lol.

 

EDIT: The positive news is that I burnt this to ROM and ran it on the Lynx and it looks the same (incorrect palette), and it runs at the same speed as in Handy, and gun fire sounds the same.

Edited by GadgetUK
Link to comment
Share on other sites

Ive sorted this finally!! The solution was to use a different sprite type and pass the redir value in there - I understand how it works but not why the other type that Karri suggested doesnt work with default palette order, but it is related to palette order from what I can see.

 

SCB_REHV_PAL titlesprite = {

BPP_4 | TYPE_NORMAL,

PACKED | REHV,

0x01,

0x0000,

&titlescreen[0],

0,

0,

0xFF,

0xFF,

{0x01,0x23,0x45,0x67,0x89,0xAB,0xCD,0xEF}

};

 

 

I've now got a large chunk of the core mechanics working. Scoring, enemy spawn, shooting, death and removal delays and automatic removal of dead enemies, plus the main navigation of the game menus. Just need to work on animation, more work on sprite movement, bosses, cover, enemy fire, and cosmetics.

Edited by GadgetUK
Link to comment
Share on other sites

I am not sure if this is relevant, but the SCB with a palette is needed whenever you want to change the palette or need to set it the first time round. The SCB palette registers hold onto whatever value was last written to them. Theoretically you only need to set the palette once (ever) if you're using the same palette in your bitmaps all over the place and do not do any fancy color changing in your sprites. Well, that's the theory.

 

I cannot believe how much you have gotten done in such a short time.

Need any new tutorial episodes on a particular topic? ;)

Link to comment
Share on other sites

Thanks, I totally understand the palettes issues i had been experiencing now! Ive also seen how amazingly powerfull this feature is, because with a small change to the redir value in a SCB and you can have different coloured enemies =)

 

Ive made excellent progress so far, basically because of how well the Lynx framework has been put together in CC65. EDIT: And your superb tutorials, combined with the support from Karri and orhers here! Ive not handled collision detection yet - I am doing manually with bounding box atm which is eating cycles, so if youve not done a tutorial on that I could sure use some examples. What else would be usefull is a way to change the anchor points on sprites in code - but I am not sure thats possible as its probably related to the order of pixel data?

Edited by GadgetUK
Link to comment
Share on other sites

EDIT: And your superb tutorials, combined with the support from Karri and orhers here! Ive not handled collision detection yet - I am doing manually with bounding box atm which is eating cycles, so if youve not done a tutorial on that I could sure use some examples.

Thanks for the compliments (on behalf of all). I am working on the collision detection now. Stay tuned.

Link to comment
Share on other sites

The 10th part of the tutorial is online. It covers the basics of collision detection. I wanted to get this out here so people can start reading it.

This part uses the latest build of CC65 with all the new definitions (e.g. sprites). I will revisit the earlier ones later to update those as well.

I have attached the source code for all tutorials. Hopefully they help understanding the tutorials better.

If you see any mistakes or have other comments, suggestions or tips, I will be happy to hear them and use them to improve the posts.

http://atarilynxdeveloper.wordpress.com/2012/12/09/programming-tutorial-part-10collisions/

Tutorials.zip

Edited by LX.NET
  • Like 1
Link to comment
Share on other sites

That is another great addition to your tutorial!! Ive implemented it now and it works but not quite as expected!

 

Ive had to declare the byte as an int or a char, and for some reason the result of an index of 1 actually = 256, 2 = 512, etc, so if I shift by 8 bits it matches the value passed in the sprite collision index properly. I cant use the byte data type atm.

 

I also need to work out how to disable collision detection on background sprites tommorrow night after work.

 

Thanks for doing this over the weekend, its much appreciated.

Link to comment
Share on other sites

That is another great addition to your tutorial!! Ive implemented it now and it works but not quite as expected!

Thanks. Your compliments are a great encouragement.

Ive had to declare the byte as an int or a char, and for some reason the result of an index of 1 actually = 256, 2 = 512, etc, so if I shift by 8 bits it matches the value passed in the sprite collision index properly. I cant use the byte data type atm.

It is a recent change that I requested and that Karri has made to CC65 (2 weeks ago maybe?). The depository is only a single byte, yet the previous implementation of tgi_setcollisiondetection set the relative offset to -2 ($FFFE). You are describing exactly how it used to be. Now, the recent snapshot has the $FFFF for -1 and a byte will work. (Tested it yesterday with the tutorial).

I also need to work out how to disable collision detection on background sprites tommorrow night after work.

 

Thanks for doing this over the weekend, its much appreciated.

I am working on a pens tutorial now. There is sample code for pens in the zip already. The trick is to use TYPE_BACKGROUND or TYPE_BACKNONCOLL instead of TYPE_NORMAL for the SPRCTL0 and the proper pens (pen 0, E and F are special). The spec has a pretty nice write-up on this here: http://monlynx.de/lynx/lynx6.html#_62

Edited by LX.NET
Link to comment
Share on other sites

  • 1 month 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...