Platform Game DevKit thread

Pagina 1/2
| 2

Door flyguille

Prophet (3031)

afbeelding van flyguille

28-04-2016, 00:47

I opens this new forum thread, it is for relevant questions about the Platform Game DEVKIT as it is.

Working game video demo which does the DevKit out of the box

DevKit Download

TniASM v0.45 Website

Aangemeld of registreer om reacties te plaatsen

Van flyguille

Prophet (3031)

afbeelding van flyguille

04-05-2016, 02:16

New link: Upgraded devkit

tniASM v0.45 free download from this website

Warning: if for moving the "MSX HDD" directory files, are using the OpenMSX's feature "Dir As Disk", it will truncate some file, because it is already bigger than 720K. Try to copy that truncated file in another step, or dividing the files in two directories and swap them using the OpenMSX's Catapult.

Van flyguille

Prophet (3031)

afbeelding van flyguille

04-05-2016, 21:19

The game out of the devkit has problems controlling the FPS as now there is OPL4 ints enable, and it confuses the little FPS control routine, which as simple as it is just a HALT loop for wasting time as many vdp frames wasn't used.

But now, the routine really needs to check that them are vdp /int. So, I will change it to just monitor the vdp fps counter.

Original code

FramesPerSecondControl:	ld a, (IsTurboEnabled)
			and a
			jr nz, .NoWaitNeeded

			ld a, (VBlankCountInFrame)		; Speed control. In B = how many Vblanks per frame?.
			ld c, b

			cp c
			jr nc, .NoWaitNeeded

			ld b, a
			ld a, c
			sub b

.WaitLoop:		halt
			dec a
			jr nz, .WaitLoop

.NoWaitNeeded:		call IsShiftPressed			; A = 0 pressed.
			and a
			ld a, 255
			jr z, .TurboEnabled

			xor a

.TurboEnabled:		ld (IsTurboEnabled), a

			ld a ,(VBlankCountInFrame)
			ld (DiagnoseVBlanksCount), a		; Diagnostic variables for helping the development.

			ld hl, (DiagnoseVBlanksPointer)
			ld (hl), a
			inc hl
			ld (DiagnoseVBlanksPointer), hl
			ld de, DiagnoseVblanksList_End
			and a
			sbc hl, de
			jr c, .NoWrap

			ld hl, DiagnoseVblanksList_Start
			ld (DiagnoseVBlanksPointer), hl

.NoWrap:		xor a					; Resets the vblanks counter.
			ld (VBlankCountInFrame), a

			ld hl, (DiagnoseVDPBotleneck)		; Diagnostic variables for helping the development.
			ld (DiagnoseVDPBotleneckPermanent), hl
			ld hl, 0
			ld (DiagnoseVDPBotleneck), hl
			ret

and this is the fix

FramesPerSecondControl:	ld a, (IsTurboEnabled)			; Speed control. In B = how many Vblanks per frame?.
			and a
			jr nz, .NoWaitNeeded

			ld a, (VBlankCountInFrame)
			cp b
			jr nc, .NoWaitNeeded

.WaitLoop:		halt

			ld a, (VBlankCountInFrame)
			cp b
			jr c, .WaitLoop

.NoWaitNeeded:		call IsShiftPressed			; A = 0 pressed.
			and a

			ld a, 255
			jr z, .TurboEnabled
			xor a

.TurboEnabled:		ld (IsTurboEnabled), a

			ld a ,(VBlankCountInFrame)
			ld (DiagnoseVBlanksCount), a		; Diagnostic variables for helping the development.

			ld hl, (DiagnoseVBlanksPointer)
			ld (hl), a
			inc hl
			ld (DiagnoseVBlanksPointer), hl
			ld de, DiagnoseVblanksList_End
			and a
			sbc hl, de
			jr c, .NoWrap

			ld hl, DiagnoseVblanksList_Start
			ld (DiagnoseVBlanksPointer), hl

.NoWrap:		xor a					; Resets the vblanks counter.
			ld (VBlankCountInFrame), a

			ld hl, (DiagnoseVDPBotleneck)		; Diagnostic variables for helping the development.
			ld (DiagnoseVDPBotleneckPermanent), hl
			ld hl, 0
			ld (DiagnoseVDPBotleneck), hl
			ret

Van Grauw

Ascended (10821)

afbeelding van Grauw

04-05-2016, 21:46

Lesson for all: Never use HALT to wait for VBlank.

I see it too often, while a poll on JIFFY is just as easy and you’re not saving yourself development time by not doing that. Using HALT will bite you in the ass someday, as evidenced here Smile, and cost you much more time to investigate and deal with. Be it either by your own doing because you forgot you were relying on the single-interrupt assumption when you introduced that line interrupt or sound chip interrupt, or by some TSR / 3rd party hardware / fast CPU/ MSX3 in use by the user.

Van flyguille

Prophet (3031)

afbeelding van flyguille

04-05-2016, 21:48

Grauw wrote:

Lesson for all: Never use HALT to wait for VBlank.

I see it too often, while a poll on JIFFY is just as easy and you’re not saving yourself development time by not doing that. Using HALT will bite you in the ass someday, and cost you much more time to investigate and deal with, as evidenced here Smile. Be it either by your own doing because you forgot you were relying on the single-interrupt assumption when you introduced that line interrupt or sound chip interrupt, or by some TSR / 3rd party hardware / fast CPU/ MSX3 in use by the user.

Halting makes the cpu to rest, it works cold, also it consumes less power.

See that I fixed, and still using HALT, just checking for the vblanks counter after the half, if it reached the required count it escapes from the loop, nothing can be more simple than that.

