• Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.

Was the Dreamcast actually powerful at launch? Or the beneficiary of no competition?

Was the Dreamcast a powerhouse at launch?

  • No

    Votes: 111 11.4%
  • Yes

    Votes: 864 88.6%

  • Total voters
    975

Alexios

Cores, shaders and BIOS oh my!
I mean, sure you can't play GTAIII or San Andreas on Dreamcast at their wonderful ~20 fps as on the mighty PlayStation 2 since it was discontinued before AAA development really took off but you can play all these and many more gems so Dreamcast held its own while it lasted and holds up 🤷‍♂️

I edited the timestamps, Crazy Taxi 2's last missions take you through the whole city (in impressive speeds & 60 fps), Skies of Arcadia's intro at the start is amazing but the timestamp shows one of many cool effects it casually throws, F355's intro is sweet but so is the Long Beach course etc.

I couldn't find a better quality or quicker Le Mans video showing all it has going for it with real time day/night cycles, lighting, flare, glowing, rain, lens, reflection etc. effects in full 24 car races so that comparison with the PC version of that era will have to do since it includes all of that stuff.

PSA: When looking for Dreamcast footage be mindful of the state of the hardware (or emulation quality which I avoid, I'm only not certain about Sakura Taisen 4 above but decent footage of those games is rare). A DOA2 video I've since replaced, either due to a worn drive or because of a modded Dreamcast with the loading issues some drive replacement devices seem to have, often paused the image while taking longer than normal to load the next scene. It both looked wrong and the music got completely desynced so the last intro part was silent, here's Crazy Taxi chugging on a similarly problematic Dreamcast. Many more games look great, the Shenmues, Maken X, Grandia II or Tokyo Xtreme Racer 2 and even some of the better PS1 ports are tranformed on Dreamcast while low budget/effort stuff like the Atomiswave's bootleg Initial D wannabe Faster than Speed look solid too, showing it wasn't so hard to do well on the system (some of the best graphics are in launch window games after all, then again almost its whole life was a launch window being so short) but most companies just didn't care or even have the know how at the time, pioneering times for 3D and all.​
 
Last edited:
The Dreamcast didn't support Hardware bump mapping.
I dont think that is true, I remember reading somewhere specs that say it has support, but more important there are demos and there are games like tomb raider 4 and a godzilla game where godzilla appear to use emboss bumpmapping oh and the famous shenmue coin even if it doesnt have support doesnt seem to be too much of a problem to use it

 
Last edited:

PaintTinJr

Member
what makes a game look good(other than art direction) are the effects, the more effects you use it can affect the number of triangles that is why the number of triangles is not necessarily a good metric against another game since you have to make concessions depending what you want to show in your game there are things that you wont get just with high polycounts, not only depends how are you using those triangles, what if you want particles? what if you want water that reacts with movements? what if you want bump maps? o simply what if you want more than a couple lights in the scene?, I have heard that doa2 in DC has a debugg mode where you can play with lights, afaik the game uses 1 light per character and one for the scene you add more than that and the framerate decreases just like the cutscenes are 30 fps as it has more lights(probably it doesnt require 30 but vsync forces it) so even doa2 has to make concesions when it wants more, wants more light and vsync? then you can only display half the triangles per second as before, that is the concession

an it will be until you find a way to do better

I dont know exactly what tools you are talking but sure better tools help in development and experience get better result so naturally later games in general have better effects than the early ones but dramatic improvements tipically require something in the machine that have not been exploited and now you are using it, wasnt used correctly before or clever ways of using it are found and this last one is particularly important, for example sonic R in saturn use effects the machine really cant do but with clever ways of using the hardware and using part of the hardware you dedicate to it then it becomes possible




so yea you can use improved effects in DC games but there is a cost so it doesnt help to make exagerations about what is possible or disregard another game just because another game has this or that characteristic, its better to see what is available and how can be used

Yeah, this is the point I keep coming back to. AFAIK the Dreamcast only provides a high level - highly abstracted - interface for the GPU at the fixed path Opengl 1.4 or less level, meaning you'd need to do other things in software on the CPU, or use CPU or the 2D accelerated capabilities as a paint by numbers painter to do the shading that the fixed path fragmentation pipeline in the console GPU lacks the versatility to do.

Although, having watched those videos, on Dreamcast with OpenGL, I suppose clever pre-modification of graphics data in a similar vain to trick the linear interpolation acceleration lighting feature - in multiple blend passes- into providing non-linear lighting at each pixel could be possible.

Sparingly using GL_POINTS on a surface would allow non-linear lighting from neighbouring points but could be brutal on performance and memory use and would still produce gaps or need more points at different viewing angles

In the same vain of the blend example in one of the videos, a clever manipulation of a GL_TRIANGLE_STRIP with the strip stacking bigger polygons underneath the previous, so as to produce just 1 triangle from the strip, but with each strip polygon - each with a unique surface normal - just showing one line of the final rendered triangle, and this would result in per line lighting, but without any overdraw and should get pre optimised at the Vertex Array loading stage by GL and might perform reasonably well, despite a redundancy of probably 6 (or many more) polygons per line lit triangle.
 
It sure does, not only you can see it in commercial games and tech demos, it is well documented in the SDK, the only console that didn't support hardware bump mapping that gen was the PS2.
It wasn't true Bump mapping, but a effect that looked the same and barley any game made use of the effect either.
 

Esppiral

Member
It wasn't true Bump mapping, but a effect that looked the same and barley any game made use of the effect either.
Doesn't matter how you want to paint it, it supports hardware bump mapping. Period

The fact that barely any game used it doesn't mean it does not support it.
 
there are games like tomb raider 4 and a godzilla game where godzilla appear to use emboss bumpmapping oh and the famous shenmue coin even if it doesnt have support doesnt seem to be too much of a problem to use it
but the price must have been high, tomb raider 4 is part of the list of shimmering games on the Dreamcast, the game with fog and shadows upgrades were too much for the system.
 

SomeGit

Member
but the price must have been high, tomb raider 4 is part of the list of shimmering games on the Dreamcast, the game with fog and shadows upgrades were too much for the system.

Shimmering is because it doesn’t use mipmaps, there’s no performance advantage to it other than a small amount of memory usage by not generating them, quite opposite really it’s more expensive to draw full size textures for the entire screen.

PS2 rarely uses them too.
 
Last edited:

PaintTinJr

Member
Shimmering is because it doesn’t use mipmaps, there’s no performance advantage to it other than a small amount of memory usage by not generating them, quite opposite really it’s more expensive to draw full size textures for the entire screen.

PS2 rarely uses them too.
I find that highly unlikely, when Opengl's utility library GLU generates them automatically when loading the textures if needed, it only cost 1.333x the normal texture storage for the base and mipmaps,, and you would still get shimmering transition artefacts using nearest neighbour mipmap selection, when the mipmap chosen really needed a bilinear or anisotropic blend of mipmaps for the sampler output.
 

SomeGit

Member
I find that highly unlikely, when Opengl's utility library GLU generates them automatically when loading the textures if needed, it only cost 1.333x the normal texture storage for the base and mipmaps,, and you would still get shimmering transition artefacts using nearest neighbour mipmap selection, when the mipmap chosen really needed a bilinear or anisotropic blend of mipmaps for the sampler output.

Man, no.
 

Esppiral

Member
Mip Maps improve performance A LOT on Dreamcast yes it has a memory footprint penalty but it speed up rendering.

Also are we using again a cheap psx port that is running under WinCE (performance hogh) to talk about the Dreamcast capabilities? Haven't we learnt anything from this thread?
 
Last edited:

PaintTinJr

Member
Which factual part are you saying no to?

Is the fact that textures shimmer with camera movement even with mipmaps with a minification issue when filtering is disabled (ie nearest neighbour mipmap selection is enabled)?

Or are you arguing against the fact that the Utility GLU library can and will generate them automatically on request? or the fact that for conventionally square textures the complete mipmap collection is 1.333 (recurring) times the storage of the original texture?
 

SomeGit

Member
Mip Maps improve performance A LOT on Dreamcast yes it has a memory footprint penalty but it speed up rendering.

Also are we using again a cheap psx port that is running under WinCE (performance hogh) to talk about the Dreamcast capabilities? Haven't we learnt anything from this thread?

And like some example given earlier, like Tony Hawk, even the original PC version is hard capped at 30FPS.

Which factual part are you saying no to?

Is the fact that textures shimmer with camera movement even with mipmaps with a minification issue when filtering is disabled (ie nearest neighbour mipmap selection is enabled)?

Or are you arguing against the fact that the Utility GLU library can and will generate them automatically on request? or the fact that for conventionally square textures the complete mipmap collection is 1.333 (recurring) times the storage of the original texture?

I'm saying No, I'm not arguing anything because it's either wrong or irrelevant.

That 1) the game doesn't use mipmaps, google "Tomb Raider 4 Dreamcast" you can see far textures full res textures that are still filtered and 2) it's a WinCE port, ie DirectX, why are we even talking about OpenGL GLU? Even the Katana SDK doesn't use OpenGL (But yes each have their own way of generating mipmaps automatically).
 

