BlazingRenderer / BRender

Modernized fork of BRender
MIT License
49 stars 5 forks source link

Really dark output #19

Closed Arcnor closed 1 year ago

Arcnor commented 1 year ago

Hi,

I've been running the robot demo as well as others and the output is really dark, not sure if that's intended or not.

robot_4qnn0JeEch

This is supposed to be a completely white cube, but still, it's just almost black.

brtutor1_T1Tyv7Pohw

Changing the light attenuation from 1.0 to 0.1 or something similar makes the object visible, but I'm sure it should work with the default values, like the original DOS version. Any idea what the problem is? I've tried on multiple machines (Windows & macOS) just in case, but I get the same result.

vs49688 commented 1 year ago

Could you please post some screenshots of what it's meant to look like with different values? I've been meaning to fix this, but haven't had a reference to compare against.

What type of light is this? Directional, using the "default" attenuation values (constant, linear, quadratic) of (1, 0, 0) (and intensity = 1/c = 1)?

I've had a stab at this in the past (comparing to renders of other engines), but fixing it causes Croc's lighting to break badly. @crocguy0688 might be able to shed some light (heh) on this.

Arcnor commented 1 year ago

I actually cannot, unless you mean taking the input from the DOS version, which I can do (although it's from v1.2 AFAIK and it has a logo on the corner, and the light itself looks completely different, so I'm not sure if the code matches 100%)

dosbox-x_AaGCfCszvt

For the box, I've just ported the tutorial programs from BRender, but there are no compiled versions that I've seen, I might compile it on DOS at some later date to test more.

I also assumed it had something to do with Croc (by the way, I've tried looking for the Croc repository but couldn't find it anywhere, I'm assuming it's been kept private for some reason?).

vs49688 commented 1 year ago

In the meantime, if you comment out all the BrEnableLight() calls it should be fullbright, which at least should allow you to see things.

I actually cannot, unless you mean taking the input from the DOS version, which I can do (although it's from v1.2 AFAIK and it has a logo on the corner, and the light itself looks completely different, so I'm not sure if the code matches 100%)

dosbox-x_AaGCfCszvt

For the box, I've just ported the tutorial programs from BRender, but there are no compiled versions that I've seen, I might compile it on DOS at some later date to test more.

Can you post a link to the tutorial programs? I'd like to do proper ports of them to supplement this repo, and it would be good to have "original" programs to compare against.

I also assumed it had something to do with Croc (by the way, I've tried looking for the Croc repository but couldn't find it anywhere, I'm assuming it's been kept private for some reason?).

It's private until permission is given to release it.

Arcnor commented 1 year ago

In the meantime, if you comment out all the BrEnableLight() calls it should be fullbright, which at least should allow you to see things.

Yeah, I know, but I wanted to get "correct" output of course :).

I actually cannot, unless you mean taking the input from the DOS version, which I can do (although it's from v1.2 AFAIK and it has a logo on the corner, and the light itself looks completely different, so I'm not sure if the code matches 100%)

dosbox-x_AaGCfCszvt

For the box, I've just ported the tutorial programs from BRender, but there are no compiled versions that I've seen, I might compile it on DOS at some later date to test more.

Can you post a link to the tutorial programs? I'd like to do proper ports of them to supplement this repo, and it would be good to have "original" programs to compare against.

I can share the ports I've created, most of them "do something" but none work reliably, so maybe it will be useful to fix a bunch of bugs, so I'll push them to a fork in a bit.

As mentioned I cannot provide screenshots of how they are supposed to look, though, until I can build the original on DOS, but I'll let you know if I manage to get that working. (I was actually trying to get the software renderer working again on this repo, but I'm having a bit of trouble with that, the internals are a bit confusing :D).

I also assumed it had something to do with Croc (by the way, I've tried looking for the Croc repository but couldn't find it anywhere, I'm assuming it's been kept private for some reason?).

It's private until permission is given to release it.

Yeah, that's what I thought. Have you talked with Jez San? He might be happy to get it out, like he did with BRender, but in any case I really appreciate that at least this BRender port is public :).

Arcnor commented 1 year ago

Added my changes in #20 , I hope they're useful. Let me know if you need anything else.

