Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - XL2

Pages: 1 ... 10 11 [12] 13 14 ... 23
166
Project announcement / Re: Sonic Z-Treme
« on: April 14, 2018, 10:56:08 pm »
These games use the color calculation  (with ratios) to make a smooth fade in and fade out. It's what I'm doing now. It might be possible with CLUT sprites too, but I have to try a few more things first. But the only way to do actual gouraud shading on color bank sprites requires a ton of color RAM, but you only have 4 KB shared for all the background layers and the color bank sprites.
High res mode is attractive, but you can't simply flip a switch and make it work. You really need to setup everything in a specific way and there are many limitations.
I could try it for menus and such, but even for that I don't want to waste time on it.

167
Project announcement / Re: Sonic Z-Treme
« on: April 14, 2018, 05:24:09 pm »
The flat shaded quads in SGL can use flat lightning both in RGB and palette format.
I'm not using the SCU DSP yet, so it's SH2 only.
I can't do realtime light with color bank sprites, but I'm now doing like in Sonic R and Bulk Slash.

I can't use the high res mode, it's super hard to setup, so I don't want to waste time on it.

168
Project announcement / Re: Sonic Z-Treme
« on: April 12, 2018, 03:12:18 pm »
I just did a small video (it's not public as there isn't much to show) for the split screen mode and the removal of gouraud shading/use of CRAM sprites.

https://youtu.be/jHaXoe9lfMc

169
Project announcement / Re: Sonic Z-Treme
« on: April 11, 2018, 03:08:26 pm »
The way they did it in the Chrome demo is that they use a palette of different luminances.
The VDP1 does the gouraud shading processing, but when it's using paletted sprites it just offsets an index instead of the actual RGB color.
So the result is that by using only red gouraud processing you will exactly offset +- 1 to 16 in each direction for each verticle.
You could do it with 16 colors banks, but then you could only do it with one color and only 7-8 different luminances, else it will overflow.

I could do like Sonic R, but I could also just put static lightning on the textures.
The issue with Sonic R is that you have gouraud on quads close to the camera, then you lose that luminance as it starts disappearing.
I have enough VRAM left to generate other textures for luminance.
From the videos of Saturn Shenmue, it seems to be what they did.
Speaking of Saturn Shenmue video, I noticed lots of triangles in the background (they get clipped out). So I'm not sure if it's running on a real Saturn or if it's using software rendering for backgrounds.

170
Project announcement / Re: Sonic Z-Treme
« on: April 10, 2018, 11:55:57 pm »
Haha, just using the SCU DSP would be a great start!
It has really limited memory, so it can't do that much.

Update on the project, I've now moved from 16 colors Lookup tables to 16 color bank (CRAM). That means no more gouraud shading...but I will be able to use transparency, which is better.
I'm not sure if you can do color calculation over the back screen, but if you want the same effect as depth gouraud shading you can just put a black background and use the VDP2 transparency to have the same effect.
It also offloads work from the VDP1.
The only issue is that the color RAM is really limited, but so far it seems all the maps I tested got everything within about 1000 colors, and if it can't fit in CRAM I put a "safety" measure where it just uses CLUT.

I haven't made much progress on Sonic Z-Treme yet, so the game is currently improving only on a technical level, but I hope to be able to integrate everything in the game soon.


171
General Jo Engine Help / Re: Audio issues - repeating/skipping
« on: April 08, 2018, 01:39:49 am »
I hope you didn't give up on your project, but using the tone editor on a mac emulator you could load your audio to the audio RAM, avoiding the PCM DMA transfer, which should fix your issues.
It's quite complicated to setup, but I can help you with it.

172
Project announcement / Re: Sonic Z-Treme
« on: April 07, 2018, 02:49:50 pm »
You can issue program change commands, but I highly doubt it can process programs in parallel.

173
Project announcement / Re: Sonic Z-Treme
« on: April 07, 2018, 12:02:21 pm »
Good idea for the SCU DSP.
If that's what Burning Ranger does, the entire code could be retrieved with Yabause.
But I thought they used it for lightning.
You can see when there is voice audio playback if the SCU DSP gets a program change.

174
Project announcement / Re: Sonic Z-Treme
« on: April 06, 2018, 04:27:30 am »
The overhead is, I guess, for the main SH2, since it get decompressed by the SH2, then it's no different from uncompressed audio once it's transfered to the audio RAM.
It could be that the SBL library isn't super efficient, but even for uncompressed audio it's still expensive to use PCM (even if it's "just" 5%.
And more importantly it hogs the B bus, which is the same bus used for the vdp1 and vdp2.
For the DMA, it's always SCU DMA on the b bus.

CD audio goes straight to the DAC, so it doesn't consume cpu power (the SH1 can't be used for anything else than loading). It's the easiest option.

Then sequence audio is great as well, you have the SCSP and the M6800 just for doing that, it has it's own RAM, it can playback PCM data (from its own memory), so it doesn't consume cpu power except for transfering the play commands. It's a bit tricky to use, but for fx sounds it's a no brainer.

PCM audio from CD is good to play voices or play music while loading data, but it should be avoided as much as possible.

PCM audio from memory is easy to use and convenient for that, but it really should be avoided.

I don't know if it's possible to keep data in the CD buffer, so that you could store 512 KB of PCM data in that RAM, but it would be a good option (if possible) to at least save some main RAM if you have to use PCM memory playback.

I would really like to use MIDI audio as it's the more flexible option and keep the CD available, but it's also the hardest to use.

EDIT : The program I mentionned which converts sequences to MIDI. Now we need to figure out how to do the other way around!
https://github.com/mistydemeo/seq2mid/find/master?q=

