Compileable version of Alien Breed 3D II - The Killing Grounds

[Karlos]

I have the additional motivation that I want to finish something I started in 1996/97 lol

[Karlos]

On the subject of C/asm interoperability...

There are some functions ported from asm to C that, from the C side would benefit from being easily inlined. Short functions like Sys_MarkTime() that are just wrappers for a call to ReadEClock() for example. Inlining these in C is easy (just declare them in the headers as inline) but we'd need to absolutely ensure that a callable version is emitted to allow it to be called from the assembler side still.

Is there a way to guarantee that the compiler will generate an externally callable version of a function that is inlined everywhere else in the C code? The only solution that sprang to mind without going into compiler specifics would be to rename the inline version and have the assembler callable version use it, but that feels really clunky.

Alternatively, we could just have completely separate asm versions since the C version uses an underscore at the start of the symbol name anyway and just keep them separate. Inline C version and the assembler cod calls it's own (original) version. More stuff to maintain though.

[paraj]

You can use the esoteric "extern inline" feature (https://en.cppreference.com/w/c/language/inline), but probably nicer to just have few facade functions in C that ASM code can call to deal with register conventions as necessary. I.e.

// In a header
inline ULONG Sys_MarkTime(struct EClockVal* dest)
{
    return ReadEClock(dest);
}


// In A C file
ULONG Sys_MarkTime_ASM(REG(a0, struct EClockVal* dest))
{
    return Sys_MarkTime(dest);
}

A bit of extra work in this case, but keeps register stuff out of the C code, which will make your PPC port easier

[Karlos]

Originally Posted by paraj

You can use the esoteric "extern inline" feature (https://en.cppreference.com/w/c/language/inline), but probably nicer to just have few facade functions in C that ASM code can call to deal with register conventions as necessary. I.e.

// In a header
inline ULONG Sys_MarkTime(struct EClockVal* dest)
{
    return ReadEClock(dest);
}


// In A C file
ULONG Sys_MarkTime_ASM(REG(a0, struct EClockVal* dest))
{
    return Sys_MarkTime(dest);
}

A bit of extra work in this case, but keeps register stuff out of the C code, which will make your PPC port easier

Pfft. Don't get me started. There's no desire to port it to PowerPC here. I'm not opposed but a system friendly 68K binary that works with RTG/AHI and doesn't bang any hardware directly is already suited for OS4/MOS.

[Karlos]

@pipper & @abu

Now that we have RTG and 50Hz can no longer be considered the standard for timing, I am thinking we should use a more consistent timing mechanism. For example, I stead of updating animations every game frame (or multiples thereof), we should probably define a standard animation rate that's independent of the frame rate.

I am thinking we can use the timer we added to measure the elapsed time between frames and use that to update a basic counter for the animation frame number when the elapsed time has exceeded a given interval. This way, when the frame rate is high, the animations will run at an approximately constant rate of our choosing (based on that interval) but on slower machines, the increment rate will approach once per frame, thus ensuring the animation doesn't become jerky.

[samo79]

@Karlos

In end it may be less work to get it working by compiling the game directly on PPC for OS4/MOS than to adapt the current 68k RTG version to fully work on NG systems :-)

[Karlos]

Originally Posted by samo79

@Karlos

In end it may be less work to get it working by compiling the game directly on PPC for OS4/MOS than to adapt the current 68k RTG version to fully work on NG systems :-)

How do you come to this conclusion?

System friendly 68K applications generally run fine directly on NG systems. That's one of, perhaps the the only true benefit of NG today. Absolutely every other semi modern thing they can do at all can be done more easily and for far less expenditure on any contemporary x64 or ARM hardware.

I'm not saying an NG port has no place but the target should be a migration to platform agnostic C, not to NG specifically.

For that goal, I'd say a clean room reimplementation of the engine is the correct approach. Otherwise you remain locked in by many of the limitations of the original that are difficult to unpick.

