SSNTails is probably more qualified to discuss this than I am. What I can say is slopes have always been deemed process-intensive for as long as I can remember by various people who speak on these things. Though those same people will insist FoF is not doable on old hardware, and I've always been a tad bit skeptical of those claims. We'll see what happens. Maybe slopes will be implemented if it can be done in a practical way. The impression I get about slopes is they're challenging due to the math involved. The 32X hardware doesn't handle any polygons; all that kind of stuff is pure software rendering. So the texturing and shaping of rooms is done with columns and spans. Spans are floors and ceilings, drawn horizontally. Columns are for everything else, drawn top-down. When things are half their normal horizontal resolution, it becomes possible to drawn word-sized columns (i.e. two bytes, or two pixels), which helps speed up drawing times. Rendering of these drawing segments involves calculating where the ceiling and floor are vertically so it knows where to draw the column and how tall it is. And with complex shaping of sectors comes a certain amount of overdraw (i.e. draw walls way in the back, followed by walls that are in front of the back walls). This port actually does a significant amount of simplification to make the memory footprint smaller. However, if you simplify too much, then it takes away a lot of the look and feel of the original levels, so it's a balancing act to try and make it run well while looking like SRB2 is supposed to look. The game way slower when we started, so it's definitely come a long way. And there's always room for adjustments of things. Does that answer your concerns?
Yeah, actually- many thanks. It's definitely weird to see a 3D game running without any true 3D polygon rendering, but that does kinda explain why things are designed they way they are, and yeah- nothing I know about reducing poly count and saving resources will work here, so I'm content to just trust the pros
Slopes weren't even a part of SRB2 until V2.1.15 (2016). Before that levels didn't include them or used steps to achieve a similar effect.
Yeah the steps are how I remember SRB2 so it wasn't weird to see in the 32X port. As long as Sonic controls fluidly enough on them I think actual slopes are more of a visual flair than something necessary (or at least for the first level).
@Rhythm Raccoon This actually uses a software renderer using vertical strips, there aren’t really polygons in the traditional sense. @saxman Chaotix freezes up in emulators too upon level loads. It’s an issue with Chaotix itself.
This is really cool. I always envisioned SRB2 being easily done on the Sega Saturn, especially a proper 'remake' of Doom that properly used VDP1 and VDP2 instead of doing strictly software rendering like the final ports did, but I never would've imagined anything reasonable from the 32x let alone anything playable. I feel STI is rolling in its grave right now, lol. I also think it's pretty sweet that the demo has one foot in the classic pre version 2 SRB2 and the other in the new SRB2 era. It feels oddly nostalgic for me since I remember playing SRB2 all those decades ago (is SFGHQ still around? lol). I do have one technical question though that I'm sure there is an answer for. I'm not very versed in the technical complexity of blending 32x and Mega Drive planes, or the 32x in general. But I was wondering if it would've been possible, if not preferable someday, to put the background graphics strictly on the Mega Drive's VDP rather than all on the 32x? I remembered Markey Jester's "Mode 7" demo running on the Mega Drive, and I thought that something like this would've been a great solution to recreate the skybox and ocean that was used in the original version of the first level. I'm not sure if this is possible to do given I don't know much about how much this demo is using of the Mega Drive's resources. It looks like everything is running on the 32x's hardware sans the Z80/68k for sound. But it didn't look like the demo was using the Mega Drive's VDP for anything. I can kind of imagine it freeing up some resources on the 32x end while also adding a cool effect at the same time. But maybe that's not the case... I can't wait to see where this goes. Keep up the good work! Maybe a Saturn port is a possibility someday.
We have quite a bit of Genesis VDP code in place that's simply not being used in this demo. We're still cooking. But I will say that I am definitely an advocate for using all the hardware available for reasons you have pointed to. More hardware means more power! The 32X has some very clever capabilities as far as how it fuses the two VDPs together. Thru pixels can be designated on the 32X side to poke holes in the 32X frame buffer to reveal Genesis graphics. And any use of transparent pixels on the Genesis will show the RGB color of the thru pixels being used. So it effectively allows a 32X graphical layer in front of Genesis graphics, as well as behind. If you consider plane A and B, along with high and low priority sprites to be four layers, then the 32X adds two more. The 32X is more capable than most people realize, as proven by the reactions to this demo. I am happy to make this more apparent to people! But also, anything the 32X can do, the Saturn can do better. I don't think VDP2 would be necessary to pull off a satisfactory Doom port. But I suppose one could be creative with the use of VDP2 and really make a strong impression. I'd love to see it happen. If Resurrection/Fusion gets ported to Saturn, I'd be a big advocate for doing the same with SRB2.
HUD definitely should move to the MD side, since every pixel you have to write comes at a relatively big cost on the SH2 due to all the wait states it gets on framebuffer accesses. It has been a while since I last looked at it, but I recall 5 wait states figure, which is bad enough that it takes close to entire frame worth of time to update all of the pixels of a screen...
I was actually worried about that very thing. We did some Genesis drawing experiments early on and were surprised to find that it did very little to improve performance. It turns out that since we're running at a target rate of 30 fps as opposed to 60, the pixel thru-put rate doesn't affect us nearly as dramatically. Despite that, I have suggested to SSNTails that we move the HUD to the Genesis, but we have some other competing purposes for the VDP, so it's really a one-or-the-other situation.
Now I wonder what those other purposes are, it doesn't look like there is much ingame that could benefit from being on MD side...? How is the sound/music working exactly ? I know that percussion is handled on 32X side along with the SFX that are sample based. It would be interesting to get them recreated on MD side or lifted from the existing game data although I have no idea what the limits on sound engine side are. The biggest thing that worries me is the offsync drums vs melodic bits, I have measured variable delay between ~21 to 33ms in length relation to YM2612 output. I modified my MD to have 32X on left channel and YM2612 alone on right to separate the percussion and meldic bits so that it would be easy to compare in an audio editor : Fixing this delay would make the music sound much better than it already is. I'm not sure how the sound engine works, the variable delay is a bit odd to me but it is a pretty long one and very noticable to the ear...
If I were to chip in my 2 cents on optimization utilizing the MD for extra power, I'd probably throw the actor logic onto the 68k and keep the 32X exclusively to rendering. Of course I'd imagine that's way easier said than done, and I have my sig for a reason. But I'd think that would do more for performance than skybox or HUD rendering.
No practical way to have the Genesis graphics in front of the play area while potentially using the Genesis VDP for graphics behind the play area too. So it's a trade off of performance improvement vs neat graphics effects. We've been leaning on the latter, but it's certainly possible to do the Genesis HUD when the VDP isn't being used for other things. As for sound, the sound driver is a modified version of what Doom CD32X Fusion is using. That game streams the audio samples, whereas we've butchered the VGM a bit to support proprietary drum sample queue commands. So when the sound driver comes across one, it is told what drum sample ID to play, and that ID gets sent back to the 68000, which then sends it to one of the SH-2s via a CMD interrupt, which in turn plays the drum sample the same way normal sounds are played during gameplay. The sound driver isn't the fastest thing in the world, not because it isn't well optimized, but because it's VGM being streamed from a Z80. So I'd say that contributes to the problem. It's possible but unconfirmed that the chain of events I outlined slows it down slightly. I actually initially had the 68000 playing PWM drum samples directly, but with sound effects on the 32X side also being done using PWM, there were bus contention concerns, so I went the interrupt call route instead. I did start the ground work for replacing the sound driver, but there's a lot of work yet to be done. I'm not totally sure that would do the trick. I believe the actor logic eats up the *most* CPU time, so having a fast CPU to handle it is paramount.
I was thinking you could move the HUD into the borders so you can do both, granted the border isn't nearly tall enough so you'd probably have to deviate from the original and make a horizontally oriented HUD. Figures... Is every actor in a map loaded and active at once? Or is there something else in the way? I don't really feel like this is an avenue that should be so quickly shut down...
The stereo on the drums has bugged me for quite a while though. It's hard to explain but it has that Oki stink and I couldn't help but feel like I was listening to Street Fighter's samples. The way the bongo cuts through everything while the other songs were more well mixed didn't help either.
I totally forgot about the video priority aspects. I'm not totally sure what those effects can be other than the far BG behind rendered bits becoming high resolution which could be nice of course. Ok, I can see how this results in the variable delay I see and how it will be difficult to work around it. VGM format is relatively hostile and doesn't lend well to frame worth of delay on FM+PSG side activities to bring the two sides closer up during playback, especially not in the async way things seem to be working at... but it should be possible to bring the drum commands some amount of time backwards in time in relation to FM+PSG side, which will help to make the music much better. There will still be some extra delay on top of the baked in one, but the drums will still be much closer to synchronity than they are now. 68K definitely cannot do this sort of heavy stuff, because every access it has to do to ROM, it stalls SH2 from many instructions worth of processing time because the 68K bus cycles are just so slow compared to SH2 and Z80 accesses are even worse. This puts severe restrictions on what you can do with MD side if you want to have SH2 running as fast as it could, since it bascially means the MD side should run out of the RAM available there without coming to touch the ROM.
Unless they changed the way Doom itself works, yes, this is how it goes. Every actor in every level of Doom is always loaded from the get go, they're just "asleep" before you encounter them. But they still tick their logic every gametick. EDIT: Or I should say, tick their logic with their frequency relative to gameticks, because not everything in doom necessarily runs at 70 hz. Re: Slopes -- look at Duke Nukem 3D, anytime it has to handle slopes the game slows down on lesser computers because slopes have always been crazy expensive. In Duke Nukem 3D, slopes are an entire secondary rendering process completely different from the rest of the game, like a second rendering pass, that is slower than the original even though it's handling less rendering. And Duke Nukem 3D isn't nearly as physics heavy as a Sonic game is supposed to be.
AFAIK slopes are the only part of DN3D that use floating point math and that was extremely performance intensive on CPUs prior to the og Pentium, does the SH2 in the 32X support floating point calculations in hardware?
The SH2 doesn't support floating point. It was introduced on the SH4. But you can use fixed point decimal to do the same things (albeit with less precision, but at this resolution I don't think that 10,000ths of a number really matter). I don't think slopes are happening though.
I can't stop playing this. Every night when i get home from work I just do a quick romp through Greenflower and it is one of the greatest, simplest joys I've had in quite some time. On another note, found the debugger, and running the game with the flat color graphics like it's Star Fox is incredibly amusing (if not straining on the eyes ahaha).
Speaking of the SH2, does this port use both of them or just one? I'm curious if anyone has ever managed to successfully get some performance improvement out of using both of them. Concurrency is a pain even on modern CPUs, but I'm not even sure how somebody would go about locking a region of main memory with an SH2 out of the box. Would you have to write your own thread library, or what? Pardon my ignorance if there's technical documentation about this on the wiki.