nkarafo

Member
sorry but the theory of the short life of the Dreamcast is total bullshee imo, Sega pulled the plug in 2001 but many games continued to come out (SA2, HeadHunter, Soldier of Fortune, stunt gp etc) then Dreamcast gained extra life through the arcade Naomi 1 and Atomiswave. Ranger Mission 2004 is superior to similar games on Dreamcast, for all intents and purposes Dreamcast has not only completed its cycle but is also one of the most explored consoles.
Yeah, i forgot about the Naomi.

How long did that last on arcades?
 

Fat Frog

I advertised for Google Stadia
Yeah, i forgot about the Naomi.

How long did that last on arcades?
Quite long i would say but with cheap or non impressive games like Love Berry, Mahjong...

Underdefeat is an interesting one.
Yeah it's 2005 and it proves how important are modern tools:

The game is impressive, only made by a tiny team, G. Rev...
Imagine a 2005 high budget game by Square, Naughty Dog. (in a multiverse of course)
 

RetroAV

Member
Unlike the PlayStation 2, the top developers in the industry did not put their best efforts into Dreamcast development (which was understandable due to the uncertainty surrounding Sega at the time). Aside from Shenmue, even Sega themselves seemed more focused on trying to establish a diverse library of games before the PS2 hit than to completely max out its capabilities. Two years was not enough, the Dreamcast needed more time.
 

