|
|
Post by Tongara on Apr 11, 2012 19:56:13 GMT
Here are two further videos that I didn't notice on your YouTube channel - the second is from a very late beta version, but has quite a few minor differences (including the placeholder music I mentioned earlier, plus alternate sounds in places along with a preliminary HUD design): www.nicovideo.jp/watch/sm9032049 (time reference: 04:47-05:32) www.nicovideo.jp/watch/sm9048711 (time reference: 05:29-07:27) P.S. Did you say artwork on the final Clockwork Knight game discs was found in a Mega Drive format? I've heard from a lot of programmers who revealed that prior to the Sega Graphics Library being finalised in mid-to-late 1995, 16-bit era tile editors were still used in Saturn developments. Thank you, I'll check those out! I hope you don't mind me nicking those for my channel!  And some of the graphics in CK1/2 can be viewed in Genesis format using tile layer pro, yes. That is some pretty cool info, btw, as things make more sense now! |
|
|
|
Post by buckoa51 on Apr 11, 2012 19:59:37 GMT
Ah, impressive feat of reverse engineering, but pulling apart an old 68000 game is an awful lot easier than trying to disassemble a Saturn game.
|
|
|
|
Post by Tongara on Apr 11, 2012 20:02:21 GMT
Ah, impressive feat of reverse engineering, but pulling apart an old 68000 game is an awful lot easier than trying to disassemble a Saturn game. Oh, of course! It was easier with the Sonic games as most of the data locations had been documented for years previous, so it was just a matter of writing is as ASM and making is into a text/bin split. Most Saturn games have never been touched, and probably never will.  |
|
|
|
Post by TrekkiesUnite118 on Apr 11, 2012 20:03:07 GMT
If the tons of homebrew people who dick around with PS2, PS1, Dreamcast, Genesis, CD, NES, SNES, PC-Engine, N64, and 32X games can disassemble those games and hack them to death, I doubt they'd have much trouble with a Saturn game if they truly applied themselves. It's just that no one wants to do it.
In a sense NES, SNES, and N64 games are more of a nightmare to work with than Saturn stuff due to the buttload of mappers.
|
|
|
|
Post by Anthaemia. on Apr 11, 2012 20:18:14 GMT
That is some pretty cool info, btw, as things make more sense now! According to my research notes, Tadahiro Kawamura of AM2 started work on the Sega Graphics Library in November 1994, with the first version completed by the release of Virtua Fighter 2 and Virtua Cop in late 1995 (these were the first two games developed using the new OS). Then, for the conversion of Fighting Vipers in mid '96, an updated 2.1 revision was used. By the end of the same year, copies of 3.02 were finally being sent out to a select number of third party developers - this was the source for a major online leak back in the day. With official programming tools restricted to a handful of in-house titles before this point, it's hardly surprising a lot of games were produced using outdated solutions like a 16-bit era tile format, to give just one example! |
|
|
|
Post by buckoa51 on Apr 11, 2012 21:32:25 GMT
Buttload of mappers?! Na I doubt NES games are more complex than the mess that is Saturn hardware/software  |
|
|
|
Post by TrekkiesUnite118 on Apr 12, 2012 5:15:53 GMT
Almost every NES game has a mapper in it that you have to deal with when it comes to reverse engineering them. Same is true for a lot of SNES games as well. And unlike Sega, Nintendo used a ton of different ones rather than making one or two standard ones.
|
|
|
|
Post by tvc15 on Apr 12, 2012 20:11:43 GMT
The Saturn was difficult to code for due to the dual CPU setup, but that does'nt necessarily mean that the methods that where used where difficult to understand, careful sub-division and parallelisation of code for example is not an issue now like it was 20 years ago, modern computing is all about extrapolating performance from multi-core/cpu setups and now even GPU's are being used in general purpose computing.
The SH-2's where really solid great chips for the time, and lacked the major bugs that the Jag chips had for example. Plus the SGL dev tools have all been leaked and are readily available. Lets put it this way, if Dev's can spend time writing games for the Jaguar which is a load of butt-hurt, I'm sure disassembling some Saturn games is achievable, through hard work.
As a little aside, Kevin from assembler.com did a backup of Cotton 2 on the Saturn, it came in at 41MB total, somebody then mentioned if you strip out the Redbook Audio from Virtua Fighter, the game is literally 6MB in size. Thats the size of an extra large SNES ROM cart. Not that much to disassemble.
However the VDP1+VDP2 and all those complicated blend modes, layers etc would be a pain in the arse to learn, and the SCU DSP was'nt well documented. But surely that where all the knowledge accumulated from the dev's working on emulators comes in handy, so we do know how this hardware works, ins and outs.
|
|
|
|
Post by buckoa51 on Apr 12, 2012 20:56:02 GMT
Oh you mean a memory map hardware, that's not such a big problem it just lays out where the banks of memory are and how to switch between them.
Believe me it is still a huge issue. Plus you can't really compare the Saturn's esoteric dual CPU setup to modern multi-core/processor systems. Nothing's impossible, but picking apart a Saturn game, then finding some way to recompile it and remaster it is not a trivial challenge by any stretch. Ask people working on fan translations of Saturn games how easy it is, and they're only swapping out character data.
|
|
|
|
Post by zyrobs on Apr 13, 2012 3:00:49 GMT
The problem with Saturn development is not the complexity of the hardware, but the lack of convenient developer environments. For nes/snes/md/ps1 you just fire up any emulator that has a full debugger, and compatibility is near 99.9% mark on any of them. For the Saturn, the only emulator with a semi-useful debugger is Yabause, which has horrible compatibility and missing a TON of video and audio features, and has poor timing. SSF has nearly complete video/audio, but almost zero debugging functionality (you can view some registers on-the-fly but thats it). So to write WORKING code, you have to use a real Saturn, in which case you are forced to burn dozens of CDRs, and you have no easy way to debug anything - except maybe an Action Replay with a comms card, but that only works if you have a 14 year old PC around. Even if you go around all of that, you have to remember that the documentation we have on the Saturn has some errors. Some audio registers are not documented, and the SCU DSP docs we have are worth fuck all. As a little aside, Kevin from assembler.com did a backup of Cotton 2 on the Saturn, it came in at 41MB total, somebody then mentioned if you strip out the Redbook Audio from Virtua Fighter, the game is literally 6MB in size. Thats the size of an extra large SNES ROM cart. Not that much to disassemble. 6mb is a ridiculous amount of code to disassemble. Even if we are generous and think that, say, 4mb of that is graphics and audio. |
|
|
|
Post by Anthaemia. on Apr 13, 2012 4:55:50 GMT
According to one developer back in the day, Sega might have been deliberately holding back official documentation of the SCU DSP to hide its capabilities from rivals. In fact, it's claimed that only a handful of programmers (mostly with in-house or affiliated divisions, including AM2, Team Andromeda, Sonic Team and Camelot Software Planning) were ever aware of this chip's full power. When you consider the source of that SGL leak a few years back, it's hardly surprising we don't have more written evidence regarding what this particular element of the Saturn's architecture could really do - third parties were only just receiving their SGL packages a whole year after the likes of AM2 had completed games using the OS, and even then a full two revisions were produced before they finally had copies to play around with as well.
I'm sure Hideki Sato and the original design team might be able to provide a more detailed description of what this could exactly do, but I believe the plan was to reveal more and more software far beyond the white paper specifications before confirming that a previously unlisted component was indeed present and responsible for the unexpected leap in graphical quality. I don't really want to derail this thread already, yet an increasing number of later Saturn games were indeed boasting the kind of effects that weren't regularly seen before... and yes, that may include the Shenmue prototype or mythical conversion of Virtua Fighter 3. Ironically, most of the best-looking titles originated from the divisions I mentioned earlier, with Camelot's Shining Force III a real showcase of what could be achieved by utilising the DSP to its maximum.
Come to think of it, didn't Yu Suzuki once boast that VF2 would use the Saturn's full power, only to later be quoted as giving a figure of just 66%? I'd be willing to bet the DSP was to help with later AM2 efforts, since there's no way that Shenmue would have been possible without squeezing even more power from the stock console. If this feature hadn't been exploited already, perhaps it was being kept for a late surprise? On the other hand, I recall the US launch promotional video explicitly listing the DSP chip as being something of a secret weapon, although only a handful of games ever made good use of this. Bringing this post full circle, maybe its relative lack of use really was due to an overall absence of documentation, after all?
|
|
|
|
Post by zyrobs on Apr 13, 2012 14:25:38 GMT
From what I've gathered, the scu dsp wasn't too useful to begin with, missing instructions that could make it useful. Some titles that used it did very minimal things with it, like moving data or a timer function. So I doubt that they looked in that direction when they wanted to squeeze more power out of the Saturn.
It has been used as early as the first Virtua Fighter, by the way.
According to the devs it uses the dsp for copying data from one location to the other, which is a reason for the game having audio skips.
|
|
|
|
Post by Anthaemia. on Apr 13, 2012 14:46:47 GMT
Ah, yes! The myth was that Shining Force III used the Saturn's sound chip to generate transparency effects, and because the DSP was reconfigured to handle audio playback, this is why you could hear a lot of jumping. In reality, the DSP's role was to reduce load times by streaming data, which caused the skipping. I know it was also utilised in the original Virtua Fighter, but I don't recall exactly what for... anyone prepared to give me a reminder?
|
|
|
|
Post by zyrobs on Apr 13, 2012 14:50:50 GMT
Don't know for sure, but they are used ingame and only when you are in control (not when it plays replays or you pause, or when you do a throw move which has prefixed animations). It's probably something related to character movement, since incorrect emulation of the scu dsp causes people to fly to the other side of the ring when punched.
|
|
