Could Dreamcast et al handle this/that game/effect? *DC tech retrospective *spawn

see colon said:
Just because newer libraries were available and assets weren't in the most optimal formats doesn't mean that the game wouldn't have shipped in the state that it was last leaked. NetherRealm and Rocksteady stuck with Unreal Engine 3 for much longer than most other developers, and Wukong just shipped on an outdated fork of UE5. It isn't all that uncommon. Maybe these things would have changed, but maybe not. We got a fair amount of PC to Dreamcast ports like Psycho Circus and Soldier of Fortune that clearly shipped in a less than optimal state.
Click to expand...
I just wanna say i loved Soldier of Fortune, even with all and its flaws. And yes they released that port unpolished because from a bussiness point of view, there wasnt a good reason to keep investing on polish a game which is going to be released on a dead console anyway. Would you do it? But we all know there was room for improvement, because we all have seen way more complex games on DC running better. Same happened with HL, and even worst because they finally cancelled it.
see colon said:
Unreal Engine 4 was released to developers in 2012 and Mortal Kombat 11 shipped on UE3 in 2019. It's not uncommon to ship a game with outdated libraries.
Click to expand...
Yes, but the version of UE 3 MK 11 uses is way improved....to the point it made MK 11 look way better than most UE 4 games. In fact, is there a 3D Fighter which looks better than MK 11 on PS4/One?
 
see colon said:
Unreal Engine 4 was released to developers in 2012 and Mortal Kombat 11 shipped on UE3 in 2019. It's not uncommon to ship a game with outdated libraries.
Click to expand...
But can we objectively say MK 11 had outdated libraries? The engine was soooo heavily modified that it did what nobody would have expected from the original UE3
 
Nesh said:
But can we objectively say MK 11 had outdated libraries? The engine was soooo heavily modified that it did what nobody would have expected from the original UE3
Click to expand...
Also older engines versus libraries - are they the same thing. Refactoring to a new engine can be costly and disruptive. Updating DLLs, if not doing anything radically different, should be more straight-forward. But I'm guessing there. Did updating libraries on console result in refactoring issues like changes in function calls and operations that'd nee extensive code reworking?
 
see colon said:
Unreal Engine 4 was released to developers in 2012 and Mortal Kombat 11 shipped on UE3 in 2019. It's not uncommon to ship a game with outdated libraries.
Click to expand...

UE isn't a "library" as such, it's an entire engine. It's constantly updated - sometimes radically so within a single main version - and a branch of UE3 with many years of customisation may well be a better fit for a particular game than a newer main version without all those years of customisation.

Win CE for the Dreamcast was not an engine. It is an OS and what would be called "drivers" on PC. The HL engine for DC was more comparable with a version of UE3.

Mortal Kombat 11 on UE3 in 2019 will not have shipped with pre 2012 drivers (or equivalent on console), and it will not have shipped with the same OS as from 2011.

Changing the .dlls used with DC Half Life for still old, but less old versions, is like driver and OS updates. These can have a huge impact on performance, especially if they were pretty terrible to begin with. It's not the same as changing the game engine. It's simply reducing some of the handicaps that the leaked, pre-release version of HL has due to what it was bundled with.

Two things are certain: PS2 HL was finished, and it was not using an outdated version of notoriously low performance Win CE. You have to acknowledge those things before you even start to look at the hardware.
 
function said:
Win CE for the Dreamcast was not an engine. It is an OS and what would be called "drivers" on PC. The HL engine for DC was more comparable with a version of UE3.
Click to expand...
OK, yeah. But Gearbox was involved. And the leaks were from so late in development I have zero faith thinking that the version of WindowsCE in those leaks were anything but the ones that were going to ship with the game. My Unreal Engine analogy was just to show that sometimes games ship with older software in a general sense. I'm sure plenty of Dreamcast games shipped with outdated WinCE .dll's as well.
 
see colon said:
OK, yeah. But Gearbox was involved. And the leaks were from so late in development I have zero faith thinking that the version of WindowsCE in those leaks were anything but the ones that were going to ship with the game. My Unreal Engine analogy was just to show that sometimes games ship with older software in a general sense. I'm sure plenty of Dreamcast games shipped with outdated WinCE .dll's as well.
Click to expand...

Actually development duties was carried out by captivation digital labs. They were responsible for the very early tech demos of katana sdk set 2( basically just a graphics card for Windows PC)
 
Cloofoofoo said:
Actually development duties was carried out by captivation digital labs. They were responsible for the very early tech demos of katana sdk set 2( basically just a graphics card for Windows PC)
Click to expand...
Given their history, I think we can all agree they don't have to be the main developer on a project to have a disproportionately negative influence on said project. Hence why I said they were "involved".
 
I think this Tweet covers something that was touched upon in the last few pages, these mods or user made ports benefit from decades and knowledge that wasn't there at the time.

Case in point, there's this new tool now for DC's CPU, which didn't exist when DC was actually on the market.

There has even been a developer who worked on DC comment, and say he wished he had something like this back in the day.