PaintTinJr

Member
...

I'm saying No, I'm not arguing anything because it's either wrong or irrelevant.

That 1) the game doesn't use mipmaps, google "Tomb Raider 4 Dreamcast" you can see far textures full res textures that are still filtered and 2) it's a WinCE port, ie DirectX, why are we even talking about OpenGL GLU? Even the Katana SDK doesn't use OpenGL (But yes each have their own way of generating mipmaps automatically).
I watched and can't see the shimmering on the dreamcast in the video below, but ironically can on the Ps1, probably due to crude software rasterization. The Dreamcast game rendering in the video gives zero indication of a lack of mipmapping being enabled. If you have a video with the Dreamcast shimmering feel free to post it and the timestamp.



As for Windows CE, I wasn't directly talking about that game, more the point you were asserting shimmering and failure to use mipmaps were related, when crude CPU rasterization or absent mipmap filtering in minification can provide the same outcome, and that one of the UK's technically skilled devs of the time choosing to not do the bare minimum requirement for texture mapping(ie to use mipmaps) seemed far fetched.

And as for Windows CE Dreamcast SDK not using OpenGL, I'm downloading the SDK slowly from archive.org to check, because the deal to integrate opengl 1.2 into Windows between SGI - the owners of opengl - and Microsoft was before the Dreamcast launch IIRC.
 
Last edited:

SomeGit

