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] 2 3 ... 18
1
General Jo Engine Help / Re: Why is this skipping?
« on: July 17, 2018, 07:47:35 pm »
Memcpy l uses long words (32 bits) while memcpy w uses word access (16 bits). You must use word access when writing to anything else than high ram since the only 32 bits things are related to the sh2 AFAIK.
Also, if you have a buffer in main ram, use the high ram as low ram is also 16 bits access and, if I'm not mistaken, you can't scu dma directly from low ram, so it will copy to a high buffer, then scu dma to sound ram, which is obviously slow (again, if I'm not mistaken).
The faster transfers are during vblank with indirect access (dma) since it's at that point where SGL will put the audio cpu in "listening mode".
I haven't looked at your code, but did you try to transfer during vblank?
Scu dma channel 0 should be free during that point, so just look at my model convert code for the "myvblank" function to transfer data.
While SGL documentation says otherwise, the slDMAcopy function seems to look at the destination and then switches to either cpu or scu dma depending on the destination.
Edit : Seems like you do it during vblank. Also, don't use dma wait as it will just cause useless delays. There is also a sbl function to transfer data to the audio ram, I had the code last time I shared with you, use that instead of slDMAcopy if you still have issues.

2
General Jo Engine Help / Re: Why is this skipping?
« on: July 17, 2018, 03:20:08 pm »
Yeah, I wish I could help, but sadly I haven't played much with PCM.
I don't hear anything that couldn't be done on the audio CPUs thought.

Now, that would require using this tool backward and creating a tool to convert from midi to sequence :
https://github.com/mistydemeo/seq2mid/find/master?q=

That's really the best way to go, even if it's not the easiest one!

3
Free talk / Re: Would a Flash player be possible?
« on: July 15, 2018, 12:56:05 am »
RAM, RAM, RAM. And it would probably be slow and you would only be able to run a few programs. I'm not sure how the 486 handled it, but I guess the performance should be somewhat similar.

4
Project announcement / Re: Sonic Z-Treme
« on: July 14, 2018, 07:47:11 pm »
I'm not sure I understand what you mean, but I don't have time right now to focus on little details as I barely got some gameplay.

5
Project announcement / Re: Sonic Z-Treme
« on: July 14, 2018, 05:41:48 pm »
Yes, it's frustrating. Try all main 3 emulators each time before burning a disk.
You should also try the USB cart if you don't need cd access for your tests.
At least I understand how the whole paletted gouraud shading bug works, so I can at least plan ahead and make sure it works on paper before wasting a disk.
But it does look truly amazing on real hardware, I hope I can expand it for more effects as it looks like something you would see on PS2 or Dreamcast, not Saturn.

6
Project announcement / Re: Sonic Z-Treme
« on: July 14, 2018, 05:02:29 am »
Ok, scratch that, the green gouraud bug works on real hardware as I thought, but not on emulator sadly.
But it does allow pseudo environment mapping and easy switching between flat and gouraud shading.

7
Project announcement / Re: Sonic Z-Treme
« on: July 14, 2018, 02:31:38 am »
No, I will try to focus more on the gameplay for now.
I spend a bit too much time on graphics, but the gameplay is super buggy now.

8
Project announcement / Re: Sonic Z-Treme
« on: July 13, 2018, 09:56:31 pm »
Using CRAM and paletted sprites/gouraud to create a bump mapping effect was easier than I thought.
It works, but sadly using the green gouraud didn't seem to work, so only the red worked for me so far.

9
Project announcement / Re: Sonic Z-Treme
« on: July 13, 2018, 01:15:38 am »
I'm using SGL, which makes heavy use of the slave SH2, so it's not an option. Even in Sonic R they scrapped using it ingame, probably because it was too intensive for such a little effect.
If I were to use software rendering, it would be for something such as transparency on the NBG0 or NBG1 layer, using them as framebuffers.
And only if I could use the SCU DSP or sound cpu to do it.

10
Project announcement / Re: Sonic Z-Treme
« on: July 12, 2018, 10:52:46 pm »
Environment mapping is a sure no, it's super slow to read from the framebuffer and there are no texture coordinates.
I am considering power ups but I have many other things to do first.


11
Project announcement / Re: Sonic Z-Treme
« on: July 12, 2018, 06:50:53 pm »
I'm doing something similar, but I'm not reading the mtl file so I just use the texture name.
I will expand that system in the future to try to allow bump mapping.

12
Project announcement / Re: Sonic Z-Treme
« on: July 10, 2018, 10:20:52 pm »
Thanks.
Good news : SAGE as been pushed back one month, which should help me quite a bit to get a demo out in time.
I've also added support for very basic paletted light sources (per face instead of per vertex, so no gouraud for now).
I will have to improve my support for light sources, but it doesn't look bad and comes at no costs since it's just precomputed.

I might stick with this technique and maybe use gouraud shading on special objects to allow bump mapping (see third and fourth images for the SGL tech demos).

13
General Jo Engine Help / Re: Request for real hardware tests
« on: July 08, 2018, 12:53:05 am »
Well, I'm already doing that in Z-treme, I could try to share it soon enough.

14
General Jo Engine Help / Re: Request for real hardware tests
« on: July 07, 2018, 09:41:36 pm »
What do you mean about variable interpolation?
About the real hardware, I don't even have access to real hardware for now so I can't help you for now.

15
General Jo Engine Help / Re: Request for real hardware tests
« on: July 07, 2018, 03:29:50 pm »
Can you show me the problem?
I won't have access to my Saturn for a while.
About the matrix issue, how big is it?
A couple of vertices?
If so, move your vertices to high ram (just set your model's pdata pntbl pointer to a global array of say 200 vertices, the model functions will just overwrite the data anyway).
Your pcm functions are also on low ram?
Make sure the alignment is right.
There is a SGL document somewhere that explains issues with audio stored in low ram, again because - if I'm not mistaken - you can't do scu dma from low ram.
Make sure your audio buffer is in high ram.
Low ram is slower and has many restrictions as it's not directly linked with the scu.

Pages: [1] 2 3 ... 18
SMF spam blocked by CleanTalk