[samo79]

Well from direct experience I noticed that not always old games marked as 68k RTG will actually work well under OS4... maybe they work better on AmigaOS 4 for classic but not on every OS4 compatible machines.. atleast this was my experience by try certain games on my Sam440
Anyway we'll see, I'm available to try it and possibly report to you any eventual problems, you can count on me for betatest ... after all, the source is always available if someone in later future wants to port it directly to OS4 or MorphOS :-)

[abu_the_monkey]

Originally Posted by Karlos

@pipper & @abu

Now that we have RTG and 50Hz can no longer be considered the standard for timing, I am thinking we should use a more consistent timing mechanism. For example, I stead of updating animations every game frame (or multiples thereof), we should probably define a standard animation rate that's independent of the frame rate.

I am thinking we can use the timer we added to measure the elapsed time between frames and use that to update a basic counter for the animation frame number when the elapsed time has exceeded a given interval. This way, when the frame rate is high, the animations will run at an approximately constant rate of our choosing (based on that interval) but on slower machines, the increment rate will approach once per frame, thus ensuring the animation doesn't become jerky.

all for having better timing for animations, using elapsed time is far better than waiting on vbl and having a bunch of 'hacks' to try and achieve reasonable visuals (tried that already and it's not pretty).

[pipper]

Originally Posted by Karlos

@pipper & @abu

Now that we have RTG and 50Hz can no longer be considered the standard for timing, I am thinking we should use a more consistent timing mechanism. For example, I stead of updating animations every game frame (or multiples thereof), we should probably define a standard animation rate that's independent of the frame rate.

For now I papered over the timing issue by creating a 50Hz timer interrupt to drive the former VBlank stuff on RTG. Not ideal, but seems to work. I think once we have ported most of the game loop to C we can try rearranging things in a more framerate independent way. One thing I would like to keep is the mouse input responsiveness. I always liked how “low latency” the mouse input feels regardless how sluggish the game runs.

[abu_the_monkey]

I always liked how “low latency” the mouse input feels regardless how sluggish the game runs.

[Karlos]

Originally Posted by samo79

Well from direct experience I noticed that not always old games marked as 68k RTG will actually work well under OS4... maybe they work better on AmigaOS 4 for classic but not on every OS4 compatible machines.. atleast this was my experience by try certain games on my Sam440
Anyway we'll see, I'm available to try it and possibly report to you any eventual problems, you can count on me for betatest ... after all, the source is always available if someone in later future wants to port it directly to OS4 or MorphOS :-)

I think you are underestimating the difficulty of porting this to PPC. It's not portable code, until very recently it's 100% 68K assembler. Now it's about 2% C and that C replaces assembler code that was specifically refactored out as low hanging fruit for initialising the application and display.

In my opinion, at least, the effort involved in implementing a from scratch version in C or C++ is rather less than trying to convert from ASM to C and in doing so you can avoid lots of pitfalls and plan for new features better. When you write entire applications in assembler you generally don't need to care about things that lend themselves to maintenance and longevity. This gets reflected in the code that is written.

[Karlos]

Originally Posted by pipper

For now I papered over the timing issue by creating a 50Hz timer interrupt to drive the former VBlank stuff on RTG. Not ideal, but seems to work. I think once we have ported most of the game loop to C we can try rearranging things in a more framerate independent way. One thing I would like to keep is the mouse input responsiveness. I always liked how “low latency” the mouse input feels regardless how sluggish the game runs.

You know, there's a lag on mouse rotation that makes the weapon move slightly after the turn that I've always found quite nice, it makes the weapon feel "weighty" like it's being hefted when you turn quickly. I suspect it's an unintended side effect of how the engine works as it's all but gone at 50fps. Assuming that it wasn't particularly intentional, I'd love to try and keep it. Also, some slight weapon movement when idle for a while would be nice, just a subtle movement like readjusting grip.