Calico

[Quasar]

I'd be interested in seeing the difference between the CRY color cube and the color cubes for RGB555 and RGB565, since they hold the same amount of information.

[Quasar]

I am having some pretty big problems with the renderer that I simply cannot track down. I've been back over the assembly for phases 2, 4, and 6 repeatedly, compared as much as possible to vanilla Doom and 3DO to look for differences, and tried changing some things that obviously have implementation-defined behavior (signed/unsigned mismatches mostly) without any success whatsoever.

You can see two phenomena I am dealing with in this shot:
http://pasteboard.co/KotStDzL.png

First off lines that intersect the edges of the view aren't projected correctly. It's been totally impervious to changes so far. Second, once the top of a line is clipped, the distortion gets even worse. I single stepped the rendering of a whole problem line last night and pulled out all the numbers it's calculating, and the projected height of the columns is just totally wrong for a reason I cannot see.

I am hoping some people who are good with the Doom renderer can take a look, try to run this code, and suggest some changes, because otherwise, for the time being, I have run into a dead end.

[Rachael]

Is there a reason for reverse engineering the renderer itself, rather than reusing the renderer code that already exists?

Other than possible things like sector colors and whatnot, I don't know if Jaguar Doom supports transparency or what not but if it does you should be able to get the exact alpha values from the drawers, themselves, somehow, and save yourself a lot of trouble?

[Quasar]

Eruanna said:

Is there a reason for reverse engineering the renderer itself, rather than reusing the renderer code that already exists?

Other than possible things like sector colors and whatnot, I don't know if Jaguar Doom supports transparency or what not but if it does you should be able to get the exact alpha values from the drawers, themselves, somehow, and save yourself a lot of trouble?

It's not possible to just drop in the PC renderer and be accurate to the console. For one thing it renders at a fixed 160x180 instead of 320x200 with a variable window size. For another, it's really part of the point of the project, to show how the console ports work at a basic level, with the 9-phase rendering process. The 3DO source release fails to demonstrate this due to radical, far-reaching changes that Burger Becky made to it.

Finally, dropping in a lot of PC code in places I think are wrong or questionable has so far failed to fix this problem.

[Rachael]

Ah. You may not like it but there are a couple of renderer gurus over on the ZDoom forum - you may consider cross-linking this thread to get their attention.

I'd be more helpful, myself, if I had more experience working with it, beyond changing certain parameters of it to meet certain needs.

[dpJudas]

Not sure how much this helps, but it looks like dc_texturemid is not being properly adjusted when the wall is being clipped against ceilingclip.

For the wall to the left, it is getting clipped by the top of the screen. For the wall to the right it is getting clipped because the midtexture lowered the ceilingclip to only cover the entrance to the side room. All other walls on the screenshot have no clipping on their start dc_texturefrac position.

[Quasar]

dpJudas said:

Not sure how much this helps, but it looks like dc_texturemid is not being properly adjusted when the wall is being clipped against ceilingclip.

For the wall to the left, it is getting clipped by the top of the screen. For the wall to the right it is getting clipped because the midtexture lowered the ceilingclip to only cover the entrance to the side room. All other walls on the screenshot have no clipping on their start dc_texturefrac position.

I definitely think you're onto something, but the problem is the way the line scaling is so different from vanilla - I can see where vanilla has a step for the top and bottom of a line, in addition to the texturemid, but that's missing entirely from Jaguar so I'm left wondering how exactly it's managing it.

I'm about to break down and try to adapt PC's R_RenderSegLoop just to see if it works correctly given the rest of the engine's setup. It's still possible, and pretty probable, that part of the problem is in the earlier code (phase 2 or phase 4 setup). Linguica thinks integer overflows could be part of the problem but I'm having trouble pinning those down if they exist. There's no way to catch an integer overflow in Windows that I know of :/

[Linguica]

I kinda hope you don't backfill in with PC Doom code. Figuring out and documenting the weird changes the Jaguar Doom engine seems like it ought to be half the utility of the project.

[Quasar]

Linguica said:

I kinda hope you don't backfill in with PC Doom code. Figuring out and documenting the weird changes the Jaguar Doom engine seems like it ought to be half the utility of the project.

