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

[abu_the_monkey]

@Karlos

nice! there never seems to be enough time
the only issue I have had with the current version is if I start a level, then quit out and try to restart the same level it freezes with jit enabled, in cycle exact it seems ok. haven't tested so much on real hardware yet.

[Karlos]

Originally Posted by abu_the_monkey

@Karlos

nice! there never seems to be enough time
the only issue I have had with the current version is if I start a level, then quit out and try to restart the same level it freezes with jit enabled, in cycle exact it seems ok. haven't tested so much on real hardware yet.

So I noticed that just now but didn't retry it to see if it was systematic. I also accidentally flipped back to workbench which I assumed has resulted in the instability.

[Karlos]

Regarding the sound, I do still get issues but it sounds more like the sample isn't playing to completion and getting truncated. What I haven't noticed are the odd bursts of atonal audio that were probably 160 bytes or garbage on the end of the 5040 long sample (or just whatever was after it). It's odd, it is the only sample that was a funny length, the rest are all perfect multiples of 200. Not sure how this happened, 20 years ago me was pretty anal about that stuff.

[abu_the_monkey]

the jump back to workbench happened once to me on the A4000 just before it bombed to the yellow screen which I put down to a power/connection issue in the machine, not had it in winuae so far.

[Karlos]

Originally Posted by abu_the_monkey

the jump back to workbench happened once to me on the A4000 just before it bombed to the yellow screen which I put down to a power/connection issue in the machine, not had it in winuae so far.

I assumed I'd pressed something... It was in a moment of furious blasting, after all.

[pipper]

"I also accidentally flipped back to workbench which I assumed has resulted in the instability."

Oh, yeah, this can happen! If you move the invisible mouse cursor up enough, press LMB and pull down, you can actually manage to pull down the screen! I once managed to make the WB come in front again and then couldn't switch back.

This is due to two things.

1) Our input handling is crap... via using the keyboard input directly AB3D has no notion of "keyboard and mouse focus". This needs to be resolved by using a more traditional input loop and/or better mouse movement handling (resetting the pointer every frame so it may never reach the top of the screen).

2) the screen probably should be allocated with the "SA_Exclusive / SA_Draggable " tags to prevent it from being dragged.. but honestly its just too cool to see it happen. In long term I want the screen to remain draggable :-D

[abu_the_monkey]

that's so cool
not when your in the middle of a fire fight mind, but you know what I mean.

[Karlos]

It did come as a surprise. One moment I was shooting at a pair of big robots and the next I was clicking on an icon.

[grond]

When I once worked on an engine for a system friendly J&R game, I made the screen undraggable but Amiga-keys for flipping through screens (Amiga+M/N, iirc) still worked. If the screen wasn't on top, I would simply pause the "game" (was just a rough tech demo). I thought that made most sense.

[Karlos]

As nice as it is that the engine isn't kicking the OS in the nuts, I think it would be preferable if switching back and forth was by regular hotkeys

[abu_the_monkey]

tried building with
SA_Draggable,0
SA_Exclusive,1
but the screen depth arrange gadget persisted.
turned out that
SA_ShowTitle,0
is enough to stop interactions with the screens gadgets/title bar
happy days

[BSzili]

Originally Posted by pipper

I made another commit.
After looking at the ADoom and DoomAttack code, I _think_ I have understood the problem now: ChangeScreenBuffer will only produce messages if the call succeeds (i.e. we can't expect a message to tell us when a failed call can be retried).
The fix stores a boolean to tell the next frame that ChangeScreenBuffer succeeded and thus a message can be expected.

I can _still_get it to freeze, though in emulation with JIT enabled when switching between game and menu super quick... this might be some other issue, though.

Very useful information! With this I was able to fix a hang in JFBuild, which happened sometimes when I switched screens using the Amiga+M/N combination.

[Karlos]

@pipper

I've raised my first PR in what seems like forever, this time for issue #1. Floor damage is now only applied when in contact with a damaging floor and not just because you are in the zone. Water is not yet taken into account, I'm of the opinion that floor damage should probably extend to water so that you can have deep pools of acid and the like.

[Karlos]

I've noticed abu's changes are currently in conflict due to the call to FPS_time2 being in the same place where the check for the result of ChangeSceenBuffer was introduced. Originally the FPS timer call would've been straight after it but if moved after the handling of the of the return, seems to be immediately before the second call to the FPS timer. Is that how it was?

[Karlos]

A quick follow on PR from the last PR. Floor damage is now also applied if the player is in water, even if not in contact with the floor. This makes sure that while pits of hazardous substances can be flown over, if you land in one, it's going to hurt whether you actually reach the bottom or not.

[Karlos]

Maybe being submerged in harmful liquid should increase the DPS compared to just walking over a harmful surface. What do you guys think? This could be implemented by reducing the time to damage value once it's ascertained you are submerged.

-edit-
There's currently only one counter though and it's shared between both players (DM). So maybe just applying a multiplier for being in water.

[abu_the_monkey]

@Karlos

Regarding the fps timer, sounds correct, but I will check tomorrow. Layed up with a cold at the mo, feeling rather lethargic

[abu_the_monkey]

@Karlos

fps_timer was like this in the PR

				move.l	MainScreen,a0
				CALLINT	ChangeScreenBuffer		; DisplayMsgPort will be notified if this image had been fully scanned out

				jsr	FPS_time2				;fps counter c/o Grond
*****************************************************************
				jsr	FPS_time1				;fps counter c/o Grond

				move.l	#SMIDDLEY,a0
				movem.l	(a0)+,d0/d1

should now be something like

				CALLINT	ChangeScreenBuffer		; DisplayMsgPort will be notified if this image had been fully scanned out

				tst.l	d0
				beq.s	.failed

				move.w	d2,ScreenBufferIndex
				st.b	WaitForDisplayMsg
				bra.s	.screenSwapDone

.failed			clr.b	WaitForDisplayMsg		; last attempt failed, so don't wait for next message

.screenSwapDone

				jsr	FPS_time2				;fps counter c/o Grond
*****************************************************************
				jsr	FPS_time1				;fps counter c/o Grond

				move.l	#SMIDDLEY,a0
				movem.l	(a0)+,d0/d1

after check for the result of ChangeSceenBuffer was introduced.

The fps counter is always displayed.

[Karlos]

Deconflicted. If you pull your branch down locally and confirm it's all still good, I think it would be good if we can get your changes merged.

[abu_the_monkey]

I will give it a try when I get home from work and report back.