The (RND*command questions x infinity<<16) Help Thread

[Clint Thompson]

This is very weird. What raptor does internally is take whatever value R_sprite_x has and add R_sprite_xadd. That's all to it. It really doesn't care much what increment you give it, 0 to max highest or lower number. So if I were you I'd rule out completely that this is the cause of your problems.

 

How are you testing this by the way? Real hardware or VJ?

Strangely on the emulator it works perfect, real hardware is the issue. If it were the other way around I wouldn't even care. I'm going to change some things around and experiment some more this weekend and see if I can figure it out but there's nothing else really going on.

 

If I can't figure it out, I'll post the roms and/or builds for dissection. Naturally it's probably my own fault since almost everything up into this point has been, but changing some like this with the alter effects seems like bizarre behavior.

[sh3-rg]

If you're really stuck and bored, check the object definitions for duplicated lines, I had a couple of similarly weird issues when I'd done some shoddy cut'n'paste action.

[Clint Thompson]

If you're really stuck and bored, check the object definitions for duplicated lines, I had a couple of similarly weird issues when I'd done some shoddy cut'n'paste action.

I did it completely from scratch and it doesn't matter so I'm not really sure what the culprit is but I went ahead and released what I made the other night into the main forums for people to mess with if they want. Strangely it still exhibits slightly slower/degraded audio playback but works fine in the emulator. Doubt I'll even bother with it much more at this point because I've actually made progress elsewhere.

 

The break was much needed and after a good dinner and coming back to the Cosmic madness, I've managed to figure it out. I was certain that I had included the RHIT in the sub routines before and it didn't work so I'm not sure if the build just wasn't cleaned or if I hadn't placed it in the right spot but as long as I'm putting it in BEFORE a needed DELAY(1) -otherwise the graphic simply will not display - it works. Now I can finally move the hell on and work on the actual game itself...

 

[+Stephen]

Ooh - I love Cosmic Ark!

[Clint Thompson]

I've been using Zerosquare for everything up until this point and decided to give the U235 player a go. Seems like a lot of mods play but it has severe cracking/popping issues which most would say means bus overload but it happens even with 28k MOD file.

 

The string is:

 

MODPLAY((int)strptr(MOD_AXELF))

 

Should I be doing something else outside of having the normal VSYNC stuff going? I even fooled around with that and nothing. The only other thing going on is a 16bit image displayed full-time, nothing else, so there can't possibly be bus overload or slowdown as a result. Seems fine in VJ however... whatever sense that makes.

 

Please see example and run in VJ to hear how fine it is then on real hardware to see how shit it is...

 

JagJuke.rom

Edited January 18, 2018 by Clint Thompson

[ggn]

Maybe the Jaguar reacts because the tune is absolutely horrible?

 

Anyway a couple of pointers:

 

a) Both U-235 and Zerosquare's engines don't require anything from the 68000 once it asks them to play something. Adding or removing VSYNC won't do anything. Hell, you can even crash the 68000 and the audio will still be playing.

b) Try removing the object altogether or displaying a 4 bit image. It's not impossible that there's bus implosion - after all depending on the pic's dimensions you're asking the OP to read 70k/frame and upwards.

[sh3-rg]

cracking and popping might suggest more likely the results of all the different mod trackers out there and different implementations (samples not looping correctly). often the only place a mod sounds good is in the tracker is was created in. if it's bus contention, i think you'd normally hear the mod sounding odd in different ways (our way of describing it was it sounds "under water" )

[Clint Thompson]

Maybe the Jaguar reacts because the tune is absolutely horrible?

 

Anyway a couple of pointers:

 

a) Both U-235 and Zerosquare's engines don't require anything from the 68000 once it asks them to play something. Adding or removing VSYNC won't do anything. Hell, you can even crash the 68000 and the audio will still be playing.

b) Try removing the object altogether or displaying a 4 bit image. It's not impossible that there's bus implosion - after all depending on the pic's dimensions you're asking the OP to read 70k/frame and upwards.

 

Will try removing the image and see how that works, thanks for the suggestion!

 

cracking and popping might suggest more likely the results of all the different mod trackers out there and different implementations (samples not looping correctly). often the only place a mod sounds good is in the tracker is was created in. if it's bus contention, i think you'd normally hear the mod sounding odd in different ways (our way of describing it was it sounds "under water" )

 

I've experienced that a bit with the Zerosquare player though it seems hit or miss based on what is being played.

 

 

**would like to also question - is there a way to ROM pack MODs like you can do with the sound files with Zerosquare? I'm guessing not because I tried and it didn't work but seeking clarification in case it actually does and I'm screwing it up.