Well I tried putting in PC's R_RenderSegLoop for the last 3 hours and can only either A. crash the program or B. draw a single pixel strip across the screen. I cannot figure out the proper way to scale the numbers being thrown at me.

So for now, until I either have a major breakthrough eureka moment or somebody else can figure out what's wrong, I'm finished. There's nothing else I can do. I cannot fix it.

[Quasar]

Here's results from a single step of a frame at the end of DEMO1 (which desyncs for whatever reason, but that's beside the point), hoping this might help if somebody decides to take a deeper look. Everything seems fairly normal to look at until it pulls 102 out of its ass for the bottom of the column, and ends up scaling it totally incorrectly at the end of phase 6.

I've made at least 3 more passes over the assembly, and even tried modifying I_DrawColumn so that it does its own clipping; that doesn't work either.

http://pastie.org/10969288


EDIT: here's a pic of the situation when this single-step was done (the line being stepped is the linedef that is touching the left side of the screen - which, as you can see, is rendering incorrectly).

http://pasteboard.co/1VU7yaCKK.png

[SaladBadger]

Ok, I'm curious, since you know 102 is clearly wrong, do you know at least the magnitude it should be in? I tried running the faulty calculation manually using constants from your trace and from the source, and ended up with this:

Constants involved
SCREENHEIGHT = 144
CENTERY = SCREENHEIGHT / 2 = 72
HEIGHTBITS = 6
SCALEBITS = 9

variables involved
scale = 889
bottomheight = -512

faulty line:
bottom = CENTERY - 1 - ((scale * tex->bottomheight) / (1 << (HEIGHTBITS + SCALEBITS)));

72 - 1 - ((889 * -512) / (1 << 15))

-455168 / 32768 = -13

72 - 1 - -13 = 84

which feels odd since this isn't what the computer came up with (I showed my work here for a reason, in case I messed something up). In any case I have no idea if 84 is even the right value (I doubt it), but I have no idea. Assuming I didn't fuck up my work, maybe this is indicating something along the chain messing up the value of bottomheight or something?

Also, while this is unrelated, I do find it a little weird that CENTERY is defined twice in r_local.h. feels like it might hide a problem, though it doesn't seem to be in this case.

[Quasar]

InsanityBringer said:

Ok, I'm curious, since you know 102 is clearly wrong, do you know at least the magnitude it should be in? I tried running the faulty calculation manually using constants from your trace and from the source, and ended up with this:

Constants involved
SCREENHEIGHT = 144
CENTERY = SCREENHEIGHT / 2 = 72
HEIGHTBITS = 6
SCALEBITS = 9

variables involved
scale = 889
bottomheight = -512

faulty line:
bottom = CENTERY - 1 - ((scale * tex->bottomheight) / (1 << (HEIGHTBITS + SCALEBITS)));

72 - 1 - ((889 * -512) / (1 << 15))

-455168 / 32768 = -13

72 - 1 - -13 = 84

which feels odd since this isn't what the computer came up with (I showed my work here for a reason, in case I messed something up). In any case I have no idea if 84 is even the right value (I doubt it), but I have no idea. Assuming I didn't fuck up my work, maybe this is indicating something along the chain messing up the value of bottomheight or something?

Also, while this is unrelated, I do find it a little weird that CENTERY is defined twice in r_local.h. feels like it might hide a problem, though it doesn't seem to be in this case.

It should be in the neighborhood of 105-106-ish. It's off by a few pixels because the scaling goes flat once the top of the line starts to be clipped.

While it's odd there's two definitions for CENTERY, it's benign because they both evaluate to the same value. However, I don't know where you got 72 - SCREENHEIGHT is 180, so CENTERY is 90.

EDIT: I have added a pic to the previous post that illustrates the situation.

[SaladBadger]

Forgive me about the 144 thing, misread #ifndef MARS as #ifdef MARS, so used the wrong value. oops. I'll continue to dive deeper into the trace, then.

EDIT: This is probably meaningless, but I looked at your last two sample screenshots in an image editor, and I noticed if you projected the top line out past the point where it clipped, take the bit that's clipped off, and then mirror it vertically and stick it onto the bottom, if you slide down the bottom bits, you get something that's perspective correct as far as I can tell. I'm not sure how much this is helpful, but now I'm digging deeper into the clipping code. It seems almost like its supposed to compensate for those clipped off pixels somehow, but it isn't. This may just be me being silly though, given the really low resolution of the system, so it might not actually be correct while looking so. The brown wall does have a further issue on the lower bit of the wall, also. hmm

