This thread is for all those who like this game and want it to be ported on the Amiga. You may well think it is overly ambitious, especially because sources are not available, but I started the project anyway and got some interesting result.

Of course, to run it you'll need the game data files and I can't provide those.
Note that this is a full port using original code that I have reSourced, not a complete rewrite like Free Heroes2.
It also works (or must work ) on regular AGA machines with 16MB ram.

Now, I'm here to ask for help. I especially need :
- coders expert in fast hires chunky graphics
- musicians who can convert/redo midi (or cd audio) musics into regular tracker
- audio programmers who can do fast 4 or more mono channels playing from fastmem with good quality (for both music and sfx)
- coders expert in floating-point ops removeal (there is a legion of them, and computer AI is very slow because of this)
- someone who can reSource and/or decompile the PC versions so I can use that to implement h2x extensions not present in the Mac 68k version I've used

I can give the sources to whoever wants them, but beware : they are large.

There are many bugs, but you can theoretically play. Don't expect the game to be fast, but it's not very slow either.

You can help in several ways, including play testing. But please read the readme file in the archive before reporting anything !

I don't think there's a difference between high and lowres c2p except that because you're using interlace you only have to update half the number of scanlines per frame (needs double buffering). This may sound silly, but why not convert the graphics to bit planes and do the effects using chunky+c2p?

If you're going to have mixing in the game, then it's probably best to simply resample the cd audio and sound effects (on the peecee using Sox), and mix the music with the sound effects. Fast and simple once the audio is converted, and you get 14 bit quality. At the price of larger game data.

I don't think there's a difference between high and lowres c2p except that because you're using interlace you only have to update half the number of scanlines per frame (needs double buffering).

No way ! Updating half the scanlines in one frame isn't possible (already too slow). So I update when program says that an area needs to be updated - and only this area.

Quote:

Originally Posted by Thorham

This may sound silly, but why not convert the graphics to bit planes and do the effects using chunky+c2p?

Because it probably would end up being slower. Planar graphics are quite a pain to blit with the cpu, and they're WAY too numerous to fit into chipmem (in fact, sounds don't even fit and I had to play from fastmem).

Quote:

Originally Posted by Thorham

If you're going to have mixing in the game, then it's probably best to simply resample the cd audio and sound effects (on the peecee using Sox), and mix the music with the sound effects. Fast and simple once the audio is converted, and you get 14 bit quality. At the price of larger game data.

You can not pre-mix SFX with music because they don't happen synchronously with it. SFX can be played directly and don't need to be resampled, and cannot be pre-mixed either.

No way ! Updating half the scanlines in one frame isn't possible (already too slow). So I update when program says that an area needs to be updated - and only this area.

Sorry about that one, I wrote to fast. That interlace technique can only be used if writing half of the scan lines takes less than a frame, my mistake. If it would always take less than one frame, then you could even use interlace as a souble buffering system, because only half of the scan lines are shown. In this case that doesn't matter, though, so just forget this none sense

Quote:

Originally Posted by meynaf

Because it probably would end up being slower. Planar graphics are quite a pain to blit with the cpu, and they're WAY too numerous to fit into chipmem (in fact, sounds don't even fit and I had to play from fastmem).

How is cpu blitting slower than c2p? Anyway, I said it might not be useful

Quote:

Originally Posted by meynaf

You can not pre-mix SFX with music because they don't happen synchronously with it. SFX can be played directly and don't need to be resampled, and cannot be pre-mixed either.

That's not what I meant. The music is resampled to a frequency the audio dma can handle, and the same goes for the effects, where both of them have the same sample rate. Now you can easily mix them at run time in the game as needed. If you want more than four channels total you already have to mix, so why not make it easy? Pre-mixing would mean you'd have to mix for every possible combination, and that would probably take up millions of exa bytes

Sorry about that one, I wrote to fast. That interlace technique can only be used if writing half of the scan lines takes less than a frame, my mistake. If it would always take less than one frame, then you could even use interlace as a souble buffering system, because only half of the scan lines are shown. In this case that doesn't matter, though, so just forget this none sense