Member
I watched and can't see the shimmering on the dreamcast in the video below, but ironically can on the Ps1, probably due to crude software rasterization. The Dreamcast game rendering in the video gives zero indication of a lack of mipmapping being enabled. If you have a video with the Dreamcast shimmering feel free to post it and the timestamp.

As for Windows CE, I wasn't directly talking about that game, more the point you were asserting shimmering and failure to use mipmaps were related, when crude CPU rasterization or absent mipmap filtering in minification can provide the same outcome, and that one of the UK's technically skilled devs of the time choosing to not do the bare minimum requirement for texture mapping(ie to use mipmaps) seemed far fetched.

And as for Windows CE Dreamcast SDK not using OpenGL, I'm downloading the SDK slowly from archive.org to check, because the deal to integrate opengl 1.2 into Windows between SGI - the owners of opengl - and Microsoft was before the Dreamcast launch IIRC.

You can easily see the shimmering on the floor at 2:30, and you can also see it's filtered at distance a half screen YT video probably isn’t way to spot but you can easily see it. It’s less than PS1, but since the PS1 is both low res and completely unfiltered it makes sense why that is.

I've played the game a lot Dreamcast and know it doesn't use mipmaps, that tangent is completely irrelevant to the specific game that was being discussed Tomb Raider 4, not any general relation. Why they chose not to use them, I don't know I can speculate but ask them not me, like Shenmue it doesn't use them.

Feel free, but Windows CE never had OpenGL support only OpenGL ES support but that was way way later. If you need the specific DC one it's called Dragon SDK from what I remember.
 
Last edited:
I watched and can't see the shimmering on the dreamcast in the video below, but ironically can on the Ps1, probably due to crude software rasterization. The Dreamcast game rendering in the video gives zero indication of a lack of mipmapping being enabled.
It varies from stage to stage, I was really impressed by the jaggies in the background, in the real time cutscenes the entire scene has jaggies, honestly the dispute with MSR was fierce.
 

PaintTinJr

Member
It sure does, not only you can see it in commercial games and tech demos, it is well documented in the SDK, the only console that didn't support hardware bump mapping that gen was the PS2.
That generation bump mapping, Embossed maps and normal maps were used as interchangeable terms, because the output was low colour or low resolution across the board, but to say the PS2 didn't support them when we had a full graphics paper linked a page or two back describing two techniques doing more than DC bump mapping and we see it used well on all the target surface platforms in monkey target deluxe on PS2 is a very wrong, and odd claim IMO.
You can easily see the shimmering on the floor at 2:30, and you can also see it's filtered at distance a half screen YT video probably isn’t way to spot but you can easily see it. It’s less than PS1, but since the PS1 is both low res and completely unfiltered it makes sense why that is.

I've played the game a lot Dreamcast and know it doesn't use mipmaps, that tangent is completely irrelevant to the specific game that was being discussed Tomb Raider 4, not any general relation. Why they chose not to use them, I don't know I can speculate but ask them not me, like Shenmue it doesn't use them.

Feel free, but Windows CE never had OpenGL support only OpenGL ES support but that was way way later.
Just unpacked it, and if I search and replace all ninja references NDJ_ and nd to GL_ and gl in the headers files of the KATANA installation folder it reads like Opengl with GLU integrated, far more than DirectX5 or DirectX6 of the time. and the recommend example in the README is ironically a mainstay of Opengl: the Standford Teapot, and in that example in the "\KATANA\Sample\Ninja3d\teapot" folder the source code that links into ninja.h which references ninjadef.h in the include folder has this interesting flag

#define NJD_TEXATTR_AUTOMIPMAP BIT_22

and I presume it is on by default because the teapot example, test.c file has this call to use filtering of MIPMAPS

njSetConstantAttr( 0xffffffff, NJD_FLAG_USE_TEXTURE | NJD_FLAG_USE_ENV|NJD_FILTER_BILINEAR);

Which all looks more than coincidental.

