Oh my gosh ! Stimulating project.

Edit : Ok, found the discussion thread.

Great news and good luck with the project. Looking forward to watching the youtube videos of progress.

I took a little break from the sprite extraction stuff and decided to test my theory on the scrolling with 8 bit planes.

The video below is a simple scroll test which is blitting the back 3 bit planes to show that the engine would actually work, what is in front is just a simple 32 colour bit map in the front 5 bit planes.

There's no double buffering or anything going on so it appears a bit jerky but the important thing is that I can scroll 2 playfields, 1 at 32 colours and the other at 8 colours... dual playfield mode in 16/16 colours just won't do the game justice.

https://youtu.be/2k07qEndzPY

that's awesome. Your work makes me wonder why arcade conversions were so lame at the time (except for a few ones), when people were actually PAID to do the stuff :)

Well, sometimes they were provided with the arcade cabinet in free play and "figure the rest out"... Now there's MAME. Makes a difference in the gfx section. The gfx rip from ROM still needs work though. For having tried on a few games, it's far from obvious, even in amiga games.

Are you sure you want to use native development tools for your games? Since I migrated to VASM for whdload slaves, JST & CD32load, asm development became way easier. The only drawback is that you have to switch between winuae and notepad++ (but you can add a hotkey to notepad++ to run a makefile to call vasm)

Having the graphics for a game makes a big difference, especially if you're a coder and crap at drawing like me. My thoughts on the arcade ports are when the license was granted from the original creators to do the ports, it didn't matter what shit they churned out...as long as it looked good on the back of the game box people were going to buy it. Then there were the bribes that went to the magazine reviewers too whcih didn't help.

I actually use both. If I want to knock up something quick I'll use Devpac/MonAM as it's faster, however as the project grows I'll move to VASM/Notepad++ toolchain.

as you must know games weren't made with large bitmaps they used a tiles map .

excellent work mcgeezer. How much ram is free with that?

One of the reasons could be time. I read an interview over on Codetapper's site with Dave Semmens, who converted some non-arcade games to the Amiga (notably the Lion King). He tended to get one or two months to do the job. That doesn't leave much time for nice stuff!

Of course, I'm assuming here that Arcade conversions where no different here (partly because I saw the end titles for R-Type on the C64 bragging about how it was converted in just six weeks). But it would answer a lot.

Yeah. Conversions were rushed. Not a labor of love like some other games. And not having access to the original material didnt help.

BTW what did you plan in the audio department? AFAIR the music could be remade by sampling 3 or 4 parts and loop them together. It's not like it's changing a lot.

I don't know if it would be of any use to you but i can extract the tiles from the gfx view in MAME. Depending on how the game handles palettes it can be a pain to find the right colours but could be useful in extracting the tiles and sprites.

I did it already, it took me 3 days to get all the level tiles with the right palette.

I'm doing it with a much smaller game and it is rather time consuming.

Thanks for this. Unfortunately they are useless without the game level maps.

The maps are not easy to extract from the ROM either, for example, each 16x96 block of pixels is referenced by a single byte that is interleaved to draw the upper and lower portion of the display.

So the bytes might go something like this...

Even with this it goes off on a tangent and does weird things... I may take another look at it later to see if I can reverse engineer it.

There is another way I can do it but even that is a bit tedious, but it means the levels will be accurate which is what is important.

I used a technique when remaking gods. Identify the tile size and recognize the tile from picture and rebuild the map. Of course it needs a perfect copy of the background image.

I can turn the picture into a map if it helps but I tried it before with Rygar and felt the tiles don't align correctly like you say in your above post.

Its a map and then trees on top or rocks etc.

This is the technique I'll be using. The trick is getting that perfect background image - very time consuming.

Is it me or the japanese have a very special way of coding? I've reverse-engineered a lot of (simple) games, all french-coded or english-coded and I wasn't that lost. On the other hand, when I tried to reverse some japanese titles I had a tough time (moon patrol, pang)

You have to admire their game designers, when you start to look at their games you realise just how well they are designed and the software engineers and artists are brilliant at memory efficiency.

Cool project mate! Best of luck! :great

Yes, their games are very good, also more difficult to reverse engineer. They're also very secretive with their source code. They NEVER provide their code to sub-contractors. All home conversions of arcade ports don't have the original code. Mortal Kombat has some original code from the arcade (but I think the company is american)

For the tiles, one technique I was using was to paste one image onto the other with overlap. If the image moves when pasting, then there's a problem. but one error and the tile recognition system is toast. TBH I used that on pixel-perfect game maps, probably ripped from original logical tile data :)
I also used that on custom-made levels done with paintshoppro with grid lock on 32x16