ROM assets vs ABS assets?

[WAVE 1 GAMES]

I am currently working on a 4mb rom but have ran into some issues on the testing side of things.

For this project the amount of needed assets has well surpassed 2Mb so I decided to go for a 4mb ROM style game instead of my typical 2MB ABS. (so will likely be a cart only final)

I first dug through ggn's tutorial concerning audio playback in RB+. All of the music tracks for this game are now designated ROM in the assets.text file and I followed the instructions on what to write for them to play correctly in the .bas

 

for this project I am using Zeroplayer

 

 

so for example in the assets file I have:

ROM,SFX_ZOMBOOGIE,SFX_ZOMBOOGIE,ASSETS\zombieboogie.raw

 

and in the .bas file when it's time to play the audio I have:

SNDZEROPLAY(2, (void *)SFX_ZOMBOOGIE, (SFX_ZOMBOOGIE_end-SFX_ZOMBOOGIE+3) and 0xfffffffc, 35000/4000, Zero_Audio_8bit_Unsigned|Zero_Audio_Looping)

 

YES 35000/4000 is perfect and it IS a .raw file.

 

 

This works absolutely fine in Virtual Jaguar. It hammers it out with absolutely no audio issues whatsoever, however when I try to load the binary onto my skunk and test it out on real hardware I get complete garbage feedback and noise where the music track should be and all of the sounds that have are designated ABS in assets are playing fine on top of the garbage noise.

 

another thing I am trying to do is force feed a high resolution background animation using a trick I picked up from another thread. for this however I seem to  be having the same issue. the 6 individual frames are written in the assets file as such:

ROM,BMP_FRAMEA,gfx_clut16,ASSETS\hallframeA.bmp
ROM,BMP_FRAMEB,gfx_clut16,ASSETS\hallframeB.bmp
ROM,BMP_FRAMEC,gfx_clut16,ASSETS\hallframeC.bmp
ROM,BMP_FRAMED,gfx_clut16,ASSETS\hallframeD.bmp
ROM,BMP_FRAMEE,gfx_clut16,ASSETS\hallframeE.bmp
ROM,BMP_FRAMEF,gfx_clut16,ASSETS\hallframeF.bmp
ROM,BMP_SKINWALKER,gfx_clut16,ASSETS\ranch.bmp

in the .bas file you can see me pointing to the individual frames for the background object with the following counter sequence:

select case halltimer

case 0
RSETOBJ(HALLWAYBG,R_sprite_gfxbase,(RGETOBJ(frameA,R_sprite_gfxbase)))
RUPDALL
case 4
RSETOBJ(HALLWAYBG,R_sprite_gfxbase,(RGETOBJ(frameB,R_sprite_gfxbase)))
RUPDALL
case 8
RSETOBJ(HALLWAYBG,R_sprite_gfxbase,(RGETOBJ(frameC,R_sprite_gfxbase)))
RUPDALL
case 12
RSETOBJ(HALLWAYBG,R_sprite_gfxbase,(RGETOBJ(frameD,R_sprite_gfxbase)))
RUPDALL
case 16
RSETOBJ(HALLWAYBG,R_sprite_gfxbase,(RGETOBJ(frameE,R_sprite_gfxbase)))
RUPDALL
case 20
RSETOBJ(HALLWAYBG,R_sprite_gfxbase,(RGETOBJ(frameF,R_sprite_gfxbase)))
RUPDALL
case 24
halltimer=0
RUPDALL

end select

this is supposed to be rendering the individual frames to the background every 2/2 seconds. The objects frameA-frameF have the correct sprite index in the rapap.ini file and remain inactive through the entire loop so we are only using them to point to the .bmp files here.

 

this trick works FINE in Virtual Jaguar. In fact it looks really bad ass and seems to handle the whole process quite well but when I try and load to skunk and test on real Jaguar hardware I get a distorted image with large grey bars running through the animation. Everything seems to be running at full speed and you can kind of see the animation but it's like the image files are not making it all the way through.

 