In addition the example uses this initialisation line, similar to the latest Dreamcast SDK dev examples, and specifies a RGB_555 colour frame buffer.

sbInitSystem( NJD_RESOLUTION_640x480_NTSCI, NJD_FRAMEBUFFER_MODE_RGB555, 1 );

So it is very possible the shimmering is actually just the result of a pixel having a temporary colour saturation (to 1) in the limited colour range they would have used with all the alpha blending they are doing to. I really find it impossible to believe texture mipmapping wasn't enabled in that commercial title.
 
Last edited:

SomeGit

Member
Ninja is a Sega library for Katana SDK, Katana SDK and Windows CE's Dragon SDK are 2 seperate SDKs for the Dreamcast. Of course Katana won't look like DirectX 6 because it's not DirectX 6. Tomb Raider uses Windows CE, you can see it on the boot screen.

I'm not going to bother to entertain your lunacy any further, get a Dreamcast and look at the game, that specific game does not have mipmaps. Your outlandish theories don't apply, stop creating absurd assumptions when you have no clue what you are talking about.
 
Last edited:

PaintTinJr

Member
Ninja is a Sega library for Katana SDK, Katana SDK and Windows CE are 2 seperate SDKs for the Dreamcast. Of course Katana won't look like DirectX6 because it's not DirectX 6. Tomb Raider uses Windows CE, you can see it on the boot screen.

I'm not going to bother to entertain your lunacy any further, get a Dreamcast and look at the game, that specific game does not have mipmaps. Your outlandish theories don't apply, stop creating absurd assumptions when you have no clue what you are talking about.
Windows CE is an operating system, and I was under the impression from the what I read on the temporary install was that katana runs on the Windows CE OS. If not, what SDK does the Dreamcast's Windows CE provide for graphics? How Kantana is written looks really simple for writing Dreamcast katana games on Windows CE and with small adjustment would have ported easy to Windows PC with Opengl.

Has anyone tried forcing enabling mipmapping on TR4 on an actual dreamcast to get a non-shimmering version? Surely that wouldn't be too difficult?
 
Last edited:

Fafalada

Fafracer forever
the only console that didn't support hardware bump mapping that gen was the PS2.
There was no such thing as 'hardware bumpmapping' in that console gen (fixed function BM was one and done before DC came out).
DC had a dot-product function in texture combiner that expected normal-vectors in polar coordinates. Basically it was setup to compute what we now call normal-mapping, but it required some hoops to implement. It could not perform dependant lookups (so no perturbed reflections/water shaders).

GCN had a dependant texture lookup that was based on 2x3 matrix transform. Basically the closest analogue is what DirectX called 'EMBM' - it was designed to make perturbed reflections easy (Water shaders etc). Getting creative with the lookup destination, it was also possible to get visual results of specular or even diffuse-like surface perturbations(aka bumps). Due to input parameter limitations it was not really useable for 'Normal mapping'.

PS2 had no separate instructions for DOT but it could be implemented using standard pixel math. When optimized, performance was just a bit over 1 Dot product/cycle (using 3 light-sources). Semantics arguments aside that still makes it hw-accelerated, even though the setup was even more cumbersome than on DC/GCN (but it did have the benefit of hw-accelerated geometry setup with VUs). And like DC it had no hw-accelerated way to perform dependant lookups either.

XBox had separate instructions for DOT product and dependant texture lookup. Ie. you could combine them to do what GCN did(but it was more costly, yes), or use just DOT to do what DC did (but without the polar-coordinate limitations). And like PS2 - it had vertex-shaders to 'setup' the pixel shader computations. Basically it had the benefits/functionality of all the other consoles, and none of their downsides in this particular case.
 

SomeGit

Member
Windows CE is an operating system, and I was under the impression from the what I read on the temporary install was that katana runs on the Windows CE OS. If not, what SDK does the Dreamcast's Windows CE provide for graphics? How Kantana is written looks really simple for writing Dreamcast katana games on Windows CE and with small adjustment would have ported easy to Windows PC with Opengl.

Has anyone tried forcing enabling mipmapping on TR4 on an actual dreamcast to get a non-shimmering version? Surely that wouldn't be too difficult?

There are 2 seperate SDKs, Katana SDK which was developed by Sega which uses libraries like Ninja from Sega (as you saw) and also Kamui from NEC/VideoLogic which is more low level.
Honestly don't have a clue about which was more used in commercial games, but I remember reading from a later version of the SDK (r10?) that Ninja was discontinued and all samples ported to Kamui, so I guess Kamui was more popular but that's just me assuming. On the disc you got you probably has samples for both.

The second one was Dragon SDK and uses WinCE and DirectX.
 
Last edited:
but the price must have been high, tomb raider 4 is part of the list of shimmering games on the Dreamcast, the game with fog and shadows upgrades were too much for the system.
well it mostly depends the game, I dont think that just because it have shimmering its bad or something, I have not played the DC port in recent time, I dont think TR4 in particular has too much of a problem given the scope of the game, at first look seems as a straight port of PSX just taking advantage of DC power but without too much optimization it was surpising they took the time to include some bump maps but other than that I dont think it squezes the console or something, DC have so many ports of PSX/N64 games I think they could improve those games a bit more with special effects and not just a bump in resolution, framerate and draw distance wich is a welcome adition
 
at first look seems as a straight port of PSX just taking advantage of DC power but without too much optimization it was surpising they took the time to include some bump maps but other than that I dont think it squezes the console or something, DC have so many ports of PSX/N64 games I think they could improve those games a bit more with special effects and not just a bump in resolution, framerate and draw distance wich is a welcome adition
they did
almost all so-called ps1 ports are dreamcast games after being ported to it, there is no BM on ps1. There are a lot of myths surrounding DC, one of which is that Windows CE steals performance, this excuse started with Sega Rally 2 because the port was inferior, at the time reviewers thought that the Dreamcast was more powerful than the Model 3 arcade board. the other is that a game continues to be a 'ps1 game' after receiving an increase in polygons, an increase in resolution, BM, fog and shadows etc

Dreamcast's Shadowman is not an N64 game nor is Soul Reaver a PS1 game.
I would like to know how many polygons nulldc gives to Tomb Raider on the Dreamcast, someone check it out to us.
 
Last edited:
Doesn't matter how you want to paint it, it supports hardware bump mapping. Period

The fact that barely any game used it doesn't mean it does not support it.
It's not true Bump mapping.
Umm yeah the power vr2 could do bump mapping and even had a texture format for normal maps.


The powervr2 was a little powerhouse.

The DC didn't support true Bump mapping that's all I'm saying


26587824664_9c64878d75_o.jpg
 
Let's make a list of DC games with proper shadows.

pen pen no
godzilla no
sonic 1 no
seventh cross evolution no
Industrial Spy: Operation Espionage no
Resident Evil Code: Veronica no
grandia 2 no (only in battle)
Carrier no (60fps)

Cyber Troopers Virtual On yes (60fps)
all 3d fighting yes
Dynamite Cop yes enemies and main character (60fps)
Incoming yes
Blue Stinger yes
D2 yes enemies and main character
NFL 2k yes
Toy Commander yes
TrickStyle yes
shenmue yes main character and npcs
Rippin' Riders Yes (60fps)
Team Stalkers yes
Zombie Revenge no (60fps)


Maken X no (60fps) only boss battle has proper shadows
death crimson ox (60fps)
No FPS game have proper shadows
Frame Grid no
Draconus: Cult of the Wyrm no
Skies of Arcadia no
Spawn no
Record of Lodoss War no

cannon spike yes
JSR yes
ecco the dolphin yes
Sonic Adventure 2 yes
UEFA Dream Soccer yes
Virtua Striker 2 yes
soul fighter yes
MDK2 yes

Super Magnetic Neo no (60fps)
Slave Zero no
Rent-A-Hero No.1 no (60fps)

virtua cop 2 yes
headhunter yes
Sword of Berserk yes
illbleed yes (60fps)
Virtua Tennis 2 yes

