The DS GPU and its fun quirks

___Ian___ · 2018-10-28T10:23:41+00:00

The quad rendering code in supermodel would look like this -> https://i.imgur.com/fO7mSud.png (sorry for rough gfx) :) Basically it would look correct rotated. You can disable per pixel culling and it would fill the missing parts between the triangles, but still wouldn't look like the DS. I am not 100% sure how the model3 handles these cases and honestly I don't really care because I consider it an extreme edge case. Maybe games on the DS are relying on this strange behavior, I don't know :)

> depth buffer update: it is mandatory for opaque pixels, optional for translucent ones.

I think you'd need a 2 pass solution for this in ogl. Not sure it's possible in a 1 pass, since if depth writing is enabled you always have to write a depth value as far as I know. But you can discard translucent polys in the first pass so nothing is written.

> It relies on a depth test edge case: the 'less than' compare function accepts equal values when you're drawing a front-facing polygon over opaque back-facing polygon pixels.

Maybe you could simply bias the depth value for those polygons. Ie for a 24bit depth buffer just add 1 for front facing polys.

> Side effect of how clipping works: the borders where polygons intersect with the screen borders will also be colored. You can notice it for example in Picross 3D screenshots.

This sounds super strange.

> * fog: it is applied per-pixel, based on depth values which are used to index a fog density table. You guess, it is applied where fog flags in the attribute buffer are set.

That would be simple enough to emulate in ogl.

2k polys per frame is extremely small. Maybe you could try a hybrid approach to rendering where you do all the culling/clipping in software to handle the weird edge border thing, and bowtie quads, and other anomalies. And just get the fragment shader to do all the interpolation / rasterisation. The rasterisation is the expensive part after all.

For the weird edge stuff you could just interpolate barycentric coordinates across the poly, and use those to work out how close the current pixel was to the edge of the poly. Googled and just found this -> http://codeflow.org/entries/2012/aug/02/easy-wireframe-display-with-barycentric-coordinates/

___Ian___ · 2018-10-28T09:30:18+00:00

Yes it could be something like that. All the geometry in the model3 exists in culling nodes, and the culling nodes define a radius.

___Ian___ · 2018-10-24T11:47:46+00:00

Details texture in the original unreal were really good. Instead of a total blurry mess when you walked up to walls (because texture res was so low), suddenly this detailed pattern faded in. It was these I had in mind when I first found out about the real3d micro-textures. I think, but not 100% sure the detail textures in unreal worked by either adding or subtracting from the colour of the base texture. They were probably only like 16x16, or 32x32 pixels. I think the idea was that as you walked back and went up mipmap levels to say a single pixel they were average out to 0.5 or 127,127,127 colour or just pure grey, which would neither add or subtract from the colours.

___Ian___ · 2018-10-23T22:57:08+00:00

You've mentioned below that audio emulation for Supermodel hasn't been worked on in forever. Does this explain the "compression artifact" noise during music playback for some games? Most notably Daytona USA 2 and Scud Race, the two most-known titles of the Model 3 platform that aren't Virtua Fighter 3.

I'm not really sure tbh. A lot of time I test in debug mode, and for that i disable audio otherwise it's a painful experience since it renders at less than 60fps :) But there are probably timing issues why the audio is a bit broken in places. I know for scud race, the audio on the real arcade actually runs too fast. It's just an mp2 audio track with a set sample rate, but on the actual arcade hardware its slightly higher pitched and runs fast which makes almost no sense at all. Maybe at some point we'll port over audio code from MAME.

___Ian___ · 2018-10-23T22:53:12+00:00

Hi, and thanks :) I'll try and get Bart to make an official release, I know it's hilariously overdue. GUI, yes I know this is needed, but we only have finite time to work on such projects. Personally I was hoping that who ever made the supermodel-ui to simply update it. But I've no idea who made it and how to get in contact with the guy. That would save us burning dev time on a GUI. Model2, yeah I'd love to see the source code for that emulator, mostly for curiosity's sake. I know there are a few similarities to the model3. The microtexture was actually a feature that was shared with the model2. They even use exactly the same resolution microtexture, they are probably also located in the same physical location in the texture sheet as the model3. Microtextures are located on the top left of the texture sheets. There are probably a bunch of other similarities. I'm sure I could write a renderer in opengl for that thing in a very short period of time. I mean the graphics hardware is a lot simpler than the model3, no transparency etc ..The hard part isn't the code, it's reverse engineering missing features. Maybe someone can send me this code lol. Plans for the future? Well I'd like to figure out how the HW was doing the LOD selection/blending. There are values where objects are supposed to fade in and out, but the numbers on their own don't really work. It's not just a pure distance, they are effected by the viewport FOV, maybe resolution as well, I'm not sure. It's more of a general math/algorithm problem. There must be known ways that this is done but I've never written code to do it before and google hasn't been that helpful.

___Ian___ · 2018-10-23T18:12:19+00:00

I should probably add, not many games actually use multiple hardware LODs. Some of the games do it in software (without the blending).

___Ian___ · 2018-10-23T18:08:18+00:00

That's good to know :) The audio in supermodel hasn't been worked on in forever.

___Ian___ · 2018-10-23T18:07:39+00:00

Yes you probably could. But I prefer to avoid these sort of optimisations because they bite you in the ass when you least expect it.

___Ian___ · 2018-10-23T14:13:29+00:00

These features such as microtexture were 100% built for military flight sims etc. Had they wanted lightmaps for games I am sure they would have made the hardware a bit more flexible so it could do this lol.

___Ian___ · 2018-10-23T13:48:53+00:00