I do not want to try packing these bmps and using powaunpack because I am already packing a whole bunch of other stuff and anyway doesn't that automatically go into RAM in packed form? I don't want to do that.

 

I also noticed that it will not allow me to set more than 7 audio files to ROM in the assets file. I ended up doing all of my music tracks here as ROM and left all of the regular sound effects as ABS. If I try to designate any more than 7 audio files as ROM I get a build error message saying  this:

 

 

Is there a reason for this limitation?

 

What am I doing wrong with ROM vs ABS for this project in this case? It seems to me that this is some sort of compiling error on my part in that I am not telling it what to do with the files starting with ROM. But if that is the case then why does it all work flawlessly in Virtual Jaguar?

 

Is there something special I have to do with my skunk in order to test this correctly?

 

I did try the following build instructions

 

build.bat JZ2 sendy

build.bat JZ2 rom sendy

build.bat JZ2 rom unpacked sendy

 

all of these gave me the same exact results, so is there a compiling step I have missed or a RAM vs ROM rule I haven't learned yet?

 

please help.

Edited July 25, 2020 by WAVE 1 GAMES

[ggn]

Okay, you might be getting bit by ROMwidth issues since it works ok in VirtualJaguar. We discussed this topic here: 

There are 2 snippets of code in that thread. IIRC what I have in the first post should work fine on the skunkboard. Zerosquare's is more generic but it hasn't been verified by anyone on skunks.

 

