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
Для того, чтобы оставить комментарий, необходимо регистрация или !login
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
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.
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
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 , 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.
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 . 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.
flyguille: That’s not my point . 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 .
flyguille: That’s not my point . 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 .
can you elaborate more, I don't understand you.
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 . Advice wasn’t really meant for you anyway because you already found out the hard way, hehe.
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 . 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").
Well, I upload now, the final version of the DevKit, the previous having bugs was the motivation.
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.
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 . 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
Don't you have an account yet? Become an MSX-friend and register an account!