Page 6 of 6

Re: The Sonic Decompilations Megathread.

Posted: Mon Feb 01, 2021 7:52 pm
by Ian Micheal

Code: Select all

8:31 PM] ian micheal:
KOS Vram Usage
Post by PH3NOM ยป Thu Oct 06, 2016 2:54 pm

Whats up guys?

As my game has been increasing in size and complexity, I have been finding more ways to squeeze out performance of the system.

Recently, I realized that I had gotten to the point where I was sending more vertices than my pvr vertex buffer could support, and needed to increase the Vertex Buffer Size on PVR initialization.

Problem is, once I did that, I ran out of texture memory, and was afraid I would have to decrease textures quality to get everything to fit.

But first, I started digging around in KOS to look at how the Vertex Buffers were allocated, and I noticed a few questionable comments:
on pvr_buffers.c:
Line 234:
CODE: SELECT ALL

        outaddr += buf->opb_size;   /* Do we _really_ need this twice? */
So I simple commented that line out

and Line 245:
CODE: SELECT ALL

        /* XXX What the heck is this 0x50580 magic value?? All I
           remember about it is that removing it makes it fail. */
        buf->opb_size = 0x50580 + polybuf;
I made some testing an arrived at
CODE: SELECT ALL

        buf->opb_size = 0x14160 + polybuf;
On a default pvr_init_defaults, the original code gives us 4,626,688 bytes of Texture Memory Available.
With my new changes to pvr_buffers.c, pvr_init_defaults gives us 5,855,232 bytes of Texture Memory Available.

With this change, I was able to increase my Vertex Buffer size, without having to sacrifice Texture Quality.

Just posting this so see if I am missing something here, I have ran many tests on real hardware, and I can see no adverse effects, only more VRAM available.
[8:33 PM] ian micheal: It seems like i learn a lot from  PH3NOM  these days but this was amazing to me since ti works and you get  With His new changes to pvr_buffers.c, pvr_init_defaults gives us 5,855,232 bytes of Texture Memory Available. so kos your using On a default pvr_init_defaults, the original code gives us 4,626,688 bytes of Texture Memory Available.... Not seen a problem with this change only more vram

Re: The Sonic Decompilations Megathread.

Posted: Mon Feb 01, 2021 8:15 pm
by dcsteve
Absolutely amazing Ian. Your coding skills are on a whole another level compared to 10 years ago!!

Re: The Sonic Decompilations Megathread.

Posted: Mon Feb 01, 2021 8:17 pm
by Ian Micheal
dcsteve wrote:Absolutely amazing Ian. Your coding skills are on a whole another level compared to 10 years ago!!
You would hope so steve lol I got it built I'm not sure it work anyways it's untested but i got it to build anyways..

Src is there since it builds it should be easy for others to work on..


I would rather the SDL1.2 build and optimize that because i have that and opengl working very well..

Re: The Sonic Decompilations Megathread.

Posted: Tue Feb 02, 2021 8:52 am
by Ian Micheal
well it does try to run but this
--
KallistiOS Git revision v2.0.0-301-ga449e93-dirty:
Thu Jan 21 00:39:45 EST 2021
dogbox2@dogbox2-PC:/opt/toolchains/dc/kos
RetroVM Startup
Requested sbrk_base 0x8d02f000, was 0x8cf2f000, diff 1048576
kernel panic: out of memory; about to run over kernel stack
first thing straight away lack of ram system ram so 1 mb to less to start

Re: The Sonic Decompilations Megathread.

Posted: Tue Feb 02, 2021 5:53 pm
by Anthony817
Is that the version you were trying to get working with SDL 1.2 or the Sappharad source version that is running out of memory?

Re: The Sonic Decompilations Megathread.

Posted: Tue Feb 02, 2021 6:10 pm
by Ian Micheal
Anthony817 wrote:Is that the version you were trying to get working with SDL 1.2 or the Sappharad source version that is running out of memory?
Sappharad source version dc pre release src

Re: The Sonic Decompilations Megathread.

Posted: Tue Feb 02, 2021 7:17 pm
by Anthony817
Ah ok figured so. Well keep us updated if you have some breakthroughs.