Heavy Metal: Geomatrix no (60fps)
power stone no (60fps)
outtrigger no (60fps)
Ooga Booga no (60fps)
The Ring: Terror's Realm no

seven mansion yes
confidential mission yes (60fps)
the house of the dead 2 no
Demolish fist no
Ranger mission no
Floigan bro no (60fps)
Ready to Rumble no
Mobile Suit Gundam: Federation vs. Zeon no

ps1 and N64 port with shadow upgrade

Fighting Force 2
Shadowman
Tomb Raider
Aitd 4 (60fps)
Evil Dead
UFC
Rayman 2 no (60fps)
Legacy of Kain: Soul Reaver no (60fps)
Star Wars: Episode I: Jedi Power Battles no (60fps)

interesting that Dave Mirra ps1, Spiderman N64 and Jeremy Mcgrath have shadows, Tomb Raider chronicle has no shadow
The first fps game to have proper shadow was 007 Agent Underfire and Halo.
 
Last edited:
We can't underestimate shadows, shadows were rare in the 5th generation. In a quick analysis JSR appears to be the most advanced Dreamcast game to use shadow, note how advanced games like RECV don't use it.
Sonic Adventure 2 is the most advanced 60fps action game with shadows, Shenmue is also an advanced game with shadows but IMO comes in third in this quick analysis.
 

Alexios

Cores, shaders and BIOS oh my!
Plenty more games have shadows (but will now be disqualified for being just fighting, just racing, just sports or whatever). It's not a matter of yes/no to begin with (and you could have just made a yes list anyway, lmao, not list every DC game you atm remember with a no) given the varied methods.

And lol @ continuing to call multiplatform games of the pre-PS2 period with a PS version that runs/looks (way more) horrible like Shadowman "PS ports" just to diminish the DC. Might as well call Le Mans that if you're including UFC which first came out on DC then was competently (de)made for it.
 
Last edited:

PaintTinJr

Member
Just right after Nvidia ports DLLS3 to PS2
Why didn't you focus on checkerboard or FSR2, which I said would work - they work on Switch FYI - rather than me hypothesising about a XeSS/DLSS/PSSR at low resolution(160x120) could possibly work in real-time on PS2.

Or are you disputing that general compute of the PS2 CPU and co-processors could do the DLSS algorithm as slow as 1fps per hour, too?

Why be so defensive at the reality that the PS2 could transcend many of its best previous results with modern day techniques?
 

Alexios

Cores, shaders and BIOS oh my!
they work on Switch FYI
That has nothing to do with PS2, it's 15 years removed hardware. Even cheap low end mobile gpus have more and more modern features even if they couldn't handle a high end PS2 port with good performance (though many probably could).
 

PaintTinJr

Member
...

The second one was Dragon SDK and uses WinCE and DirectX.
I looked that up and it was interesting to see the files the site claimed ended up on the Dreamcast discs as a result of having to include the entire WinCE OS with each game that used it.

Given that WinCE came out at the time of a release of a complete Kernel redesign/implementation, I would say the single biggest reasons for using Windows CE for Dreamcast was for consistent thread programming between Windows PC games and the two hardware threaded single core Dreamcast CPU - long before pThreads was easy and readily used via Cygwin on Windows - and the Windows NT network stack implementation, being the easiest solution for Dreamcast game developers to offer robust network features, as an when, even if just wanting to provide the game with the ability to open hyperlinks to their website and advertise their other games via modem dialup.

What is interesting about the tiny set of DirectX files on the game discs using Windows CE, is that the main one is a HAL library file, (Hardware Abstraction Layer) meaning that Microsoft seemingly did what they do with Windows for PC. They just map the OEM hardware drivers into abstracted calls and provide a HAL and an API. So I'm pretty sure the Dreamcast's use of "DirectX" is in name only, and that the two Japanese companies in Hitachi and SGI that appear to have been the providers of the Katana solution also indirectly provided the driver solution for the Dragon SDK too, suggesting that nothing the devs did with Dragon could have more than parity with a good Katana/Opengl solution.
 