[Quasar]

Yeah it definitely should compensate, but I can't figure out how it originally worked, and I've pretty much ruled out anything being missing from the assembly in my C code. Either there's some undefined behavior in what's there, or the GPU hardware in the Jag is somehow responsible for the difference (I've tried confirming that w/o success so far).

[Quasar]

Some diagnostic shots by Kaiser, now that input and timing are working:
https://imgur.com/a/KQrDT

[kb1]

Linguica said:

CRY mode on the Jaguar basically meant that you could only use the following colors, either at full saturation or faded to black by an arbitrary amount:

http://i.imgur.com/lhtyfix.png

If you wanted any other color, you were out of luck.

Oh, ok. But, those colors are at about full saturation, so you should be able to get most colors out of it, I would think. You know, like brown is a darkened yellow. You've got all the primaries and secondaries, so, yeah, if you can darken them 0 to 100%, that's pretty much the whole range of colors.

So, if one were to find the closest color/intensity to the Doom palette, you could shade as follows:

Let's say color #100 from that CRY palette, at intensity 64, matched Doom palette #182. You could build a lookup, where entry #182 would have color 100, and div 4 (or 256/intensity 64). So, to show Doom color 182, at brightness 192 (75%), you do the lookup, and find CRY color #100, div 4. Then do brightness 192/4 = 48. Therefore, use CRY color 100 at intensity 48, which is 75% the intensity determined when the lookup was built. (This is just a guess :)

Quasar said:

I am having some pretty big problems with the renderer that I simply cannot track down. I've been back over the assembly for phases 2, 4, and 6 repeatedly, compared as much as possible to vanilla Doom and 3DO to look for differences, and tried changing some things that obviously have implementation-defined behavior (signed/unsigned mismatches mostly) without any success whatsoever.

You can see two phenomena I am dealing with in this shot:
http://pasteboard.co/KotStDzL.png

First off lines that intersect the edges of the view aren't projected correctly. It's been totally impervious to changes so far. Second, once the top of a line is clipped, the distortion gets even worse. I single stepped the rendering of a whole problem line last night and pulled out all the numbers it's calculating, and the projected height of the columns is just totally wrong for a reason I cannot see.

I am hoping some people who are good with the Doom renderer can take a look, try to run this code, and suggest some changes, because otherwise, for the time being, I have run into a dead end.

You need to compensate for the renderer not drawing the top of the wall (cause it's at a negative Y in relation to the screen). So you calculate that the wall want's to be rendered at -20 Y. You have to subtract 20 from the length, and multiply the wall scaling by 20, to make the renderer believe that it already rendered those 20 pixels.

I'd suggest checking Y against being negative (just as a test), and let it continue to render (with an if statement preventing it actually writing to the screen memory buffer at a negative Y, of course). This should make it render properly. Once that's working, you can substitute the check for negative, with the code that multiplies the texture stepper by -Y, if that makes any sense.

[Quasar]

kb1 said:

You need to compensate for the renderer not drawing the top of the wall (cause it's at a negative Y in relation to the screen). So you calculate that the wall want's to be rendered at -20 Y. You have to subtract 20 from the length, and multiply the wall scaling by 20, to make the renderer believe that it already rendered those 20 pixels.

I'd suggest checking Y against being negative (just as a test), and let it continue to render (with an if statement preventing it actually writing to the screen memory buffer at a negative Y, of course). This should make it render properly. Once that's working, you can substitute the check for negative, with the code that multiplies the texture stepper by -Y, if that makes any sense.

The problem is that the code that's there is supposed to do this implicitly, somehow, and it's not working. The top and bottom of the column are calculated from the center of the screen and have the "scale" calculated early on applied to them. I pretty much tried to do exactly what you're talking about, by deferring clipping to the column drawer and having it advance the "frac" offset into the texture properly, and this does not work either. I think there might in fact be more than one problem going on, which makes fixing any one of them much more difficult since I cannot tell that any change I make is more correct than the previous broken rendering.

[kb1]

Quasar said:

The problem is that the code that's there is supposed to do this implicitly, somehow, and it's not working. The top and bottom of the column are calculated from the center of the screen and have the "scale" calculated early on applied to them. I pretty much tried to do exactly what you're talking about, by deferring clipping to the column drawer and having it advance the "frac" offset into the texture properly, and this does not work either. I think there might in fact be more than one problem going on, which makes fixing any one of them much more difficult since I cannot tell that any change I make is more correct than the previous broken rendering.

Man, that sucks. If it were me, I'd try to figure out a way to bring up a game with a 'bad' wall in view, like load a demo, or start a certain game that has a long wall, or even hack up a level.

The point I'm making is to be able to exactly recreate a problem with, hopefully only one wall, where you're in the exact same spot and angle each time. Then, you can do some debugging on that one wall. Also, if you could back up to where the wall is just the size of the screen, check out all the vars when rendering that wall, and then move forward just a tiny bit, you should be able to check your vars then, and hopefully see the issue. In that case, Y should be 0, of course. Actually, Y should always be 0 when a taller-than-the-screen wall is visible. You only need to debug one sliver.

I might also comment out the frac fix, and just clamp the output so it doesn't crash, and see what you get. If you already have code doing the frac calc, and it's not working, either the code is wrong, or there's some code elsewhere also trying to compensate, thereby ruining the local frac fix. Can you post the render source? Another pair of eyes never hurts :)

Good luck, either way - this is an excellent idea!

[Quasar]

All the code is online at the github that's linked in the first post of this thread.

[kb1]

Quasar said:

All the code is online at the github that's linked in the first post of this thread.

Good Lord, it's in assembly! (And, I don't recognize the opcodes. What's the processor?). Anyway, I don't have time to learn a new processor ATM :). But, note that if your wall is wanting to start at -10 Y, you have to multiply frac by (-Y), or 10. I swear I think it's a flipped sign thing. Is there any sort of debug capability? Are you using an emulator? (Sorry if you've already mentioned some of this).

EDIT: Oops, disregard.

[Quasar]

None of the operative code is in assembly. The *original* Jaguar code was in assembly; I have reverse engineered it into C. Maybe you are looking at the comments instead of at the code... ?

EDIT: Progress!

http://pasteboard.co/4gZnsNELm.png

[VGA]

You can do it! Onwards, to victory!

[Quasar]

Wall and sky rendering are 100% complete!

[SaladBadger]

Neat! I am probably much more excited about this whole thing than any sane man really should be, but I really do think its a cool project. I am really curious what the fix to the problem was though, it seems like it just came out of nowhere and looking at the commit, I'm not seeing anything obvious.

[Quasar]

InsanityBringer said:

Neat! I am probably much more excited about this whole thing than any sane man really should be, but I really do think its a cool project. I am really curious what the fix to the problem was though, it seems like it just came out of nowhere and looking at the commit, I'm not seeing anything obvious.

Seems like I had some kind of brainfart when scaling the columns up for OpenGL purposes. This is now handled as a single discrete operation instead of scaling each column individually.

[Gez]

So the problem wasn't in the transcription of the Jaguar drawing code, but in the interface between the renderer and the actual display?

[Linguica]

Quasar said:

Wall and sky rendering are 100% complete!

http://eternity.mancubus.net/pics/calico_walls_complete.png

Nice.

[axdoomer]

Quasar said:

Wall and sky rendering are 100% complete!

http://eternity.mancubus.net/pics/calico_walls_complete.png

I'm excited like a kid in front of Christmas presents. Will it run on Linux?

[kb1]

Quasar said:

None of the operative code is in assembly. The *original* Jaguar code was in assembly; I have reverse engineered it into C. Maybe you are looking at the comments instead of at the code... ?

Yeah, that's what the "Oops, disregard" was about :)

Quasar said:

EDIT: Progress!
http://pasteboard.co/4gZnsNELm.png

Wow! Beautiful. Great job, as always!

[Quasar]

axdoom1 said:

I'm excited like a kid in front of Christmas presents. Will it run on Linux?

It's been written portably; I haven't added POSIX backend code yet just out of laziness.