Go Penguin WIP platformer for MSX 1 | MSX Resource Center (Pagina 10/16)

Champion (414)

10-06-2021, 15:10

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)

Van Grauw

Ascended (10708)

10-06-2021, 15:17

theNestruo wrote:

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)

Ah, that seems smart .

Van santiontanon

Paragon (1770)

10-06-2021, 20:12

Yeah good point theNestruo! In addition preventing such bug, you can make the jump so that its height is exactly also aligned with tile boundaries if so desired, or aligned with any other values that would make level design easier.

Van Grauw

Ascended (10708)

10-06-2021, 22:12

theNestruo wrote:

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)

Could also be a good way to work around the line 217 issue with sprites on the V9938. Choose the deltas so that it always skips the 9th line out of every 16 lines (assuming 16x16 tiles).

Van ~mk~

Champion (323)

11-06-2021, 23:48

Not focused on optimizations, but nice document about simulating gravity: gravidade_en.pdf

Van AnsiStar

Master (141)

12-06-2021, 22:35

Spectacular! Waiting for the result...

Van Grauw

Ascended (10708)

15-06-2021, 21:18

Game is a hit already on (Japanese) Twitter

https://twitter.com/dantemendes/status/1404459037408874507
https://twitter.com/thara1129/status/1404541320325001217
https://twitter.com/max_2608/status/1404676420119384067
https://twitter.com/nf_ban/status/1404695321465163776
https://twitter.com/madscient/status/1404823320395059204

Van thegeps

Paragon (1175)

16-06-2021, 00:31

It deserve to be a hit

Van jltursan

Prophet (2619)

16-06-2021, 08:27

Indeed, it's a very promising development!. About its jump mechanics, Malaika shows the same gameplay basics and a nice and smooth jump, it's a good example to follow.

Van albs_br

Champion (467)

24-06-2021, 00:15

I noted something strange: the game runs smooth on MSX 1, but slows down on 2+ or even worse on Turbo R.
I took a screenshot of OpenMSX running the game on the same screen on 3 machines, and this is the result:

Indeed, there are a few lines of difference from one machine to another.
Why that happens? Is there something to do with how the interruption routines are implemented on each machine?