I managed to get your code working in a basic game with two sprites bobbing around. when I try to integrate it into my 4.7 game which uses an intro/menu script, if I put the music ASM calls at the beginning of the menu event, it plays the music fine while waiting for the controlmenu to be chosen, but then bails when it jumps to the game initialization menu and first screen. If I put it in the game init event, I get no music in the intro menu (as that comes before game init) but the game still bails out once you pick the controlmenu option. Any ideas?
I don't think I've got any memory overlaps as I've planned around that. I've tried removing the menu event entirely and the game bails with the music called in game init, even without a menu event in front of it.
Turns out there is something in the game init event that the ASM call hates. If I put it at the end of the game init event, it runs fine. At the beginning and it bails. With the music call in the game init, it means my main menu is quiet so I just need to figure out what the ASM call doesnt like.
Edit: I've cleared out everything in game init and moved it over to the intro/menu event. I call the ASM at the end of the intro/menu event. music plays fine but with an empty game init, it still crashes.
If I put the ASM call inside of game init, its fine.
This means that main menus can't have music. Maybe I can issue a stop, then a restart in the game init?
Another Edit: I issued the ORG+33 disable command at the end of the intro menu event, then recalled the init routine at the end of the game init event. all sorted. the song just restarts, thats all. I can live with that.
Post by alessandro on Jun 15, 2017 15:29:15 GMT -5
Hi Prefim, glad to hear you have sorted your problems. Yes, music in game menus from within AGD is something I did not try because I knew it would not give the intended result.
It would however still be possible to have AY music playing in the background of menus, but you should write a menu routine yourself and not use the AGD CONTROLMENU command. You could have, for instance, the music playing in the background, and check if a certain key has been pressed. If the key corresponds to a menu item, music stops, game starts and the in-game tune is played. Otherwise the music keeps playing.
Post by zynaps2017 on Jun 18, 2017 15:16:13 GMT -5
My name is Jaime Grilo, creator of The Treasure Of Lumos.
Sorry to bother you but i have one problem with ASM and AY music. I don't know programing and i tried to insert a music file converted to .tap file in a AGD game, but withou success.
I want to make a game with Ay music without using proggraming compiler, only ASM commands. What i did wrong? Files: *gamemg.tap = main game without basic loader *gamebl.tap = basic loader *chuta.tap = AY music file converted *chuta.ay = AY music file, but zx blockeditor don't reconize it, so i used the .tap file.
I put a video of what i did in 2 facebook groups: Arcade Game Designer and Spectrum For Everyone.
I am not on Facebook so I cannot see the videos, however I tried your game - under emulation only for now - and the AY music was playing in the background.
Could you describe your problem so that we might try to help you? Gracias.
You are talking about The Treasure Of Lumos. In that game, David Saphier helped me to put AY music in the game. But i have 2 more games in the forge and i don't want to bother David to do that (he knows Assembler language, like you, but i don't). I just wanted use ASM commands without assembler. Meanwhile, Mat Recardo has put a video explained how it works. And it doesn't work like i want. He quotes your assembler code precisely in this subject "AY backgroud music" You can see his video here: www.youtube.com/watch?v=6DCqRXNZGGw
Because i'm using Spectaculator (instead of Fuse), i'm gonna use my zx spin 7 just for the assembler code (your code, changing the call number). I use Spectaculator for AGD main game and for basic loader, and zx blockeditor to assemble/compile all the blocks (main game, basic loader and music).
Last Edit: Jun 20, 2017 1:28:57 GMT -5 by zynaps2017
I would suggest you not to use ZX Spin's in-built assembler, it's an experimental feature and contains several bugs (as Dunny himself stated on the WOS forum). If you need to write and assemble M/C, it is much better to employ a text editor like Notepad ++, save the code as an .ASM file and assemble it with a cross-assembler like Pasmo.
I have seen the video but there are some differences with what I recommended to do in my earlier post. It is more convenient to save all blocks - game code, music caller code, music starter and music data - all together in a single block rather than load them separately. Even better it would be to compress them with a good compression utility like Einar Saukas' ZX7 and, if you really want to play it fancy, add a turbo loading scheme like my own SetoLOAD I explained it with an example here.
The video does not say - but it is stated into the AGD user manual - that if you create a game with the Particle specialization you will need an extra 300 bytes at the end of game code as a buffer space for particle effects. This means your music caller code will not have to overlap with that space otherwise the game will crash.
Similarly, the last 768 bytes from 64768 to 65535 are used as a dummy collision map area to distinguish between different types of blocks - walls, ladders, empty space and so on - so you must care not to reach that area with your music data.
Finally, the music caller code creates the 256 byte area for the AY interrupt table at address 64512, and you must also leave that space free from other data.
What does not go as expected in your other game? Perhaps it could be caused by one or more of the above.
Post by zynaps2017 on Jun 20, 2017 17:17:54 GMT -5
Hello, Alessandro. I solved the problem.
The fact is that i tried but because my game is near 61000, when i assembled it crashed because exceeded the limit of 64768. I make an experience with an old version of the unfinished game and it works!!
I thank you very much for your assembler code. I used the ZX Spin 7 (i don't know how to use Boriel, for instance). Further, i will try to incorporate 3 music files (not one):one for the game, one for the screen when the player lose; one for the screen of complete the game.
Last Edit: Jun 21, 2017 1:34:35 GMT -5 by zynaps2017
Post by zynaps2017 on Jun 20, 2017 17:25:31 GMT -5
"I have seen the video but there are some differences with what I recommended to do in my earlier post. It is more convenient to save all blocks - game code, music caller code, music starter and music data - all together in a single block rather than load them" Yes! That's what i did (kind of...). Mat pretended to show step by step what could happened. I make a video of what i did. In this video, the game doesn't work because exceded the top limit. but i did the same method with the early stage game and it works! Here's the video i made: www.youtube.com/watch?v=OZyjcEOgmz8&feature=youtu.be
Last Edit: Jun 21, 2017 1:34:18 GMT -5 by zynaps2017
Post by zynaps2017 on Jun 25, 2017 16:58:52 GMT -5
"I solved the problem." NO, I DIDN'T!
"I make an experience with an old version of the unfinished game and it works!! " NO, IT NOT WORKED!
In the exemple video, it seems to work all fine, but it doesn't. When the player loses all lives, the game continue working and when i expected to return to the start menu, the music stops and the game crashes like showned in the picture. I tried the two games in forge, i tried previous versions with more memory free, i even tried the first game (The Treasure Of Lumos - not the final version, because that was David Saphier that programmed the assembling ay music and it works 100% -, version without music at first)... The music works fine as the gam starts, but when we lose game, instead of go to main menu, it happily crashes with a "0 OK, 60:1".
Last Edit: Jun 25, 2017 17:01:48 GMT -5 by zynaps2017
Post by alessandro on Jun 26, 2017 17:30:20 GMT -5
Hola Jaime, what you see is definitely not a crash - it is the normal way of returning to BASIC of a machine code program, through a RET instruction. It means your code is working correctly, so don't panic
Perhaps you did not insert a command in your BASIC start program which would launch the game again after its end. In AGD 4.x, games always start at address 32000, although the actual code begins at a lower address, around 31000 and below.
When you see that message, enter RANDOMIZE USR 32000 and see if the game starts again.
Last Edit: Jun 27, 2017 3:53:38 GMT -5 by alessandro