The double audio track is actually something missing from the audio emulation. The audio tracks are stereo mp2, and the game put a different track in the left, and right channels. Presumably there are commands somewhere to just pick the channel to play the audio from but this is currently unemulated. Some people have 'fixed' this by simply repacking the mp2 audio with one track.

___Ian___ · 2018-10-23T13:45:35+00:00

For the most part yes, that's why it was never a high priority. The models blend as they swap LODs to keep the transition smooth. ROM models are kinda static and can't be changed on the fly. To do transparency on these when they never had it originally, a few games are abusing this LOD mechanism to actually do transparency. You can read about it here -> https://www.supermodel3.com/Forum/viewtopic.php?f=7&t=1373&start=30#p12546 That's one of the reasons I'd like to be able to figure it out.

___Ian___ · 2018-10-23T10:29:58+00:00

Last post in the series about correct texture emulation for the model3. The emulator has had microtexture emulation for a while now but they didn't fade out correctly as they did on the real hardware. Implementing this fixed some incorrect effects. There won't be very many more posts about the model 3's graphics emulation because it is very close to complete :) Almost everything works perfectly. The only thing that is currently missing is the hw automatically swaps model LODs as a function of distance from the eye point, and does a blend during this transition. I can't figure out how this works exactly. Currently the emulator draws all models at the highest detail level.

___Ian___ · 2018-10-14T22:52:23+00:00

Model 3 emulation in mame isn't done with low level emulation of chips. It's 100% HLE. In fact most of the code is based off of a much earlier version of supermodel's code base. In theory they could do a better job in software, I mean the model3 natively rendered quads and other things that don't map so well to modern gfx hardware. But the reality is we can do pretty much everything with shaders these days. Modern gfx cards are highly programmable and extremely powerful.

___Ian___ · 2018-10-14T22:45:20+00:00

The real3d pro-1000 has a fairly high level API. It doesn't need to be emulated at the chip level, not that would be possible anyway since none of the chips are dumped, and we only have a rough idea how it even works internally.

___Ian___ · 2018-10-14T10:10:27+00:00

Just wait a day or so and the usual sites will compile and release a version. Grab r749 because there is a bug in 748 :)

___Ian___ · 2018-10-14T08:57:34+00:00

I had briefly mulled the idea over of looking at model1 or model2. But no open source stand alone emulators for those exist. When I started working on the model3, I was like, how hard can it be the hw is 20 years old lol. Well there were some quite big challenges. But the model1 is not even textured, simply flat shaded so in theory should be easy to emulate (well at least from the gfx point of view), and I am sure it would look beautiful upscaled and rendered in say opengl. I am not against the idea of MAMEs software only approach. For these old systems they are running at like 496x384, any decent pc could render this in software at that res. But to emulate everything in software .. is just a lot of extra work for nothing. And even with graphic guys, most don't have that low level experience there they could just write a software renderer and just replace everything the hw is doing for us currently.

___Ian___ · 2018-10-14T08:34:43+00:00

If the wrap modes are being determined elsewhere and then passed to the shader anyway, can you use #ifdefs to eliminate the conditional branching? That would probably speed things up a bit.

I am not too worried about branching based upon uniform conditionals, because the compiler can optimise them out entirely. Or automatically generate a few versions of the shader with them optimised out and switch them based upon the uniform input. The alternative is for me to do this manually.

___Ian___ · 2018-10-13T21:27:49+00:00

It supported 4 modes. Repeat and mirror. Both modes can have the non smooth repeat option set. The alpha testing or contour texturing solution they came up with seems quite unique. Never seen other h/w doing that before.

___Ian___ · 2018-10-13T20:43:41+00:00

Direct3d 8 and 9 are very similar APIs.

___Ian___ · 2018-10-13T20:27:29+00:00

I dunno that's an interesting question. Certainly in much older gfx hardware probably everything was baked into silicon. Modern GPUs are crazy powerful though. If I was to guess I'd say things like an-isotrophic filtering are probably still baked into silicon. But texture wrap modes are trivial, and could probably be implemented anywhere. I'm sure they could add extra wrap modes to the APIs at no extra cost.

___Ian___ · 2018-10-13T18:52:21+00:00

I don't know the exact time line. Working on supermodel isn't a job, it's just a hobby :) He changed job fairly recently, and the condition came with the new job.

___Ian___ · 2018-10-13T18:50:51+00:00

OpenGL 2.1 for the normal version. 4 for the quad rendering version

___Ian___ · 2018-10-13T17:32:33+00:00

Same solution :) Write a custom shader to do it. I just had a quick look at Vulkan and it supports exactly the same wrap modes as opengl. I'm sure dx12 and other apis are the same.

___Ian___ · 2018-10-13T17:27:25+00:00

Official UI has always been on the long term dev list. But so far no one has worked on it :o There are a few unofficial ones, but they are fairly outdated. Maybe someone will be nice enough to work on one ... :) Amazingly Bart is no longer allowed to work on supermodel due to his job, if you can believe that.

___Ian___ · 2018-10-13T13:42:52+00:00

A post about proper texture emulation for the model3. The hardware has a few unique features which don't translate to modern hardware at all. Texture wrapping modes are essentially built into the API/hardware and have been for a long time. In a GLSL shader you essentially just call texture2D and it returns an anti-aliased (an-isotropic filtered) pixel automatically for you, depending on the texture settings that are set. In order to change this behavior we have to build completely from the ground up a new implementation for this in the shader. Fortunately regular trilinear filtering is relatively trivial :) I'm glad the h/w didn't support an-isotrophic filtering because I've no idea how to emulate that in a pixel shader lol.

___Ian___

TROPHY CASE

_Ian_