https://twitter.com/x/status/1830257060027736141

It's not just DC, I bet all the older platforms would benefit from modern knowledge and understanding.

I'm sure for example, Cell inside PS3 would likely be used for some modern compute like functions.
 
davis.anthony said:
Case in point, there's this new tool now for DC's CPU, which didn't exist when DC was actually on the market.
Click to expand...
Not true, official devs back in the day had a real time sh4 asm pipeline simulator. This is nothing new in that regard. What is exciting about this new one is that it's open source.
davis.anthony said:
It's not just DC, I bet all the older platforms would benefit from modern knowledge and understanding.
Click to expand...
A pipeline simulator is not a product of "modern knowledge and understanding".
 
Last edited by a moderator:
function said:
I know there's a CPU cost to doing the vertex calculations for bump mapping on the DC, but this is covering most of the screen with bump mapping at 60 fps. At 30 fps both bump mapping and the vertex calculations would have been very doable. Just as SimonF always said that bump mapping was perfectly doable in game on the DC.
Click to expand...
Apparently some of the lighting math in the previous build was incorrect, here's a video of the latest version with that fixed:
 

Attachments

  • Screenshot_2024-09-01-22-54-09-65_0b2fce7a16bf2b728d6ffa28c8d60efb.jpg
    Screenshot_2024-09-01-22-54-09-65_0b2fce7a16bf2b728d6ffa28c8d60efb.jpg
    535 KB · Views: 35
  • Screenshot_2024-09-01-22-54-20-35_0b2fce7a16bf2b728d6ffa28c8d60efb.jpg
    Screenshot_2024-09-01-22-54-20-35_0b2fce7a16bf2b728d6ffa28c8d60efb.jpg
    591.4 KB · Views: 35
Last edited:
He's not the only one to have commented about not having one.

So could it be not every had it or access to it.

I'm limited on uploads on mobile.
 
Also it's clear Sega didn't treat all devs equally as US devs didn't gain access to the higher-performance libraries as we learnt here!

State of the SDKs would actually have a huge impact on game development and hardware utilisation, particularly in the early years.
 
Shifty Geezer said:
Also it's clear Sega didn't treat all devs equally as US devs didn't gain access to the higher-performance libraries as we learnt here!

State of the SDKs would actually have a huge impact on game development and hardware utilisation, particularly in the early years.
Click to expand...
Out of national stubbornness they have been competing both their own foreign departments and their foreign third party developers probably since the Sega Saturn. Their mentality in Sega of Japan was contracted to their own world, afraid to lose power and control,instead of looking at the broader picture and at the end they almost lost everything
 
TapamN said:
There was an official pipeline simulator as part of Hitachi/Renesas's HEW (high-performance embedded workshop) SDK, but I don't know when it was created.

I've thought about making a pipeline simulator, but I was too lazy and just stuck with spreadsheets for the hard stuff, or doing it in my head for the easier bits.
Click to expand...

Would you be able to explain/show us how it works?

It would be pretty cool to see :)
 
Shifty Geezer said:
Also it's clear Sega didn't treat all devs equally as US devs didn't gain access to the higher-performance libraries as we learnt here!

State of the SDKs would actually have a huge impact on game development and hardware utilisation, particularly in the early years.
Click to expand...

The state of the graphics portion of the sdk is a mess when you look at the big picture. And I remember Sony had network when things or techniques were discovered they would circulate info to developers , Sega not so really. It had waaay too many subsections that I will list below, western devs seem neglected to me.

Darkness layer 1/2- lowest level library but seems pretty hush , not much info on it . Available on request from Sega not included on the sdk.

Ninja 1/1.5 - tnl code , model format, animation among other things provided by Sega . Meant for ease of use , used by many many Japanese developers including large percentage of Sega games. Was not given to western developers official and even removed from the western sdk after a while. Performance wasn't too great.

Ninja 2 - same as above with exception that more of the hardware was exposed like bump mapping , accumulation buffer, frame buffer options. Performance greatly improved and model export setting greatly expanded for more artist graphical control. No major game used it since it came out late 2000 except for a 2d dating sim.

Kamui - lower level access to hardware. Developers provided tnl code and performance is wholly on the developer. Provided access to GPU functions. This was the default for western devs.

Kamui 2 - same as above but performance improved and features added. Again default use for western devs

Naomi lib graphics - available to Japanese developers. Made by Sega provided model format and managed tnl . Seems to have more performance than ninja1. Used on Naomi games and Dreamcast . Used by many many Japanese devs who ported their arcade stuff to DC, including very heavy use by Sega themselves. Not part of the sdk by default , seems to be requested .

Windows ce v1/2.1 ( d3d immediate mode) ( also known as dragon sdk,)-
Direct x6.1 but specialized for DC. I hear version 1 was a shit show including some performance critical things being in c instead of assembly. Version 2.1 greatly improved and seems like it could be on par with kamui as use of assembly optimizations took place.
 
Last edited:
You must log in or register to reply here.
Back
Top