So I would suggest you put he snippet from the first post in your rapapp.s, probably after the "YOUR APPLICATION GOES HERE" comment. If that works, try swapping it out with Zerosquare's. If that works then cool, I'll add it as standard boilerplate code in all rb+ projects. (hey, it's only been 4 years since I asked for verification!)

 

If neither work we'll figure out something else...

 

 

[SCPCD]

I haven't played much with RB+, so don't understand what will be generated with the above code, but what I understand, you want the bitmap data to be readed directly from ROM memory.

If this is the case, you will need to take care about the huge loss of performance you will have :

 

The skunkboard having a 16-bit bus, it's 4 times slower than main memory for 64-bit read.

Adding to that, the number of cycles needed to read on ROM space is higher : at least 5 cycles (don't remind what is the speed setted on skunkboard) and can be up to 10 cycles (standard cartridge and I think also for the JagGD).

 

If OP bitmap data is directly readed from ROM space, it's possible that there is not enough bandwidth to parse the whole OP List (i.e. reach the STOP object) in less than ~64µs (one line drawing)

If this happens, you will have corrupted graphics on screen.

 

 

Edited July 25, 2020 by SCPCD

[WAVE 1 GAMES]

ok so from what I understand from the info you provided here this in fact IS a testing issue. (it's the skunks fault!) From what I gathered from Zerosqaures comments in that thread burning this game in it's current state to rom chips it should work just fine. obviously this isn't a solution to the testing issue but with that in mind I have to wonder,  I use the universal boot header with my games. Is the universal boot header ROM width set to the correct width out of the box, or would that need to be modified as well if I'm going to use it?

 

@SCPCD You mention there might be performance issues when testing pulling the bmp data directly from ROM. in this case you only mean from SKUNK and not actual ROM chips right?

 

I'll tell you what I'm going to do. I am going to apply the code snippet to my rapap.s file provided by ggn here. Then I'm going to test on Skunk. After that (provided that it does work on Skunk) I will split the rom and put it on 2 rom chips and use my tester board to see how it goes. I'll report back here how it all goes, if it works on skunk or if the code causes any issues on real ROM chips.

 

thanks guys

Edited July 25, 2020 by WAVE 1 GAMES

[ggn]

9 hours ago, SCPCD said:

I haven't played much with RB+, so don't understand what will be generated with the above code, but what I understand, you want the bitmap data to be readed directly from ROM memory.

 

A line in assets.txt like 

ROM,BMP_FRAMEA,gfx_clut16,ASSETS\hallframeA.bmp

actually tells the program that puts all code and graphics/sounds/etc to place the .bmp somewhere in rom, align it to 16 byte boundary, convert it to jaguar native format, and expose a variable called BMP_FRAMEA to the program that contains the address in the ROM.

 

As for bandwidth concerns, it's exactly what @SCPCD described - it'll probably be fine unless you overload the OP. In the later case magical stuff will happen. There are things to do to get over this, but let's cross that bridge when and if we come across it.

[WAVE 1 GAMES]

ok, so neither code snippet seems to have any effect when loading to skunk. I did put each one right after *YOUR APPLICATION GOES HERE MODIFY AWAY*

 

Is there somewhere else that I can try putting the code, or does something else in the rapap.s file need to be changed in order for this code to take effect properly? I ask because I get the same exact results as before. First on audio and then on the bmp. It's as if we aren't doing anything differently at all.

 

what about the universal boot header? doesn't RB+ use that when compiling a rom? does that need to be edited for proper width?

 

I'm now going to try splitting and burning the rom and putting on rom chips

 

that will at the very least serve as process of elimination and tell me if this is all a waste of time or not. According to what I read from Zerosquare, on actual ROM chips it should in theory work fine.

 

thanks

[WAVE 1 GAMES]

OH   SNAAAAAAP

I GOT IT WORKING

it goes here in place of the other memcon command

 

[WAVE 1 GAMES]

ok so I recorded a video of it running on skunk with my celphone. The music files seem to be working flawlessly but the high resolution background animation for the hallway not so much. we don't get the large grey bars running through the image this time, but the game is hemorrhaging in terms of FPS and the image is distorted as well as everything else on screen at this time. I'm willing to bet I have have overloaded the OP, BUT I can test this too as I have another bmp that isn't as large that is also being pulled from ROM directly. I'll check that out next. In the meantime the dimensions for the graphics being distorted are 352X112. We are pointing to each graphic at the corresponding time in the counter sequence. They are 6 separate frames. they are 16 bit images. The image is being stretched X 64 vertically but no scaling horizontally. would love to come up with a workaround on this that doesn't involve sacrificing resolution or color depth, but now I am left wondering if this is due to the SKUNK bus speed or overloading the OP entirely.

 

 

For reference I did try both the code from ggn and the code from zerosquare for this. ggn's code is the one that seems to be correctly pulling the assets from rom. the code from zerosquare delivers the same exact results as before.

Edited July 26, 2020 by WAVE 1 GAMES

[WAVE 1 GAMES]

ok so just did a quick playthrough to get to the other stage that is using a bmp from ROM. the bmp file in question is this one:

 

ranch.bmp

 

its not very hefty at all in size and displays just fine when I load from load from ABS.

 

the layer in question is the grassy one with the ranch house on it. it is also a 16 bit color image.

 

it should look like this in game:

 

 

 

however if you go to the 1:09 mark of this video you can see this is distorted as well:

 

 

 

Now with this particular bmp file only being 83k and me knowing full well if I change it to ABS in the assets file it will display perfectly, I'm not inclined to believe (at least not in this particular case) that I am over running the OP here. If you look at the distortion in this video we have sound glitching as well as lines and the image appears to be scaled up! There is no scaling on this particular object so that's a bit strange, I'm wondering if this is due to the SKUNK's bus or if it's just a matter of doing it a different way. Maybe because I am playing a sound from ROM during this level AND trying to pull the bmp from ROM also in this instance? I simply don't know, but would love some input and in best case scenario find a "have my cake and eat it too" work around. I already know for the animated hallway sequence I COULD try going to 4 bit color mode on that, but that would mean I would have to make the background animation 1 large 4 bit bmp containing all 6 frames and of course it wouldn't look as nice.

 

 

EDIT----> I did go back in and remove the music being played in the hallway sequence to see if it was an issue where I am fighting for both sound and graphics from ROM but there didn't appear to be any change there either

 

Edited July 26, 2020 by WAVE 1 GAMES
tried some more stuff

[SCPCD]

The distortion in the video & sound glitch is typical to not enough bandwidth for the OP.

lets verify it :

- the OP has ~64µs to parse the whole list each line : 26.59MHz * 64µs = 1701cycles

- the picture is 352 wide in 16bpp, and the skunkboard is 16-bit at 5cycles : (352*2)/2 *5 cycles = 1760cycles (only for data, extra cycles is needed to read the object description)

 

The scaled up is a side effect to this as the line buffer is swapped while OP haven't finished yet the previous line.

 

What you can do to grab some cycles, is to reduce horizontally the picture. 352 is way larger than the visible screen which is 332 in overscanned.

With a 320 wide picture, this will give you 100 available cycles to other objects in internal RAM and if there is not to much object, to wide or to much scaled, maybe it will be sufficient.

 

If you don't want to edit the picture, you can play with the Object IWIDTH and Object DATA to clip it.

 

PS :

on standard cartridge, wich is 32-bit 10cycles, you will have : (352*2)/4 * 10 cycles = 1760 cycles.

With faster ROM you can set it to 5cycles and have 2x bandwidth.

 

 

About the Universal header, I would say it's by default for standard cartridge so 32bit 10cycles unless it was already modified.

 

 

Edited July 26, 2020 by SCPCD

[ggn]

First of all, sorry for the misinformation on where to apply the romwidth code, I'm forgetting things...

 

Anyway, seems like you are out of bus time as @SCPCD proved above. The obvious solution to this would be to keep as much as possible in RAM, but that's not always doable. On the flip side: do you actually need all the data you have in RAM at any given time? I'd be willing to bet "no", since each level will more or less have different backgrounds and musics etc.

 

The code certainly won't be that big, I would assume that, including raptor and zero's audio library, it shouldn't go over than 100-150k. Then we also add 16k from the start of the RAM which is reserved for various things and that's it. Let's round up and say you have about 1.8Mb to play with. That's still a lot of space to store stuff.

 

Now, something that is swept under the carpet with rb+ to avoid confusing people much is that assets.txt makes it easy for assets to be loaded and positioned in RAM and ROM. But that doesn't mean that they have to stay in those areas in order to be displayed (or played)! For example, everything can be kept in ROM and the relevant data for each level can be copied ad hoc before the level starts and used there. This of course creates an extra burden to the programmer as they have to do their own memory management, so training wheels are off! But it is possible to modify raptor lists with graphics base addresses and same thing for the audio assets.

 

If one is feeling bold, rb+ even supports unpacking data from ROM to RAM - have a look at project pack to see how you can do this. Otherwise a straight "memcpy" from ROM to RAM will do the trick as long as you know where you copy the data from and to, and what size they are.

 

As an example, you can DIM an array and then use strptr to determine its address in RAM. (Again, project pack shows how to do this). If you know that your background pic is 24k, then "DIM back[24*1024] as BYTE" should do the trick. Also, if all your background pics are the same dimension, they're all going to be exactly the same size, so you can re-use the same buffer over and over. Same thing for game sprites and audio.

 

One final thing that comes to mind (again something that assets.txt performs in a hand-wavy manner): you have to make sure that your buffers are aligned to 8 or 16 byte boundary (I forget what types of data need 8 bytes and 16, so I usually just align to 16)! The easiest way to do this is if you assign memory locations by hand (for example, your background buffer will live at $10000 - there we go, a nice aligned number. Of course you have to be absolutely sure nobody else uses this chunk of RAM....). The second easiest way is to allocate the amount of RAM you want plus some extra, then take that address and align it by hand. So something like:

 

dim background_buffer[16*1024+16] as BYTE

dim background_address as long

background_address=(((long)strptr(background_buffer))+15)&0xfffffff0)

 

If it reminds a bit of the way we align sample buffers for Zerosquare's player, it's the same principle.

 

So that's it for now, I'm not sure you want to undertake such a complex task but worst case it might help some people in the future that encounter the same problem(s). Good luck in any case, and do ask if something is unclear.

 

[EDIT] Another possibility is of course to have some dummy entries assets.txt that point to RAM and supply blank files of the same sizes you need. Then all the alignment issues are solved for you and you just need to copy (or unpack) your desired data on top of the blank ones

Edited July 26, 2020 by ggn

[WAVE 1 GAMES]

No not everything I currently have packed needs to be packed. Some of that stuff can live just fine as raw data. Im going to try reorganizing what gets packed and what doesn't. I actually DO want to try packing to rom and then unpacking. This was actually something I wanted to ask about but was afraid it was a stupid question. I'm familiar with how setting up the buffers as DIM objects work as I am already currently doing that for my packed stuff. So it will be a matter of figuring out how to align it properly to call from ROM in my case. Setting up a dummy object sounds like a good idea! As for the grassy ranch house background layer, that thing doesn't even need to be packed or even set to ROM. It can remain as ABS and it will work just fine. The hallway animation on the other hand will need to be in ROM. I'm not sure how I'm going to achieve this the way it's currently set up. It would be great if I could nix the scaling and use a full sized image as I know scaling takes a pretty big performance hit. I did try converting the frams to 4 bit color just to see how they would look but it looked terrible to me. This animation is semetrical so another thing I thought about was cutting it in half horizontally and then creating 2 background objects woth one being flipped. However I also realize sprite_flipped takes a performance hit as well. Anyway I am going to attempt to do this one way or another and I know I need to move some other stuff around to make this all work. If I have questions about packing to ROM I'll ask but I'm going to try and figure it out myself.

 

Oh but I did have 2 other questions.

 

1) why is it that it will only allow me to designate 7 sound files as ROM?

 

2) Whats the limit on packed graphics, is there a limit as far as how many k/mb you pack or is it determined by the amount of images you pack? ie number of slots/bmps files packed?

 