vs49688 commented 1 year ago

As mentioned I cannot provide screenshots of how they are supposed to look, though, until I can build the original on DOS, but I'll let you know if I manage to get that working. (I was actually trying to get the software renderer working again on this repo, but I'm having a bit of trouble with that, the internals are a bit confusing :D).

Oh wow, on 32-bit windows, I hope? It probably won't work on anything else. That's a mammoth task.

How were you planning on doing it? Iirc, it wrote directly to DirectDraw surfaces, would you be replacing those with SDL_surfaces, or straight onto an OpenGL framebuffer?

The internals should be roughly the same. I attempt to clarify things if required - I've spent wayyyy too much time on this engine.

There was one change change that would break things majorly - the name field was added to br_tv_template_entry, which breaks all the structure template definitions. The fix here is adding a , NULL after the first BRT_* field.

static const br_tv_template_entry GLSTATEI_CullTemplateEntries[] = {
    {BRT_TYPE_T,  NULL, F(cull.type),  Q | S | A, BRTV_CONV_COPY, 0, TM_PART | TM_INVALID_CC},
    {BRT_SPACE_T, NULL, F(cull.space), Q | S | A, BRTV_CONV_COPY, 0, TM_PART | TM_INVALID_CC},
};

I also assumed it had something to do with Croc (by the way, I've tried looking for the Croc repository but couldn't find it anywhere, I'm assuming it's been kept private for some reason?).

It's private until permission is given to release it.

Yeah, that's what I thought. Have you talked with Jez San? He might be happy to get it out, like he did with BRender, but in any case I really appreciate that at least this BRender port is public :).

@crocguy0688 did, but got no clear response.

Arcnor commented 1 year ago

As mentioned I cannot provide screenshots of how they are supposed to look, though, until I can build the original on DOS, but I'll let you know if I manage to get that working. (I was actually trying to get the software renderer working again on this repo, but I'm having a bit of trouble with that, the internals are a bit confusing :D).

Oh wow, on 32-bit windows, I hope? It probably won't work on anything else. That's a mammoth task.

Well, it didn't look like much, but maybe because I ported the wrong driver, which was called softrend and only had 3 assembly files. However, I saw that there is yet another driver called pentprim which also seems to be a software renderer? I got a bit list at that point to be honest, but softrend seems to compile just fine now.

How were you planning on doing it? Iirc, it wrote directly to DirectDraw surfaces, would you be replacing those with SDL_surfaces, or straight onto an OpenGL framebuffer?

Idea was just to draw directly to an SDL_Surface, I doubt anything else would be needed even if performance is not the best, which will hardly matter in this case.

The internals should be roughly the same. I attempt to clarify things if required - I've spent wayyyy too much time on this engine.

For some reason a lot of things have changed between this one and 1.3? All those BR_METHODs seem to take different parameters now, but maybe this is best discussed in chat instead of here, lots of explanation to do.

There was one change change that would break things majorly - the name field was added to br_tv_template_entry, which breaks all the structure template definitions. The fix here is adding a , NULL after the first BRT_* field.

static const br_tv_template_entry GLSTATEI_CullTemplateEntries[] = {
    {BRT_TYPE_T,  NULL, F(cull.type),  Q | S | A, BRTV_CONV_COPY, 0, TM_PART | TM_INVALID_CC},
    {BRT_SPACE_T, NULL, F(cull.space), Q | S | A, BRTV_CONV_COPY, 0, TM_PART | TM_INVALID_CC},
};

I also assumed it had something to do with Croc (by the way, I've tried looking for the Croc repository but couldn't find it anywhere, I'm assuming it's been kept private for some reason?).

It's private until permission is given to release it.

Yeah, that's what I thought. Have you talked with Jez San? He might be happy to get it out, like he did with BRender, but in any case I really appreciate that at least this BRender port is public :).

@crocguy0688 did, but got no clear response.

That's unfortunate, he seemed pleased when he allowed BRender to be opened, hopefully he can do the same for Croc one day, even if he wants to remake it one day...

vs49688 commented 1 year ago

I think this is fixed by https://github.com/crocguy0688/CrocDE-BRender/commit/4940b1415096fb65738688f0e2b140fd562f3523, can you please verify?