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

I'm sure the guy on Twitter did say they did optimise the disk layout of PS2 to help achieve maximum transfer rates.

So I wouldn't be surprised if there's a lot of duplicates data on the DVD.
 
As long as it's not publicly available, there's jack shit they can do about it*. Someone experimenting to port a game from one ancient console to another is fine and legal.

* Legally. They can hire assassins...
 

Huh, Dreamcast is really getting a burst of software out of nowhere after years of no attention. The new push is to push maximum performance to boot. Out of all things there's a programmer who's actually maxed the sh4 ( CPU ) performance on a Minecraft clone. Basically has said he's been pushing around 5.5 million polygons per second in actual game situation . His code has been reviewed by the sh4 compiler maintainer and pretty much said his code his is as fast as you practically go while being a game and not just polygon push. That's the DC version below.( Real hw vga he said)

 
Last edited:
Huh, Dreamcast is really getting a burst of software out of nowhere after years of no attention. The new push is to push maximum performance to boot. Out of all things there's a programmer who's actually maxed the sh4 ( CPU ) performance on a Minecraft clone. Basically has said he's been pushing around 5.5 million polygons per second in actual game situation . His code has been reviewed by the sh4 compiler maintainer and pretty much said his code his is as fast as you practically go while being a game and not just polygon push. That's the DC version below.( Real hw vga he said)

They're looking into adding shadow volumes for clouds and such, too! I think we're really gonna start seeing true DC power in the next year or so! Btw, i just found out through some devs that the DC's cpu numbers don't mean much. They said if you program it with parallel code, it's more like 400mhz, not the 200 listed! There was so much nuance to DC that was never taken advantage of!
 
They're looking into adding shadow volumes for clouds and such, too! I think we're really gonna start seeing true DC power in the next year or so! Btw, i just found out through some devs that the DC's cpu numbers don't mean much. They said if you program it with parallel code, it's more like 400mhz, not the 200 listed! There was so much nuance to DC that was never taken advantage of!

Well it isn't quite like that. What they are referring to certain instructions on the CPU can be executed in parallel on the sh4 leading to far greater performance. It's not magic, basically the issue was the compilers that generated code sucked( and seems still suck) at this so people who write assembly have been trying to use fastest( low latency) instructions that can be parallelized for important things liked 3d math.

Sound familiar ? Yeah ps2 had this kind of love and care for its vu co processors but since the Dreamcast failed they obviously didn't bother to optimize to this level.

Some people do the above and take it further , they cycle count how fast their vertices are on the cpu ( sh4) that's how the flock of meese Minecraft on GameCube and DC achieved this kind of performance on Dreamcast. If anything he even tested how fast he can push the vertices if he doesn't have to worry about a game situation( game sit was 5.5 million). He actually very nearly reached the on paper 7 million pps for sh4. Very very very few people ever bothered to optimize to this level on dc and probably almost none during its commercial lifetime.

Tested it a few moments ago. Skipping UV coordinate computations reduces cycles/vertex from 36 to 30 (5.5 -> 6.6 million pps). I didn't notice a difference between enabling or disabling texturing on the PVR. Still getting 6.6 million pps with texturing enabled and without UV coordinate calculations. In other words, you can hit the theoretical peak throughput of the PVR with textures enabled.

Loading and converting U and V took 6 cycles. This is just an experiment to measure how close I can get to theoretical peak throughput of the PVR.

Wikipedia says the theoretical maximum is near 7 million pps (29 cycles/vertex). You'll run out of VRAM before exceeding 7 mil.
 
Well it isn't quite like that. What they are referring to certain instructions on the CPU can be executed in parallel on the sh4 leading to far greater performance. It's not magic, basically the issue was the compilers that generated code sucked( and seems still suck) at this so people who write assembly have been trying to use fastest( low latency) instructions that can be parallelized for important things liked 3d math.

Sound familiar ? Yeah ps2 had this kind of love and care for its vu co processors but since the Dreamcast failed they obviously didn't bother to optimize to this level.

