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

[Aladin]

Thanks you, it works

[abu_the_monkey]

[amipal]

Just read through this thread, courtesy of Karlos raising it over on Amigaworld.

Just... wow. I'd always heard that the TKG source was a mess, and never thought anyone would be able to do anything meaningful with it. But here you are, already making optimisation and improvements to it! Amazing work.

[Karlos]

@pipper

With functional RTG output, how feasible are high resolution modes for emulator targets, do you think? I imagine that in increasing the render area to 320 you've already found most of the places where the screen width/height or values derived from them are used.

I can't be the only one wondering what it might be like to play at 1280*1024 on UAE...

[pipper]

Originally Posted by Karlos

@pipper

With functional RTG output, how feasible are high resolution modes for emulator targets, do you think? I imagine that in increasing the render area to 320 you've already found most of the places where the screen width/height or values derived from them are used.

I can't be the only one wondering what it might be like to play at 1280*1024 on UAE...

Mhhm, I'm not sure how easy that would be. The maximum resolution is hardcoded in many places, sometimes expressed in things like table sizes.
Worst part is likely the number of bits reserved for things like fractional step through textures etc. This might fall apart with higher resolutions.

Also, be careful what you wish for... the low resolution's graininess might actually help suspension of disbelief. Higher resolutions easily reveal the lowres textures and make the enemies look like the cutouts they really are.

[Karlos]

To be fair, you get that sense whenever they are up close anyway. Maybe 640*480 could be an interesting RTG target.

Regarding the "wobbly" texturing, I'd always assumed this was down to some sort of perspective correction optimisation.

[Karlos]

In terms of building this, on the assumption I don't currently have a 68k-amigaos-gcc cross compiler installed and I'm using some vanilla brand .deb Linux installation, is there a nice simple prerequisite install somewhere? I'm keen to have a go at building and having a mess around with it

[Karlos]

There are some limits that I'd love to see removed. The whole floor texture set, for one. When I was editing levels, I found it quite restrictive that there was so little variation possible for floors. Similarly, but to a lesser degree, the textures for vector objects.

[pipper]

I can wholeheartedly recommend Bebbo's GCC Toolchain (vasm/vlink come along with it)
https://github.com/bebbo/amiga-gcc

The great thing about it is that it comes with the Amiga NDK and various library headers pre-installed from Aminet. So no searching and manual installation of quite a few libraries. You can start developing amiga stuff out of the box.

Install the prerequisites (described in the README)
Then build the toolchain

make all all-sdk PREFIX=/home/<user>/amiga-gcc-out -j <n>

Then set your path there

export PATH=~/amiga-gcc-out/bin/:$PATH

And you're off to the races!

"amiga-gcc" is actually a meta-repository that ties in various other repos (gcc and binutils, libnix etc) and contains scripts to patch and format the NDK/SDK for GCC use.

On a regular basis you'll want to update it

git pull origin
make update PREFIX=/home/<user>/amiga-gcc-out 
make clean clean-prefix PREFIX=/home/<user>/amiga-gcc-out 
make all all-sdk PREFIX=/home/<user>/amiga-gcc-out -j <n>

If you find bugs with it, raise an issue on GitHub, Bebbo is usually very responsive.

[Karlos]

Roger that, and thanks.

[abu_the_monkey]

@pipper

built the latest version earlier, and, running under winuae 68030@50mhz cycle exact emulation (as I can't use the real amigas as the moment) it really does seem like a big improvement on the original speed wise testing back to back on the same settings.

[pipper]

That’s good to hear! We’re lacking tools for objective measurements, though :-(

The lastest version in master has all the system friendly changes I made so far. Even the double-height rendering is done via a a system friendly custom copper list. What baffles me is the bug with double height rendering where when you move the view up or down all the floors come and go :-( I have been looking at the “pastscales:” code line 7846 for a while now, but can’t find anything wrong with it. But I think the bug must be somewhere there.

[abu_the_monkey]

assembly language is not really in my toolbox, but, I am almost sure this 'hall of mirrors' effect was also present in the original (maybe not to the same extent, but, the faster it goes the more you see it I guess?). I will cast my eye over it, cos, fresh set of eyes and all, but, I am sure you have this one covered.
As for tools for measuring performance, that can wait for now.
Keep up the great work

[Karlos]

As soon as I get some free time, I'm going to try and get into this. My 68K is a bit rusty but what better way to refresh?

[Jacques]

Could someone put the latest compiled version binary into The Zone, please?

[abu_the_monkey]

@Jacques

t'is done.

enjoy.

[abu_the_monkey]

Originally Posted by pipper

That’s good to hear! We’re lacking tools for objective measurements, though :-(

The lastest version in master has all the system friendly changes I made so far. Even the double-height rendering is done via a a system friendly custom copper list. What baffles me is the bug with double height rendering where when you move the view up or down all the floors come and go :-( I have been looking at the “pastscales:” code line 7846 for a while now, but can’t find anything wrong with it. But I think the bug must be somewhere there.

I tested the 'original' (cracked) version by team17 and it too has this effect in its doubleheight mode.

[pipper]

The way the double height floor drawing is implemented is rather simple:
1) make sure we start on an even line (i.e. a line on screen that won't be skipped)
2) double the renderbuffer increment from line to line (was 320byte, is now 640)
3) half the number of lines to render
4) step at double speed through the "line tables" (which store the left and right coordinates of the lines to draw)

The C2P Routine is set up to only convert every second line. The copper list will make all even lines appear twice.

[abu_the_monkey]

the odd floor and ceiling effects only seem to happen if you are using mouse controls, keyboard controls (at least for me) rendering seem rock solid.

[Karlos]

Come to think of it... That floor bug does ring a bell. I rarely used the double height modes and stuck to 2/3 size 1x1 pixel modes for the most part.