Heaven/TQA Posted January 28, 2015 Share Posted January 28, 2015 as everybody uses the RMT... I know that there are Delta Composer which is used in Asskicker demo... I was wondering what is the best player in terms of cpu cycle usage? CMC? MPT? or any other? I am asking because right now in my latest projects RMT sux too much cycles I have to admit... 1 Quote Link to comment Share on other sites More sharing options...
ac.tomo Posted January 28, 2015 Share Posted January 28, 2015 (edited) This subject came up in a previous thread, I also would like to know how many cycles different sound engines take. I was told that RMT changes depending on the complexity of the tune, but how many cycles wasn't stated. Another engine I used to use is called Torsten Karwoth's soundmon, originally only 4 channels, though, I do believe there is an 8 channel version. This engine takes approx. 2.5 scan-lines per frame (the 4 channel version). Edited January 28, 2015 by ac.tomo Quote Link to comment Share on other sites More sharing options...
TheNameOfTheGame Posted January 29, 2015 Share Posted January 29, 2015 Yes, a table listing the various cpu usages would be very helpful I'm sure. Good idea! Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted January 29, 2015 Author Share Posted January 29, 2015 (edited) Oh... good old T. Karwoths Soundmon? I used that in my first productions dated back 1990... Jesus... totally forgot... researches showed me that there are quite a lot soundtrackers: - CMC - MPT - TMC - RMT - Future Composer - Delta Composer - Peter Finzel (those were times) Soundmachine - T. Karwoth's Soundmonitor Edited January 29, 2015 by Heaven/TQA Quote Link to comment Share on other sites More sharing options...
ac.tomo Posted January 29, 2015 Share Posted January 29, 2015 Black magic composer was another, though, this does take a lot of time, not one of the better ones I believe. There's also pro-tracker, which is capable of some very nice digitized musix, allowing for frequency control with each digi. Neotracker is also apparently another good one, though, time wise, how much they take I don't know, all I know is that they usually execute during the VBlank and quite often, musix trackers (engines) that run during the VBlank don't usually leave that much time for anything else (during the VB). Quote Link to comment Share on other sites More sharing options...
Creature XL Posted January 29, 2015 Share Posted January 29, 2015 I am asking because right now in my latest projects RMT sux too much cycles I have to admit... Why not implement the idea Rybags, I guess it was him - if not he posts so many good things that the probability is high, had years ago. Let the RMT-player output its POKEY values in a ring-buffer, and copy them to the registers in the VBI (or DLIs). It cannot go any faster than that. The idea would be that you the program has enough CPU at some time. For example, in a scrolling game (or demo screen) you have to copy new gfx data. However, only in every e.g. 4th frame, so you have three frames to pre-render the sound data. Mostly my programs do most of the stuff in DLIs and the VBI. And I have a main-loop to do things which doesn't need to be done every frame - like counting score or advancing the timer display or stuff like that. However, in many frames the loop is idle and can happily pre-render music TBH, I haven't really thought that trough and I realise it is actually not easy, as you need to keep track and not to render too much or too little.But it should get the idea across. If I missed something, someone (maybe Rybags) will tell us where I went wrong 1 Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted January 29, 2015 Author Share Posted January 29, 2015 On my list is render the song to dump data and store that in extra ram bank... No need for ring buffering then.... VBL would take 9 values (?) of pokey and paste them into hardware... But would little bit overkill Quote Link to comment Share on other sites More sharing options...
Creature XL Posted January 29, 2015 Share Posted January 29, 2015 On my list is render the song to dump data and store that in extra ram bank... No need for ring buffering then.... VBL would take 9 values (?) of pokey and paste them into hardware... But would little bit overkill You demo coders suck I aim for 64k (well, 62k). But, if you rewrite the RMT-player to render into a bank, it would be easier fo rme to modify it use ring-buffers Although, 9 values you say? that means over 2k on ring-buffers (as a page per value is the easiest way to do it). Anyhow, going to bed now... Quote Link to comment Share on other sites More sharing options...
ac.tomo Posted January 29, 2015 Share Posted January 29, 2015 (edited) What are ring buffers? Edited January 29, 2015 by ac.tomo Quote Link to comment Share on other sites More sharing options...
AtariGeezer Posted January 29, 2015 Share Posted January 29, 2015 (edited) What are ring buffers? Also known as circular buffers... You have a head and tail pointer that tells you where to read and store the next variable. See: http://en.wikipedia.org/wiki/Circular_buffer for explanation on usage. Edited January 29, 2015 by AtariGeezer Quote Link to comment Share on other sites More sharing options...
ac.tomo Posted January 29, 2015 Share Posted January 29, 2015 (edited) You demo coders suck I aim for 64k (well, 62k). But, if you rewrite the RMT-player to render into a bank, it would be easier fo rme to modify it use ring-buffers Although, 9 values you say? that means over 2k on ring-buffers (as a page per value is the easiest way to do it). Anyhow, going to bed now... Not all software needs 62K, there are loads of excellent games that take as little as 16K. @creature, and as for demo-coders, it's those people who break down the barriers of impossibility & discover newer & better ways of doing things. point aired. Edited January 29, 2015 by ac.tomo Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted January 30, 2015 Share Posted January 30, 2015 (edited) Nah, overkill for me (aside from a great Motorhead track) is to not have any RMT player on the A8 at all. Have the RMT composer app itself output the whole 9-byte dump stream and then: a) take each byte stream and convert the values to the movement size (note 1) b) Huffman analyse the frequencies of the resulting values (note 2) c) encode each stream using the table produced. Alternatives would be to make a) optional (leave values as is) and/or for b) & c) be to replaced with run-length-encoding. note 1: i.e. new value - old value but as this only gives us -127 -> +127 So -128 (b10000000) could be used as an escape to have the following byte set the new value. note 2: bit of extra memory space wasted needing to save the table in addition to the encoded song data. Therefore a small playback routine can get the next byte from each of the the 9 streams and then pump these to the Pokey registers. Benefit... more CPU time for your super screen/sprite code. Potential space savings by the compression on the raw Pokey data and size of playback routine. Disadvantages... probably a PITA to implement... even the compressed data may end up larger than the actual RMT song/pattern/instrument data Other considerations... sound effects?.... 50/60Hz need different initial outputs? Edited January 30, 2015 by Wrathchild Quote Link to comment Share on other sites More sharing options...
Rybags Posted January 30, 2015 Share Posted January 30, 2015 Yep, I had the idea of buffering - it's advantageous in situations where you might have a mix of frames with spare time and those with next to none (and in a deterministic way). I also had the idea of simply churning the register output to a file then using that dump (preferably with some compression) for playback. VBlank for tracker calls isn't really critical, it can happen any time. What is important is the actual stuffing of notes into registers, that should be done in some sort of timed fashion, although we get away with composing RMT stuff for PAL and skipping every 6th frame's playback call if it's running on an NTSC system. Realistically though, a compressed playback system is likely to take 3 scanlines or more - probably slightly less time than a "slack" RMT call. The songs that have the background colour change are good indicators of the fluctuating time for RMT calls. Quote Link to comment Share on other sites More sharing options...
emkay Posted January 30, 2015 Share Posted January 30, 2015 People often wondered about the clearness of some Basic programmed tunes. It's simple as that. They're not stuck at a VBI doing changes on POKEY's registers. Start a note is some Pokes, do variations, is some pokes, and the tune itself plays on a "realtime" counter, depending on the speed of the played note, the volume gets a correction every second, instead of every VBI Cycle, which also solves the 50/60hz problem. Btw: This would also work with using POKEYs modulation features. Quote Link to comment Share on other sites More sharing options...
Creature XL Posted January 30, 2015 Share Posted January 30, 2015 (edited) Not all software needs 62K, there are loads of excellent games that take as little as 16K. @creature, and as for demo-coders, it's those people who break down the barriers of impossibility & discover newer & better ways of doing things. I tried to express I try to squeeze my GAMEs into 62k instead of using extended RAM as Heaven suggested for his DEMOs. And I know pretty well what demos are about. The fact I haven't released a hi-profile demo on the A8 does not mean I don't know one thing or the other about them. EDIT: By now I have realised that for games the POKEY-pre-render-streaming is useless as long as SFX use the RMT-routines as well EDIT 2: Another problem for games. Take "heli in the Caves". The tune changes when you enter a shop and gets changed back to the normal song when leaving. Or imagine a game (like Metroid on the NES f.e.) where you get a jingle when you collect something essential. Either not possible with streaming or uses a lot of space as you have multiple song-stream data lying around. Again, possible in a demo not so useful in "complexer" games. For now I still prefer the buffed version, as I know for certain, as stated in that post, I have (almost deterministic) frames where lots of CPU power is wasted. Edited January 30, 2015 by Creature XL Quote Link to comment Share on other sites More sharing options...
TMR Posted January 30, 2015 Share Posted January 30, 2015 Have the RMT composer app itself output the whole 9-byte dump stream and then: a) take each byte stream and convert the values to the movement size (note 1) b) Huffman analyse the frequencies of the resulting values (note 2) c) encode each stream using the table produced. This is basically what .YM files are, the values for each register are taken once a frame and stored as streams, with the final file then optionally being compressed (can't remember if it's LHA or LZH off the top of my head but you can just change the extension to open it). The converter for my Apple II Mockingboard driver takes an unarchived YM, rips the streams out, nudges the frequencies and RLE encodes the result, so the output is inefficient for memory but quite quick to play back. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted January 30, 2015 Author Share Posted January 30, 2015 yeah... look how much a Stereo RMT track needs cycles per frame... and a 9 byte RLE encoded stream could be the way to go. I definitly will try... right now RMT costs me 1 FPS. Oxyron used on c64 similar method in some productions btw. re: sound fx... right now we even have no sound fx library (not RMT)... I have no clue how... Look like RoF, Koronis Rift, Alley Cat, Star Raiders etc programmed sound. I am totally newbie on this field... Does anyone have experience in programming "explosions" etc? Quote Link to comment Share on other sites More sharing options...
Creature XL Posted January 30, 2015 Share Posted January 30, 2015 yeah... look how much a Stereo RMT track needs cycles per frame... and a 9 byte RLE encoded stream could be the way to go. I definitly will try... right now RMT costs me 1 FPS. Oxyron used on c64 similar method in some productions btw. re: sound fx... right now we even have no sound fx library (not RMT)... I have no clue how... Look like RoF, Koronis Rift, Alley Cat, Star Raiders etc programmed sound. I am totally newbie on this field... Does anyone have experience in programming "explosions" etc? Just for simplicity the guys doing msx (and sfx) for me (505 and OSon) use RMT. It's just an instrument. Which you can trigger with a call the RMT-player (Offset +15 or +9? dunno). That is not to say that I am of the opinion that the sfx used by me are awesome Check my signature link the my NYD 2013 video there are explosions from 505. Guess basically it's fast Attack and slow Decay. Waveform is essentially noise. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted January 30, 2015 Author Share Posted January 30, 2015 (edited) yeah... Miker did Griddrunner SFX in RMT (uj... do I need to release the final since years... ) but I want to have RMT for our music guys and then "export" "compress" stuff in production. but RLE plus 9 bytes per frame sounds not bad... (very optimistic). SFX I was interested in "old fashion" programmed way... means BASIC or assembler... (sound FX in BASIC can be transfered to high level). Edited January 30, 2015 by Heaven/TQA Quote Link to comment Share on other sites More sharing options...
pseudografx Posted January 30, 2015 Share Posted January 30, 2015 One other option to reduce player overhead is to play a tune at 25fps. That would save 50% of time required. Of course the tune would have to be adjusted for that but might still sound reasonably good. Quote Link to comment Share on other sites More sharing options...
Creature XL Posted January 30, 2015 Share Posted January 30, 2015 yeah... Miker did Griddrunner SFX in RMT (uj... do I need to release the final since years... ) but I want to have RMT for our music guys and then "export" "compress" stuff in production. but RLE plus 9 bytes per frame sounds not bad... (very optimistic). SFX I was interested in "old fashion" programmed way... means BASIC or assembler... (sound FX in BASIC can be transfered to high level). You are really trying to do such a compressed version? that would be cool! Programming sfx... same way as in basic. Using tables should be appropriate as you have not so much sfx and they are mostly short. But I guess you know that. Therefore, I am not sure if I got your question. When it is about the actual values you have to use then ask the msx guys. Let them do it in RMt and just build tables according to their instrument settings. Or rephrase your question Quote Link to comment Share on other sites More sharing options...
MaPa Posted January 30, 2015 Share Posted January 30, 2015 (edited) It's just an instrument. Which you can trigger with a call the RMT-player (Offset +15 or +9? dunno). I don't know either I just use jsr rmt_sfx (same for jsr rmt_init and jsr rmt_play) Edited January 30, 2015 by MaPa Quote Link to comment Share on other sites More sharing options...
Rybags Posted January 30, 2015 Share Posted January 30, 2015 Related to PG's idea... another thought I had was do half the processing per VBlank if possible, eg - 2 voices per frame. Then do the actual register stores at 25 Hz. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted January 30, 2015 Author Share Posted January 30, 2015 here is my dumper... done in 20 min at lunchbreak... * RMT steamer * exporter msx equ $3200 rmtplayer equ $3c00 dump equ $4000 ; $0c00 per $d20x stream stereomode = 0 org $2000 init jmp testplay lda #0 ldx #<msx ldy #>msx jsr rmtplayer loop lda #0 sta $d01a lda $d40b cmp #$40 bne loop lda #15 sta $d01a ; lda:cmp:req 20 ;wait 1 frame jsr rmtplayer+3 lda #0 sta $d01a lda dump_d200+2 cmp #$4c bcc loop jmp loop testplay lda $d40b cmp #$40 bne testplay ; lda:cmp:req 20 ;wait 1 frame lda #15 sta $d018 dumpad lda dump sta $d200 lda dump+$0c00 sta $d201 lda dump+2*$0c00 sta $d202 lda dump+3*$0c00 sta $d203 lda dump+4*$0c00 sta $d204 lda dump+5*$0c00 sta $d205 lda dump+6*$0c00 sta $d206 lda dump+7*$0c00 sta $d207 lda dump+8*$0c00 sta $d208 ; .rept 9 inc dumpad+1+#*6 bne @+ inc dumpad+2+#*6 @ .endr lda #0 sta $d018 jmp testplay ;horror 40 sec * 50 ticks per frame = 2000 bytes per stream = 9 steam = 18000 bytes org msx ins "horror_3200.rmt",6 org rmtplayer icl "rmtplayr_dumper.asm" org dump ins "pokey_dump.dat" run init RMT Dumper.zip Quote Link to comment Share on other sites More sharing options...
analmux Posted January 30, 2015 Share Posted January 30, 2015 For short tunes this would be an excellent solution to do just raw data & low CPU. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.