Van Grauw

Ascended (10821)

afbeelding van Grauw

04-05-2016, 21:57

flyguille: That’s not my point Smile. Insert a halt in the JIFFY poll loop for all I care, if you must.

Just never use HALT as a means to wait for VBlank.

The single-interrupt assumption is a recipe for problems. You’ve found out that it was a bad idea, so I just wanted to relay the warning to the other coders out there, as a best-practice advice Smile.

Van flyguille

Prophet (3031)

afbeelding van flyguille

04-05-2016, 22:08

Grauw wrote:

flyguille: That’s not my point Smile. Insert a halt in the JIFFY poll loop for all I care, if you must.

Just never use HALT as a means to wait for VBlank.

The single-interrupt assumption is a recipe for problems. You’ve found out that it was a bad idea, so I just wanted to relay the warning to the other coders out there, as a best-practice advice Smile.

can you elaborate more, I don't understand you.

Van Grauw

Ascended (10821)

afbeelding van Grauw

04-05-2016, 22:54

Grauw wrote:

Lesson for all: Never use HALT [as a means/way] to wait for VBlank.

In other words; “Advice to all programmers reading this: If you want to wait for VBlank, do not just use HALT, but check if JIFFY increments. Using only HALT assumes there is only one interrupt, which is bad practice. Spending a tiny bit of time to write a simple loop which checks JIFFY is totally worth it, because the odds are high that it will cost you a lot more time and headaches in the future if you don’t.”

Hope it’s more clear now Smile. Advice wasn’t really meant for you anyway because you already found out the hard way, hehe.

Van flyguille

Prophet (3031)

afbeelding van flyguille

04-05-2016, 23:53

Grauw wrote:
Grauw wrote:

Lesson for all: Never use HALT [as a means/way] to wait for VBlank.

In other words; “Advice to all programmers reading this: If you want to wait for VBlank, do not just use HALT, but check if JIFFY increments. Using only HALT assumes there is only one interrupt, which is bad practice. Spending a tiny bit of time to write a simple loop which checks JIFFY is totally worth it, because the odds are high that it will cost you a lot more time and headaches in the future if you don’t.”

Hope it’s more clear now Smile. Advice wasn’t really meant for you anyway because you already found out the hard way, hehe.

I found out in just 5 minutes of work when I notice something odd about the fps historygram.

Because I simply connect event A with event B (using the brain), and it took me few seconds to do that.

Then to open the source file, took a bit more, maybe because drinking the coffee, is to say, where else you will find a wrong game speed?.

Ofcourse, I agree with you, doing just HALTs, and not checking what kind of /ints was, is a good source of problems for games already released and closed.

In konami games, runs the game routines (any part of the game) on the $F9DF hook, and there is a HALT but it is a blind HALT, just HALT + JR -3, to wast the free time and for stop the main run of the game (lets say the main cpu "thread").

Van flyguille

Prophet (3031)

afbeelding van flyguille

05-05-2016, 04:17

Well, I upload now, the final version of the DevKit, the previous having bugs was the motivation.

Final DevKit

CHANGES
------------
The FPS control speed was fixed.
Also was changed the way the sprites can dissapear, now exists a function called "RemoveMe" which remplace the deleted "RemoveOwnSprite" which was doing tricks for removing the sprite from the non active screen buffer, that was deleted because it can do visual glitches by just one frame if the screen raster was just passing over the sprite.

Now "RemoveMe" will setup an empty pattern, and switch the sprite to a new "RemoveMeClass", this class will wait two frames but skipping the sprite render routine, so it remove itself "cleanly" and without using extra cpu time. And no more glitches when a sprite dissapear, on the other hand it has the advantage of be able to be called from any event code, not just from the main class code. Make sure the sprite pattern #43 be empty (zeroed in your sprite set).

Other things improved, now the CONTINUE and GAME OVER screen will wait for the music to end if there is playing a music, if no music, it run a timeout count just like before. For this purpose, now there is a flag variable that flags that the music reached its end and just looped. The flag ir reset any time a new song is mount, or when error on loading (like song not found).

The most interesting change, now when collecting all the fruits, a circular shied will be set on the player, and the player can kill enemies with that shield, well, it is not a "shield" really, because it don't deffends against fireballs, etc.
The player will maintain that shield for a while, helping to kill dozens of enemies easily, so fruits now has a huge meaning (not just for get the revival potion) making players wanting to collect fruits, and if multiplayer, to carefully administrate the fruits, so some player don't steal the fruits that other player needs to complete the set (that status windows will be very handy for this purpose).

Well, I thinks that is all, well, the previous release already has the respawn tile only if multiplayer, so the map turns more populated of enemies if multiplayer.

In the previous release also was already freed like 5KB of space in the main code segments.

Current status of the DevKit, no more bugs in sight, no more "wanted features", it is completed, no a single reason for another update.

So, guys, this one is the final final.

If possible some admin change the download link in the related news-post.

Van Josb

Master (206)

afbeelding van Josb

05-05-2016, 18:48

Grauw wrote:

In other words; “Advice to all programmers reading this: If you want to wait for VBlank, do not just use HALT, but check if JIFFY increments. Using only HALT assumes there is only one interrupt, which is bad practice. Spending a tiny bit of time to write a simple loop which checks JIFFY is totally worth it, because the odds are high that it will cost you a lot more time and headaches in the future if you don’t.”

Hope it’s more clear now Smile. Advice wasn’t really meant for you anyway because you already found out the hard way, hehe.

would you be so kind to show an example of how to use it?

thanks

Pagina 1/2
| 2