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 ... 3 4 [5] 6 7 ... 23
61
Project announcement / Re: Sonic Z-Treme
« on: July 21, 2018, 09:40:18 pm »
That seems like a z sort issue.
There is no z buffer on the Saturn, so that happens all the time.

62
Project announcement / Re: Sonic Z-Treme
« on: July 21, 2018, 09:21:18 pm »
There is an hardware feature, called windows, where it doesn't draw to one part of the screen.
That's what Lobotomy did with their slavedriver games to have little overdraw.

63
Project announcement / Re: Sonic Z-Treme
« on: July 21, 2018, 09:12:40 pm »
You just dicovered a bug!
I forgot to add an option to render only within the window screen.
It doesn't use interrupts.

64
Project announcement / Re: Sonic Z-Treme
« on: July 21, 2018, 07:22:04 pm »
Yeah, Ponut is right.
Now, offloading a lot of work to the vdp2 using a rgb0 plane would solve many issues, but using it in splitscreen is way harder since you need to use interrupts.

65
Yeah, but the problem will be the same, we won't have more time to work on it. As Ponut suggested, your best bet is to try the official Sega tools first and try to make it work.
I couldn't get the midi conversion working, but I didn't put much time in it.

66
Project announcement / Re: Sonic Z-Treme
« on: July 21, 2018, 12:16:36 am »
Thanks, but I already have logo screens that I use to hide loading.
Adding a video would defeat that purpose.

67
Project announcement / Re: Sonic Z-Treme
« on: July 20, 2018, 04:54:48 pm »
I don't have one, else I would be using it ;)

68
Project announcement / Re: Sonic Z-Treme
« on: July 20, 2018, 04:34:32 am »
Here it is in action with both the metal effect (working on real hardware nicely) using both green gouraud shifts (when the metal player is invincible) and red gouraud (both when invincible and not).
I added global lightning to the maps using per-vertex lightning and averaging the results to get a per-quad flat lightning shifting palettes.
I also added back rings and ennemies, but the ennemies are static since I didn't code in an insertion function for the octree nodes.

https://www.youtube.com/watch?v=Solq-N_jI28

69
I guess it could be done, but someone would need to step up to make it happen.
Sadly I don't know much about audio so I couldn't do it for now.

70
Project announcement / Re: Sonic Z-Treme
« on: July 18, 2018, 09:06:08 pm »
It should be, but it didn't seem to work when I used it.
It's not about the colors, but it's about how the hardware interpolates the gouraud shading, which shouldn't work, but since it still sends the interpolated data to the VDP2 you can play with the palette and use it to shift values.
Blue falls at bit 10 to 15, so it's inbetween the palette's address and the color calculation ratios, which means it can't be used unless you use sprite type 4.

71
Project announcement / Re: Sonic Z-Treme
« on: July 18, 2018, 08:51:09 pm »
I didn't discover the red gouraud bug, but I never saw anyone else knowing about the green gouraud bug. See previous posts for more information on this.

72
Project announcement / Re: Sonic Z-Treme
« on: July 18, 2018, 08:41:58 pm »
It is "free" in terms of rendering speed since it's all precalculated and I'm just doing palette swaps to darken the shadowed areas (again, done offline).
I could easily put gouraud shading on the quads closer to the screen since I'm using a 16 color LUT, but the main issue are the quads away from screen since I'm using palettes for the transparency effect.
As I mentionned before, there is paletted gouraud bug that I can use (I use it on my metal version of Sonic), but it's not easy to use at all and it puts lots of limits.

73
Project announcement / Re: Sonic Z-Treme
« on: July 18, 2018, 06:44:20 pm »
So I got some global lightning using per-vertex values, averaged for a flat per face lightning using palette shifts.
It looks ok, but it doesn't look as good as gouraud shading obviously, but with the palette restrictions it might be hard to do much better.



74
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.

75
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!

Pages: 1 ... 3 4 [5] 6 7 ... 23
SMF spam blocked by CleanTalk