175
Project announcement / Re: Sonic Z-Treme
« on: April 05, 2018, 05:02:18 am »
Thanks.
But if anyone wants to do it, it would be more than welcome for the whole community!
I need to finish the model converter I promised and continue working on the engine for a long overdue update.

Edit : Just added an image of PCM-ADPCM CPU overhead. Note that playing small sounds from memory is less expensive since you don't need to transfer data from the CD, but it still requires DMA and hogs the B-Bus.


176
Project announcement / Re: Sonic Z-Treme
« on: April 05, 2018, 12:41:09 am »
Yes, but the idea would be to write an app to do this. I would certainly take a while, but on another forum someone sent me an app that converts sequences to midi, so I would need to do the opposite.

177
Project announcement / Re: Sonic Z-Treme
« on: April 05, 2018, 12:29:35 am »
Yes, I will mix both.
So for menus or title screen, I might use ADPCM to allow loading in the background and keep some space on cd.
I will use normal  cd audio for ingame for now, but using midi audio would be nice as well.

178
Project announcement / Re: Sonic Z-Treme
« on: April 04, 2018, 08:27:27 pm »
Ok, using SBL and the Tone Editor on my Mac emulator, I got audio played from Audio RAM working.
You need to create a bank with the "voices" you want (using AIFF PCM files) and create a map file.

On the Saturn, you load the sound driver and the map data.

For the map file :
Byte 0 : MSB at 0 = used, bits 6,5 and 4 are for the type, with 0 being tone data, 1 for a sequence. The next 4 bits are the bank ID number (so 0 to 15).
Bytes 1, 2, 3 : Last 4 bits of byte 1 and the remaining bits are for the adress of the tone in memory.
Byte 4 : MSB is 0, the rest seems unused.
Bytes 5 to 7 : size of the tone data.
You then need to use end codes for the area map and for the global map : so 0xff and another 0xff.
You could put a couple of map info for more than 1 bank.


Code: [Select]
char sound_map[]= {0x00,
0x00, 0xb0, 0x00, //Start adress
0x00, //except for the MSB, seems unused
0x05, 0x61, 0x22, //size of the tone data
0xff, 0xff //end code
};

That means my sound data takes 352 546 bytes (all at 11,025 khz, mono, 16 bits - using 8 bits would halve that).
The map can include sequences, but I couldn't get the tools working on the Mac emulator, so I use Midi direct commands to the sound driver.

You need to load your tone data in the sound RAM using the offset 0xb000.

Now, to playback the audio, here is the function I wrote :

Code: [Select]
void TEST_AUDIO(Uint8 nb)  //Nb = number, both for voice and channel
{
   SND_CtrlDirMidi(0x02, 0x00, 0x03, nb, 0x20, 0x00);  //Bank change. Not needed if you have only 1 bank
   SND_CtrlDirMidi(0x02, 0x00, 0x04, nb, nb, 0x00);  //Voice change. That's the sound you want to play (16 values max)
   SND_CtrlDirMidi(0x02, 0x00, 0x00, nb, 60, 127); //Stop playing the previous sound on the passed channel. It will stop playing at the end anyway, BUT that channel will remain flagged as used if you don't clear it)
   SND_CtrlDirMidi(0x02, 0x00, 0x01, nb, 60, 127); //Start playing the current sound on the passed channel
}


Sadly it would take a while to study the tone data file in order to recreate a tool on PC to do all that.
The tone data includes stuff like the pitch and loop data.
For the pitch, I put it at 84 (for 11,025 khz) on the tone editor, so I put it at 60 (44,1 khz) for the Midi direct command so that it plays it at the correct speed.

I could probably also check at v-blank which channels are done playing the sound to clear them, it would make it easier to manage the channels.

179
Project announcement / Re: Sonic Z-Treme
« on: April 03, 2018, 09:46:19 pm »
Yes, but sadly it's really not as easy as it seems.

All the apps to create sequences and tones are Mac-based (6800K cpu).
The only way to use them is either to buy an old mac or to use an emulator.

While using PCM on the main RAM is very easy, you are limited to low quality (for RAM) and it's hogging the B-Bus since you need to DMA data each time you play a file (CPU overhead).
And it's very complicated to use the sound RAM  : Using the PCM functions within the sound RAM doesn't work properly as Sega probably thought everybody would use sequences, but PCM streams are much easier to deal with.

I've been using a Mac emulator, so compatibility isn't that great and I have no Saturn Sound box which was needed to create some of the needed files.
So you need to create the tone data, then setup the sequences (which is where I'm stuck) and make a DSP program (if needed, but it can allow extra effects such as echo).

The SBL library is hard to use for that since the documentation is mostly in japanese and the code isn't really easy to read/understand.
Plus the demos just don't work in emulators for some reasons.

So in other words I'm not sure if I'll find a solution to these issues.

180
Project announcement / Re: Sonic Z-Treme
« on: March 30, 2018, 05:22:56 pm »
I recently restarted working on Sonic Z-Treme, but I'm slowly transitionning to the newer version of the Z-Treme engine.
I pretty much need to discard almost everything I did with Sonic Z-Treme and restart, but it also forced me to make the engine more modular, which is good for future projects.
Right now I'm mainly working on implementing new audio functions to stop using PCM streams and properly use the Saturn's sound CPUs, but I haven't made much progress yet.
I probably won't be showing anything about Sonic Z-Treme until Sage 2018.

Pages: 1 ... 10 11 [12] 13 14 ... 23
SMF spam blocked by CleanTalk