Conversion Capers: Rygar

[sandruzzo]

Originally Posted by Codetapper

Check the zone for an example of the output from my map software. Most files should be self explanatory, but the "Popular" extension are tiles that are in the map more than 10 times (from memory), and "Rare" I believe are tiles used 3 times or less. If you overlay the rare image over the full map, you can see exactly where these hardly-ever-used tiles are. The tiles are not laid out logically in blocks or anything, it simply works left to right, top to bottom adding tiles as it goes. The whole program is meant to cut up full level rips rather than having to piece levels together. And I have no idea what palette you're using so this is just a rough example.

Checked! Wow what a work! So now I have the tiles' map and block image. I'll work around them. About palette, I'll convert iff file and use it.

@CodeTapper

Thanks Mate

[Codetapper]

The app does the work, all I did was load the background and hit the button. It outputs all those files itself!

[sandruzzo]

Originally Posted by Codetapper

The app does the work, all I did was load the background and hit the button. It outputs all those files itself!

Are we talking about PowerCrawler?

[Codetapper]

No, a program I knocked up a few years ago to convert an image into a map. It outputs PowerCrawler compatible maps if you need to edit them on the Amiga though, and the map format is pretty efficient anyway - just 100 or so bytes wasted at the start of the map file.

[sandruzzo]

Originally Posted by Codetapper

No, a program I knocked up a few years ago to convert an image into a map.

A ok. Is it in the Zone?

[nobody]

That program helps a lot, if we have a palette for the sprites and tiles and use it or use the current one, then most job is done.

[sandruzzo]

@nobody

We have te palette for sprite, and about tiles, we use them to extract it.

[Cylon]

Thanx, Codetapper!

Just about what i was thinking a few pages ago:

Originally Posted by Cylon

Tile ripping is actually quite fun, once one got the correct offset and the bobs are removed, everything fits together:
The ripping itself/tile elimination could be done with a tool.
Rygar-Round2_nobg4_test.png (29.8 KB)

Good to know someone actually made it happen.

[Shatterhand]

I am looking forward to see this. I don't know any way I can help, but motivate you guys working on it. I would love to see this running on a standard ECS machine

[sandruzzo]

We do what we can do!

[sandruzzo]

Shit, we have some conflict with rygars' palette and tiles' palette!!

[Shatterhand]

Well, I can help by playtesting it. Guess it's not a big help, but if you want someone to playtest it, I'd love to do it

I was playing Rygar arcade just yesterday, after I saw this thread.

The controls have to be well adapted, since with just 1 button, you will have to use up to jump, but up+button also does a specific attack.

Please, consider supporting 2 buttons controllers

[nobody]

Originally Posted by sandruzzo

Shit, we have some conflict with rygars' palette and tiles' palette!!

I think if you use 32 colors in playfield, sprites don't have exclusive use of colors maybe i am wrong.
I think this is one of the drawbacks of 32 color mode but not sure.

[sandruzzo]

Originally Posted by nobody

I think if you use 32 colors in playfield, sprites don't have exclusive use of colors maybe i am wrong.
I think this is one of the drawbacks of 32 color mode but not sure.

you're right. the latest 16 colors are shared.. We have to do some changes with sprites, not a great issue

[sandruzzo]

We have to rethink palette distribution. To all. Is it better to have the first 16 colors for enemies and the others 16 for background or vice versa?

[Tsak]

Have a unified 32 color for everything. Sharing the same colors is not a problem if you apply some selective outlining to the sprites (using the darker shades of the palette). In the end, the sprites will still be faithfull to the original while the overall gfx quality will be uplifted
due to the extra colors used.

[Codetapper]

I would personally go for a different approach. Rip as many screenshots of the sprites and levels as you can, and work out which colours can be shared throughout the entire game.

For example, you might find there are 20 colours that are commonly used (including the Rygar sprite which of course will have to have a fixed portion of the palette as it will not change between levels). Rygar might use 8 colours, so those 8 will be fixed in the sprite palette region (colours 17-24). If you wish to do some 3 colour sprite multiplexing with sprites 6 and 7 for the background layer (changing palette regularly), then you'll have to leave colours 29-31 free in the palette.

It also helps if you know which vertical sections of the screen can only have certain enemies in them, as you can change your palette for those regions. But you really have to analyse the game thoroughly before you begin, as there's nothing worse than assuming the bottom lava part is always browns and red colours, then finding that on a later level you can have lava and water, and enemies that fly into it at the same time and you've assumed that could never happen etc.

After all of this, you should know where you have free palette entries, and it won't really matter where you have them. Since you're using sprites for Rygar, it would seem that your colours for the backgrounds (and enemies) will more than likely sit in the first 16 colours, but of course it will be optimal to have some of the enemies sharing colours from the Rygar sprite (greys and pink etc).

[Cylon]

Hi,
i am still screwing around with the level tiles manually. I've removed the support colours and now my pal is down to 32!
As mentioned before there are a lot of colours we need to preserve for baddies and sprites and so on. Thats why i want to promote the AGA approach again.
Note: With AGA you can select the colour palette range used by sprites.

The white grid must go sometime, the color itself is used somewhere else too.
Here is my share of work for you to mess with:

[sandruzzo]

@cylon

Challenge is to have it on ecs machine. Aga maybe later.

@Codeteapper

I like your approch, but 16 colors for all, is a to few' I've seen many time rygars' long play, and we can work witj copper to add color in the floor and trees' upper portion

[Codetapper]

I'm not suggesting 16 colours for everything, I'm saying will be a block of colours that are always the same, if that happened to be 20 then you'd have 12 left for each level that can be changed, and within those 12 you can use the copper to alter them down the screen.

@cylon: I don't think constructing the levels that way is a good use of time. Just rip the whole level and recolour it with a paint program, and my app can cut it into the tiles itself. Breaking trees into their individual bits etc seems a waste of time. Presumably sandruzzo is going to use the original level maps, so there's no point reconstructing them. You only need to colour reduce them and work out which bands can work for colour changes without making the enemies change colour when they swoop down/up the screen.