Since both sit on one bus, one has to leverage internal cache as much as possible to get good performance on concurrent use, aswell as time division so that there's some semblance in taking turns as far as bus access goes. If one is accessing RAM or ROM or anything else that is outside the CPU, and other wants to do the same, the other will be stalled until first is finsihed and this is very costly on a CPU which can execute one instruction every clock. With just 4KB of that cache and having everything sit in external world, it will not be so easy to maximize performance for both sides, but even then it'll still be faster than just 1 of them (but both will be slower than if either alone) but it will not reach 2x the performance except in very special circumstances.
As for if the game is using both, the answer is yes. That's all the doing of Chilly Willy and Vic from their work on the Doom 32X Resurrection port. For example, both CPUs split the frame buffer drawing.
Sounds entirely possible. Would probably resemble something like Super Monkey Ball Jr. on the Gameboy Advance.
Really appreciated, you guys are awesome! Trying to do 3D rendering in software with those constraints sounds like banging one's head against the wall, but lo and behold someone put in the time and found a way to do it successfully. Splitting up frame buffer drawing is pretty clever in its simplicity. Every CPU is on a fixed schedule with the same job on every frame and never needs to write to the same region of memory; smart. I learned something about how they did it in the olden days before people put blind trust in the compiler's optimizer and the CPU's cache, so big thanks for that!
This might be interesting to you: https://github.com/viciious/d32xr/wiki/Engine-optimizations,-part-1 Vic, Doom 32XR creator made a series of blog posts explaining how the engine was optimized. In part 1, he explains how the render pipeline works, including how it determines where to split the frame between cpus. BTW, first post here, and want to congratulates everyone for this incredible port! Been playing in original hardware and amazed how this was achieved!
Yeah, I don't understand those crashes. By most accounts (including my own at this point), it runs pretty well on hardware. I got it to crash once, and so far that's it. Some people have them, and some don't. But I've never heard of it crashing all the time like this (unless someone here wants to chime in and say it happens to them too). I'm very happy he gave this a try. As a developer, I want to figure out what the trouble here is. I don't know if there's really a software solution here or not, but I'm thinking a checksum might be helpful for no other purposes than to definitively detect a problematic connection somewhere in the hardware, of which I am certain there is at least in some part. Not that software-related crashes couldn't also play a role.
For whatever it may be worth, that crash from the second badnik right at the start was something that happened to me at least twice iirc. I could probably easily replicate it.
RHS got a lot of feedback about those crashes, so he did a live stream of the game today. But SSNTails gave him a build that includes some of the stuff we've been adding to it since the public release back in December: * Techno Hill Zone * Genesis skies with 32X 15-bit gradient fill * Some modest optimizations
Played this on my PAL MD I (TMSS) with 32X and despite a screen mentioning NTSC-only, it runs really well! Looking forward to some stabilisation of the frame rate and the next release I do think that there needs to be an option regarding the stopping speed, the games probably needs some optimisation for the lower res and controller.
Jeez, this is absolutely insane. I remember way back in the 00's when people would constantly be posting about Saturn or Dreamcast ports and it got so annoying - the creators and other technical folks would repeatedly explain it didn't work that simply - a DC version was eventually released, but I think it lacked sound - I don't know that we ever even got a Saturn port ... so the idea that Saturn was skipped and we went all the way down to the 32X is beyond mind-blowing. I love this community for this absolutely insane kinda stuff it pulls every once in a while. To those commenting on slopes - slopes weren't in SRB2 for what it seemed like forever. I barely even played it after they got the slopes, heh. There was a 'core' version called SRB2ME for years ... I remember it finally getting updated in like 2014, and it still didn't have slopes yet. I would've first ran into SRB2 around 2004/5...I never remember it having slopes. When did they get implemented?
Wow, so it was only 2019 that they were added - 15 years into development. :O I think for a long time we just assumed it wouldn't happen, that it was just a fact. XD I can honestly say I've never tried it since then. It was one of my favourite games of all time as a kid. I should give it another shot sometime soon!
It's been a rather curious thing to me. The conventional understanding among SRB2 fans is the game is so advanced that it just can't be ported to old systems. I never bought into that, because it's still largely Doom code that's running, and Doom can run on a 32X and Jaguar, as well as a decent 386 PC. So why wouldn't SRB2 be able to run on a 32X, at least in some sort of state? So when SSNTails approached me about doing this, among other reasons, I was also just enthusiastic about the idea of proving this could be done. You've no doubt seen Doom 32X Resurrection and how that runs. This has been built off that codebase. My suspicion about those other ports that didn't run well (because I never played any of them) is they made no concerted effort to simplify things and optimize areas of the code that probably really ought to be anyway. I suspect, based on this as well as what I have seen of its code, that SRB2 is being developed now in a post-Doom era where PCs are *really* fast, so there just isn't much thought put into optimizing things that could easily be optimized with a little forethought. We have looked into slopes and floor-over-floor. If it happens, it happens. We're hopeful. And I think those things are doable so some degree, which would surely blow the lid off another long-running myth about these types of games and their ability to do that stuff on such old hardware.
I would say that the immaturity of the development scene and tools back then probably also didn't help. There's a ton more knowledge about these wonderful old pieces of hardware these days than there was, say, 15 years ago when SRB2 started development, and a lot more people actively developing for them. I love seeing old hardware pushed to it's limits - I entirely agree that these days with such crazy amounts of computing power, it really does seem optimization is an afterthought. Thanks for all your contributions to this community over the decades, saxman! It's a pleasure to see you still active and doing amazing and inspiring things.
One year ago today, SSNTails began the first code changes that would become SRB32X. Yes, it's sort of a phony anniversary. I don't expect celebrations over it. This is more for me to look back at where we started and to give a peek at where it was on June 2, 2024: This was the beginnings of the chase camera. Not very Sonicy yet. The earliest evidence of Sonic in the game that I have came on June 14: The color palette is really wrong, but he's there! Finally, the Greenflower Zone map appeared on June 18: All of these early things I'm showing are SSNTails' doing. He got the ball rolling, and then I started making some of my own contributions as well. We developed it pretty fast for being a team of two developers. And we've come a long ways since the public demo too. To be clear, this is no victory lap. I don't like to take those, #1, and #2, we've got so far to go still. These are just little things I find interesting as someone who has seen it from the very beginning. There's a lot more, but those things are for another time.
Thanks for sharing, I find this stuff fascinating. It really feels like we're slowly entering a new era of backports, there's also someone porting Mario 64 to the PS1 now and potentially a similar Saturn port, though that one is stalled. I can only imagine where the 32X scene (if there really is one, anyway) will evolve over time. This is why I like decomps more than the recomp stuff since you get all these neat experiments when you have the actual portable codebase.