Some people do the above and take it further , they cycle count how fast their vertices are on the cpu ( sh4) that's how the flock of meese Minecraft on GameCube and DC achieved this kind of performance on Dreamcast. If anything he even tested how fast he can push the vertices if he doesn't have to worry about a game situation( game sit was 5.5 million). He actually very nearly reached the on paper 7 million pps for sh4. Very very very few people ever bothered to optimize to this level on dc and probably almost none during its commercial lifetime.
Hopefully we'll start seeing 5/6/7 million pps on the regular after this!
 
Hopefully we'll start seeing 5/6/7 million pps on the regular after this!

Uhh yeah no. Don't get your hopes up so high. Performance will increase with the way kos and tools are improving but don't expect 6/7{ 7 especially he just said he can't reach due to out of vram likely, 6 also was just non game situation) on a regular basis. It's case by case and depends on the individual skill level( not every one is an embedded wizard). This Minecraft project is the exception not the norm( probably has conditions that help reach his in game peak). Remember this is homebrew not a paying gig, this is pretty hardcore stuff .
 
Last edited:
Uhh yeah no. Don't get your hopes up so high. Performance will increase with the way kos and tools are improving but don't expect 6/7{ 7 especially he just said he can't reach due to out of vram likely, 6 also was just non game situation) on a regular basis. It's case by case and depends on the individual skill level( not every one is an embedded wizard). This Minecraft project is the exception not the norm( probably has conditions that help reach his in game peak). Remember this is homebrew not a paying gig, this is pretty hardcore stuff .
Doesn't need to be during gameplay imo. Maybe those nembers in tech demos, maybe a cutscene or two, etc. Also, you never know, they could easily sell their games and make it a job, haha
 
Hopefully we'll start seeing 5/6/7 million pps on the regular after this!

Need to leave some room in vram for textures!

IIRC geometry took up something like 40 Bytes per polygon in vram. 6 million at 30 fps would be 200,000 per frame, or 7.63 MB, with no room for textures or a framebuffers.

At 60 fps that'd be ~3.8 MB, and 5 MB with framebuffers so it'd still be getting tight for textures even with DC's awesome VQ texture compression.

If you had the CPU headroom, might be better to go with less geometry but do more with lightsources and bump mapping (bump maps have a CPU cost and a vram cost for bump maps, but they can potentially add a lot more detail than geometry at a lower cost). A Resident Evil game with cone lights for flashlights and swinging overhead lights, and bump maps for where the cone of light hit surfaces (particularly at an acute angle) would have been super atmospheric.
 
Doesn't need to be during gameplay imo. Maybe those nembers in tech demos, maybe a cutscene or two, etc. Also, you never know, they could easily sell their games and make it a job, haha

Well that would be nice. The reason I said before that Minecraft probably had ideal conditions to hit his peak (5,5mpps) in game situation since it's PROBABLY procedural meshes, no skinned meshes , limited light sources ( though he does seem to do some impressive looking lighting as is) .

His engine probably has a lot of head room to do a lot geometry( I would bet far more than doa2) but wouldn't likely hit these numbers with skinned meshes( bones+ animation) , speculars and other materials , point light sources or high number of directional light sources. Still the future looks bright
 
Need to leave some room in vram for textures!

IIRC geometry took up something like 40 Bytes per polygon in vram. 6 million at 30 fps would be 200,000 per frame, or 7.63 MB, with no room for textures or a framebuffers.

At 60 fps that'd be ~3.8 MB, and 5 MB with framebuffers so it'd still be getting tight for textures even with DC's awesome VQ texture compression.

If you had the CPU headroom, might be better to go with less geometry but do more with lightsources and bump mapping (bump maps have a CPU cost and a vram cost for bump maps, but they can potentially add a lot more detail than geometry at a lower cost). A Resident Evil game with cone lights for flashlights and swinging overhead lights, and bump maps for where the cone of light hit surfaces (particularly at an acute angle) would have been super atmospheric.

I guess good thing it's mine craft. Texture quality is a lot less limiting , he can just focus on pushing vertices. Probably main ram is more important since he has procedural world building .

How many people will want to buy a MC clone for DC??

Dunno. It's good for dc either way these Uber skilled devs showed up with these random projects. Betters the homebrew tools.
 
Back
Top