Edited January 18, 2018 by Clint Thompson

[ggn]

**would like to also question - is there a way to ROM pack MODs like you can do with the sound files with Zerosquare? I'm guessing not because I tried and it didn't work but seeking clarification in case it actually does and I'm screwing it up.

I'm not sure what you mean but rb+ does support two kinds of packing:

 

a) When building a ROM it will pack all code and assets marked as "ABS" in assets.txt into a single lump. This is automatically decompressed when the cart boots

b) You can pack any imported asset individually by specifying "packed" as import attribute. Then it's your responsibility to unpack it using the powaunpack command. You can find some code and info in project "pack" - there a 16bit picture is imported into rom packed and then the main program unpacks it into ram.

 

So I think one of the above will fit your needs. Otherwise let us know.

[Clint Thompson]

I'm not sure what you mean but rb+ does support two kinds of packing:

 

a) When building a ROM it will pack all code and assets marked as "ABS" in assets.txt into a single lump. This is automatically decompressed when the cart boots

b) You can pack any imported asset individually by specifying "packed" as import attribute. Then it's your responsibility to unpack it using the powaunpack command. You can find some code and info in project "pack" - there a 16bit picture is imported into rom packed and then the main program unpacks it into ram.

 

So I think one of the above will fit your needs. Otherwise let us know.

 

Fixed my problem but now I've run into another one.

 

MODPLAY(0) does not stop the mod... the last note played will continue to play until another mod is selected... the other problem is if MOD FILE1 is faster than MOD FILE2, if you play one or the other, whichever first, it permanently sets the tempo or speed for all the mods after that.

 

So if File1 is at 128BPM, and File2 is 150... if you play 2 after 1, it's too slow... if you play 1 after 2, it's too fast. How do you completely kill the modplayer and force it to restart fresh for each one?

 

Also, I've noticed when switching between the files, they're still playing even if I try the MODPLAY(0) so it's like a radio dial.. I go back to another mod file and it has continued playing this entire time.

 

See video:

 

I press 1 and it plays Axel F fine... I play 2 and Billie Jean plays ok but seems a little off and then going to Straight Up it runs way slower than it should. After restart, if you play Straight Up first, it plays just fine, but then everything else every is like double speed. Suggestions besides scrap the MODs and use something else...

 

 

Then playing fine if played first...

 

[+CyranoJ]

 

Fixed my problem but now I've run into another one.

 

MODPLAY(0) does not stop the mod... the last note played will continue to play until another mod is selected... the other problem is if MOD FILE1 is faster than MOD FILE2, if you play one or the other, whichever first, it permanently sets the tempo or speed for all the mods after that.

 

So if File1 is at 128BPM, and File2 is 150... if you play 2 after 1, it's too slow... if you play 1 after 2, it's too fast. How do you completely kill the modplayer and force it to restart fresh for each one?

 

 

That's a bug in the U235 player with some variables/pointers not getting reset.

 

RAPTOR API 2.0 includes fixes for this.

[Clint Thompson]

 

That's a bug in the U235 player with some variables/pointers not getting reset.

 

RAPTOR API 2.0 includes fixes for this.

 

God da... I for sure thought I updated everything once already. Thanks. Shoot me.

[+CyranoJ]

 

God da... I for sure thought I updated everything once already. Thanks. Shoot me.

 

AFAIK, API 2.0 isn't integrated into rB+ at this time. Also, rB+ calls the U-235/Zero players external to RAPTOR. Given that, these fixes would have to be implemented on the rB+ side.

[ggn]

I'll keep this short: rb+ is not going to be moving to raptor 2 any time soon (there are various reasons for this but I'd rather not go into them now).

 

Your problem is known, as atari2600land had the same problems some time ago. The best fix we could come up with is the following:

 

        MODPLAY(0)
        SNDKILL(0)
        SNDKILL(1)
        SNDKILL(2)
        SNDKILL(3)

        VSYNC

        U235SE_modregdump[0]=0
        U235SE_modregdump[2]=0
        U235SE_modregdump[3]=0
        U235SE_modregdump[4]=0
        U235SE_modregdump[5]=0

        ' Play next module
        MODPLAY((int)strptr(Module2))

Try using this snippet when you want to stop a module and start a new one. I only tested it in virtualjaguar and sometimes it wouldn't restart the new .mod file but it might be working ok on the real hardware.

 

If anyone knows of any better way to fix this that doesn't include updating raptor or anything else, I'm up for suggestions.

[Clint Thompson]

