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

[Karlos]

It didn't break because nothing calls that function yet. All the Dev metrics go via a macro that just does the lower 32-bit eclock difference.

Aww, I was gonna do some RTG *sniff*

No seriously, go for your life.

[Karlos]

Regarding RTG, isn't the render area already 320*240?

Replace the border with a HUD, I'd suggest.

[abu_the_monkey]

@pipper

cool stuff indeed

[Karlos]

Funny tidbit: Andy might have been a The Black Lotus fan

Also, "The Goodies" *, given that one of the branch labels for odd Y values (itsoddy) is called "itsbilloddy".

*A late 70s weekend early evening comedy.

[Angus]

Originally Posted by Karlos

Also, "The Goodies" *

*A late 70s weekend early evening comedy.

My dear fellow, I believe it ran from 1970! :-)

[Karlos]

Originally Posted by Angus

My dear fellow, I believe it ran from 1970! :-)

I only remember it from then, really.

[Karlos]

@pipper

On the RTG front, I don't know if this has changed since the CGX4/OS3.9 days but back then the only way to do performant rendering was to lock the bitmap and use your own copy/transform code to blast raw pixel data from your chunky buffer into the bitmap. All of the provided functions tended to suck at this. Using move16 on the BVision I was able to reach near total saturation during transfer.

[daver]

Got it running on my A4000 3660 @50 mhz, between 5-11 fps and in winuae steady 59 fps. must say although the fps very enjoyable play wise. will try on my 1200T later.

im also all for keeping it on the amiga i only thought it odd that it was never ported to ppc for the blizzard accelerator and such back in the day but guess the developers had moved on to other platforms by then and didnt see the point.

[Karlos]

There was a tool that purported to be able to translate 68K assembly language source to PPC assembler. I don't know how well, or even if, it worked.

I wouldn't be surprised if the current build actually runs on a PPC equipped classic machine where the hardware that it does touch is actually available.

[pipper]

Man, the menu code is a hot mess. I tried to find a single entry that would be called regularly called when the menu is shown (so I can squeeze a call to BlitBitMapRastPort() in there), but couldn't find a suitable one.
I ended up creating a second task(!) that would receive a message from the vblank interrupt to execute the blit from offscreen menu bitmap (planar) to onscreen RTG (chunky).
That works sorta... but is a really shoddy solution. I only did it because I don't want to deal with the menu code just yet.

I think once I muddled through and got the actual game run on RTG, we might want to completely overhaul the menu system in C.

[Karlos]

Originally Posted by pipper

I think once I muddled through and got the actual game run on RTG, we might want to completely overhaul the menu system in C.

Agreed. If we are having to copy from chip to VRAM (possibly even going via fast memory internally), the menu is likely to end up more CPU bound than the bloody game, lol.

[abu_the_monkey]

yep, the menus are a mess, all 3 versions that are scattered throughout the code

[Karlos]

Are the menu glyphs planar? We could preconvert those to chunky and just have a functional menu without the snazzy fire and scroll effects for RTG. Then we can have four versions lol.

[pipper]

Yes, going forward I'd opt for rendering the menu entirely in fastmem as chunky buffer. On RTG this will then be just copied over to the graphics card, on AGA the classic C2P routines will be used. I would want to keep backwards compatible with the assets, though (fonts, images etc), which shouldn't be too much of a hassle.

[pipper]

Ok lads, I have updated the C migration branch with rudimentary RTG rendering.
No text, no HUD, no functioning doublewidth/double height modes and slow main menu along with slow loading while the menu is running) - but hey, we got the game render through RTG ;-)
Its not as fast as I hoped on my A3000 with a BFG9060...but there's likely still room.

[Karlos]

How are you copying the fast buffer to the bitmap?

[pipper]

Either memcpy or a single call to CopyMemQuick.

[tomcat666]

Is there a built exe of the rtg test version anywhere?

[Karlos]

Originally Posted by pipper

Either memcpy or a single call to CopyMemQuick.

I'd probably have a function pointer for this and have a number of routines that can be switched through. Certainly on my old BVision, for 040 and 060, move16 was a clear winner. If you use the copymemquick type patches, you could approach it. With the C memcpy, you are totally at the mercy of the compiler standard library implementation.

[abu_the_monkey]

Originally Posted by pipper

Ok lads, I have updated the C migration branch with rudimentary RTG rendering.
No text, no HUD, no functioning doublewidth/double height modes and slow main menu along with slow loading while the menu is running) - but hey, we got the game render through RTG ;-)
Its not as fast as I hoped on my A3000 with a BFG9060...but there's likely still room.

@pipper

I am unable to build hiresC, it terminates with
fatal error: ld terminated with signal 11 [Segmentation fault]

might be something I done wrong?