It's not a bad idea to use that kind of interlace trick, but sadly chipmem is too slow even for this.
Besides, you might regret that the day your game works on a non-interlaced screen.

Quote:

Originally Posted by Thorham

How is cpu blitting slower than c2p? Anyway, I said it might not be useful

Transparent blitting is easy to do with chunky pixels (write non-transparent ones and skip the others), but in planar mode it's more complicated.
Or do you have a very fast blitting routine ? (I guess not )

Quote:

Originally Posted by Thorham

That's not what I meant. The music is resampled to a frequency the audio dma can handle, and the same goes for the effects, where both of them have the same sample rate.

The effects are already in range, as they are 22050 hz. Of course the music can be resampled to this value, but it would still mean a whole lot of data.

Quote:

Originally Posted by Thorham

Now you can easily mix them at run time in the game as needed. If you want more than four channels total you already have to mix, so why not make it easy? Pre-mixing would mean you'd have to mix for every possible combination, and that would probably take up millions of exa bytes

Of course, but I'd prefer to use tracked music.

Quote:

Originally Posted by NovaCoder

Cool, I'll have to try this on my Miggy.

Yes

Quote:

Originally Posted by NovaCoder

If you're after fast C2P you should look at the ADoom source code (on Aminet) although most C2P is designed for low-res screens and will not work with 640x480.

I don't think my C2P can be beaten on '030
(anyway not by enough to be significant)

But perhaps there exists better refreshing methods. For now I just C2P whatever screen region the game tells me to refresh.

Quote:

Originally Posted by NovaCoder

As for the floating point stuff, you could either target FPU users (like me!) or borrow the fixed-point code from ADoom.

I can't target FPU users for two reasons : the game CAN work without FPU (and it already does), so it MUST work like that. The other reason is that I don't have FPU

I don't see how I could borrow some fixed-point code. What I need is that float stuff to be rewritten to no longer use float. It's not extremely difficult (already half done in the editor), it's just that the game has too many of them to do.

It's not a bad idea to use that kind of interlace trick, but sadly chipmem is too slow even for this.

Yep, if the band width required exceeds the available band width, the interlace method becomes useless. Sad really.

Quote:

Originally Posted by meynaf

Besides, you might regret that the day your game works on a non-interlaced screen.

That could have been solved, except for the fact that it doesn't matter in this case

Quote:

Originally Posted by meynaf

Transparent blitting is easy to do with chunky pixels (write non-transparent ones and skip the others), but in planar mode it's more complicated.
Or do you have a very fast blitting routine ? (I guess not )

Yeah, I know what a pain it can be. The fast cpu blitting routine I have is sadly only usable in my Advance Wars conversion, because it simply blits two tiles with two bobs on top (works, because only one unit can move around at any one time, in that case I use a 16 color sprite).

Quote:

Originally Posted by meynaf

The effects are already in range, as they are 22050 hz. Of course the music can be resampled to this value, but it would still mean a whole lot of data.

Tried it today, and there was one solvable problem: The game data from HOMAM2GOLD PC version doesn't include one of the intro anims. The game says it can't find sh2intro.smk, so I just cloned snwclogo.smk (I think it was that file). Problem fixed

It might be a good idea to simply skip those non important anim files if they're not found, and display a message if it can't find an important one, and just continue the game. Could you send me a list of expected anims so I can see which ones are missing? Maybe it's not as bad as it looks.

Anyway, I only tried playing very briefly, and although combat seems to be fast (I only tried AUTO, and died ), moving around the map is just too slow, but you probably already knew that.

10/10 for effort, and when the game gets it's much needed optimization, it should be quite good to play

Hi I test your version 0.1 and its amazing!
It have few bugs, but its realy much better then some freeheroes2 via sdl (I hate sdl).
Hope you'll do a newer version soon can't wait for it
I used the PC version datafiles.

I am going to try this too, as soon as the PC version finishes downloading. Will I also have to rename the animation file, as Thorham did? I guess we'll soon see.

I like the idea of resampling the CD audio tracks to stereo IFF samples (or another easily played format) that can spool from the hard drive, leaving two channels free for sound effects. If you have a look at the old game Labyrinth of Time, it uses the same method for playing back its awesome atmospheric soundtrack.