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

[Karlos]

Something else that may not be immediately obvious (unless you trace where the calls com from) is that both player code paths are executed by both machines in two player mode. The master doesn't behave like a server in this context, both games are running the game logic. This is why the game has to wait for all the comms and runs at the rate of the slowest machine since they both have to compute the same overall game state.

[abu_the_monkey]

I have a new branch, refactoring/player-code-redux

So far, it should all be nonfunctional and only data locations have been moved about, so if anything breaks in two player mode it means there's some action at a distance that was not characterised last time. The branch at least demystifies these offsets.

all seems to work correct

edit: in 1 and 2 player games

[abu_the_monkey]

Originally Posted by Karlos

Something else that may not be immediately obvious (unless you trace where the calls com from) is that both player code paths are executed by both machines in two player mode. The master doesn't behave like a server in this context, both games are running the game logic. This is why the game has to wait for all the comms and runs at the rate of the slowest machine since they both have to compute the same overall game state.

that's exactly what I thought I was seeing

[Karlos]

So we can go back to deduplication next then. Tomorrow...zzz

[abu_the_monkey]

It would appear so

I will test a bit more tonight and post if I find anything off.

edit: 25 minutes of running around various levels in 1 and 2 player games and nothing seems amiss. weapon animation, doors, lifts, lighting, level exits all working as expected

[Karlos]

Ok, that's good and expected. I didn't change any code yet other than making sure some of the fields that have been added to the player structure are populated on level initialisation.

It's interesting, it seems like the player weapon is in world space as an actual entity. Maybe this explains the apparent lag sometimes when rotating the view quickly since it's position and orientation would need to be updated. I'd always assumed that was an intentional effect to make it feel more weighty, but maybe I was a happy accident.

[Karlos]

Not directly related, but I've pushed some asset changes to my mod:
* Fixed rocky wall brightness
* Added the blue and red lit versions of the same texture
* Fixed the alignment of the light tile floor/ceiling texture
* Replacement floor texture for one of the less used/interesting ones.

[abu_the_monkey]

@Karlos

looking good

[Dunny]

Older demo, but much better frame rates in PiStorm32Lite:

[ Show youtube player ]

Courtesy of Tom-Cat as before.

[abu_the_monkey]

Originally Posted by Dunny

Older demo, but much better frame rates in PiStorm32Lite:

[ Show youtube player ]

Courtesy of Tom-Cat as before.

The increased frame rate is due to the updated firmware on the PiStorm

[Dunny]

Originally Posted by abu_the_monkey

The increased frame rate is due to the updated firmware on the PiStorm

Yes indeed. As far as I am aware, the trick was to allow accesses to chip ram to be bundled up. Small accesses are still slow, but for something like this it has quite a dramatic effect

[abu_the_monkey]

Originally Posted by Dunny

Yes indeed. As far as I am aware, the trick was to allow accesses to chip ram to be bundled up. Small accesses are still slow, but for something like this it has quite a dramatic effect

Kind of like burst mode I guess

[Karlos]

Wow, that is a world of difference. Also, can someone tell him where the shotgun is?

[tomcat666]

So, with new pistorm32 firmware we get solid 50fps now:

[ Show youtube player ]

And it seems Michal still has some improvements to make.

[abu_the_monkey]

@tomcat666

you should try promoting it to super72 hires (its 400*300) just to see if you get 70fps or not

attached is a pic of winuae running super72 hires through 'newmode' mode promotion tool (jit is enabled in winuae)

[Karlos]

Took a short break from the code to revisit some retexturing

[ Show youtube player ]

[abu_the_monkey]

liking the stone block walls and the blue hues, not sold on the rusty coloured metal riveted wall texture (seems too bright for the rest of the scene)

good work

[Karlos]

Originally Posted by abu_the_monkey

liking the stone block walls and the blue hues, not sold on the rusty coloured metal riveted wall texture (seems too bright for the rest of the scene)

good work

The breeze blocks are somewhat pinched from doom, with some modification. As for the rusty one, that's mostly down to unfinished lighting. The rivetted sections are at full illumination. The blue variants of the wall are supposed to be the same wall texture under blue light. This is why the joins between the normal and coloured versions are always dark. I used this trick a lot in the docking ring level.

[abu_the_monkey]

lighting, a most powerful tool

[Karlos]

I've been giving some thought to mod expansion. We can change all the limits we like within the game engine but the basic fact is, none of the tooling would be able to take advantage or would have any awareness. Equally, the game link data is somewhat directly loaded into memory and any changes would break compatibility with existing mods.

So, what I am going to propose is that every level is able to provide its own floor textures, model textures and sky background, falling back onto the default if nothing is found. These assets have a fixed size, unlike walls and bitmap objects, so loading them in over the top of the resident ones should be entirely safe and non leaky. This can be used in conjunction with the previously described sound bank concept for greater audio variation.

This would go some way into fixing the "sameness" of the level graphics while remaining completely backwards compatible.

I do find the 16 floor textures very limiting, so an alternative approach might be to allow more (the floor index in memory appears to be a byte value, so up to 256), and then have a properties file that is added to a level directory that contains floor definition overrides for zones. This is a bit non trivial since you'd need to know the zone number somehow, before specifying which new, extended floor texture to use. However, a benefit of this is that you can also specify distinct sounds and damage values for each overridden floor type.