KarlosTKG now on GitHub

[Karlos]

As bizzare as the following overall statement sounds in my head, I've fixed some issues with the mod and pushed them to the git repo:
- Stopped the green Ashnarg from spawning enemies on death as they are not targetable and in some cases invisible. Now he spurts corrosive kibbles like his red cousin but has a lower hit point score to differentiate.
- Fixed an issue in level C that could leave you trapped underwater unable to get out.
- Increased the assimilated marine's movement speed. He's still as much of a bullet sponge as ever but moves noticeably faster when not patrolling.

I've also begun to take stock of the assets and refamiliarise myself with the ideas I had to rework the levels.

[eXeler0]

Originally Posted by Karlos

As bizzare as the following overall statement sounds in my head, I've fixed some issues with the mod and pushed them to the git repo:
- Stopped the green Ashnarg from spawning enemies on death as they are not targetable and in some cases invisible. Now he spurts corrosive kibbles like his red cousin but has a lower hit point score to differentiate.
- Fixed an issue in level C that could leave you trapped underwater unable to get out.
- Increased the assimilated marine's movement speed. He's still as much of a bullet sponge as ever but moves noticeably faster when not patrolling.

I've also begun to take stock of the assets and refamiliarise myself with the ideas I had to rework the levels.

I'm curious about the 3d stuff you've added. What format does the game read (1. geometry, 2. textures) and what does your pipeline look like? (e.g. Blender to obj then convert obj to something native etc)

[Karlos]

Originally Posted by eXeler0

e.g. Blender to obj then convert obj to something native etc.

Alas, I'm afraid not. Textures were made/edited in PPaint. 64x64, 32 colour subset of the game palette. Component objects were then made in the object editor. Components were loaded into the animation editor.

The game uses it's own vector model format, exported by the animation editor.

All the assets are in the repository. Most are in IFF or game specific formats. However, I did prepare this image today to help me understand how much wall texture space I can use in the set I currently have https://github.com/0xABADCAFE/karlos...view_Walls.png

Each wall is a 32-colour IFF brush that's up to 640 pixels wide by up to 128 tall (height must be a power of 2). The restrictions on colour make it important to group textures together by colour scheme. Of the 32 colours you use, they should ideally be a subset of the games 256 colour palette.

The same is true for floor and model textures, etc. There are a lot of obscure limitations likely originating from the 3 pixels per 16-bit word in-memory representation.

[eXeler0]

I ventured an optimistic guess , I do Quake 1 maps so I have a "#toolchain" for working with maps and textures on the Quake palette, but when it comes to adding custom 3d models it becomes clumsy...up to really awkward.
But maybe something like Milkshape could have been in the work-pipeline.

[Karlos]

Originally Posted by eXeler0

I ventured an optimistic guess .

Yep. Everything was created using standard Amiga applications. Personal Paint was used for pretty much all the 2D image work. I used provided vector modelling tools which where ... Challenging. And yet also primitive enough that you can't get lost in the detail. It would've been nice to have screenmode support on it at least. Regular PAL all the way.

I used LevelEd 303 which, while quirky, is much more accessible the default editor.

[Karlos]

I know the experimental loop based music hasn't been especially popular so I've reverted it back to a (slight variation) of the original bass pulse. The other assets are all still present, it's just the game link that's been changed.

There are some small fixes for level A and some additional pickups.

[pipper]

Where does the original limitation for the music size come from? Formerly there was a chunk of ~70kb of chipmem reserved for the music file. I recently removed the hard coded size. It will now dynamically allocate whatever the unpacked size of the music file is.

[Karlos]

Originally Posted by pipper

Where does the original limitation for the music size come from? Formerly there was a chunk of ~70kb of chipmem reserved for the music file. I recently removed the hard coded size. It will now dynamically allocate whatever the unpacked size of the music file is.

Brilliant! Although that does mean that a levels can be backwards incompatible if the music is bigger than the original limit. I do suspect it can't be too big though because we have display buffers and things to worry about.

Thinking about it... How much chip ram data is dynamically allocated each level? It's probably only the module. I imagine all the other allocations are probably done once. That could by why it was fixed in the first place, to make sure that all the chip allocation could be done ahead of time.

[pipper]

Chipmem is used for the sound FX and the screen frame buffer. I think we can assume that we will have around 1.5mb available. One thing I’m not going to do is to try resurrect the “cheesey” 2MB version that ran on unexpanded A1200/ CD32 :-)

[abu_the_monkey]

Yeah, the 2mb version was very poor. do you think the floor and ceiling texturing was taken out because of the double height rendering bug that was present in the 4mb version or were they totally unrelated?

