Main Menu

Cpct?

Started by AGP, September 16, 2019, 06:45:59 PM

Previous topic - Next topic

AGP

Now that even Excelsior Jet has been made extinct, how would you feel about making a c# version of jpct? At least the OpenGL bits would be better.

EgonOlsen

Well, I'm not interested in C# at all. As long as I don't have to use it (and I don't see why that would happen), I won't touch it.

AGP

#2
Even with the Mono project (and, thus, being multi-platform)? How come? Now that there's no way to make machine code out of Java, I think that I may go with C#.

EgonOlsen

I looked into it briefly, I found it like Java with some additional clutter on top, that doesn't really make it any better and it's Microsoft. I have nothing against Microsoft, but the community is strange. Whenever I had to deal with the community of a Microsoft product (the scripting language in Powershell is an example where I had to rely on it, VBA for Access another), it's somehow disappointing...I've noticed a pattern:


  • Java community: You usually get a solution or at least an idea pretty quickly. Sometimes is overly complicated, because Java people tend add layers of libs on top of each other, but you can ignore that most of the time.
  • Javascript community: Similar to Java, actually. Just more unorganized and more focused on the latest hot shit (i.e. not older than 2 weeks).
  • PHP community: You usually get a soution, but it often feels awkward and clunky, just like the language itself.
  • Microsoft community: One question, multiple solutions but none refers to the actual quesiton. But obviously that doesn't matter, because the poster of the question thanks them anyway.

AGP

I have found every question I've ever had already asked and answered. I hope to be able to show something in the next few days.

AGP

I'm stuck in the FrameBuffer pixels thing. I found a way to do pretty much the same thing (https://stackoverflow.com/questions/1563038/fast-work-with-bitmaps-in-c-sharp), but pixels[] is too entrenched in the code.

AGP

Software renderer is compiled and running (not drawing anything yet, though).

AGP

I even ported the loader. Everything's working except for the actual rendering (when I don't assign random colors to the polygons in SoftGLRenderer). In clearSoftware(Color col), I'm printing this: Logger.log("Coloring. Color: "+color +", Col: "+col.ToArgb());

And the result is: Coloring. Color: 16711680, Col: -65536

Could this be a byte order thing or is it just because the first integer doesn't hold the alpha?

AGP

Sure enough replacing pix=color; with pix=col.ToArgb(); started clearing. I'm now getting unshaded, untextured objects rendered against the appropriate color. Is my line much slower than your bit-shifting?

EgonOlsen

It's certainly slower. I'm not sure from where exactly this code snippet comes!? Is it inside the rendering loop or some loader/setup code. In case of the former, it might be critical.

AGP

It's in clearSoftware(Color).

EgonOlsen

I see. In that case, just move the call to col.ToArgb() out of the loop and assign the result, so that you don't have to do it thousands of times for frame.

AGP

Done. But if the clear color was wrong, doesn't it follow that the texture-rendering stuff would be, as well (hence the unshaded sillouettes)? Put differently, where do I find the perspective-correct texture code in which to look for this issue?

EgonOlsen

In the SoftGLRenderer.

AGP

It's a bit hairy for me, since I don't really know what you're doing, but from what I gather alpha should be 24 bits shifted LEFT, red shifted 16 left, and so on. Is this line (under OptiZ) wrong (green is shifted by 8, then the whole thing gets shifted by 16)?
g=(((col>>8)&255)*(sgI>>10))>>16;