Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 28
  1. #11
    Graphic programming enthusiast Narann's Avatar
    Join Date
    Jan 2010
    Posts
    86
    Mentioned
    0 Post(s)
    Hi weinerschnitzel, I agree, a RenderBase refactor would be great. Actually, I'm starting to draw how class work and how they could work even better. I wonder if "RenderBase" C functions could be merged in the Render class.

    For now we have:

    DL_Parser functions (parse the dword commands) send raw result to -> RenderBase functions (convert the raw values to "renderable stuff", e.g.: uint8 colors to float) -> call Render abstract class.

    RenderBase work with a lot of global "used anytime everywhere" variables.

    But organize RenderBase would improve general code consistency.

  2. #12
    Moderator death--droid's Avatar
    Join Date
    Feb 2008
    Posts
    1,337
    Mentioned
    14 Post(s)
    Got to agree with weinerschnitzel, the RenderBase needs one hell of a refactor... keep trying to find something to distract me when I have a look at it. DL Parser isnt actually to bad

  3. #13
    Graphic programming enthusiast Narann's Avatar
    Join Date
    Jan 2010
    Posts
    86
    Mentioned
    0 Post(s)
    Ok so as you guys have already read the RenderBase "function set" here is my advise, please feedback:

    • RenderBase was a bunch of function "related to render". Some where just "set this to the gRDP struct" some where more "utilities" (inline ViewPortTranslatef_x which transform a viewport pixel position to a float equivalent) and some where highly important (InitVertex(), PrepareTriangle(), ProcessVertexData() etc...). Notice this last one are ca
    • Trying to understand what was the initial author intention I think the gRDP and gRSP struct was supposed to be encapsulate into the RenderBase (InitRenderBase() init all the gRDP and gRSP).


    I suggest:
    • Separate the RDP getter/setter RSP getter/setter in both distinct classes. This classes will encapsulate the gRDP and gRSP. In the future, this both struct could disappear replaced by .
    • Then have a RenderBase class that gather all the rest.
    • Then, anything in RenderBase which is not uniquely called by the parser (e.g.: ViewPortTranslatef_x) is put in a more appropriate class (Render in this last case).

  4. #14
    Graphic programming enthusiast Narann's Avatar
    Join Date
    Jan 2010
    Posts
    86
    Mentioned
    0 Post(s)
    lol Yesterday I was starting to read how I would refactor RenderBase code and realize there is ton of (from my investigation) useless code.

    I've removed the PostProcessSpecularColor (which do nothing) and PostProcessDiffuseColor. This both function work in a totally old way. I explain: This functions get a vertex and modify the color depending on Color Combiner parameters. It take time to me to understand what's the point as my ColorCombiner use only the vertex color before the PostProcess modifications. And I realize this are just bunch of old code when their was no other way to do (OpenGL 1.x)... Each time I dig in such code, I'm very impressed by all the massive work that have been done to provide this because their was no other way to do. Compared to how things are easier now. Anyway, I removed all this PostProcess stuff and realize a lot of code could be trash away with them.

    This open some doors to what could be removed safety. My next big remove should be the "GeneralCombiner". I have investigate a little and how this work is totally crazy and genius (even if totally useless now). But if this code is removed, other code directly related could follow!

    Notice I use the regression test tools avaible in the mupen64plus-core each time I do a commit and for now, except some alpha erode (I know where this problem came, sometime it provide better results than before, sometime not) I still get the same results than before so any code remove doesn't massively break things.

    So no RenderBase refactor yet, still removing old deprecated code.

    PS: The current way Rice deal with specular "seems broken". It give a specular but as if the specular light where on camera position and it's very shiny. Reading through the doc it's hard to get how the specular is actually computed, more investigation/debug is needed.

  5. #15
    Moderator death--droid's Avatar
    Join Date
    Feb 2008
    Posts
    1,337
    Mentioned
    14 Post(s)
    Damnnnnn I had been staring at those PostProcessSpecularColor code for so long and never realised its pretty much useless >.< and yeah got to agree that the things Rice had to jump through to get things working on older systems :\ and how much API's have come since then.
    Thanks to this finding all this no longer used code
    Last edited by death--droid; July 29th, 2014 at 12:41.

  6. #16
    Moderator Clements's Avatar
    Join Date
    Feb 2003
    Location
    UK
    Posts
    5,510
    Mentioned
    1 Post(s)
    I believe some of the code was to help people with Geforce 2 and Geforce 4 MX cards back in the day, as Rice tried to make his plugin as compatible with low-end hardware as possible. Glad to hear that it is still being worked on and updated to the modern age without worrying much about legacy stuff.

  7. #17
    Graphic programming enthusiast Narann's Avatar
    Join Date
    Jan 2010
    Posts
    86
    Mentioned
    0 Post(s)
    @death--droid: look at the PostProcessDiffuseColor and look at what vertex color is actually used by the GPU and you will realize PostProcessDiffuseColor "path" has no impact on vertex color. So you remove PostProcessDiffuseColor. Removing PostProcessDiffuseColor you realize there is a lot of function in it, so you remove this functions, and if you do it well, you should also realize IColor.h is totally useless as it is only "really" used in a GetColor() function that use the demuxed combiner modes to return the color the combiner will use, and GetColor is used by one of the function used in PostProcessDiffuseColor...

    After this, you have another door to totally remove the GeneralCombiner (and it's impressive CombinerTable that, if you follow how its use, make you understand how brilliant was the author).

    Yeah... I often feel like a spelunker digging into old code no one want to touch anymore and finding some treasures (even if the finality is to remove them...).



    @Clements: I must admit I feel a little inglorious when I do the "git rm" command on all this massive files that are not usefull anymore. All this impressive hack and tricky code. I read them, trying to understand them and think: Damn so brilliant! And the file is plenty of stuff like this? So many hours of work! My general programming knowledge push up since I do that. About legacy, mupen64plus-video-rice was dying so I need this refresh. I don't wan't to frustrate peoples and I think OpenGL 2.1 is a good compromise (My 32bits 2008 Intel 965GM chipset is OpenGL 2.1 so I have myself a tiny computer).

    PS: I just found why Top Gear Rally had bad texts:



    I was thinking it was UV troubles because Rice has a lot of troubles with UVs (and dig into UVs, aspect ratio, realize TopGearRally actually create a FrameBuffer of 1280x480...) but this was not that and it's my Color Combiner... For a unknown reason (bad demux? It seems unlikely...) the tex0 color (the one with letter color pixels) is not used in the GLSL shader program (generated from the combiner mode dwords) responsible of text draws. And I have no idea to look in. A high debug will be needed (or a simple hack if(GAMEISTGR) but I hate that).

  8. #18
    Moderator death--droid's Avatar
    Join Date
    Feb 2008
    Posts
    1,337
    Mentioned
    14 Post(s)
    Awesome thanks for the heads up for that!!

    BTW if your keen on writing a new color combiner I would take a good look into pixel shaders, it should simplify the whole entire process, something gonetz also is doing with his latest plugin. DirectX version of Rice Video also makes good use of it so I would check out that as well.

  9. #19
    EmuTalk Member
    Join Date
    Jul 2014
    Posts
    5
    Mentioned
    1 Post(s)
    Sorry that this is a bit late, but yes, I didn't notice any missing triangles near the camera, so all is good in Nvidia land. Anything you are looking to see on other hardware?

  10. #20
    Graphic programming enthusiast Narann's Avatar
    Join Date
    Jan 2010
    Posts
    86
    Mentioned
    0 Post(s)
    The Top Gear Rally bug drive me crazy! The SetCombiner dwords are properly demuxed (I've compared with the old way and Glide64 code) but Top Gear Rally seems to send the Texel1 at the place the Texel0 is supposed to be. I guess there is a bug in the way my ColorCombiner is generating the GLSL code.

    death--droid: I will defenetely look at it and see how you generate your pixel shader code! I really hope I will find why mine create this problem (on this specific game!)

    darkjack: Thanks! About TGR, I'm almost sure you will have the problem too but as you ask: Could you test Top Gear Rally (and maybe other Top Gears) to see if the text bug still appear? If you can save me and said: It's OK!

    If everything seems ok on my ColorCombiner, I will have do a hack in the SetCombiner demux part (Rice actually had a lot of hack just after demuxing Combiner dwords).

    For any N64 guru: Reading the doc I realized N64 vertices can have one and only one texture coordinate per vertex. In Rice there is two. I really wonder if it's still needed as ColorCombiner never use the second.

Page 2 of 3 FirstFirst 123 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •