Go Penguin WIP platformer for MSX 1

Van thegeps

Paragon (1176)

09-07-2021, 08:24

Eheheh! It was Grauw

https://www.msx.org/forum/msx-talk/development/halt-otir

Van santiontanon

Paragon (1771)

09-07-2021, 16:23

Wohoo! Glad it's resolved now!!!

Van thegeps

Paragon (1176)

19-07-2021, 19:58

theNestruo wrote:

santiontanon wrote:

Simulating gravity using fixed-point arithmetic as you suggest is a fine approach that is better than the fixed speed jump, but I find it's often hard to finetune the physics constants to get jumps that are not too "floaty". So, in my experience, just using jump tables (precalculated jump arcs, with an "escape options" in case you want to allow to control the jump height) are much easier to finetune to get the right "feeling", and is also much faster CPU-wise

I agree with Santi. For reference, here is Stevedore delta-Y table:

; Delta-Y (dY) table for jumping and falling
PLAYER_DY_TABLE:
	db	-4, -4			; (2,-8)
	db	-2, -2, -2		; (5,-14)
	db	-1, -1, -1, -1, -1, -1	; (11,-20)
	.TOP_OFFSET:	equ $ - PLAYER_DY_TABLE
	db	 0,  0,  0,  0,  0,  0	; (17,-20)
	.FALL_OFFSET:	equ $ - PLAYER_DY_TABLE
	db	1, 1, 1, 1, 1, 1	; (23,-14) / (6,6)
	db	2, 2, 2			; (26,-8) / (9,12)
	db	4
	.SIZE:		equ $ - PLAYER_DY_TABLE

; Terminal falling speed (pixels/frame)
	CFG_PLAYER_GRAVITY:		equ 4

Bonus point: vertical movement with this table always crosses tile boundaries aligned to the tile (that gives some optimization opportunities, and helps preventing the "foot stuck 1px deep" problems)

so, CFG_PLAYER_GRAVITY is used in case the player release the fire button during jump to make the sprite fall fast (the "escape option" to wich Santi was referring)?

Van albs_br

Champion (468)

22-07-2021, 05:41

thegeps wrote:

so, CFG_PLAYER_GRAVITY is used in case the player release the fire button during jump to make the sprite fall fast (the "escape option" to wich Santi was referring)?

No, this constant is the terminal falling speed. On the above table, if player is falling (both from the top of a jump or falling from a block) then the first six frames it falls by 1px, next three frames by 2px, and after by 4px per frame.

The ascending part of a jump has a known limit (max height), but not the descending part. It will fall until encounter ground (or the screen bottom).

Van thegeps

Paragon (1176)

22-07-2021, 07:05

Yep, I understood it. I thought that it is the above mentioned escape too. So, if the player release the button when ascending, gravity is applied to abort jump quickly. But then, thinking about it, I realized that applying the fall offset is enough

Van albs_br

Champion (468)

22-07-2021, 19:42

One question for you guys: is it worth to use hardware based collision? To check if any sprites collided and then use the bounding boxes only when it returns true.

My guess is that no, it don't worth. The bounding boxes algorithm is relatively light (load some vars, make one cp for vertical, if true load more vars, another cp for horizontal). Maybe the gain is too small to pay the effort (some sprites may be redrawn to don't overlap).

Van Grauw

Ascended (10716)

22-07-2021, 21:05

I’m no expert on it, but as far as I know the hardware collision is rarely used, it’s too limited for most intents and purposes. I wouldn’t call bounding box calculations light personally (especially if you have to do many), but unless the game logic is so simple that any sprite collision is a death, you’d be doing those checks anyway and it would just be a best case optimisation while the worst case gets worse.

By the way, I guess this flag it is the reason why the status register is passed into H.TIMI since it is cleared on read, and if you clear it inside H.TIMI you can shave a small 42 cycles off the execution time of the BIOS ISR when it occurs.

Van thegeps

Paragon (1176)

23-07-2021, 06:51

I don't use hardware collision. Bounding boxes, but only for active sprites. Usually I set a table of sprites' state (not only sprite active) wich first entry of each object (it could be done of more sprites) is 0-sprite is active/1 sprite is not active. First check on this, continue if active else check next object

Van albs_br

Champion (468)

25-07-2021, 05:27

Following advice from @thegeps, I changed my game loop from using HALT to checking JIFFY and there were some (very good) side effects:

- No more extra slowdown when running on machines MSX 2 and over (especially Turbo R). Now the behavior is consistent across all MSX generations;

- That terrible bug when you change direction quickly while running and it trashes all the screen is 99% gone. Still blinks trash for a fraction of second sometimes, but next frame everything is alright. The conclusion is that the bug was caused because the frame were still processing when the next frame starts;

- My routine to get when a frame takes more than one Vblank finally works.

When you do things right, good things happen

Van thegeps

Paragon (1176)

25-07-2021, 19:35

Congrats! Keep up the good job, we want to play Go Penguin asap!