I'll keep this short: rb+ is not going to be moving to raptor 2 any time soon (there are various reasons for this but I'd rather not go into them now).

 

Your problem is known, as atari2600land had the same problems some time ago. The best fix we could come up with is the following:

 

        MODPLAY(0)
        SNDKILL(0)
        SNDKILL(1)
        SNDKILL(2)
        SNDKILL(3)

        VSYNC

        U235SE_modregdump[0]=0
        U235SE_modregdump[2]=0
        U235SE_modregdump[3]=0
        U235SE_modregdump[4]=0
        U235SE_modregdump[5]=0

        ' Play next module
        MODPLAY((int)strptr(Module2))

Try using this snippet when you want to stop a module and start a new one. I only tested it in virtualjaguar and sometimes it wouldn't restart the new .mod file but it might be working ok on the real hardware.

 

If anyone knows of any better way to fix this that doesn't include updating raptor or anything else, I'm up for suggestions.

 

 

Thanks again for the help, really appreciate it. Will give that a go tonight and see how it works out.

[Clint Thompson]

I'll keep this short: rb+ is not going to be moving to raptor 2 any time soon (there are various reasons for this but I'd rather not go into them now).

 

Your problem is known, as atari2600land had the same problems some time ago. The best fix we could come up with is the following:

 

        MODPLAY(0)
        SNDKILL(0)
        SNDKILL(1)
        SNDKILL(2)
        SNDKILL(3)

        VSYNC

        U235SE_modregdump[0]=0
        U235SE_modregdump[2]=0
        U235SE_modregdump[3]=0
        U235SE_modregdump[4]=0
        U235SE_modregdump[5]=0

        ' Play next module
        MODPLAY((int)strptr(Module2))

Try using this snippet when you want to stop a module and start a new one. I only tested it in virtualjaguar and sometimes it wouldn't restart the new .mod file but it might be working ok on the real hardware.

 

If anyone knows of any better way to fix this that doesn't include updating raptor or anything else, I'm up for suggestions.

 

This is my current problem during compile and I'm not sure why:

 

[ggn]

Definitely looks like your rb+ setup is out of date. Check your include\raptor.h, this line should be there:

 

extern int U235SE_modregdump[4] asm("U235SE_modregdump");

If not, add it to the file anywhere, save and try compiling again.

 

 

Another option would be to download a clean copy from bitbucket/github and copying your project(s) over.

[sh3-rg]

Not sure on your latest build errors there, Clint, but it seems like some of your mods assume the default tracker values. You could either add tempo commands to each of them at the start (any that are lacking them in position 0 pattern 0, or maybe try making a blank mod with a single sample of looped silence and as many default tracker commands as you can think of and play this between songs. If you're really stuck as a last resort this hacky bollocks approach might work, if you need help making it I can help.

[Clint Thompson]

Well that was a good learning exercise.

 

extern int U235SE_modregdump[4] asm("U235SE_modregdump"); is absolutely not in raptor.h, even after a Rb+ re-install so manually added. Also, I noticed it said v1.3 even though my old version was 1.3. Feel like that should be changed to reflect any updates made.

 

Strangely it didn't fix it the first time I implemented but it didn't have a build error either. Clearing up the cache did the trick and now it seems to work as it should and expected.

 

Thanks again for the patience and aid everyone!

Edited January 20, 2018 by Clint Thompson

[ggn]

Sorry, my bad, you're absolutely right - I should have said rbasic.h.

 

Also, just to clarify: if you're using the installer to set up your rb+ then you're not getting the "bleeding edge" version. I always suggest people to download the repository and use the files directly as they're much more recent since v1.3 (like I say on tutorial #1).

[Clint Thompson]

Sorry, my bad, you're absolutely right - I should have said rbasic.h.

 

Also, just to clarify: if you're using the installer to set up your rb+ then you're not getting the "bleeding edge" version. I always suggest people to download the repository and use the files directly as they're much more recent since v1.3 (like I say on tutorial #1).

 

I actually just downloaded all the updated files and overwrote the old ones but it broke and wouldn't build anything after so I just did a fresh download and re-install and viola it worked again - then added the line in raptor.h

 

Either way anyway, it was a good lesson and I appreciate the help.

 

Thanks so much!

[ggn]

I actually just downloaded all the updated files and overwrote the old ones but it broke and wouldn't build anything after so I just did a fresh download and re-install and viola it worked again - then added the line in raptor.h

 

Either way anyway, it was a good lesson and I appreciate the help.

 

Thanks so much!

This is super weird but it's ok as long as it works for you . On to the next subject!