Fafalada

Fafracer forever
Why be so defensive at the reality that the PS2 could transcend many of its best previous results with modern day techniques?
It's a bit of a stretch to go that far back with these.
FSR2/TAA would translate pretty well to PS3 hardware (as would PBR to that entire gen) so that's definitely been a case of missed timing (ie. probably every PS3 game could be '1080p' with reconstruction, and with damn sight better IQ than results we did get).

PS2 though - yes there's some modern techniques that missed the boar - specifically deferred shading - but it's hard to judge if visual trade-offs of getting Floating point pixel shading model would have outweighed the cost.
Image reconstruction though - that just gets into prohibitively expensive realm - like what you said about '1s per frame' type of things.
 
Plenty more games have shadows (but will now be disqualified for being just fighting, just racing, just sports or whatever). It's not a matter of yes/no to begin with (and you could have just made a yes list anyway, lmao, not list every DC game you atm remember with a no) with varied methods used.

And lol @ continuing to call multiplatform games of the pre-PS2 period with a PS version that runs/looks (way more) horrible like Shadowman PS1 ports just to diminish the DC. Might as well call Le Mans that if you're including UFC which first came out on DC then was competently (de)made for PS.


Baseball 2k2, Virtua Tennis 2, and Sports Jam, they always have seen to me the most advanced visually sports games on all DC catalogue...if only we would had a proper soccer game which looks and play as good as those.
 

PaintTinJr

Member
That has nothing to do with PS2, it's 15 years removed hardware. Even cheap low end mobile gpus have more and more modern features even if they couldn't handle a high end PS2 port with good performance (though many probably could).
You are confusing feature sets, with the accelerated vector graphics versatility that the PS2 had. Fafalada already explained how the PS2 could do meshlets all the way back then,
 

Evil Calvin

Afraid of Boobs
The Dreamcast-type games is what Xbox needs (the industry needs).......games like Hi-Fi Rush (....whoops). Games like Chu Chu Rocket, Toy Commander and Crazy Taxi were fun games. Sure they aren't all 10 million sellers but publishers need to lower expectations and forecasts, spend less but make smaller 'FUN' games. Bring back storefronts like Xbox Arcade.
 

PaintTinJr

Member
It's a bit of a stretch to go that far back with these.
FSR2/TAA would translate pretty well to PS3 hardware (as would PBR to that entire gen) so that's definitely been a case of missed timing (ie. probably every PS3 game could be '1080p' with reconstruction, and with damn sight better IQ than results we did get).

PS2 though - yes there's some modern techniques that missed the boar - specifically deferred shading - but it's hard to judge if visual trade-offs of getting Floating point pixel shading model would have outweighed the cost.
Image reconstruction though - that just gets into prohibitively expensive realm - like what you said about '1s per frame' type of things.
For FSR2, I was also taking account of a much lower starting resolution 160x120, and inferencing to just 320x240, and was basing it on the 320x240 training data is order of magnitude lower than today's games, purely on the basis of comparing component video bandwidth to hdmi 1.2. So the number of inference maths calculations per pixel I would still expect to be around the 20 maths ops you mentioned IIRC in another post, although I guess the motion vector data streamed into the PS2 RAM could easily be a deal breaker too, but if native rendering was a 160x80, the PS2 would also get a disproportional gain in spare processing capacity, say compared to a Switch maybe using 10%, of its performance, the PS2 might have more like 70% spare to use for FSR, from the very low res native render was what I was thinking.
 

SomeGit

Member
Baseball 2k2, Virtua Tennis 2, and Sports Jam, they always have seen to me the most advanced visually sports games on all DC catalogue...if only we would had a proper soccer game which looks and play as good as those.
If Sega pulled their money to get a competent port of ISS Pro Evo 1 or 2, instead of their dozens of attempts with Silicon Dreams they would have filled that market. Shame, Virtua Striker is still fun though.
 
Top Bottom