[abu_the_monkey]

Originally Posted by Karlos

Yep. Everything was created using standard Amiga applications. Personal Paint was used for pretty much all the 2D image work. I used provided vector modelling tools which where ... Challenging. And yet also primitive enough that you can't get lost in the detail. It would've been nice to have screenmode support on it at least. Regular PAL all the way.

I used LevelEd 303 which, while quirky, is much more accessible the default editor.

I had a chance to revisit LevelEd 303 this evening, and while it is most definitely quirky and a bit crash happy it was not nearly as bad as I remember.

[Karlos]

Originally Posted by pipper

Chipmem is used for the sound FX and the screen frame buffer. I think we can assume that we will have around 1.5mb available. One thing I’m not going to do is to try resurrect the “cheesey” 2MB version that ran on unexpanded A1200/ CD32 :-)

We should consider removing all the cheese sauce.

One thing I would like to check is the audio subsystem. The game claims to support an 8 channel mode and the restrictions on samples are reminiscent of OctaMEDs legacy 5-8 channel mode. It keeps 1 channel for the music mod and I know that this channel is not split because I was using mods with samples more than half volume and at sample rates higher than the sound effects rate of 8kHz.

If the game does any software sound mixing at all, the sounds should be in Fast RAM and only a playback buffer in chip. Also, 8kHz? What is this, late 80s telephony? It would be great to have a modern sound mixer

[Karlos]

Originally Posted by abu_the_monkey

Yeah, the 2mb version was very poor. do you think the floor and ceiling texturing was taken out because of the double height rendering bug that was present in the 4mb version or were they totally unrelated?

It was probably to save a bit of memory, but equally it may have been broken if they had tried to use it.

[Karlos]

Looking back at this this, I remembered something I meant to do.

One of the things that always bothered me was the jarring changes of texture as you go from some metal bulkhead to some weird green alien gubbins on an adjoining wall. So the plan was to create a few sections that have transitional textures, e.g. a bulkhead being slowly taken over by the alien stuff. You'd only need a few left and right sides transitions and you could make parts of the level a lot less jarring

That brown wall with pipes though. Damn. I hate that texture. That and the metal panel was bloody everywhere.

[pipper]

Originally Posted by Karlos

We should consider removing all the cheese sauce.

One thing I would like to check is the audio subsystem. The game claims to support an 8 channel mode and the restrictions on samples are reminiscent of OctaMEDs legacy 5-8 channel mode. It keeps 1 channel for the music mod and I know that this channel is not split because I was using mods with samples more than half volume and at sample rates higher than the sound effects rate of 8kHz.

If the game does any software sound mixing at all, the sounds should be in Fast RAM and only a playback buffer in chip. Also, 8kHz? What is this, late 80s telephony? It would be great to have a modern sound mixer

I think the 2MB version is all the code in "ifne CHEESEY" blocks.

The game does indeed support 8 channel stereo sound, controlled by F3
See code here:
https://github.com/mheyer32/alienbre...hires.s#L10021
We can make the 8 channel sound default by changing the 4 into an 8 here:
https://github.com/mheyer32/alienbre...hires.s#L10144

I haven't tried allocating what happens when samples get allocated in fastmem... worth an experiment.

I think this can be done by replacing MEMF_CHIP with MEMF_ANY here:
https://github.com/mheyer32/alienbre...llchunk.s#L178

[pipper]

In fact I couldn't resist to test this... it worked! So I submitted the patches to GitHub :-D

The downside is that there's now audible clicking and popping sounds... something does not work 100%, as if the mixing is not producing enough data and the HW channels run into random noise.

[Karlos]

Originally Posted by pipper

In fact I couldn't resist to test this... it worked! So I submitted the patches to GitHub :-D

The downside is that there's now audible clicking and popping sounds... something does not work 100%, as if the mixing is not producing enough data and the HW channels run into random noise.

Is this on a branch?

[pipper]

I put it straight into main

[Karlos]

Originally Posted by pipper

I put it straight into main

You're fired

It does seem weird though. As long as the output buffer is still in chip ram for Paula to read, why would this be a problem? I've not seen the actual code for the mixing yet, just code that flags a sound for playback. I want to find it because I'd like the option of replacing it with something better, or at the very least increasing the mixing rate and using a matching sample rate for new sound assets.

[grond]

Originally Posted by Karlos

It does seem weird though. As long as the output buffer is still in chip ram for Paula to read, why would this be a problem? I've not seen the actual code for the mixing yet

Totally wild guess: perhaps some of the data transfer from sample to mixing buffer is done using the blitter?