Thanks for the help.

Edited July 26, 2020 by WAVE 1 GAMES

[ggn]

9 hours ago, WAVE 1 GAMES said:

Oh but I did have 2 other questions.

 

1) why is it that it will only allow me to designate 7 sound files as ROM?

 

2) Whats the limit on packed graphics, is there a limit as far as how many k/mb you pack or is it determined by the amount of images you pack? ie number of slots/bmps files packed?

 

Thanks for the help.

 

1) Really? What's your use case? I just tried this without issues:

 

ROM,rom_bmp_player1,gfx_clut,assets\partipal.bmp
ROM,rom_bmp_player2,gfx_clut,assets\partipal.bmp
ROM,rom_bmp_player3,gfx_clut,assets\partipal.bmp
ROM,rom_bmp_player4,gfx_clut,assets\partipal.bmp
ROM,rom_bmp_player5,gfx_clut,assets\partipal.bmp
ROM,rom_bmp_player6,gfx_clut,assets\partipal.bmp
ROM,rom_bmp_player7,gfx_clut,assets\partipal.bmp
ROM,rom_bmp_player8,gfx_clut,assets\partipal.bmp
ROM,rom_bmp_player9,gfx_clut,assets\partipal.bmp
ROM,rom_bmp_player10,gfx_clut,assets\partipal.bmp
ROM,sfx_11,sfx_mlaw,assets\SFX\touche3ATARI.wav
ROM,sfx_12,sfx_mlaw,assets\SFX\touche3ATARI.wav
ROM,sfx_13,sfx_mlaw,assets\SFX\touche3ATARI.wav
ROM,sfx_14,sfx_mlaw,assets\SFX\touche3ATARI.wav
ROM,sfx_15,sfx_mlaw,assets\SFX\touche3ATARI.wav
ROM,sfx_16,sfx_mlaw,assets\SFX\touche3ATARI.wav
ROM,sfx_17,sfx_mlaw,assets\SFX\touche3ATARI.wav
ROM,sfx_18,sfx_mlaw,assets\SFX\touche3ATARI.wav
ROM,sfx_19,sfx_mlaw,assets\SFX\touche3ATARI.wav
ROM,sfx_1a,sfx_mlaw,assets\SFX\touche3ATARI.wav
ROM,sfx_1b,sfx_mlaw,assets\SFX\touche3ATARI.wav
ROM,sfx_1c,sfx_mlaw,assets\SFX\touche3ATARI.wav
ROM,sfx_1d,sfx_mlaw,assets\SFX\touche3ATARI.wav

 

2) No limits. Pack to your heart's content